4 minutes
Design once, scale everywhere with Worldpay payments
Multi-market payment support is an architecture decision, not a deployment task. Here’s how to design for global scale from the first commit.
Simon Farrow
Solution Architect
Simon Farrow is an IT architect specialist with 10 years’ experience in payment integrations, specializing in secure, scalable enterprise payment infrastructure.
Key points
- Global payment expansion adds integration complexity across clearing systems, routing, currencies and compliance. Designing for this early helps avoid rebuilding for every new market.
- Payment types – domestic clearing, domestic wire, SEPA and international SWIFT – vary by cost, speed and data needs. Choosing the right type is an architecture decision.
- Account Payouts API from Worldpay, now Global Payments, supports domestic, domestic wire, SEPA and international payments across covered markets. Country-specific fields, cut-offs and delivery windows are detailed in the Developer Hub.
This article is part of a series focused on helping developers design, build and scale payment integrations with real-world guidance and practical examples.
A single-market payment integration is a solved problem. The APIs are documented, the patterns are well-understood and most teams can reach production quickly. The difficulty starts when you need to move money across borders.
Currency conversion, local clearing systems, regional compliance requirements, per-market bank account field formats, settlement timing differences – each of these is manageable in isolation. Together, without a deliberate design approach, they become a source of ongoing engineering debt.
Here’s how to think about multi-market payment architecture, and how our infrastructure supports it.
The problem with bolt-on global coverage
Most platforms enter their second market the same way they entered their first: They find out what’s required, add the capability and move on. This works twice. By the third or fourth market, the pattern breaks down.
The result is a patchwork: different payment providers per region, inconsistent data models, divergent error handling and an integration surface that grows with every new market rather than absorbing them.
"The goal isn’t to build for every market at once. It’s to build so that adding a market is a configuration exercise, not a re-architecture."
The alternative is to design for multi-market scale at the architecture level – not by anticipating every market, but by choosing infrastructure that handles regional variation without requiring bespoke integration work each time.
The goal isn’t to build for every market at once. It’s to build so that adding a market is a configuration exercise, not a re-architecture.
Payment types and when each applies
The first thing to understand about multi-market payments is that "send money to country X" is not a single operation. The payment type that applies depends on the target country, the target currency and what infrastructure we have in that market.
Domestic payments
Where we have an active bank partner and operating account in a country, you can route payments directly into that country’s local clearing system. This is the most cost-efficient option and avoids the correspondent banking charges that come with international transfers.
Domestic payments require that the target currency is local to the country – a USD payment to a UK account is an international payment, not a domestic one. They also require that the payment request includes bank account details in the format that country’s clearing system expects.
For some markets, you have two options for bank account format:
- IBAN – recommended where available. We validate IBAN structure and reverses invalid payments before they reach the beneficiary bank.
- BBAN – available for migrations from providers that use BBAN format, avoiding the need to recollect account data from payees.
Domestic payment speed varies by market. Some countries support real-time processing with no cut-off; others offer same-day settlement with fixed cut-off windows; others operate on T+X settlement (where X is the number of business days). These timings are specified per country in the documentation.
Domestic wire payments
Domestic wires extend the reach of domestic currency payments to countries where we don’t hold a direct operating account, using our international banking network. Unlike international SWIFT transfers, domestic wires don’t incur correspondent bank charges, and the payee receives the full amount in their local currency.
The same rule applies: The target payment currency must be local to the destination country.
SEPA payments
SEPA (Single Euro Payments Area) covers 47 European markets and standardizes euro-denominated bank transfers across that zone. If your platform operates in Europe and moves euros between accounts, SEPA is the relevant payment type – not international SWIFT.
SEPA supports both real-time and same-day settlement. Real-time is available for beneficiary banks that participate in the SEPA Instant scheme; payments to non-participating banks fall back to same-day processing automatically.
International payments
Where domestic payment isn’t available – either because the currency is not local to the destination country, or because we don’t have a local bank presence – international payments route through a global banking partner.
International payments are available to most countries worldwide in 23 currencies:
AED, AUD, CAD, CHF, CZK, DKK, EUR, GBP, HKD, HUF, ILS, JPY, MXN, NOK, NZD, PLN, RON, SEK, SGD, THB, TRY, USD, ZAR
JPY is a zero-decimal currency, so payout amounts submitted with decimals are rounded up. If your platform handles JPY, account for this in your payment instruction logic.
International payments are not available to countries on our country risk policy list, or those where the global banking partner does not have the appropriate reach. If you’re building for emerging markets, check coverage with your Relationship Manager before committing to a market.
Risk and compliance considerations at scale
Multi-market payment infrastructure introduces compliance complexity that scales with geographic reach. Two areas worth building in from day one:
Transaction limits
We operate a third-party payout limit of EUR 50,000 (or currency equivalent) per transaction per individual or legal entity. Payments above this threshold can be processed but may require additional due diligence and documentation on the source and application of funds. If your platform handles high-value payouts, build in a flag for transactions approaching this threshold and a process for providing supporting information when required.
Gambling restrictions
We do not support gambling or gambling-related transactions to or from a defined list of restricted countries due to the regulatory and legal environment in those markets. If your platform operates in or adjacent to the gambling vertical, review the restricted country list in the documentation before designing your payout flows.
Designing for this in practice
Multi-market payment readiness comes down to a few design decisions made early:
- Payment type routing logic. Your integration needs to determine, per transaction, which payment type applies – domestic, domestic wire, SEPA or international. Build this as explicit logic. Don’t let it fall back to defaults. Each type has different data requirements and different fields in the API request.
- Per-market field validation. Bank account details vary by country: IBAN formats, routing codes, account number lengths and bank identifier requirements differ. The country-specific documentation in the Developer Hub defines the required fields for each market. Validate at submission time, not on the receiving error.
- Cut-off and delivery time awareness. If your product makes commitments to payees about when funds arrive, those commitments need to be grounded in the actual cut-off and delivery windows for each market. Real-time, same-day and T+X settlement behave differently – surface this to your users rather than abstracting it away.
- Currency handling. Domestic payments require the local currency. International payments support 23 specific currencies. Zero-decimal currencies like JPY require attention in your amount formatting logic. Handle currency as a first-class input to your routing decisions, not a post-hoc concern.
- Compliance flags. Build in checks for transaction limits, restricted countries and, if applicable, gambling-adjacent use cases. These are not edge cases – they affect specific transaction types at volume.
Country-specific requirements
The country coverage documentation in the Developer Hub details the required bank account fields, available payment types, cut-off times and estimated delivery windows for each market, organized by region:
Before designing your multi-market payout flow, check the relevant country pages for each target market. The field requirements and payment type availability are the inputs your integration logic needs to be built around.
To enable specific payment types for your account, contact your Relationship Manager.
Further reading
Related insights
