A marketplace platform reaching $10M GTV faces a payment architecture inflection point. The stack that worked at $1M, a single payment gateway, manual seller payouts, and FX handled by the bank, starts showing structural cracks. Approval rates vary by country without any clear explanation. Payout reconciliation that should take hours takes three days. The engineering team is maintaining four separate integrations instead of one.

Each failure mode is manageable in isolation. Collectively, they signal something more significant: an architecture built reactively, one short-term fix at a time, that solves the immediate problem while creating the ceiling at $50M.

This guide is for the CFO and CTO making architecture decisions together. It covers the three layers every cross-border marketplace payment solution requires, the compliance obligations a marketplace must own versus outsource, and what a best-in-class stack looks like in practice. The goal is decisions that are financially sound and technically defensible at the scale you are aiming for, not just the scale you are at.

Most payment architecture problems at marketplace scale trace back to the same root cause: the three core functions of a marketplace payment stack, accepting buyer payments, disbursing seller payouts, and managing treasury and FX, are handled by separate systems that were never designed to work together. Each layer has distinct requirements. The architecture decision with the highest long-term impact is whether all three sit on a single platform or a patchwork of providers.

Buyers need to pay in their local currency using their preferred local payment method. A marketplace operating simultaneously across Southeast Asia, Europe, and North America cannot treat Visa and Mastercard as complete payment method coverage. Those two networks are the floor. A buyer in the Netherlands expects iDEAL. A buyer in Singapore expects GrabPay. European B2B buyers expect SEPA. US customers expect ACH. Each unmet expectation is a lost transaction.

The requirements for this layer are: local payment method support per market (30 or more methods for a platform operating across major global regions), multi-currency settlement, 3DS2 for fraud reduction, and intelligent transaction routing for approval rate optimisation. That last requirement carries direct commercial weight. The same card declined at one acquirer may be approved at another. A cross-border payment gateway with direct acquirer relationships in your target markets routes each transaction to the acquirer most likely to approve it, lifting approval rates meaningfully at scale.

Build on a provider with direct acquirer relationships in your target markets, not one routing transactions through regional intermediaries.

Intermediary routing adds latency, increases decline rates, and introduces an additional FX conversion at each hop. Direct acquirer relationships produce faster settlement, higher approval rates, and cleaner reconciliation.

Sellers need to receive their earnings in their local currency, via their preferred payment method, on a predictable schedule. For a marketplace with sellers across 40 countries, this is a separate and non-trivial infrastructure challenge from the pay-in layer. A credible marketplace payout solution covers far more than SWIFT wire transfers.

The requirements for this layer are: payout coverage across 60 or more countries, local rail access rather than SWIFT wherever available (SEPA in Europe, ACH in the US, FPS in the UK, UPI in India), automated payee onboarding with built-in KYC, and real-time reconciliation. Local rails matter because SWIFT is slower and more expensive than domestic transfer networks, and sellers in markets with strong local rail infrastructure expect domestic payment timelines.

The operational cost of manual payout management compounds quickly. At 500 active sellers across 20 countries, reconciling payouts across separate systems without automation is a substantial finance team burden. At 5,000 sellers, it is unmanageable without dedicated headcount.

Payout infrastructure should sit on the same platform as acceptance infrastructure, not with a separate provider.

Splitting acceptance and payouts across two providers creates FX double-conversion: the marketplace pays conversion once when funds are received in the acceptance currency, then again when funds are disbursed in the seller's local currency. A unified platform applies one conversion at a transparent rate and presents all flows in a single data model.

The marketplace itself holds funds between the moment of acceptance and the moment of payout. The currency conversion applied to those funds, and the timing of that conversion, is a financially material decision. At significant GTV, a 0.5% difference in FX pricing compounds into a meaningful annual cost. A multi-currency payment gateway that applies a default bank spread to every conversion without transparency is not a treasury solution. It is a cost centre with no visibility.

The requirements for this layer are: transparent FX pricing at mid-market or near-mid-market rates rather than an automatically applied bank spread, multi-currency wallet capability to hold balances across currencies and choose the conversion timing, and configurable settlement timing to allow the marketplace to manage currency exposure rather than converting at the moment the provider finds convenient.

A unified infrastructure handling all three layers through one API eliminates FX leakage and reconciliation friction.

Each additional provider in the stack introduces at least one FX conversion event and one reconciliation boundary. A three-provider stack can apply FX charges to the same funds three separate times. One API means one conversion, one data model, and one commercial relationship to manage.

Marketplaces are not neutral intermediaries for payment purposes. Depending on structure and operating jurisdiction, a marketplace may be classified as a payment institution, which carries its own licensing and reporting obligations. Understanding the boundary between what your infrastructure partner carries and what you retain is not a legal nicety. It is an operational requirement.

A best-in-class infrastructure partner should handle the following on behalf of the marketplace: KYC and KYB screening for sellers during onboarding, AML transaction monitoring, chargeback management workflows, and PCI-DSS compliance for all cardholder data. These are legal requirements for operating a marketplace payment flow in most regulated jurisdictions. They also require ongoing investment to maintain. Delegating them to an infrastructure partner with the scale and regulatory expertise to execute them well is the correct division of labour.

The marketplace retains responsibility, regardless of infrastructure choice, for: enforcing its own terms of service, making platform-level fraud policy decisions, and completing any market-specific regulatory filings required if the marketplace itself holds user funds directly. These decisions require commercial and legal judgement specific to the marketplace's business model and cannot be delegated.

The practical shortcut for a scaling marketplace is to work with an infrastructure partner holding direct regulatory licences in its operating markets. A partner licensed by the FCA in the UK and by MAS in Singapore means the payment flows in those markets operate under regulated infrastructure. The marketplace benefits from that regulatory coverage without needing to obtain its own payment institution licence in each jurisdiction, a significant cost and time advantage for a platform expanding across multiple regulated markets simultaneously.

The architecture principles above translate into a concrete end state. An embedded payments platform built for global marketplace scale has five characteristics that distinguish it from a collection of point solutions stitched together over time.

Single integration point. One API for acceptance, payouts, and FX management rather than four separate integrations maintained by the engineering team. Adding a new market or enabling an additional payment method becomes a configuration change, not a new integration project.

Local payment method coverage in every market. 170 or more payment methods available through that single integration, not separate regional provider relationships negotiated market by market. Coverage that keeps pace with buyer expectations in every geography the marketplace enters.

Automated seller onboarding. Sellers submit banking details and compliance documents through a white-labelled portal. KYC and KYB validation runs automatically rather than through a manual review queue. The compliance bottleneck that limits seller acquisition at scale is removed from the critical path.

Unified reconciliation. One data model across all payment flows: acceptances, payouts, FX conversions, chargebacks, and refunds. The CFO has a single source of truth. The finance team is not manually reconciling across systems with different settlement timelines and different data structures.

Dedicated enterprise support. A named account management team with defined escalation paths, not a ticket queue. For a marketplace at $50M to $100M GTV, a payment infrastructure issue is an operational crisis. A support structure built for that reality is a commercial requirement, not an optional extra.

Onerway is the infrastructure partner built for this architecture: global market coverage, direct regulatory licences including FCA and MAS, a unified API spanning acceptance, payouts, and FX, and dedicated account management for enterprise clients. The full capability is accessible through a single integration. More at onerway.com.

The architecture decisions made at $10M GTV determine what the business can accomplish at $50M. A stack built from separate providers, each optimised for its own layer without reference to the others, accumulates FX leakage, reconciliation overhead, and integration debt that compounds as transaction volume grows.

A unified platform covering acceptance, seller payouts, and FX management through a single API is both the technically correct and commercially sound choice for a marketplace building toward enterprise scale. Onerway is built to that requirement: institutional depth, direct regulatory licences, a unified API, and dedicated support that treats payment infrastructure as a strategic asset.

If any of this resonates with a challenge your business is navigating, our team welcomes a direct conversation.

Onerway's unified payment API is purpose-built for global marketplace platforms, covering acceptance, seller payouts, and FX management in a single integration across 170+ payment methods and 60+ countries.

If you're at a platform inflection point, our team can review your current architecture and map what a consolidated stack would look like for your specific markets.

A cross-border marketplace needs three integrated layers: a pay-in layer that accepts local payment methods across all buyer markets, a payout layer that disburses funds to sellers in their local currencies via local rails, and a treasury layer that manages FX conversion and settlement timing. These three layers are most efficient on a single platform. Running them across separate providers introduces FX double-conversion, reconciliation complexity, and integration overhead that compounds with transaction volume.

The most scalable approach uses a payout infrastructure that supports local payment rails (SEPA, ACH, FPS, UPI) rather than routing all disbursements through SWIFT, which is slower and more expensive than domestic transfer networks. Automated payee onboarding with built-in KYC removes the manual compliance bottleneck that limits seller acquisition at scale. A platform that handles payouts and acceptance under one API also eliminates the FX double-conversion that occurs when the two functions run through separate providers.

A marketplace is not a neutral intermediary: depending on its structure and operating jurisdiction, it may be classified as a payment institution, which triggers licensing and reporting obligations. Working with an infrastructure partner holding direct regulatory licences (such as FCA in the UK or MAS in Singapore) means the payment flows in those markets operate under regulated infrastructure, reducing the compliance burden on the marketplace. The marketplace retains responsibility for its own terms of service enforcement, fraud policy decisions, and any local regulatory filings required if it holds user funds directly.

FX leakage occurs when funds pass through multiple conversion events, each charged at a spread above the mid-market rate. A three-provider stack applying conversion at acceptance, at the platform treasury, and at payout can charge FX three times on the same funds. The solution is a unified platform applying a single transparent conversion at a near-mid-market rate. Configurable settlement timing also allows the marketplace to manage currency exposure rather than converting at the default moment set by the provider.

The inflection point typically arrives around $10M GTV, when approval rate inconsistencies across markets, multi-day payout reconciliation, and multi-provider integration maintenance start generating measurable operational cost. A unified platform makes financial sense when the combined cost of FX leakage, engineering maintenance, and finance team reconciliation effort exceeds the migration cost. For most marketplaces scaling toward $50M GTV, that calculation favours consolidation significantly earlier than most teams make the move.