Routing Payments by Currency

Routing Payments by Currency: When Currency Should Influence PSP and Acquirer Selection A customer sees a price of €100. Behind that single number, a merchant may have three possible routes. Route A: PSP A accepts the €100 transaction in EUR but ultimately settles the merchant in USD. Route B: PSP B processes the €100 transaction through an EUR-capable MID and settles EUR into the merchant's EUR account. Route C: the merchant converts the price into USD before submitting the transaction and processes the payment as USD. All three providers may truthfully say they support EUR somewhere in their payment stack. They are not economically equivalent routes. They can differ in which merchant entity processes the transaction, which MID is used, where acquiring occurs, whether the card transaction is treated as domestic or cross-border, where foreign exchange occurs, which currency reaches treasury, what happens when the customer is refunded, and ultimately what the merchant pays to turn the order into usable cash. That is why routing payments by currency cannot mean simply matching the customer's currency with a PSP that accepts that currency. Currency should become a routing input when it changes: * Route eligibility * Transaction treatment * Payment performance * Settlement * Foreign-exchange exposure * Total merchant economics Otherwise, it may simply be another attribute of the payment. The question is not: Which PSP supports EUR? It is:

What happens to this €100 from the moment the customer agrees to pay it until the merchant can reconcile and use the proceeds?

One payment can contain several different currencies Payment systems frequently compress several currency concepts into the word currency. A useful international payment architecture does not. At minimum, merchants should distinguish the following. Presentment currency The presentment currency is the currency in which the customer is shown and agrees to the price. If a customer sees: €100 then EUR is the presentment currency. Presentment is principally a customer and commercial decision. It does not by itself tell you which acquirer is processing the payment or which currency the merchant ultimately receives. Processing or transaction currency This is the currency in which the payment is submitted through the relevant provider or payment rail. It may be the same as presentment currency. It may also differ if a conversion is deliberately introduced before processing.

Currency support is therefore partly an execution constraint, not merely a display feature. Acquiring currency and MID capability A merchant ID or acquiring arrangement may support particular transaction currencies. That means a PSP-level statement such as “supports EUR” is not enough information for routing. The relevant question is: Does this merchant entity, through this provider, using this MID and acquiring arrangement, support this transaction in EUR? That is a much narrower—and much more useful—question. Settlement currency Settlement currency describes the currency in which payment proceeds become payable to the merchant under the relevant provider or acquiring arrangement. It does not have to match what the customer paid. Cross-currency payment infrastructure can explicitly separate the payer's currency from the recipient's currency. The European Central Bank's TIPS cross-currency service, for example, allows Swedish or Danish users to initiate payments in their domestic currencies while a recipient in the euro area receives euros. The example concerns instant account payments rather than merchant card acquiring, but it demonstrates the underlying principle clearly: payer currency and recipient currency are separate stages of a payment flow. Payout or treasury currency Even settlement and treasury do not necessarily represent the same decision.

A merchant may collect currencies into separate balances, receive provider payouts in selected currencies, or convert funds before they reach the account from which the business actually manages cash. This is where payments architecture starts meeting treasury strategy. Merchant functional currency Functional currency is an accounting concept, not a routing attribute. Under IAS 21, an entity's functional currency is the currency of the primary economic environment in which it operates. A US-centered merchant might therefore present and collect EUR, GBP and JPY while managing much of its business economically in USD. That does not mean those international transactions should automatically be converted into USD as early as possible. It means payment teams and treasury need to understand where conversion occurs and why.

The currency path Instead of storing one currency against a payment, think of the transaction as having a currency path: Presentment → Processing → Settlement → Treasury/functional currency For the €100 example: Route A EUR → EUR → USD → USD The customer pays EUR. The payment is processed in EUR. The provider converts the proceeds. The merchant receives USD. Route B EUR → EUR → EUR → USD later The customer pays EUR. The payment is processed in EUR. The merchant receives EUR. Treasury decides separately whether and when to convert it to USD. Route C EUR displayed → USD charged → USD settled → USD This is substantially different. If the customer actually authorizes a USD amount rather than €100, the merchant has changed the transaction currency itself rather than merely changing settlement. That can affect customer experience and should not be hidden inside routing logic. A routing engine should therefore know not just: currency = EUR but, where relevant: presentment_currency = EUR transaction_currency = EUR settlement_currency = USD merchant_functional_currency = USD fx_stage = provider_settlement merchant_entity = ENTITY_US provider = PSP_A mid = MID_42 The exact fields will differ by architecture. The important point is that the distinctions survive.

Currency support does not mean domestic acquiring This is the most dangerous shortcut in currency routing. A merchant sees EUR. PSP B has a European brand or office. The routing rule sends EUR to PSP B. Nothing in that logic proves the transaction is domestically acquired. For card payments, domestic or cross-border treatment can depend on geographical characteristics such as the issuer, acquirer and merchant/point-of-sale location under the applicable scheme and regulatory framework. The EU Interchange Fee Regulation provides a useful concrete example. It defines an EU cross-border card transaction according to the locations of the issuer and acquirer, or issuer and point of sale—not simply according to the transaction currency. Mastercard likewise publishes separate country-level “intra-location” interchange schedules as part of its European interchange materials, demonstrating that acquiring geography is a distinct dimension of transaction economics. So these are different statements: The PSP accepts EUR. The MID accepts EUR. The transaction is acquired locally. The transaction qualifies for a particular domestic or regional treatment. The merchant settles in EUR. A route can satisfy one without satisfying all the others. That is why country routing and currency routing should remain separate parts of the architecture. Routing Payments by Country should determine which geographic relationships make a route appropriate or eligible.

Routing Payments by Currency should determine what the currency characteristics of those eligible routes mean economically and operationally.

When currency changes route eligibility Currency should first operate as a filter, not an optimization score. Before comparing costs, the routing layer should ask whether the candidate route can correctly process the transaction. Suppose the merchant has these possible GBP routes: Route Entity MID supports GBP? Method supports GBP? GBP settlement? PSP A UK entity Yes Yes Yes PSP B US entity Yes Yes No PSP C EU entity No

PSP C is not a GBP route simply because the provider operates internationally. It is ineligible for that transaction configuration. PSP B may be eligible for GBP processing even though the merchant eventually receives another currency. PSP A may preserve GBP all the way through settlement. Routing can only begin comparing A and B after those facts are known. A useful hierarchy is: Eligibility → Correctness → Compliance → Customer compatibility → Availability → Performance → Economics → Resilience Currency belongs near the beginning when it determines eligibility. It belongs later when it determines economics.

When currency changes acquiring economics Once multiple routes are eligible, merchants can examine whether changing the route also changes acquiring treatment. This is where the common rule: EUR → European PSP fails. What actually matters may include: * Merchant entity * Merchant location * MID * Acquirer * Issuer geography * Applicable card-network region * Payment method * Transaction currency * Provider contract For EU card payments specifically, applicable regulation distinguishes domestic and cross-border transactions using issuer, acquirer and point-of-sale location. The transaction currency remains relevant, but it is not sufficient to determine the classification. This leads to a better routing question: If I change the provider or MID for this currency, what else about the acquiring path changes? The answer might be: Nothing material. If so, currency-based routing may provide little value. Or it might change: * Acquirer * Geographic treatment * Merchant service pricing * Authentication implementation * Authorization performance * Settlement timing * Settlement currency Then currency can be a useful routing input—but only because it identifies a route whose full payment path differs.

Do not optimize an FX line while ignoring the transaction FX costs are visible, which makes them seductive optimization targets. A provider quotation may make one route appear cheaper because it offers: * No explicit FX fee * Lower stated FX markup * Same-currency settlement But payment cost contains more than FX. Visa describes interchange as a transfer between acquiring and issuing banks and separately notes that merchants negotiate a merchant discount with their financial institution, which can encompass different processing services. A merchant comparing two currency routes therefore needs to evaluate something closer to: **Provider/acquiring charges * scheme-related costs borne through the commercial arrangement * authentication/fraud effects * FX cost * settlement/banking cost * refund economics * operational cost** And then compare that against: completed, collectible revenue, not merely transaction attempts. The cheapest conversion rate attached to a route that completes fewer good transactions may not produce the lowest cost per completed order. Conversely, a higher-priced processing route is not automatically justified merely because it settles in the customer's currency. The merchant needs evidence.

Where FX happens matters as much as whether FX happens For a merchant with centralized USD treasury, the question is rarely whether international currency will ever be converted. Often it will. The useful questions are: Where? When? By whom? At what rate and fee structure? Who controls the timing? What happens when the payment is refunded? Consider a UK customer paying £100. Route 1: provider conversion Customer: GBP 100 Processing: GBP 100 Settlement: USD equivalent Treasury receives: USD The conversion has effectively been delegated to the provider/acquiring arrangement. Route 2: preserve GBP Customer: GBP 100 Processing: GBP 100 Settlement: GBP 100 less applicable payment costs Treasury receives: GBP The merchant can then use GBP for GBP expenses, hold it, or convert it according to treasury policy. Neither is universally better. The preferred route depends on the merchant's: * GBP inflows * GBP expenses * Bank accounts * Conversion pricing * Cash requirements * Hedging or treasury policy * Accounting structure * Operational capacity That is why detailed decisions about which currencies a merchant should ultimately hold belong in How to Choose Settlement Currencies rather than inside the routing engine itself. Currency routing needs to expose the settlement consequence. Treasury decides whether that consequence is desirable.

EUR example: the same currency, different routes Consider a hypothetical US-headquartered software company with substantial European sales. A French customer pays €100 using a card. The merchant has two valid routes. Route A * Merchant entity: US * Transaction currency: EUR * Provider: PSP A * Settlement: USD Route B * Merchant entity: EU * Transaction currency: EUR * Provider: PSP B * Settlement: EUR A simplistic currency rule prefers Route B: EUR → Route B But the correct analysis is broader. The merchant should determine: 1. Is each entity permitted and contractually configured to process the transaction? 2. Which MID is used? 3. Where is the acquirer? 4. How is the particular transaction treated under applicable network and regulatory rules? 5. What authorization and completion performance does each route produce for comparable French-issued cards? 6. Where does conversion occur? 7. What fees apply across the entire route? 8. What currency is settled? 9. How are refunds handled? 10. Can finance reconcile the route? Only after answering those questions does “EUR” become a useful routing signal.

GBP example: settlement can justify a different route Now suppose the same company pays significant UK operating expenses. It receives millions of pounds from UK customers each year. If one eligible route preserves GBP through settlement while another converts every transaction to USD, the first route may have treasury value even if its headline processing price is not the lowest. The merchant might naturally use incoming GBP for GBP expenses instead of repeatedly converting between currencies. But that is a merchant-specific cash-flow advantage, not a universal payment rule. Another merchant with almost no GBP liabilities and a USD-only treasury operation might reach the opposite conclusion. The routing system should expose: Route → resulting settlement currency and cost It should not encode: GBP settlement is always better.

JPY example: currency can be necessary but still insufficient Imagine a merchant selling in Japan in JPY. It has: Route A: a JPY-capable route connected to one merchant entity and acquiring arrangement. Route B: another global provider that accepts JPY but settles the merchant in USD. Both may be technically capable of charging the customer in JPY. That tells the merchant almost nothing about which should win. The merchant still needs to compare: * Entity and MID eligibility * Actual acquiring path * Comparable authorization performance * Processing cost * FX stage * Settlement economics * Refund handling * Operational reliability If Route A materially improves transaction treatment or performance, currency may strongly influence the routing rule. If both routes produce effectively the same acquisition and customer outcome, the choice may come down mostly to settlement, economics or resilience. Again, JPY is an input, not an answer.

Volatile or restricted currencies require a different question Some currencies can introduce another dimension: convertibility, volatility, settlement availability, repatriation constraints, provider limitations, or materially different treasury risk. These situations should never be generalized from one market to another. Instead, suppose a merchant operates in a hypothetical market where customers strongly prefer local-currency pricing but the merchant cannot reliably maintain or use settlement balances in that currency. The route may need to preserve local-currency presentment while converting proceeds earlier in the payment chain. In another market, keeping local currency through settlement may be economically preferable. The architectural lesson is not “convert volatile currencies immediately.” It is: Make the conversion point explicit and configurable. Accounting standards themselves recognize that currencies can raise questions about exchangeability; IAS 21 addresses foreign-currency transactions and circumstances involving lack of exchangeability. Payment routing should not attempt to replace legal, accounting or treasury analysis in markets with currency controls or unusual convertibility conditions.

The Currency Routing Decision Tree Before sending a transaction down a route, ask these questions in order. 1. Is the transaction currency supported? Check the actual payment configuration—not the provider's marketing coverage. Validate: * Payment method * Currency * Amount * Country * Merchant project/account * Provider If no, remove the route.

2. Which merchant entity is processing? Determine which legal merchant relationship will own the transaction. Do not decide the entity merely from currency. 3. Which MID supports the currency? Validate the actual MID/acquiring configuration. “Provider supports GBP” is less useful than: MID X under Entity Y can process this GBP transaction through Acquirer Z. 4. Does the route change domestic or cross-border treatment? Evaluate the applicable issuer, acquirer, merchant location and network/regulatory rules. Do not infer the answer from currency alone. The EU definition of cross-border card transactions is a clear example of why. 5. Where does FX occur? Possible answers include: * Before transaction submission * Within the provider/acquiring path * During settlement * At the merchant's bank * Later under treasury control Record who provides the conversion and the rate/fee methodology. 6. What settlement currency results? A route that processes EUR may settle EUR, USD or another supported currency depending on the commercial arrangement. Settlement capability should be validated provider by provider. 7. What is the total payment cost? Do not compare FX spreads alone. Compare the payment path as a whole and use equivalent transaction populations. 8. Are refunds handled correctly? Determine: * Customer refund currency * Merchant funding currency * Whether another conversion occurs * Which FX rate applies * Whether the merchant can refund when the original settlement balance is unavailable

9. Is the route operationally recoverable? Ask: * Can operations identify which currency path was used? * Can unknown payments be resolved? * Can fallback preserve the agreed customer amount and currency? * Can finance reconcile processing and settlement currencies? * Can refunds still be executed during a provider incident? Only after the route passes all nine questions should performance or price optimization select among the remaining routes.

Fallback should not silently change the economic contract Suppose the customer agreed to pay: €100 PSP A becomes unavailable. PSP B supports only USD for this merchant configuration. A routing system should not casually transform the transaction into: $116.37 and call that provider failover. The customer agreed to a particular amount and currency. Changing that may create customer-experience, accounting, contractual, payment-method or regulatory implications depending on the implementation and market. A safer fallback architecture distinguishes: Provider fallback from: Currency conversion. If the merchant wants a route capable of failing over while preserving €100 as the transaction currency, that fallback route needs to be qualified in advance. Otherwise the correct action may be to surface another payment option rather than silently rewrite the transaction.

Refunds reveal bad currency architecture Currency-routing mistakes can remain invisible during successful sales. Refunds expose them. Imagine: Sale: €100 Processing: EUR Settlement: converted to USD Two weeks later, the merchant refunds €100. The merchant needs to know: * Does the customer receive exactly €100? * Is the refund funded from an EUR balance or converted from USD? * Is a new conversion performed? * Who bears any exchange-rate movement? * Are additional fees involved? * How will finance link the refund's currency movement to the original transaction? The answers depend on the provider, acquiring setup and contract. They should therefore be captured as route properties, not assumed globally. A useful metric is: Refund FX variance For transactions involving conversion: merchant-functional-currency cost of the refunded portion minus merchant-functional-currency value originally recognized for that refunded portion The metric needs an internally consistent accounting and FX methodology before being used for provider comparison.

Recurring payments can constrain future currency routing Recurring payments add another question: Can the future transaction actually use the route the routing engine selects? A recurring credential may be represented by: * A provider token * A network token * A merchant vault reference * Another stored-payment credential Changing the preferred currency route may therefore interact with credential availability and the merchant's original customer agreement. Currency logic should not assume a token usable with PSP A is usable with PSP B. That subject belongs primarily in Payment Token Portability, but currency-routing design needs at least one rule: A route is not eligible unless the required payment credential can validly be used on that route.

What the routing data model should preserve Currency routing becomes difficult to audit when one database field called currency is expected to explain everything. For transactions where these distinctions matter, consider preserving: payment_intent_id payment_attempt_id

customer_country issuer_country

merchant_entity provider acquirer mid route_id route_version

presentment_currency presentment_amount

transaction_currency transaction_amount

settlement_currency settlement_amount

fx_stage fx_rate_reference fx_fee_or_markup_if_available

merchant_functional_currency

provider_status canonical_status

refund_currency refund_amount

provider_transaction_id settlement_reference Not every provider will expose every field. That is acceptable. The architecture should preserve what is known and avoid inventing what is not. Most importantly, do not overwrite the original currency data after conversion. Finance needs to be able to reconstruct: what the customer paid → what was processed → what was settled → what the merchant received.

How to measure whether currency routing is working A currency rule should be treated as a testable economic hypothesis. Do not evaluate it from blended global results. Segment by at least: * Currency * Customer market * Issuer country where available and appropriate * Merchant entity * Payment method * PSP * Acquirer/MID where available * Route * Authentication path * Transaction-value band Then measure the outcomes. Volume by currency and route eligible payment attempts sent to route X for currency Y ÷ all eligible payment attempts for currency Y This shows what the routing rule actually controls. Authorization rate For card authorization comparisons: approved authorization attempts ÷ valid authorization attempts submitted Compare equivalent populations. Sending French cards to Route A and US cards to Route B and then declaring one PSP better is not a meaningful provider comparison. Completed-order rate Choose a business definition and preserve the denominator. For example: orders reaching the merchant's defined paid/completed state ÷ eligible payment intents entering payment This can capture customer and asynchronous-method effects that authorization alone cannot. FX cost Measure: explicit conversion fees + estimated FX spread, where the latter can be calculated consistently against a treasury-approved benchmark. Do not mix different benchmark methodologies between providers. Total payment cost A useful decision metric is: attributable payment-route cost ÷ successfully completed payments

or, for a revenue-weighted view: attributable payment-route cost ÷ successfully completed payment volume Define exactly which fees are included. Settlement currency mix Track the percentage of settlement received in: * EUR * GBP * JPY * USD * Other currencies Treasury can then determine whether routing is creating useful currency balances or accidental exposures. Refund FX variance Track currency-related refund gains or losses using one finance-approved methodology. Currency-route failure rate transactions failing because the selected route could not correctly process the currency configuration ÷ transactions routed using that currency rule This can expose stale MID eligibility, provider configuration errors and unsafe fallback assumptions.

What would disprove a currency-routing strategy? Suppose a merchant believes: Routing EUR to Route B will improve economics because Route B preserves EUR settlement and has a better European acquiring configuration. That is a hypothesis. Evidence against it might include: * No measurable payment-performance improvement * Higher total transaction cost after all fees * Higher technical failure rate * Material reconciliation workload * Unfavorable refund economics * Unusable EUR balances building up in treasury * No meaningful difference in actual acquiring treatment * Operational inability to recover the route during incidents If those effects outweigh the expected benefit, the currency rule should be removed or redesigned. Routing logic earns its complexity. It is not entitled to it.

A global payments platform can reduce the number of currency-and-market combinations a merchant has to integrate separately, but the merchant still needs to understand the economics of the routes it uses.

The right role for a payments partner here is not to make the merchant stop thinking about currency. It is to make more valid routes available while giving the merchant enough information to understand what those routes actually do.

Currency-routing scenarios If a US-issued card pays €100, should I route it to my European PSP? Not because of EUR alone. First establish the merchant entity, MID, acquirer, issuer geography, applicable transaction treatment, provider eligibility, payment performance, settlement currency and full cost. In the EU regulatory framework, cross-border classification itself depends on issuer/acquirer or issuer/point-of-sale location rather than transaction currency alone. If our company ultimately wants USD, should every payment be converted to USD immediately? Not necessarily. Early conversion simplifies some treasury operations, while same-currency settlement may preserve flexibility or offset same-currency expenses. The correct answer depends on the merchant's cash flows, banking arrangements, conversion pricing and treasury policy. If one PSP advertises zero FX fees, should it receive all foreign-currency volume? No. Determine the actual exchange rate or spread and evaluate it alongside processing/acquiring charges, payment performance, settlement, refunds and operating cost. A zero line item is not the same thing as a zero economic cost. Should JPY always go through a Japanese route? No. JPY tells you the transaction currency. It does not alone establish entity eligibility, acquiring geography, MID configuration or route performance. If a Japanese route produces a measurable advantage for comparable transactions, JPY may become a useful routing signal.

Can fallback change the transaction from EUR to USD? Technically possible in some payment experiences does not mean economically or operationally equivalent. If the customer has already agreed to €100, changing the charged currency should be treated as a separate currency/customer-experience decision rather than ordinary provider failover.

Final recommendation Use currency first to establish route eligibility and then to understand route economics. Do not build rules such as: EUR → PSP A GBP → PSP B JPY → PSP C until you can explain what each rule really means: Which entity? Which MID? Which acquirer? Which transaction currency? Which geographic treatment? Where does FX occur? Which settlement currency results? What happens on refund? What is the total cost per completed payment? Currency matters when changing it—or changing the path attached to it—changes the payment. When it does not, routing on currency is complexity without an economic reason. The strongest currency-routing rule is therefore not: Send each currency to the provider that looks most local. It is: Among the routes that can correctly process the payment, use currency when it identifies a materially better complete path from customer price to merchant settlement.

The research supports the brief’s core distinction especially well: transaction currency and transaction geography are not the same thing. In the EU card framework, for example, whether a card transaction is cross-border depends on issuer/acquirer or issuer/point-of-sale location; the definition is not based simply on whether the transaction is denominated in EUR. Editorial interpretation Architecture decision owned: when transaction currency should influence PSP, acquirer, MID, and fallback selection. Unique evidence anchor: €100 can travel through several economically different payment paths even when every provider involved claims to “support EUR.” Editorial position: currency deserves routing weight only when it changes eligibility, transaction treatment, expected payment performance, settlement, or total merchant economics. An FX fee viewed in isolation is not a sufficient routing strategy. Common assumption challenged: “If the customer pays in EUR, send the payment to the European PSP.” Merchant decision: select the route based on the complete currency path—customer currency through processing/acquiring, conversion and settlement—not the ISO currency code at checkout. Format: currency-flow investigation followed by a decision tree.

Most important control boundary: the merchant should distinguish and retain the transaction's presentment currency, processing/acquiring path, settlement currency, and treasury/accounting currency rather than reducing all four to a single currency field. Proposed architecture: Customer price │ │ Presentment currency ▼ Payment intent │ ├── Merchant entity ├── Payment method ├── MID eligibility ├── Acquirer / PSP eligibility └── Country / issuer context │ ▼ ROUTE DECISION │ ▼ Provider / Acquirer / MID │ Processing currency │ FX occurs? / \ No Yes │ │ └──────┬──────┘ ▼ Settlement currency │ FX occurs? / \ No Yes │ │ └──────┬──────┘ ▼ Treasury account │ ▼ Merchant functional/reporting currency  Original practical asset: Currency Routing Decision Tree For the visual version, I would make the tree deliberately asymmetric—six gates before optimization, so the visual itself reinforces the editorial argument:  PAYMENT INTENT │ ▼ 1. Currency supported? No ───────► Reject route │ Yes ▼ 2. Correct merchant entity? No ───────► Reject route │ Yes ▼ 3. Valid MID? No ───────► Reject route │ Yes ▼ 4. Acquiring / geographic treatment │ ▼ 5. Where is FX? │ ▼ 6. Settlement currency? │ ▼ ┌────────── ELIGIBLE ROUTES ──────────┐ │ │ ▼ ▼ 7. Payment performance 7. Payment performance 8. Total cost 8. Total cost 9. Refund behavior 9. Refund behavior

10. Recoverability 10. Recoverability │ │ └──────────► SELECT ROUTE ◄────────────┘ Supporting visual title: From €100 at Checkout to Merchant Cash: The Currency Routing Decision Tree Alt text: “Currency routing decision tree showing transaction-currency eligibility, merchant entity, MID, acquiring treatment, FX point, settlement currency, payment performance, cost, refunds, and recoverability before PSP selection.”

Measurement plan Metric Recommended definition Primary use Currency route share Attempts on route ÷ eligible attempts for that currency Verify routing behavior Authorization rate Approved authorizations ÷ valid authorization attempts Payment performance Completed-order rate Completed paid orders ÷ eligible payment intents Business outcome Explicit FX cost Recorded conversion charges ÷ converted volume Direct FX economics Estimated FX spread Difference from approved benchmark using consistent methodology FX comparison Total payment cost Attributable payment cost ÷ completed payment volume/orders Route economics Settlement-currency mix Settlement amount by currency ÷ total settlement Treasury impact Refund FX variance Defined functional-currency refund difference Refund economics Currency-route failure rate Currency/configuration route failures ÷ attempts using route Architecture quality The provider comparison population must remain comparable by country, issuer geography, payment method, transaction size, authentication and fraud policy before performance differences are attributed to routing. SEO package SEO title: Routing Payments by Currency: PSP, FX & Settlement Decisions H1: Routing Payments by Currency: When Currency Should Influence PSP and Acquirer Selection URL slug: /expand/internationally/international-payment-architecture/routing-payments-by-currency/

Meta description: Learn when currency should influence payment routing across PSPs, acquirers and MIDs—and how processing, FX and settlement affect total merchant economics. Primary keyword: routing payments by currency Secondary keywords: currency based payment routing; PSP routing by currency; international payment currency routing; payment routing rules currency; payment processing currency; multi currency routing; payment routing FX; acquiring currency routing. Related entities: presentment currency, settlement currency, functional currency, foreign exchange, FX spread, PSP, acquirer, MID, local acquiring, cross-border acquiring, merchant entity, interchange, issuer, refund, treasury. Excerpt: The currency a customer sees is only the first currency in a payment's economic path. Effective currency routing evaluates the merchant entity, MID, acquiring route, FX point, settlement currency, refunds and total payment cost before choosing a PSP.

Internal links The primary internal links should be: * Routing Payments by Country — from the domestic-versus-cross-border distinction. * Multi-Currency Settlement Explained — from the section separating processing from settlement. * How to Choose Settlement Currencies — from the treasury discussion. * Local Acquiring vs Cross-Border Acquiring — from the acquiring-treatment section. A secondary link to Payment Token Portability is appropriate from the recurring-payments section, but it should not become a major SEO target here. I would not strongly cross-link this article to Multi-PSP Strategy from several sections. The provider portfolio is contextual, whereas currency route selection is the owned decision. Authoritative source recommendations For publication, I would retain a compact source set rather than over-cite the article. The strongest sources are the EU Interchange Fee Regulation for a concrete, authoritative example showing that card cross-border classification involves issuer/acquirer and point-of-sale geography; IFRS IAS 21 for the precise meaning of functional currency; ECB documentation for a real example of payer and recipient currencies differing within one payment path; and Visa/Mastercard official interchange materials for the roles of issuer, acquirer and geography in card economics.

Proposed author and review

Before publication, use four role-based reviews: a payments architect for route and MID logic, an acquiring specialist for domestic/cross-border claims, a treasury/finance specialist for FX and settlement economics, and a reconciliation reviewer for refund and settlement-data treatment. Fact-check requirements Architecture and routing

Provider and acquiring For every concrete future provider example, validate the merchant entity, MID currency, acquirer geography, local-acquiring status, scheme treatment, supported payment methods, settlement currency and contract. Never infer local acquiring from a PSP office, brand, currency list or country page. Any statement that Route A produces lower interchange, higher authorization or better acquiring treatment should require actual merchant configuration and data. Tokens and recurring payments No token-portability claim is necessary for this article. Before adding any provider-switching recurring example, verify token type, ownership, provider usability, network rules, migration capability and customer agreement. Keep the final publication to the principle that credential eligibility constrains fallback unless product-specific portability has been confirmed. Data model

* Transaction/presentment currency * Settlement/payout currency * Merchant entity * Provider * MID/acquirer * Refund amount/currency * FX amount/rate * Fees * Settlement reference

Security/compliance There is no need for a long PCI section in this article. Review is required only if the implementation guidance expands into credential transfer or different checkout integrations. Any market involving exchange controls, repatriation limitations or restricted currency should receive legal/treasury review rather than being presented as a generic payment-routing rule. General disclaimer: This article provides general information and does not constitute accounting, treasury, tax, legal, regulatory, security, or compliance advice. Merchants should validate market-specific payment and currency requirements with qualified specialists and their payment providers.

Cluster sameness-audit record Field Routing Payments by Currency Opening Three routes for the same €100 purchase First conceptual distinction One payment can contain several currencies Primary format Currency-flow investigation + decision tree Evidence anchor “Supports EUR” does not describe the transaction economics Editorial position Route on full path, not FX line item Common assumption challenged EUR should automatically go to a European PSP Merchant decision When currency materially changes route Main visual Currency Routing Decision Tree Primary merchant examples EUR, GBP, JPY, constrained/volatile currency Original framework 9-question Currency Routing Decision Tree Primary economic concept Total cost per completed payment Closing device Currency-routing scenarios + final routing rule CTA direction Evaluate full currency paths / discuss international routing configuration Explicitly not owned General FX strategy, country routing, PSP portfolio, settlement-currency strategy Required differentiation from Article 5 Country determines geographic eligibility; this article follows currency economics through eligible routes Required differentiation from settlement articles This article decides which route; settlement articles decide which currencies to hold/receive

The most important improvement here is that the article never asks “Which provider is best for EUR?” It asks what changes elsewhere in the payment chain when EUR causes the routing decision to change. That should give this article a much clearer search and conceptual territory than either the country-routing piece or the settlement-currency pieces.