Routing Payments by Country

Routing Payments by Country: How Global Merchants Choose the Right Payment Route A customer is sitting in France. Their billing address is French. The order will be delivered in France. But the card was issued by a German bank. The merchant selling the product is a U.S. legal entity. Its payment provider can send the transaction through a Dutch acquirer. The merchant also has a French acquiring relationship, although that relationship is available only to its European subsidiary. So which country should the routing engine use? France? Germany? The United States? The Netherlands? The answer is all of them—and none of them alone. Each country describes a different participant or relationship inside the payment. France can describe the customer market. Germany can describe the issuer. The United States can describe the merchant entity. The Netherlands can describe the acquirer. And France can appear again as the destination market or an alternative acquiring configuration. The mistake is treating all of those facts as a single field called: country = FR and then attaching routing logic to it.

Visa's current technical services illustrate how distinct these fields can be. Its BIN Attribute Sharing Service exposes issuer country as an attribute of the issuing BIN, while Visa acceptance documentation separately carries an acquirer country code and a card-acceptor country/location. Visa's merchant-location guidance also treats accurate merchant location as transaction data that acquirers are responsible for representing correctly. Mastercard gateway documentation likewise supports acquirer-link routing rules that can include issuer country, demonstrating that issuer geography can be a routing input without being synonymous with customer geography. This leads to the central rule for country-based payment routing: Do not ask which country the payment belongs to. Ask which geographic attribute controls the decision you are making. And then apply a second rule: Eligibility must come before optimization. The cheapest route is useless if the merchant entity cannot use it. The highest-authorizing route is unusable if the payment method is unavailable. The geographically closest acquirer is irrelevant if the merchant has no eligible acquiring relationship with it. Country routing should therefore begin with correctness, not a leaderboard of PSP performance.

“Country” is not one field A mature international payment model should represent geographic attributes separately. At minimum, merchants may need some combination of: Geographic attribute What it describes Potential routing use Customer/account country Market associated with merchant's customer account Market configuration, localization Billing country Address associated with billing information Fraud, tax, some eligibility checks Shipping/delivery country Destination of physical fulfillment Tax, delivery, market context Issuer country Country associated with card issuer/BIN Card acquiring and route analysis Payment-method country Market in which a local method is offered or eligible Local-method eligibility Merchant entity country Legal entity selling/contracting PSP/acquirer/MID eligibility Merchant location country Merchant location represented for payment purposes Network/acquiring correctness Acquirer country Country/jurisdiction of acquiring configuration Domestic/cross-border analysis PSP contractual country/entity Provider entity serving merchant Contract and service eligibility Seller country Relevant underlying seller in a marketplace Marketplace configuration Device/IP location Observed technical location Risk/context—not authoritative identity Currency market Market inferred from currency Usually weak as geographic evidence Not every merchant needs every field. But merchants should resist converting several of them into one ambiguous country_code.

Once that semantic information is lost, later routing becomes difficult to reason about.

Country fields answer different questions Consider the original French customer. What checkout should we show? Customer market or selected commerce market may be relevant. Which local payment methods can be shown? Customer/payment-method eligibility and merchant/provider availability matter. Which card acquirer should receive the transaction? Merchant entity, issuer country, acquiring eligibility, currency, network configuration, and route performance may matter. Which entity should receive the order revenue? Merchant entity and settlement configuration matter. Is it a domestic card transaction? That cannot safely be inferred merely from the customer's IP or billing address. It depends on the relevant network/acquiring transaction characteristics. Which fraud rules should apply? Multiple attributes could be relevant: * Customer account * Issuer * billing * shipping * device * historical behavior A routing engine therefore needs meaning, not simply geography.

Authoritative, derived, and inferred country signals Country signals also differ in confidence. A useful architecture separates them. Authoritative or contractually established Examples: * Merchant entity jurisdiction * Acquirer jurisdiction * MID configuration * PSP contract * Payment-method configuration These should normally come from merchant-controlled configuration or verified provider metadata. Payment-instrument derived Examples: * Card issuer country derived from current BIN/account-range data Visa's BIN Attribute Sharing Service explicitly exposes issuer-country information and describes maintaining current BIN attributes as important for use cases that include acceptance troubleshooting and authorization-related analysis. A merchant should use an authoritative or appropriately licensed current BIN source rather than assuming the first six digits of every credential permanently encode all required routing information. Customer supplied Examples: * Billing address * Shipping address * Account country Useful, but dependent on: * Accuracy * Customer context * Different billing/shipping situations Inferred Examples: * IP geolocation * Device locale * Browser language * SIM country where lawfully and appropriately available Useful as context. Usually weak as the sole determinant of acquiring eligibility.

Customer IP is not verified transaction geography A French IP address can belong to: * French resident * Tourist * VPN user * Corporate network * International traveler * Customer whose card and account are based elsewhere IP location may be valuable for: * Fraud scoring * Checkout defaults * Risk anomalies * Localization hints But the routing system should not silently convert: ip_country = FR into: issuer_country = FR or: merchant_transaction_country = FR or: use_french_mid = true Those are different propositions.

Country routing begins with eligibility Imagine three potential routes: Route Acquiring configuration Historical issuer approval Effective cost A Domestic 95% 1.8% B Regional 93% 1.5% C Global 92% 1.4% A naive optimizer might choose A. But suppose the payment belongs to Merchant Entity US, and MID A is contractually available only to Merchant Entity EU. Route A's 95% approval rate is irrelevant. It is not an eligible route. This is why performance should never rescue a route that failed a correctness gate. The proper sequence is: Potential routes ↓ Merchant/entity eligibility ↓ Payment-method eligibility ↓ Provider/acquirer/MID eligibility ↓ Regulatory and network correctness ↓ Currency compatibility ↓ Technical health ↓ Performance/cost optimization Only routes that survive the upper gates should reach the optimizer.

Eligibility is not merely provider country coverage A PSP may advertise that it operates in France. That does not establish that a particular merchant can process every French payment through every French configuration. Production eligibility can depend on: * Merchant entity * Merchant category * Acquirer * MID * Acceptance channel * Currency * Card or payment method * Provider contract * Risk underwriting * Local scheme rules * Settlement model Visa's rules are themselves geographically scoped: current Visa guidance states that regional or country-specific rules can apply to transactions, merchants, issuers, and acquirers operating in those relevant regions or countries. Mastercard similarly states that additions or modifications to its rules may apply by country, region, or other geographic area. So: Provider availability is the start of eligibility analysis, not the conclusion.

Merchant entity should usually be an early routing gate For a multi-entity merchant, the seller cannot safely be selected at the end of payment routing. Suppose a group contains: US Corp EU Ltd Singapore Pte. Ltd. Each may have different: * PSP contracts * Acquirers * MIDs * Merchant categories * Settlement accounts * currencies * Tax treatment * Customer terms A payment routing engine should ordinarily receive an already-resolved merchant entity or execute a controlled merchant-entity determination before selecting routes. Otherwise the system can make a logically impossible choice: Use Acquirer X followed by: Which merchant entity owns the Acquirer X relationship? That reverses the dependency. A safer hierarchy is: Who is selling? ↓ Which payment configurations can that seller legally and contractually use? ↓ Which of those configurations should process this payment?

Merchant entity country is not acquirer country A German merchant can potentially use a non-German acquiring configuration. A U.S. merchant can potentially have eligible acquiring relationships outside the United States. A multinational can use different acquiring countries for different entities or traffic populations. Therefore preserve: merchant_entity_country acquirer_country as separate fields. Do not derive one from the other. Visa's acceptance API documentation itself distinguishes acquirer country and card-acceptor country/location as discrete transaction attributes.

Merchant location needs its own governance Merchant location is not a convenient routing label that an optimizer should rewrite dynamically. Visa's merchant-location guidance requires accurate merchant business-location data, while its Merchant Data Standards separately address ecommerce merchant location. So a merchant should not reason: French customer → set merchant location France → transaction becomes French. Merchant-location data must reflect the permitted acquiring and merchant configuration. Routing selects among valid configurations. It should not fabricate the properties that would make an invalid route appear valid.

MID selection belongs inside the eligible route A MID is not merely a reporting field appended after PSP selection. It can represent a specific acquiring configuration. A merchant may have: * Global MID * French MID * UK MID * Subscription MID * Travel MID * Backup MID The route should therefore be modeled more completely than: route = PSP_B A more useful route object might be: route_id merchant_entity_id provider_id acquirer_id mid_id payment_method transaction_currency authentication_profile settlement_profile country_configuration_id Not all merchants need all these attributes. The design principle is that the route represents a valid payment configuration, not just a provider name.

Local acquiring is not geographic proximity Suppose the customer is in France. Provider A processes through an acquirer in the Netherlands. Provider B processes through a French acquiring arrangement. Provider C's European operations center happens to be in Paris, but the merchant's transactions are acquired elsewhere. Which is “closest”? The question has almost no architectural value. Local acquiring is about the acquiring arrangement and applicable merchant/network configuration, not server location, office address, or physical proximity to the customer. Card-network documentation reinforces the distinction among issuer, network, and acquirer participants. Mastercard describes a normal card transaction as moving between the issuer and acquirer through the network, while Visa separately identifies merchant/acquirer and issuer attributes. The routing question should therefore be: Is an eligible local acquiring route available for this merchant and transaction? not: Which PSP is nearest?

Local acquiring should be a route attribute, not a global assumption A route can be classified, after verification, as something such as: acquiring_scope: domestic regional cross_border unknown But the classification must have an explicit definition appropriate to the merchant/network analysis. Do not derive it solely from: customer_country == acquirer_country because the customer country may not be the relevant network geography. The merchant may instead need attributes involving: * Merchant location * Issuer country * Acquirer jurisdiction * Network region * Entity configuration The exact rules are network- and market-specific.

Why local acquiring might enter the optimizer Once a local route is known to be valid, it can be compared with other eligible routes. Potential dimensions include: * Authorization * Payment completion * Cost * Domestic card/scheme access * Settlement * Provider concentration * Operational reliability But local acquiring should not automatically receive priority. A locally acquired route can be: * More expensive * Operationally weaker * Poorly integrated * Less reliable * Limited for certain card types The merchant needs evidence. This is where the adjacent What Is Local Acquiring? and local-acquiring cluster should take over the deeper economics and authorization analysis.

Country routing for local payment methods is different from card routing Consider a domestic bank or wallet method available only in Market X. If the customer selects that method, routing may become much simpler: Payment method X → Provider B → Market X merchant configuration → Required settlement/acquiring/payment-method path Here, the payment method itself can heavily constrain the eligible provider set. The merchant should therefore model: Method availability Is the method theoretically integrated? Merchant eligibility Can this merchant entity/category use it? Customer eligibility Can this particular customer use it? Route eligibility Which provider/configuration can process it? These are separate.

A method being “available in France” is not enough Suppose a provider lists Method F as available in France. Before adding it to routing, determine: * Which merchant entities can contract for it? * Which customer population is eligible? * Which currencies are supported? * Which providers can initiate it? * Does it require a French or European entity? * What merchant categories are excluded? * How are refunds processed? * Does it support recurring transactions if required? * Which settlement model applies? Country routing should consume a verified capability configuration, not marketing coverage.

The Country Routing Decision Tree This is the article's central framework. Gate 1 — Which merchant entity is selling? Resolve: * Merchant entity * Entity jurisdiction * Merchant category * Channel * Product/business unit where relevant If the merchant entity is unknown, stop. Do not route first and decide the seller afterward. Output Set of configurations contractually and legally available to that merchant entity.

Gate 2 — Which payment methods are eligible? Determine: * Customer-selected method * Market method availability * Customer eligibility * Transaction type * One-time/recurring * Provider integration * Currency Output Eligible method configurations. If the customer selected a local method, this may reduce the route set dramatically.

Gate 3 — Which providers can legally and contractually process? Filter for: * Merchant contract * Merchant category * Country configuration * Channel * Provider/acquirer permissions * Production status A provider appearing in the merchant's codebase is not enough. Output Eligible providers.

Gate 4 — Which acquirer/MID configurations are valid? For cards, evaluate: * Acquirer * MID * Merchant entity * Merchant location * Issuer/card eligibility * Channel * MCC * Credential type * Authentication configuration Mastercard gateway documentation provides a concrete illustration: an acquirer link can contain exclusion rules based on card type, funding method, and issuer country. That is exactly the sort of constraint that belongs in this gate. Output Valid acquiring routes.

Gate 5 — Is an eligible local acquiring configuration available? Classify the remaining acquiring options. Possible values: * Local/domestic * Regional * Cross-border * Unknown/unverified Do not automatically select local. Simply preserve the attribute for subsequent analysis. Output Eligible routes with acquiring classification.

Gate 6 — Which routes support the required transaction currency? Check: * Transaction currency * Acquirer support * MID/configuration support * Payment-method currency This is only a currency eligibility gate. Detailed optimization by currency belongs in Routing Payments by Currency. Output Currency-compatible routes.

Gate 7 — Which routes are healthy? Before optimization, remove routes that are operationally unsafe. Possible inputs: * Provider incident * Acquirer unavailable * Elevated technical failures * Authentication outage * Known configuration failure * Circuit breaker * Manual operations disablement A provider that is “up” globally may still have a broken country-specific acquiring route. Health should therefore be measured at the narrowest operationally useful level. For example: provider + acquirer + market + payment_method rather than provider alone. Output Healthy eligible routes.

Gate 8 — Which healthy eligible route performs best? Now—and only now—optimize. Potential objective: * Completed-order performance * Authorization * Cost * Reliability * Provider concentration * Settlement * Merchant-defined weighted objective Use matched populations. Do not compare a French domestic route handling returning debit-card customers with a global route handling all foreign-issued cards and conclude that geography caused the entire difference. Output Primary route.

Gate 9 — What fallback is safe? Determine: * Is another eligible route available? * Does the credential work there? * Is authentication reusable or repeatable? * Is payment state known? * Can retry cause a duplicate? * Is the fallback valid for the same merchant entity/method/currency? * Does customer interaction need to restart? Output Safe fallback policy—or no fallback. “No safe fallback” is a legitimate routing result.

Country Routing Decision Tree: compact version PAYMENT REQUEST | v 1. Which merchant entity is selling? | v 2. Which payment methods are eligible? | v 3. Which providers can process this merchant + market? | v 4. Which acquirer/MID configurations are valid? | v 5. Which routes are local/regional/cross-border? | v 6. Which routes support required currency? | v 7. Which eligible routes are healthy? | v 8. Which route performs best under current objective? | v PRIMARY ROUTE | v 9. If it fails, is another route SAFE? | +--+--+ | | YES NO | | v v FALLBACK FINAL FAILURE / UNKNOWN-STATE RECOVERY The important architecture is the ordering. Optimization is eighth. Eligibility begins at first.

Scenario 1: domestic customer, domestic issuer A French customer: * Customer market: France * Billing: France * Issuer: France * Merchant entity: eligible European merchant * Presentment: EUR * Local French acquiring route: available * Regional acquiring route: available The engine first confirms that both acquiring configurations are valid. Only then may it compare them. Potential comparison dimensions: * Issuer approval * Completed-order rate * Cost * Technical failure * Settlement * Operational reliability If the domestic route performs materially better after controlling for traffic mix, the merchant may give it priority. If not, “French customer” alone does not justify selecting it.

Scenario 2: French customer, German-issued card Now change one fact: Issuer country = Germany. The customer and checkout market remain France. This is a useful reminder that customer routing and card routing can diverge. France may still control: * Checkout language * Delivery * Tax context * Method display But issuer country may be more relevant when comparing acquiring performance for the card. Mastercard gateway documentation explicitly supports issuer-country conditions within acquirer-link exclusion rules, while Visa provides issuer-country BIN attributes separately from merchant/acquirer geography. The engine therefore should not overwrite German issuer geography merely because the order's market is France.

Scenario 3: cross-border card A customer in Brazil: * Customer account: Brazil * Billing: Brazil * Issuer: United States * Merchant: U.S. entity * Card: U.S.-issued * Delivery: digital * IP: Brazil What should “country route” mean? For customer experience, Brazil may remain the appropriate market. For the card-acquiring comparison, a U.S.-issued card can behave differently from Brazil-issued traffic. A rigid rule: if customer_country == BR: route_to_brazil_acquirer may therefore send an internationally issued credential into a route that was designed or optimized for domestic Brazilian cards. A stronger rule first tests whether that route is valid for the specific issuer/card population.

Scenario 4: local payment method A Netherlands customer chooses a local account-based payment method. Relevant attributes may be: * Customer market * Method eligibility * Merchant entity * Provider * Currency * Method contract Issuer-country card logic may no longer be relevant because this is not a card transaction. The route could collapse from five candidate PSPs to one or two provider configurations. That is correct. A routing system should not manufacture choice where the payment method itself imposes valid constraints.

Scenario 5: multi-entity merchant A global merchant has: * U.S. entity * EU entity * UK entity The French customer is eligible to contract with the EU entity under the merchant's approved commercial structure. The routing system receives: merchant_entity = EU_ENTITY market = FR currency = EUR method = CARD issuer_country = DE Candidate routes must now be selected from the EU entity's acquiring portfolio. The engine should not route to a high-performing U.S.-entity MID merely because historical German issuer approval happens to be better there. The route failed the first gate.

Scenario 6: marketplace Marketplaces add at least one more country. Suppose: * Buyer: France * Seller: Italy * Marketplace entity: Ireland * Issuer: Germany * Acquirer: Netherlands Which country matters? Different ones can affect: * Buyer checkout * Seller eligibility * Merchant/payee structure * Marketplace acquiring * Payouts * Tax * Fraud Do not overload: country = FR or: country = IT to represent the transaction. The marketplace needs explicitly modeled buyer, seller, merchant, issuer, and acquiring geography. Payment-facilitator structures make these distinctions even more important. Mastercard defines a payment facilitator as an acquirer-registered service provider facilitating transactions for submerchants, which means the acquiring architecture can include distinct intermediary and underlying-merchant identities. Detailed marketplace legal and payout architecture belongs elsewhere; the routing lesson is simply that seller country is another geographic dimension, not a replacement for buyer or acquirer country.

Routing is not failover These terms should remain distinct. Routing Selecting a route before the attempt is sent. Example: French-issued card → French acquirer based on a valid policy. Primary route The first eligible route selected for the attempt. Fallback A defined alternative route used when the primary cannot or should not process the payment. Failover Operational movement to another route because a route is unavailable or unhealthy. Retry Another attempt after an unsuccessful or uncertain attempt. A retry can use: * Same route * Different route and should not automatically be called failover. Cascading Sequential attempts across routes/providers, usually after particular outcomes and under controlled rules. Load balancing Distribution among multiple healthy eligible routes according to a policy rather than an individual failure. Country routing can participate in all of these, but they solve different problems.

A fallback route must pass the same eligibility gates This seems obvious. In practice, incident logic often bypasses normal architecture. Suppose: French acquiring route is unavailable. The emergency rule says: Send France to Global PSP B. Before enabling that route, confirm: * Same merchant entity is eligible. * Currency is supported. * Credential is available. * Method is supported. * MCC is eligible. * Authentication can be handled. * MID/configuration is valid. * Settlement works. * Route is actually operational. Fallback should not mean: Ignore the rules because the primary is down. It means: Select the next valid route.

A decline is not necessarily a reason to fallback Suppose an issuer says: Insufficient funds. Sending the same payment to another acquirer is unlikely to create money in the account. Likewise, blindly rerouting after: * Expired credential * Customer cancellation * Certain fraud rejection * Certain authentication failures may be pointless or inappropriate. Fallback policies should distinguish: * Provider technical error * Acquirer unavailability * Timeout * Issuer decline * Authentication failure * Merchant rejection * Unknown state Mastercard's gateway documentation itself distinguishes response states such as issuer declines, acquirer system error, authentication failure, pending, submitted, timeout, and other technical outcomes. The routing layer should preserve the distinction rather than translating all of them into: failed = true.

Unknown state is more dangerous than a failed route Suppose the primary provider times out. The routing engine does not know whether: 1. The provider never received the authorization. 2. The acquirer received it. 3. The issuer approved it. 4. The provider processed it but the response was lost. Immediately sending another authorization through the fallback can create a duplicate payment. The correct next action may be: * Query provider status * Await asynchronous event * Reconcile using merchant reference * Use idempotency controls * Delay alternate routing This is why: Country failover must preserve payment state. A second eligible PSP does not create safe fallback if the merchant cannot determine what happened at the first one.

Provider health should be route-specific Suppose PSP A is processing: * UK cards normally * French cards normally * Polish BLIK normally but its German acquirer link is failing. A single: provider_status = HEALTHY is too coarse. A single: provider_status = DOWN is equally wrong. Health can be modeled at combinations such as: provider acquirer payment_method country_configuration currency depending on architecture. The merchant then disables only the affected route. This reduces unnecessary failover.

Country ambiguity is normal Not every transaction yields clean geography. Examples: * Customer has no billing address yet. * Digital product has no shipping country. * BIN lookup returns unknown issuer country. * Customer uses a corporate card issued centrally. * Customer travels. * IP conflicts with account country. * Marketplace buyer and seller differ. * Customer chooses a currency unrelated to location. A routing engine needs explicit policies for ambiguity. Do not allow null fields to fall accidentally into the first provider in an array.

Unknown issuer country Mastercard gateway documentation explicitly contemplates unknownIssuerCountry in its acquirer-link rules. That is a useful architectural lesson. Unknown should be modeled as an actual state: issuer_country = UNKNOWN not silently converted into: issuer_country = customer_country unless the merchant has a documented, justified policy for doing so. The fallback for unknown issuer geography might be: * A globally eligible acquirer * A default regional route * A route verified to accept unknown/foreign credentials The exact choice depends on merchant architecture.

Conflicting country signals should remain visible Suppose: customer_country = FR billing_country = FR shipping_country = FR issuer_country = DE ip_country = NL That is not necessarily an error. The correct response is not: Majority vote says France. Instead: * Use customer market for market configuration. * Use billing data where that attribute is relevant. * Preserve issuer country for card analysis. * Treat IP mismatch as a possible risk signal. * Apply merchant/acquirer rules independently. Different signals can coexist because they describe different things.

Define a source for every routing attribute A routing schema should record both value and, where useful, provenance. For example: customer_market = FR customer_market_source = ACCOUNT_PROFILE

issuer_country = DE issuer_country_source = NETWORK_BIN_DATA

ip_country = NL ip_country_source = GEOIP_PROVIDER

merchant_entity = EU_ENTITY_1 merchant_entity_source = COMMERCE_CONFIG Why record provenance? Because routing teams eventually need to answer: Why did this payment go to Route B? The answer should be reproducible.

Do not hard-code another country branch for every launch A fragile routing system evolves like this: if country == "US": PSP_A elif country == "DE": PSP_B elif country == "FR": PSP_C elif country == "PL": PSP_D The fifth country adds another branch. Then requirements become: * German issuer but Austrian customer * French MID only for EUR * Polish PSP only for BLIK * Global fallback during outage * EU entity only * Brazil cards routed differently by issuer * Provider temporarily disabled The code becomes a map of organizational history rather than payment policy. A scalable design tends to separate: Stable routing engine Evaluates standardized conditions. from: Market configuration Contains the actual country/provider/MID rules.

Country configuration as data A conceptual configuration could resemble: market: FR

merchant_entities: - EU_ENTITY

methods: card: eligible_routes: - route_fr_local - route_eu_regional

routes: route_fr_local: provider: PROVIDER_A acquirer: ACQUIRER_FR mid: MID_FR currencies: - EUR acquiring_scope: domestic

route_eu_regional: provider: PROVIDER_B acquirer: ACQUIRER_EU mid: MID_EU currencies: - EUR acquiring_scope: regional

fallback: card: - route_eu_regional This is illustrative—not a production schema. The architectural value is that adding Portugal can potentially become a configuration change rather than a new provider-specific code path.

Configuration needs versioning Routing is financially consequential. A merchant should know which routing rules were active when a payment occurred. Record: routing_policy_version country_configuration_version route_id decision_timestamp This allows payment teams to answer: * Which rule chose the route? * Was the provider healthy? * Which routes were eligible? * Which configuration version was live? * Did yesterday's routing change cause today's decline anomaly? Without versioning, post-incident analysis becomes guesswork.

Store the route decision—not only the final PSP A useful payment-attempt record might contain: payment_attempt_id merchant_entity_id customer_market billing_country shipping_country issuer_country issuer_country_source payment_method transaction_currency

selected_route_id provider_id acquirer_id mid_id acquirer_country acquiring_scope

routing_policy_version routing_reason fallback_sequence fallback_used Preserve relevant provider-native information separately. This article does not own the complete canonical payment-data schema; that belongs in Global Payment Data Standardization. But country routing cannot be operated responsibly if its decisions are invisible after execution.

Routing reason codes Human-readable routing logic becomes easier to operate when every decision has a reason. Examples: LOCAL_ACQUIRING_PRIMARY LOCAL_METHOD_REQUIRED_PROVIDER MERCHANT_ENTITY_ELIGIBILITY ISSUER_COUNTRY_OPTIMIZED REGIONAL_DEFAULT PRIMARY_ROUTE_UNHEALTHY FALLBACK_TECHNICAL_FAILURE UNKNOWN_ISSUER_DEFAULT MANUAL_ROUTE_OVERRIDE Avoid free-form-only routing logs. Reason codes allow: * Dashboards * Incident review * Audit * Experiment analysis * Configuration cleanup

Country-routing accuracy The primary architecture metric should measure whether the routing engine followed intended configuration. Country-routing accuracy Eligible routed payment attempts sent to the intended valid country configuration ÷ eligible routed payment attempts × 100 The numerator should not mean: PSP returned HTTP 200. It means the payment reached the route that policy intended, including the correct relevant: * Merchant entity * Provider * Acquirer * MID * Method * Currency configuration Define precisely what “intended configuration” contains.

Route-eligibility failure rate Route-eligibility failure rate Payment attempts rejected or blocked because the selected route was not eligible ÷ routed payment attempts × 100 Possible reasons: * Merchant entity * Country * Merchant category * Currency * Method * Card type * Acquirer * MID * Contract configuration This should approach zero through configuration correctness. It is not a payment-performance metric. It is an architecture-quality metric.

Authorization by route Issuer approval rate Issuer-approved authorization requests on route ÷ eligible authorization requests on route that reached issuers × 100 Do not compare route A with route B without controlling for: * Issuer country * Issuer * Card type * Currency * Authentication * Fraud decisions * Transaction value * Customer cohort * Retry status * Time period Country routing changes traffic composition by design. Raw route approval can therefore be deeply misleading.

Completed-order rate by route Completed-order rate Completed paid orders originating from the defined routed population ÷ eligible checkout/payment population assigned to that routing comparison Define the denominator consistently. A route can have excellent authorization but poor payment completion because of: * Authentication * Capture * Technical problems * Customer abandonment Authorization is not the merchant's final objective.

Local-acquiring share Local-acquiring share Eligible payment attempts processed through verified local-acquiring routes ÷ eligible payment attempts for which local acquiring is available × 100 Do not use: local volume ÷ all global payment volume unless that is genuinely the question. And do not assume a higher local-acquiring share is better. It measures architecture usage. Performance and economics determine value.

Fallback usage Fallback usage rate Payment attempts using a fallback route ÷ payment attempts eligible for a configured fallback × 100 Segment by reason: * Primary technical outage * Acquirer outage * Timeout after confirmed no-processing * Maintenance * Manual disablement * Other approved cause A rising fallback rate can be an early incident signal.

Fallback success Fallback completion rate Completed payments through fallback ÷ safe fallback attempts initiated × 100 But pair it with: * Duplicate-payment rate * Unknown-state rate * Fraud * Authorization * Cost A fallback that “recovers” payments while creating duplicate charges is not successful.

Provider failure rate by country route Routing-related provider technical failure rate Attempts failing because the selected provider/acquirer route encountered a technical processing problem ÷ valid attempts submitted to that route × 100 Do not mix: * Issuer declines * Fraud blocks * Customer cancellation into provider technical failure.

Routing-related technical error rate Examples include: * No eligible route * Invalid MID * Unsupported currency * Wrong merchant entity configuration * Missing provider credential * Unsupported method * Routing configuration lookup failure Routing technical-error rate Attempts unable to proceed because of merchant routing/configuration errors ÷ attempts reaching routing evaluation × 100 This is one of the clearest measurements of whether the country-routing architecture itself works.

Cost by route Effective route payment cost Defined payment/acquiring/provider costs attributable to route ÷ processed payment value through route × 100 For a commercial comparison, also calculate: Cost per completed order Defined route-attributable payment cost ÷ completed paid orders through route Do not choose a route on headline processing fee alone.

Route quality should be multidimensional A route score might consider: * Eligibility: mandatory * Health: mandatory * Authorization * Completion * Cost * Technical stability * Settlement * Provider concentration But avoid hiding business decisions in a mysterious composite score. If weights are used, document them. For example: ELIGIBILITY = hard gate HEALTH = hard gate

then optimize: completed_order_value - payment_cost - expected_operational_cost The exact formula is merchant-specific. A black-box “smart routing score” that operations cannot explain is difficult to govern.

Common country-routing error 1: Customer country equals issuer country It often does not. Travelers, international cards, corporate cards, expatriates, cross-border banking, and centralized issuing arrangements make divergence routine. Preserve both.

Common error 2: Billing country equals customer market Sometimes. Not always. A business can bill a corporate address in one market for a user in another. A customer can ship elsewhere. A digital customer can move. Define customer market in the commerce domain rather than deriving it opportunistically from whichever field happens to exist.

Common error 3: IP determines acquiring IP can contribute context. It should not silently manufacture acquirer eligibility.

Common error 4: The local PSP is the local acquirer Provider branding, office location, or regional headquarters does not establish acquiring geography. Verify the acquirer and merchant configuration.

Common error 5: Provider supports country, therefore merchant is eligible Country coverage is not merchant eligibility. Verify: * Merchant entity * MCC/category * Method * Currency * Contract * Acquirer/MID * Production approval

Common error 6: Local acquiring always wins No. Local acquiring can deserve evaluation. It should win only when: * Eligible * Healthy * Compatible * Commercially superior under the merchant's objective after a fair comparison.

Common error 7: Cheapest route wins A cheap route that reduces completed orders can destroy more value than it saves. Cost belongs after correctness.

Common error 8: Fallback is any other PSP Fallback is another eligible, credential-compatible, state-safe route. Otherwise it is simply a second integration.

Common error 9: Timeout equals failure A timeout can mean unknown state. Country-routing logic that interprets unknown as decline creates duplicate-charge risk.

Common error 10: Market rules live only inside code If the architecture requires a software release every time: * A MID changes * Provider is disabled * Market launches * Fallback order changes the routing layer may be too tightly coupled for the merchant's operating scale. Not every merchant needs a control plane. But merchants operating many markets/providers generally benefit from making frequently changing routing policy explicit and versioned.

Testing country routing before production 1. Configuration validation For every market confirm: * Entity * Methods * Providers * Acquirers * MIDs * Currency * Fallbacks Reject impossible combinations before customer traffic reaches them.

2. Country scenario matrix Test at least: * Domestic customer + domestic issuer * Domestic customer + foreign issuer * Foreign customer + domestic issuer * Unknown issuer * Conflicting billing/IP * Local method * Unsupported method * Unsupported currency * Provider outage * Acquirer outage

3. Shadow routing Where architecture permits, run the new routing policy without actually sending traffic through the selected route. Record: * Route old policy chose * Route new policy would choose * Eligibility * Reason This can reveal unintended traffic movements before money is at risk.

4. Controlled traffic split When comparing two valid routes, use comparable populations. Control for: * Issuer * Card type * Currency * Authentication * Fraud * Customer * Value * Time Do not route all strong customers to A and all uncertain customers to B and then call the result optimization.

5. Failover exercise Disable a primary route deliberately in a controlled environment. Validate: * Eligibility recalculation * Token/credential access * New route selection * Idempotency * Payment state * Customer messaging * Settlement * Reconciliation A fallback that has never been exercised is an assumption.

What would disprove the country-routing architecture hypothesis? Suppose the thesis is: A configuration-driven eligibility-first country router will reduce invalid routing while allowing merchants to select higher-value acquiring routes safely. Evidence against the architecture could include: * Country configuration becomes harder to operate than direct integrations. * Eligible routes are incorrectly filtered. * Route changes increase unknown payment states. * Fallback creates duplicate attempts. * Country-level optimization provides negligible performance or economic value. * Engineering effort exceeds the merchant's actual international complexity. * Operations cannot explain route decisions. * Provider-specific capabilities are lost behind abstractions. * Configuration drift causes more incidents than hard-coded routing did. For a merchant with: * Two markets * One PSP * One acquiring relationship a sophisticated country-routing engine may be unnecessary. Architecture should follow actual routing complexity.

When simple country routing is enough A smaller merchant might legitimately use: US -> Provider A EU -> Provider B if: * Merchant entity structure is simple * Eligible routes are stable * Methods are limited * Currency is simple * No dynamic acquiring decision exists * Fallback is unnecessary The goal is not sophisticated routing. The goal is correct routing. Add abstraction when change frequency and configuration diversity make simpler architecture expensive or unsafe.

When a dedicated country-routing layer becomes more useful The business case strengthens as the merchant adds: * Multiple merchant entities * Multiple PSPs * Multiple acquirers * Country-specific MIDs * Local payment methods * Local and cross-border acquiring * Several currencies * Provider fallback * Dynamic health controls * Performance optimization At that point, geography is no longer a one-line if statement. It becomes a structured routing dimension.

Final merchant recommendation Global merchants should not design country routing around: Where is the customer? That question is necessary for some decisions but insufficient for payment routing. Instead, ask in order: 1. Which merchant entity is selling? That constrains the commercial and acquiring architecture. 2. Which payment method is being used? That determines which provider paths are even possible. 3. Which providers are actually eligible? Not which providers advertise the country. 4. Which acquirer and MID configurations are valid? The route must represent a legitimate merchant/acquiring relationship. 5. Is local acquiring available? Record it as a route characteristic; do not automatically make it the winner. 6. Which routes support the required currency? Currency compatibility is an eligibility condition. Currency optimization is a separate routing problem. 7. Which routes are operationally healthy? Do not route to an eligible route that is currently broken. 8. Which surviving route produces the strongest merchant outcome? Compare comparable populations using: * Completed orders * Authorization * Technical reliability * Cost * Settlement * Operational impact 9. What fallback remains safe? The answer may be another route. Or it may be: none until the original payment state is resolved. Globally standardize: * Geographic field definitions * Route identity * Eligibility logic * Routing audit trail * Health semantics * Payment state * Reason codes * Metrics Keep configurable: * Country * Entity * Methods

* Providers * Acquirers * MIDs * Currency support * Route priority * Local-acquiring treatment * Fallback Keep provider-specific where it genuinely belongs: * Provider API * Acquirer implementation * Error codes * Health indicators * Country/product limitations The final rule is: Country should narrow the set of valid payment routes before it helps optimize among them. That is much more powerful than routing to the PSP nearest to the customer. It also produces a system that can explain why a payment went where it went—which becomes increasingly important with every country, entity, provider, and acquiring relationship the merchant adds.

Original practical asset: Country Routing Decision Tree This should become the article's primary proprietary visual and implementation worksheet. Hard gates Merchant entity ↓ Payment-method eligibility ↓ Provider contractual eligibility ↓ Acquirer/MID validity ↓ Regulatory/network configuration ↓ Currency compatibility ↓ Route health Optimization layer Completed-order performance Authorization Cost Settlement Operational reliability ↓ Primary route Recovery layer Known failure? → evaluate safe fallback Unknown payment state? → resolve state before another charge attempt Core rule Optimization cannot override an eligibility failure.

Supporting visual “Which Country Is This Payment?” Place one transaction in the center: French customer buying €100 item Around it show: * Customer country: France * Billing country: France * Shipping country: France * Issuer country: Germany * Merchant entity: United States * Acquirer: Netherlands * PSP: European provider entity * IP country: Belgium Then map each arrow to its correct use: Customer market → checkout configuration Issuer country → card-route eligibility/performance analysis Merchant entity → contractual/acquiring eligibility Acquirer country → acquiring structure IP → contextual/risk signal Central message: One payment can have several valid countries. Routing fails when they are collapsed into one. Alt text: “International payment showing distinct customer, billing, issuer, merchant-entity, acquirer, PSP and IP countries feeding different payment-routing decisions.”

Measurement plan Metric Definition Purpose Country-routing accuracy Correct intended country configuration ÷ eligible routed attempts Architecture correctness Route-eligibility failure Eligibility/configuration rejects ÷ routed attempts Configuration quality Issuer approval by route Issuer approvals ÷ eligible auth requests reaching issuer Card performance Completed-order rate Completed paid orders ÷ defined eligible routed population Commercial performance Local-acquiring share Verified local-route attempts ÷ locally eligible attempts Architecture usage Provider technical-failure rate Provider technical failures ÷ valid attempts sent to route Route health Fallback usage Fallback attempts ÷ fallback-eligible attempts Incident/routing behavior Fallback completion Completed fallback payments ÷ safe fallback attempts Recovery Unknown-state rate Attempts with unresolved payment outcome ÷ valid attempts State safety Routing technical errors Router/config failures ÷ routing evaluations Architecture quality Effective route cost Defined payment cost ÷ processed value Economics Cost per completed order Route-attributable cost ÷ completed paid orders Commercial economics Always segment when relevant by: * Customer market * Issuer country * Merchant entity * PSP * Acquirer * MID * Currency * Payment method * Card type * Route * Authentication * Transaction value * New/returning customer * Routing-policy version

Routing edge cases Customer is in France but uses a U.S.-issued card. Which country should control routing? There is no universal single country. France may control market configuration, while U.S. issuer country can be relevant to card-route eligibility and performance. Merchant entity, currency, MID, and acquirer constraints still need to pass first. Should issuer country override customer country? Not globally. They describe different things. Choose the geographic attribute appropriate to the decision. Should an IP mismatch block country routing? Not automatically. IP is contextual evidence, not a universal source of payment geography. It may be useful to fraud controls or customer-market validation. Should local acquiring always be preferred? No. It must first be verified as eligible and then compared on merchant outcomes. Can fallback route to a PSP in another country? Potentially, if that route remains valid for the merchant entity, payment method, currency, credential, and applicable acquiring configuration and if payment state makes another attempt safe. What should happen when issuer country is unknown? Treat unknown as a real state. Mastercard gateway configuration itself supports handling unknown issuer country as a distinct condition. Use a verified default route rather than silently pretending the issuer matches another geographic field.

The uploaded brief makes this article the geographic routing-control article for the International Payment Architecture cluster. Its defining idea is unusually important: “country” is not one attribute of a payment. A transaction can simultaneously have a customer country, billing country, shipping country, issuer country, merchant-entity country, merchant-location country, acquirer country, and provider jurisdiction—and each can answer a different routing question. Editorial interpretation Unique evidence anchor: A French customer can buy from a U.S. merchant entity with a German-issued card through a Dutch acquirer. Asking “what country is this payment?” is therefore underspecified. Editorial position: Route for correctness before optimization. First determine the correct merchant entity, eligible payment method, contractual/provider eligibility, valid acquiring relationship and MID, regulatory scope, and currency support. Only after those gates pass should authorization performance, cost, or other optimization decide among the remaining routes. Common assumption challenged: “Route the transaction to the PSP closest to the customer.” Merchant decision supported: Determine which geographic signal should control each part of routing and establish a safe hierarchy for primary routes, fallbacks, and ambiguous-country cases. Selected format: Routing decision tree.

Structural rationale: Begin with the multiple geographic identities inside one transaction, turn those attributes into eligibility gates, and only then introduce performance optimization and fallback. Proposed architecture 1. Which country are we actually routing? 2. The geographic signals inside one payment 3. Geographic evidence: authoritative, derived, and inferred 4. Eligibility before optimization 5. Merchant entity, merchant location, MID, PSP, and acquirer 6. Local acquiring without “nearest PSP” logic 7. Local payment methods 8. The Country Routing Decision Tree 9. Six routing scenarios 10. Primary routing versus fallback and failover 11. Unknown and conflicting geography 12. Country configuration as data, not code branches 13. Observability and routing audit trail 14. Measurement 15. Common country-routing failures 16. Testing and rollout 17. Final recommendation 18. Routing edge cases Editorial/SEO/fact-check package SEO recommendations SEO title: Routing Payments by Country: A Guide for Global Merchants H1: Routing Payments by Country: How Global Merchants Choose the Right Payment Route Meta description: Learn how to route payments by country using customer, issuer, merchant-entity and acquirer geography, local acquiring, MIDs, provider eligibility, health and safe fallback. URL slug: /routing-payments-by-country/ Primary keyword: routing payments by country Secondary keywords: * country based payment routing * payment routing by geography * international payment routing * local acquiring routing

* PSP routing by country * global payment routing * payment routing rules * country routing payments * merchant payment routing Related entities: Payment routing, merchant entity, customer country, issuer country, billing country, shipping country, acquirer, acquirer country, PSP, MID, local acquiring, cross-border acquiring, BIN, local payment method, payment failover, payment retry, payment state. Article excerpt: A payment can have a French customer, German issuer, U.S. merchant entity and Dutch acquirer at the same time. Country-based payment routing should therefore start with merchant, method and acquiring eligibility before using geography to optimize authorization, cost or performance.

Internal-link recommendations Routing Payments by Currency Link from the currency-eligibility gate. Suggested anchor: routing payments by currency Boundary: this article establishes whether the country route supports the requested currency; the currency article should own FX, settlement, currency-specific route economics, and deeper currency selection. Multi-PSP Strategy for Global Merchants Link where eligible providers are determined. Suggested anchor: designing a multi-PSP portfolio Boundary: this article decides where an existing provider portfolio routes traffic; the Multi-PSP article owns why each provider belongs in the portfolio. Global PSP vs Regional PSP Link from provider country coverage versus merchant eligibility. Suggested anchor: global PSP vs regional PSP What Is Local Acquiring? Link when defining local versus regional/cross-border acquiring. Suggested anchor: how local acquiring works Also link selectively to: * Domestic Merchant IDs Explained * How to Build a Multi-Country Payment Stack * Global Payment Data Standardization * Global Payment Reporting

Authoritative source recommendations For publication, prioritize current primary technical and network sources. Visa Useful current areas include: * Visa Core Rules * Merchant Data Standards * BIN Attribute Sharing Service * Acceptance API definitions * Merchant-location guidance Visa's current technical material is particularly useful because it demonstrates that issuer country, acquirer country, and card-acceptor/merchant country are separately represented data concepts. Mastercard Use: * Current Mastercard Rules * Transaction Processing Rules * Gateway/acquirer-link technical documentation Mastercard's current gateway materials are useful for demonstrating that issuer-country logic can constrain an acquirer link rather than serving as a generic “customer country” field. Mastercard's Transaction Processing Rules are also useful for distinguishing payment routing at the network level from the merchant's own PSP-selection logic; current rules contain dedicated authorization and domestic transaction routing provisions. PCI Security Standards Council Use when the actual implementation involves: * Cardholder data * Routing services touching account data * Provider/service-provider architecture * Tokenization * PCI scope PCI DSS remains the baseline technical and operational standard for environments in which payment account data is stored, processed, or transmitted. Do not expand PCI discussion here unless routing architecture materially changes data handling.

Proposed author and reviewers Proposed author A payments architecture lead or senior payments technical writer with hands-on knowledge of acquiring, provider integrations, payment state, and multi-entity routing. Do not assign a name until approved. Payment architect — required Review: * Routing hierarchy * Country data model * Eligibility gates * Fallback * Unknown-state handling * Configuration design Regional acquiring specialist — required Review: * Merchant entity/acquirer relationships * MIDs * Local acquiring classifications * Merchant location * Country-specific acquiring statements Payment operations reviewer — strongly recommended Review: * Route health * Incident behavior * Manual override * fallback * metrics * support/escalation Security/compliance reviewer — when implementation detail warrants Review: * Geographic/payment data * Cardholder-data exposure * Token/credential use during fallback * Access control * Audit trail

Architecture fact-check items Before publication verify: * Definition of customer market * Merchant entity resolution * Route object fields * MID architecture * Acquirer-country treatment * Merchant-location handling * Primary/fallback semantics * Unknown-state model * Health-check granularity * Routing-policy versioning * Manual override * Idempotency behavior * Payment-state recovery * Audit trail * Configuration rollback Do not imply the sample YAML/schema is production-ready.

Provider fact-check items For each provider in an actual implementation verify: * Contracting provider entity * Merchant entities eligible * Countries advertised * Countries actually approved * Merchant categories * Methods * Acquirers * Acquirer countries * MIDs * Merchant-location configurations * Currency * Card types * Local acquiring * Authentication * Settlement * Fallback support * Health/status signals * Technical errors * Provider maintenance behavior A country in a provider's public coverage list is not sufficient evidence of route eligibility.

Routing fact-check items Verify every routing rule against: * Merchant entity * Method * Issuer/card population * Currency * Acquirer * MID * MCC * Contract * Relevant network rule * Provider configuration Particularly verify claims that: * A route is domestic * An issuer population belongs on a specific acquirer * A route is lower cost * A route improves approval * Another PSP is a safe fallback * A retry is appropriate after a given failure * A credential can be used on an alternative route

Token fact-check items Token portability is not owned by this article, but fallback can depend on it. Before claiming a second provider can receive routed stored-card traffic, verify: * Token type * Token owner * Token domain restrictions * Provider portability * Network-token configuration * Credential availability * Required customer reauthentication * Recurring credential rules EMVCo describes payment-token processing as involving tokenized credentials through merchant, acquirer, network, and issuer environments and notes that regional/country implementation requirements can exist. Do not treat a provider token as automatically routable elsewhere.

Data-model fact-check items Verify definitions and sources for: * Customer market * Account country * Billing country * Shipping country * Issuer country * Device/IP country * Merchant entity * Merchant location * Acquirer country * Provider entity * MID * Payment method * Currency * Route ID * Route reason * Local-acquiring classification * Routing-policy version * Fallback reason * Health status * Payment state Preserve raw provider/network geography where needed for debugging. Do not create one overloaded country field.

Security and compliance fact-check items If the router or routing service handles account data, verify current PCI DSS implications with qualified specialists and the merchant's acquirer/provider. PCI SSC states that PCI DSS establishes baseline technical and operational requirements to protect payment account data, and outsourcing processing does not automatically eliminate every merchant responsibility. Also verify where relevant: * Cardholder-data exposure * Token handling * Access control * Routing-configuration permissions * Audit logging * Secrets * Data retention * Privacy * Data residency * Regulatory routing restrictions This article provides general information and does not constitute security, legal, regulatory, or compliance advice. Merchants should validate architecture and data-handling requirements with qualified specialists and relevant payment providers.

Amber-flag claims Require current evidence before publishing any claim that: * Provider X locally acquires in Country Y. * Route X has domestic treatment. * A customer-country match makes a payment domestic. * Issuer country should always control acquiring. * A local acquirer improves authorization. * A local route is cheaper. * A particular MID is valid for a merchant entity. * Provider X accepts all foreign-issued cards through its local route. * PSP X is an eligible fallback. * A credential is portable between providers. * Provider health can be detected within a stated latency. * Failover is automatic. * A timeout is safe to reroute. * Country X requires a particular routing model. * A geographic signal can legally be used for a stated purpose in every jurisdiction.

Geography * Supported merchant entity countries * Customer countries * Acquirer countries * Merchant-location rules Acquiring * Local acquiring markets * Regional acquiring * Cross-border acquiring * MIDs * Merchant-category eligibility Routing * Country-based routing inputs * Issuer-country routing * Entity routing * MID routing * Health-based routing * Performance routing * Cost routing * Manual overrides * Fallback * Failover * Retry behavior Payment methods * Country availability * Merchant eligibility * Provider route * Currency * refunds * recurring support Credentials * Provider tokens * Network tokens * Portability * Multi-acquirer use Operations * Route-level health * Error classification * Payment state * Unknown-state recovery * Reporting * Reconciliation * Audit trail

A safe eventual direction is: An international payments partner can help merchants connect local methods and acquiring relationships across markets, but merchants should still understand which geographic attributes determine eligibility and how route selection, fallback, payment state, and reporting are governed.

Cluster sameness-audit fields Article: Routing Payments by Country Opening: One French customer, German card, U.S. merchant entity, and Dutch acquirer create four simultaneous countries. Primary format: Routing decision tree. Unique evidence anchor: “Country” is not one payment field. Editorial position: Eligibility and correctness precede performance and cost optimization. Common assumption challenged: Route to the PSP geographically closest to the customer. Merchant decision: Which geographic signal controls each routing decision and how the merchant chooses a safe route. Primary technical distinction: Customer country versus issuer country versus merchant entity versus acquirer country. Other key distinctions: Local acquiring/geographic proximity; availability/eligibility; primary/fallback; routing/failover; IP/verified geography. Main examples: Domestic customer/domestic issuer, cross-border card, local bank method, multi-entity merchant, marketplace, conflicting geography. Original framework: Country Routing Decision Tree. Primary metric: Country-routing accuracy. Supporting metrics: Route-eligibility failures, authorization, completed orders, local-acquiring share, provider technical failures, fallback usage, unknown-state rate, routing errors, and route cost. Conclusion: Country should filter the set of valid routes before helping choose the best route.

CTA direction: Continue into Routing Payments by Currency or Multi-PSP Strategy for Global Merchants, depending on whether the merchant's next constraint is currency or provider portfolio. Closing element: Routing edge cases instead of a conventional generic FAQ. Adjacent-content boundary: This article does not own the rationale for having multiple PSPs, detailed currency optimization, token portability, full canonical payment-data design, or global payment operations governance. That keeps the article distinct from the cluster pillar: the Multi-Country Payment Stack article asks how the entire payment system should be structured; this article asks how one particular transaction chooses the geographically correct path through that system.