International payment
topropay handles cross-border authorisations, multi-currency settlement and outbound payouts behind a single unified API. Regional acquirers in every supported region, 130+ currencies, programmatic FX policy and one normalised ledger across the lot — for merchants and PSPs operating across Europe, the UK, APAC and LATAM.
Live corridors
Five representative corridors out of the 130+ currency pairs the platform supports. Latencies are typical end-to-end settlement windows, not authorisation times.
Settle in EUR; route US BINs to US acquirers, EU BINs to EU.
FCA-licensed acquiring in the UK; AusPayNet-aligned acquirers in AU.
PIX rails for last-mile BRL; EUR-denominated card capture upstream.
SPEI rails for MXN payouts; cards via regional acquirers.
INR collections through licensed partner gateways; USD settlement upstream.
Key benefits
Five outcomes that show up consistently once orchestration sits in front of regional acquirers and payout rails — reach, cost, approvals, payouts and visibility.
topropay routes each authorisation to the regional acquirer best placed to clear it — EUR through EU acquirers, USD through US acquirers, AUD through Australian acquirers, INR through licensed partner gateways in India. The buyer sees a local checkout; the merchant sees one ledger.
Cross-border interchange is one of the largest cost lines in international payment processing. The routing engine optimises country-pair combinations per BIN — local-acquirer landing for cross-border traffic, scheme rate-tier matching, and selective use of network tokens to lower per-transaction floor pricing.
A US-issued card running through a US acquirer typically approves higher than the same card running through a non-US acquirer. The routing engine reads the issuer country off the BIN and lands the authorisation on the regional acquirer with the strongest historical approval rate for that combination.
Outbound payouts run on the same unified API as inbound collections. SEPA, Bacs, ACH, PIX, SPEI, Interac, PayID and card-to-account payouts plug into the same orchestration; FX is a per-corridor policy, not a separate platform integration.
Settlements, fees, refunds and chargebacks from every regional acquirer and payout rail normalise into one ledger, exported daily to your ERP. FX rates, currency margins and per-corridor fees are line-items, not assumptions.
How it works
The path from "we cross borders informally" to "we run an orchestrated multi-currency payment stack" is short — most merchants are live in days, not quarters.
Discovery surfaces the currency, country and method pairs you actually transact in — collections, payouts and FX. The output is a corridor list, not a generic plan.
Per-corridor acquirer selection: which connected provider gets EUR cards from EU issuers, which gets USD cards from US issuers, which handles cross-border into APAC.
Choose the FX model per corridor — pass-through, marked-up margin, or dynamic mid-market — and which currencies settle in their local form vs convert on receipt.
Every authorisation runs through the routing engine. Soft declines cascade across the regional acquirer set; FX, country-pair routing and risk thresholds combine into one composite score per transaction.
Inbound settlements land on a fixed cycle per acquirer; outbound payouts fire on the same unified API. Both share the vault-token and event-stream model.
Every transaction is traceable end-to-end with the international payment tracker exposed in the dashboard — corridor, acquirer, FX rate, fee components and settlement timing for each authorisation.
Main use cases
One headline use case plus three smaller patterns — the merchant shapes that share the same orchestration layer but stress it differently.
A merchant selling into more than one country quickly outgrows a single-region acquirer. topropay routes EU cards to EU acquirers, US cards to US acquirers, APAC cards to APAC acquirers, with local methods (SEPA, iDEAL, PIX, UPI via partners, PayID) surfaced inside the same hosted checkout. Each cross-border authorisation is scored per corridor; reconciliation rolls every currency into one ledger.
International payment bank wires, ACH, SEPA and card-on-file all work as collection rails on the same platform, with invoice-level reconciliation and FX policy per corridor.
International payout system for marketplaces, creator platforms and partner networks — SEPA, ACH, PIX, SPEI, Interac, PayID and card-to-account payouts on one API.
Resellers ride the platform's international payment processors and acquirer relationships downstream, surfacing them to their merchants under one contract.
Platform features
What the platform ships specifically for cross-border, multi-currency and payout flows — alongside the general orchestration capabilities every merchant inherits.
One contract across every connected international payment processor and payout rail; SDKs for web, mobile and server.
Authorise and capture in 130+ currencies; settle in the currency of your choice, with FX policy per corridor.
Per-transaction scoring on BIN, scheme, currency, country and risk; cascade through soft declines inside the same request.
Pass-through, fixed-margin or dynamic mid-market FX per corridor; conversion on capture, on settlement or on payout.
SEPA, Bacs, ACH, PIX, SPEI, Interac, PayID and card-to-account payouts on the same surface as inbound collections.
Stablecoin and major-token rails through partner crypto gateways, surfaced through the same unified API as fiat.
End-to-end traceability per authorisation — corridor, acquirer, FX rate, fee components, settlement timing — surfaced in the dashboard.
Approval, cost, refund and dispute outcomes per corridor and per acquirer; the data the routing engine optimises against.
Every currency, every region into one normalised ledger; CSV, Parquet and signed event feeds exported daily.
Model comparison
Two ways to handle cross-border. The bank-wire model is direct and slow; the orchestration model is multi-rail and routed — and pulls collections, FX and payouts into one ledger.
| Dimension | Traditional bank wires | topropay orchestration |
|---|---|---|
| Routing | Single SWIFT corridor per cross-border instruction; correspondent-bank hops add latency and opaque fees | Per-transaction routing across regional acquirers and rails; local-acquirer landing for cross-border traffic |
| Currencies | Tens of supported currencies; large minimums per corridor; manual FX desk for non-majors | 130+ currencies; programmatic FX policy per corridor; mid-market with controlled margin |
| Methods | Bank-rail-only; card collections handled separately by a different stack | Cards, wallets, bank rails, BNPL and crypto unified — one API for collections and payouts |
| Reconciliation | Per-account statements requiring spreadsheet merge; SWIFT MT940 / MT942 | Normalised ledger across acquirers and rails; daily CSV / Parquet / signed events |
| Visibility | Tracking ends at the correspondent; final-leg status delivered post hoc | End-to-end international payment tracker per authorisation, surfaced live in the dashboard |
Trust & compliance
Every connected acquirer and payout rail runs inside the platform's audited environment. Sub-merchants inherit the posture rather than carrying separate certifications per provider.
Authorisation and settlement support across the major and most minor currencies; corridor coverage tied to the connected acquirer panel.
Annual on-site assessment; quarterly ASV scans; inherited by every sub-merchant on the platform's acquirer relationships.
Selective authentication on the authorisation path; PSD2-compliant in Europe without breaking conversion.
Every currency, region and rail normalised into one reconciliation feed — daily export, vault-token-keyed.
Ready to map corridors
A 30-minute review walks through the corridors you actually transact in, the regional acquirers and payout rails that fit, the FX policy that makes sense, and a sandbox to test against before any commercial commitment.
Frequently asked
What buyers ask before committing — covering collections, payouts, FX, B2B invoicing, tracking and licensed-vertical fit.
An international payment starts at the merchant's checkout or back-end API call. topropay routes it to the regional acquirer or payout rail best placed to clear the transaction. The acquirer authorises, the platform captures, FX policy converts where required, and the settlement lands on the merchant's bank in the chosen currency on a fixed cycle. Every step is traceable in the dashboard.
A business international payment for invoicing usually mixes card-on-file, SEPA, ACH and SWIFT-aligned rails. topropay handles cards and the modern A2A equivalents (SEPA, Bacs, ACH, PIX, SPEI, Interac) on the same unified API; SWIFT-style wires are supported via partner banking rails where the merchant's flow requires them.
One API. International payment systems — card networks, regional acquirers, local APMs, bank rails, payout rails, FX — sit behind the unified payments API and surface as parameter choices, not as separate integrations. Adding a new system is a platform-side configuration step.
International payment processing on topropay is the routing engine sitting in front of multiple regional acquirers and payout rails. Every authorisation runs through a composite score in under 200ms; soft declines cascade inside the same request to the next-best provider for that corridor.
Yes. An international payment card — i.e. a card issued in one country and used to pay a merchant in another — is the default cross-border collection method on topropay. The routing engine reads the issuer country from the BIN and lands the authorisation on the regional acquirer with the strongest historical approval rate for that country pair.
To receive international payment as a non-domestic merchant, you integrate against topropay's unified API. Inbound cross-border authorisations route to a regional acquirer with the appropriate scheme licences; settlement lands on your bank in your chosen settlement currency. The cross-border complexity (FX, local-acquirer landing, scheme rules) happens platform-side rather than on your stack.
The international payment processing companies connected to topropay each have their own regional licences, scheme relationships and method coverage. The platform makes 'which is leading for you' a routing question against your own traffic, rather than a procurement question. The dashboard ranks them on your authorisation, cost and dispute outcomes.
Yes. Most regions have more than one international payment processor in the connected panel — that's the point of orchestration. The routing engine fans traffic across them per transaction, so a degradation at one provider doesn't take a region of revenue with it.
International payment services usually break down into four buckets: collections (inbound from cardholders), payouts (outbound to suppliers, sellers or staff), FX (currency conversion policy) and reconciliation (consolidated reporting across the lot). topropay covers all four behind one API.
International payment solutions go beyond a single-gateway model — they require multi-acquirer routing, multi-currency vaulting, FX policy controls and payout rails alongside collections. A single gateway typically covers only the first leg (authorising a card); orchestration covers the rest.
Yes. The dashboard exposes an international payment tracker that surfaces, per authorisation, the corridor, acquirer, scheme, FX rate applied, fee components and settlement timing. The same view is available via the API for embedding into in-house tooling.
To make international payment outbound, the merchant calls the unified payouts API with a payee, an amount, a currency and a corridor. The platform picks the rail (SEPA, ACH, PIX, SPEI, Interac, card-to-account, partner SWIFT) per corridor, applies the chosen FX policy and reconciles the payout into the same ledger as inbound collections.
An international payout system for marketplaces typically needs split payments, per-seller payout cadence, multi-currency settlement and ledger isolation per seller. topropay provides all four on the same orchestration layer that powers inbound collections — one platform, two directions of flow.
An international payment bank account in the merchant's name is required only at the settlement endpoint — somewhere the platform can settle funds to. The merchant does not need to hold accounts in every operating currency: settlement currency is a policy choice, and FX happens platform-side before payout.
International payment processing services for licensed high-risk verticals — regulated gaming, telemedicine, nutraceuticals, ticketing — are supported where the merchant holds the relevant operating licence in a permitted jurisdiction. Grey and black-market verticals are out of scope regardless of integration shape.
Related