Multi-currency · one integration

FX payment solutions — accept in local currency, settle in yours.

The buyer sees a price in their home currency where the scheme rules and the acquirer allow it. Settlement lands in the merchant's currency. Every row in the reconciliation feed carries the transaction currency, the settlement currency and the applied FX rate — one ledger, no rate mystery.

  • EUR
  • GBP
  • USD
  • AUD
  • BRL
  • SGD
  • JPY
  • MXN
  • +30 more
40+
settlement currencies supported
DCC-aware
buyer-currency acceptance where allowed
Per-row FX
rate metadata on every settlement row
1 ledger
across every currency and provider

Key benefits

Why fx payment providers on a panel beat a single-currency setup

Four properties that show up the moment cross-border traffic stops paying in a currency that isn't theirs.

  1. 01

    Accept in the buyer's currency

    The checkout renders the price in the buyer's local currency where the scheme rules and the acquirer allow it. Authorisation clears in that currency; the buyer sees no surprise conversion; approval rates lift as a result.

  2. 02

    Settle in your currency

    Settlement lands in the merchant's chosen currency per acquirer. FX conversion happens on the connected acquirer's rate card or a treasury-preferred conversion partner, with the rate stamped on the settlement row for reconciliation.

  3. 03

    Per-market routing that respects FX

    Routing weights consider currency and country pair alongside BIN and risk. Same-currency lanes are preferred when they clear at higher approval, cross-currency lanes fill the gap where local-currency acquiring isn't available.

  4. 04

    One ledger across currencies and providers

    Settlements, interchange, fees and chargebacks from every connected acquirer normalise into one ledger, with each row tagged by transaction currency, settlement currency and applied FX rate.

How fx payment systems flow underneath

From presentment currency to a rate-stamped ledger row

What actually happens between the buyer seeing a local-currency price and finance reading a ledger row tagged with the applied FX rate.

  1. 01

    Price the buyer in local currency

    The checkout surface renders the buyer's local price using the merchant-configured presentment currency for that market — EUR in eurozone, GBP in the UK, BRL in Brazil, etc.

  2. 02

    Route the auth with currency awareness

    The routing engine scores connected acquirers on BIN, currency, country pair and risk. Local-currency-capable lanes for the buyer's currency rank higher when they clear at higher approval.

  3. 03

    Authorise in the transaction currency

    The acquirer settles in the presentment currency where the scheme rules allow. Where cross-currency clearing is required, the acquirer's or scheme's rate is applied at authorisation, not at capture.

  4. 04

    Convert on settlement

    Settlement files arrive from each connected acquirer; conversion into the merchant's chosen settlement currency happens on the acquirer's rate card or a treasury-preferred conversion partner.

  5. 05

    Reconcile with FX metadata

    Every settlement row is tagged with the transaction currency, the settlement currency and the applied FX rate. Finance imports the merged feed into the general ledger with rate transparency intact.

Main use cases

Where fx payment processing earns its keep

Six recurring merchant shapes that benefit from FX-aware acceptance and settlement — DTC, SaaS, travel, marketplaces, B2B and licensed financial services.

  • DTC

    Cross-border DTC selling in local prices

    A DTC brand shows the buyer a EUR / GBP / AUD price on the checkout; the merchant settles into EUR. Approval rates rise vs a USD-only presentment; interchange exposure drops where local-currency acquiring is available.

  • SaaS

    SaaS with region-priced subscriptions

    Enterprise SaaS priced per-region — USD in the US, EUR in the EU, GBP in the UK — with each renewal charged in the buyer's currency and settled into the merchant's treasury currency.

  • Travel

    Travel and ticketing with multi-currency inventory

    Airlines, hotel groups and OTAs pricing inventory per market; buyers pay in their home currency; back-office reconciles by originating currency, applied FX rate and settlement currency.

  • Plat

    Marketplaces with multi-currency payouts

    Marketplaces receiving in buyer currencies, converting on settlement, and paying sellers in each seller's preferred currency — with rate metadata preserved through the payout leg.

  • B2B

    B2B invoicing across regions

    Invoices in the buyer's currency (per contract), settled in the merchant's treasury currency, with rate transparency for finance and audit purposes. Pairs with hosted invoice pay links or embedded pay-this-invoice fields.

  • FinLic

    Licensed FX brokerage and prop trading

    Licensed forex brokerage and prop-trading operators use multi-currency acceptance to onboard traders paying in their local currency and settling into the brokerage's operating currency, subject to underwriting and licence.

Platform features

Capabilities behind these fx payment solutions

Twelve capabilities the platform ships once and reuses across every supported currency — from vault-side tokens through to per-row FX metadata in the ledger.

  • Multi-currency vault

    Vault tokens carry currency metadata; refunds against the token reverse in the original currency by default.

  • Presentment currency routing

    Routing weights include buyer currency; local-currency lanes prefer where approval rates justify it.

  • Per-BIN currency detection

    BIN-level metadata tells the routing engine the issuer's most-likely home currency for the cardholder.

  • Settlement in merchant currency

    Configurable per merchant and per acquirer relationship; multi-currency settlement supported where the acquirer offers it.

  • Rate transparency per row

    Every settlement row tagged with transaction currency, settlement currency and applied FX rate for audit.

  • Scheme DCC posture

    Dynamic Currency Conversion (DCC) surfaces only where the acquirer and scheme rules permit — never as a default merchant-side markup.

  • SEPA & multi-currency bank rails

    SEPA for EUR, Bacs / Faster Payments for GBP, ACH for USD, PIX for BRL — bank rails in their native currencies through the same API.

  • Wallet & Click to Pay in local currency

    Apple Pay, Google Pay and Click to Pay surface local-currency prices on the same hosted checkout.

  • Chargeback tagged by currency

    Dispute cases surface the original transaction currency and settlement currency for evidence packs.

  • Refunds in the original currency

    Refund defaults to the original transaction currency; treasury-side FX exposure is limited to net movement between originating and settlement currencies.

  • Unified reconciliation feed

    Daily normalised feed across every connected acquirer, tagged by transaction currency, settlement currency, FX rate and provider.

  • PCI L1 & SCA baseline

    Card data captures into the PCI L1 vault; selective 3DS2 handles PSD2 SCA on the European card side alongside the FX-side flow.

Industry relevance

Multi-currency acceptance for licensed cross-border merchants

topropay's FX-aware posture targets licensed merchants operating across EU, UK, APAC and LATAM — cross-border DTC, region-priced SaaS, travel and ticketing, multi-currency marketplaces, B2B billing with region-specific invoice currencies, and licensed forex brokerage / prop-trading firms where the operator holds the relevant licence.

Trust & compliance

Compliance posture across every supported currency

One audited environment for the orchestration layer; scheme DCC rules respected per geography; licensed partner relationships for crypto settlement rails.

PCI DSS Level 1
Vault, switch and tokenisation are PCI DSS Level 1 service-provider components; sub-merchants inherit the posture across every currency the platform accepts in.
Scheme DCC rules
Dynamic Currency Conversion follows Visa and Mastercard scheme rules — offered only where the acquirer is licensed to run it, and always with the buyer's explicit choice.
SCA & PSD2
Selective EMV 3DS2 on the card path keeps European approval high on FX-priced transactions without skipping the SCA bar.
Sanctions & AML alignment
Sanctions screening on onboarding; AML monitoring tuned per merchant vertical, volume and cross-border currency mix.
MiCA-relevant crypto rails
Where the merchant uses stablecoin or crypto rails as a settlement path, delivery is through licensed partner crypto gateways with VASP / MiCA-relevant authorisations.
Licensed verticals only
Licensed forex brokerage, licensed prop-trading operators, licensed gaming and other compliance-bound verticals supported only where current operating licences exist. Grey and black-market verticals are out of scope.

Ready to sell in local currency

Bring cross-border FX onto one orchestration platform.

A 30-minute currency review covers the presentment currencies relevant to your buyers, the settlement currencies your treasury operates in, and a sandbox to test against before any commercial commitment.

Frequently asked

Buyer questions about fx payment solutions on topropay

Definitions, DCC mechanics, treasury-side FX, third-party-brand disambiguations and the practicalities of running multi-currency acceptance under one API.

  1. 01

    What does fx payment solutions cover on topropay?

    FX payment solutions on topropay cover multi-currency acceptance (the checkout in the buyer's currency where scheme rules permit), multi-currency settlement (the merchant configures the settlement currency per acquirer), rate transparency (every settlement row tagged with transaction currency, settlement currency and applied FX rate), and per-market routing that ranks lanes on currency alongside BIN and risk.

  2. 02

    Which fx payment providers does topropay connect to?

    FX payment providers on the connected panel are licensed acquirers, PSPs and treasury / conversion partners across EU, UK, APAC and LATAM. Selection is by geographic and currency coverage rather than a single provider. The merchant integrates once; the currency panel behind the scenes can grow or rotate without re-integration.

  3. 03

    How do fx payment systems on the platform compare to a single-currency setup?

    FX payment systems on the platform expose one API surface but many currency lanes underneath. A single-currency setup means every buyer pays in the merchant's currency (often lifting the acquirer decline rate on cross-border BINs); the FX-aware setup lets each buyer pay in their local currency where it clears higher, with settlement into the merchant's treasury currency.

  4. 04

    What are typical fx payment processing configurations?

    FX payment processing configurations depend on the merchant's mix. A DTC brand selling across Europe and the UK typically presents in EUR / GBP / USD and settles in EUR. A SaaS platform pricing per-region may settle in USD but accept in local currencies for buyer-approval reasons. A licensed brokerage may settle in a single treasury currency while accepting in every currency its traders speak.

  5. 05

    Some searches mention 'fx replay payment methods' — does that apply to topropay?

    That phrasing refers to the third-party trade-journal service FX Replay, which lists its own accepted payment methods on its own site. topropay is not affiliated with FX Replay and does not process payments on their behalf. The 'fx replay payment methods' query is unrelated to topropay's FX payment solutions for licensed cross-border merchants.

  6. 06

    What about 'my funded fx payment method' searches?

    That phrasing refers to the third-party prop-trading firm MyFundedFX and its own accepted payment methods, which the firm publishes on its own site. topropay is not affiliated with MyFundedFX and does not process payments on their behalf. The 'my funded fx payment method' query is unrelated to topropay's FX payment solutions.

  7. 07

    Does topropay serve forex brokerages and licensed prop-trading firms?

    topropay serves licensed forex brokerages and licensed prop-trading firms where the operator holds the relevant financial-services or investment-services licence in their operating jurisdiction. Onboarding runs through standard KYB, sanctions and AML checks. Unlicensed operators — regardless of how they describe themselves — are out of scope.

  8. 08

    How is FX exposure managed on the treasury side?

    FX exposure sits on the merchant's treasury side. The platform hands over each settlement in the merchant-configured settlement currency, with the applied FX rate stamped per row. Merchants who want to net down exposure typically pair with a treasury or FX-conversion partner that ingests the same reconciliation feed.

  9. 09

    Is DCC (Dynamic Currency Conversion) available?

    DCC is available where the connected acquirer is licensed to run it and the scheme rules allow it in the merchant's geography. Where offered, DCC surfaces on the hosted checkout as an explicit buyer choice — never as an automatic merchant-side markup. Merchants can also opt out entirely.

  10. 10

    Can settlement land in multiple currencies for the same merchant?

    Yes. Different connected acquirers can settle into different currencies for the same merchant — e.g. the EU acquirer settles into EUR, the UK acquirer settles into GBP, the US acquirer settles into USD. Reconciliation rolls them all into one ledger with currency-per-row tagging.

  11. 11

    How do refunds work across currencies?

    Refunds default to the original transaction currency, running against the vault token. Cross-currency refunds are supported where the scheme and the acquirer allow it, but the default behaviour keeps the buyer whole in their original currency and limits treasury FX exposure to the net movement between transaction and settlement currencies.

  12. 12

    What's the difference between presentment currency and settlement currency?

    Presentment currency is what the buyer sees at checkout (EUR, GBP, USD, etc.). Settlement currency is what the merchant receives from the connected acquirer. FX conversion (if any) happens between the two, at a rate stamped on the settlement row for audit.

  13. 13

    How long does a merchant need to go live with multi-currency acceptance?

    Most merchants add multi-currency acceptance in 1–3 weeks. The variables are the acquirer's supported currencies, the merchant's PCI scope, and any scheme registrations the connected acquirer needs to file. Sandbox covers every supported currency from day one.

  14. 14

    Are crypto rails part of the FX solution?

    Crypto rails are optional. Where the merchant wants stablecoin settlement (USDC, USDT, DAI) or majors (BTC, ETH) as an FX hedge, licensed partner crypto gateways deliver them through the same unified API — with the same reconciliation feed and the same rate-per-row transparency.

  15. 15

    Which geographies is FX-aware acceptance available in?

    FX-aware acceptance is available wherever the connected acquirer panel supports the buyer's currency — EU, UK, APAC and LATAM as a baseline, with additional geographies added as partner relationships expand. A 30-minute coverage review confirms availability for the merchant's specific mix before commitment.