Your selected path

Global business payments

Run multiple gateways and processors. Offer relevant local payment methods. Test provider performance and cost, reconcile settlements, optimize FX and make decisions from one reporting hub.

Illustrative example · Not a prescribed provider stack

Multiple markets. Multiple providers. One operating view.

This is an example of a global payment setup, not a recommendation or a live integration. Offer local payment methods by geography and use a smart routing engine to select among eligible payment gateways and processors. Provider names below illustrate regional options; every route still needs the right account, method and currency support.

Global checkout, vault and routing to regional providersThree stages follow the supplied sketch: local payment-method checkout, supported card and payment references in a vault, and rules-based routing to eligible providers. Regional examples are Stripe and Authorize.net in the US, Adyen and Worldline for UK and EU evaluation, and dLocal, Kushki and EBANX in Latin America. Wallets, SEPA and Pix are methods or rails, not gateways. Availability and account eligibility must be checked.CheckoutMethods matched to geographyVault / reference layerSupported cards + referencesRouting engineSelect an eligible providerUSStripe · Authorize.netUK / EUAdyen · WorldlineLatin AmericadLocal · Kushki · EBANXIllustrative route map. One eligible route per attempt; not simultaneous charging.
  1. Checkout: show eligible local methods based on market and customer context.
  2. Vault / reference layer: store supported card credentials or permitted method references, not every payment method in the same way.
  3. Routing engine: choose an approved provider using transaction attributes and account capability.
Provider execution and authentication occur through the selected integration. Bank-payment authorizations and wallet tokens may have their own flows; not every method passes through a card vault or shares a portable token.

Smart routing: eligibility first, performance and cost next

  • Transaction currency
  • Merchant entity / MID
  • Issuer / BIN country
  • Card network + funding type
  • Payment method
  • Recurring eligibility
  • Authentication requirements
  • Cost + availability

United States

Provider candidates
Stripe · Authorize.net
Methods
Cards · Apple Pay · Google Pay
Authentication
3DS for eligible card flows. Qualifying authentication may shift fraud-dispute liability, not every dispute. Wallet authentication and liability treatment are separate; do not assume a wallet requires another 3DS challenge.

United Kingdom / European Union

Provider candidates
Adyen · Worldline
Methods / rails
Cards · eligible euro SEPA payments
Authentication + scope
Use 3DS for card authentication where required or appropriate. SEPA is a euro bank-payment scheme, not a GBP rail or a card authentication flow. The UK is in SEPA’s geographic scope, but bank participation, account eligibility and provider support still matter. SEPA Direct Debit requires a mandate.

Latin America

Provider candidates
dLocal · Kushki · EBANX, by supported country and method
Brazil recurring example
Pix Automático: recurring payments with prior payer authorization.
Coverage
Pix is Brazil-specific, not a LATAM-wide method. Check current merchant eligibility and recurring integration support. The provider shortlist does not imply all three support every Brazilian recurring flow.

Keep provider selection separate from payment-method selection. A gateway or processor is not a wallet or payment rail. Confirm country, currency, underwriting, account and method support before enabling any route. Authentication does not guarantee approval or remove all liability.

Primary sources and implementation checks
The operating loop

Connect. Test. Reconcile. Improve.

Multi-provider coverage is the starting point. The value comes from measuring what each route delivers, then changing the next decision.

01 · Coverage

Multiple gateways, processors and local methods

Build an approved provider portfolio by country, entity and currency. Show relevant local payment methods by customer geography and payment context, not the same list in every checkout.

Track: method usage, checkout completion and eligible market coverage.

02 · Route + experiment

A/B test payment service providers

Use the smart routing engine to split comparable eligible traffic between providers. Hold market, issuer mix, card type, authentication and retry policy as consistent as possible. Change one lever at a time; do not compare unlike traffic.

Track: first-attempt authorization rate, paid orders, latency and all-in cost per successful order, with fraud and dispute guardrails.

03 · Settlement + FX

Reconcile what actually reaches the bank

Match payments, refunds, fees and chargebacks to provider settlement reports and bank payouts. Compare presentment and settlement currency options using FX spread, conversion fees, payout timing and reconciliation effort.

Track: unmatched items, net settlement, days to cash and total FX cost. A lower headline FX rate is not automatically a lower total cost.

04 · Reporting → next decision

One reporting hub. Evidence-led changes.

Normalize provider data into shared definitions. Compare results by market, currency, payment method, issuer and route. Use the findings to adjust traffic allocation, method coverage and settlement setup, then measure again.

Decide: expand a winning test, investigate an underperforming segment or keep the current route. No uplift is assumed.

An illustrative operating model, not a claim that every orchestration platform provides every feature. Confirm provider integrations, experiment controls, reporting feeds and FX capabilities before selecting a solution.

Explore another path (optional)

A clearer view
of payments.

Practical insights on payment orchestration,
from Atlas of Payments.

By subscribing, you agree to our privacy notice.