Currencies and settlement

COMPLETE PUBLICATION-READY PILLAR SECTION Currencies and Settlement “Accepting euros” is not one payment capability. A merchant can show €100 on a product page, charge the customer's payment method €100, receive the resulting proceeds into a USD-denominated provider balance, and ultimately receive a USD payout into its bank account. Another merchant can show the same €100 price, charge the same €100, retain the proceeds in EUR and pay those euros into a EUR bank account. To the customer, the transactions can look identical. To Finance, they are not. Current provider documentation demonstrates that these layers can be separated. Stripe distinguishes the currency of the charge—its presentment currency—from settlement currencies and bank payouts, while Adyen documents payment flows in which the currency the customer pays can differ from the currency in which the merchant or platform user receives funds. Checkout.com similarly asks merchants to specify a settlement currency for each processing currency when configuring processing. The useful question when entering another market is therefore not simply: “Do we support the local currency?” It is: “At which stages of the payment flow do we support it?” “Local currency” can mean several different things For an international merchant, currency appears at multiple stages. Currency layer The question it answers Example Product/base price In what currency does the merchant define the economic price internally? Product is economically priced at USD 110

Display currency What currency does the customer see before payment? Checkout shows €100 Presentment / transaction currency In what currency is the payment actually submitted and charged? Customer is charged €100 Provider balance / holding currency In what currency are merchant proceeds retained inside the provider's relevant balance structure? Proceeds remain in EUR Settlement currency In what currency are the merchant proceeds settled under the provider configuration? EUR or USD Bank payout currency What currency reaches the external merchant bank account? USD reaches US bank account Provider terminology is not perfectly standardized, particularly around settlement and payout. The operational discipline is to ask both questions separately: what currency are merchant funds denominated in after payment processing, and what currency ultimately reaches the bank account? Stripe, for example, describes multi-currency settlement as allowing supported merchants to accrue balances in additional currencies and then directs payouts from those balances to matching bank accounts. Adyen separately describes settlement into balances and payout of those funds to external bank accounts in its relevant product architecture. That is why “EUR supported” is incomplete payment architecture. Trace the €100 payment Consider one simplified international transaction. Customer sees: €100 ↓ Customer pays: €100 ↓ Payment is processed: EUR ↓ FX conversion point: none yet—or conversion occurs here, depending on configuration ↓

Merchant/provider balance: EUR or another configured currency ↓ Settlement currency: EUR or USD ↓ Bank payout: EUR or USD, depending on the supported setup The crucial event is the conversion point. If the merchant charges EUR but wants to receive USD, something must convert the economic value from EUR into USD. The architecture determines who performs that conversion and when. Adyen explicitly documents flows in which the customer's processing currency differs from the merchant user's settlement currency. Stripe similarly states that when a charge's presentment currency differs from the merchant's settlement currency, currency conversion occurs. So local-currency checkout does not inherently require local-currency settlement. The customer-currency decision and treasury-currency decision can be designed independently where the provider, payment method, banking setup and market support that configuration. For the operational mechanics, link deeper to multi-currency settlement explained. Display currency is not necessarily presentment currency The price a shopper sees and the currency actually sent into the payment request should also be treated separately. A merchant might display an approximate local-currency equivalent while still ultimately transact in another currency. Alternatively, the merchant or PSP can construct a genuine local-currency price and submit the payment in that currency.

Stripe's current currency tooling illustrates multiple ways of creating local prices: automatically FX-derived localized prices, merchant-controlled FX quotes, or manually configured static prices in each currency. This creates two different product decisions: Local pricing The merchant deliberately establishes a market price—for example, €99—and manages it as an EUR commercial price. FX-derived pricing A base price—for example, $109—is converted into EUR using an exchange rate or pricing mechanism. Both can produce an EUR amount at checkout. They do not create the same commercial exposure. With a fixed local price, the merchant can absorb exchange-rate changes relative to its base reporting currency until it updates the price. With an FX-derived price, the displayed amount can instead be generated from a current or locked conversion rate, depending on the system used. Stripe's current documentation makes this distinction between manually set currency prices, live FX quotes and automated localized conversion in its own products. The pillar does not need to prescribe one model. The merchant needs to know which model it is actually operating. Where conversion actually happens Once presentment and settlement currencies differ, the next question is where FX enters the chain. Possible conversion points include: Before checkout A base price is converted into a local displayed or presentment price. At or around payment processing

The provider converts between the customer's transaction currency and the merchant's settlement currency. Inside the merchant's provider balance The merchant retains one currency and later converts it into another supported balance or settlement currency. At payout or banking stage A payment or banking provider converts funds before or while sending money to the destination bank account. Later in treasury The merchant receives and retains foreign currency and chooses when and how to convert it separately. Different providers support different permutations. Stripe, for example, documents both automatic conversion into a default settlement currency and, in supported locations, multi-currency settlement that allows balances and payouts in additional currencies. Adyen documents payment-level currency conversion between processing and settlement currencies in a specific platform product, as well as configurations with multiple payout currencies. For every conversion point, Finance should ask five questions: 1. Who performs the conversion? 2. When is the rate fixed or applied? 3. What reference or benchmark is relevant? 4. What markup, spread or separate fee is applied? 5. Could the conversion be avoided by retaining or settling in the original currency? That produces a much more useful FX analysis than asking only, “What is the FX fee?” An “FX fee” is not necessarily one number Foreign-exchange cost can be represented in different ways. A provider might use:

* a reference or benchmark exchange rate plus an explicit fee; * an exchange rate containing a markup relative to a reference rate; * a fixed conversion fee; * another provider-specific pricing structure; or * a combination of components. Adyen's current FX transparency documentation, for example, distinguishes the conversion rate from additional fees and provides examples involving both reference rates and markups. Its payment-conversion documentation separately identifies an applied exchange rate that includes an Adyen markup in that product context. So when evaluating FX economics, do not record only: FX cost: 2% Record what the number means. A more useful treasury record is: Source amount: €100 Destination currency: USD Reference or benchmark: identified source where applicable Applied rate: provider rate Explicit conversion fee: if any Implied spread/markup: where measurable Resulting amount: USD proceeds Conversion stage: payment / balance / settlement / payout / treasury The objective is not semantic perfection. It is to understand the economic path from the customer's currency to usable merchant funds. For merchants comparing those paths in detail, link to how to choose settlement currencies. Currency conversion is not the same as cross-border processing FX and cross-border processing are related but separate dimensions. Currency conversion means value is converted from one currency denomination to another.

Cross-border processing concerns the geographic and acquiring configuration of the payment. The precise definition can vary by scheme and provider, so it should not be reduced to a single universal geography test. A payment can therefore raise a cross-border acquiring question without necessarily requiring FX at the merchant-settlement stage. Conversely, an otherwise supported payment flow can involve conversion simply because the customer and merchant use different currencies. This distinction matters when Finance analyzes costs. Do not put: * acquiring costs; * scheme or network cross-border charges; * PSP processing fees; and * currency-conversion costs into one undifferentiated “international payment fee.” For the mechanics beyond this section, route readers to how cross-border settlement works and, where relevant, local settlement versus international settlement. Local currency is not the same thing as DCC Dynamic currency conversion—DCC—is another concept that should not be used as a synonym for local-currency pricing. Visa describes DCC as a choice offered to a cardholder to convert a transaction into the cardholder's home currency, with the exchange rate and applicable markup or additional fee disclosed. The cardholder must be given the choice to accept or decline the conversion. That is different from a merchant deliberately pricing its product in the market's currency. For example: Merchant local pricing: A French checkout sells the product for a merchant-defined €100.

FX-derived merchant pricing: A USD base price is converted by the merchant or its provider into an EUR checkout price. DCC: A transaction denominated in one currency is offered to the cardholder in the cardholder's home currency under a DCC service. All three can place a familiar currency in front of a customer. Their mechanics, control and economics are different. Choosing settlement currencies After deciding what customers should pay in, Finance needs a separate policy for what currencies the merchant actually wants to retain or receive. A merchant that accepts ten currencies does not automatically need ten settlement currencies. The decision can depend on questions such as: * In which currencies does the merchant have meaningful revenue? * In which currencies does it pay suppliers, refunds or other obligations? * Which currencies can the provider retain or settle under the merchant's configuration? * Which currencies can relevant bank accounts receive? * What conversion occurs if a presentment currency is not retained? * How much operational complexity would additional balances create? * Does holding the currency reduce useful conversions or simply move FX management into Treasury?

Stripe's multi-currency settlement documentation offers a concrete example of this trade-off: in supported locations, merchants can add settlement currencies, retain relevant balances and direct corresponding currency payouts to supported bank accounts rather than automatically converting all incoming funds into the default currency. That is a provider-specific capability, not a universal settlement model. The strategic question is provider-neutral: Is this a currency the merchant actually wants to own and manage, or only a currency the customer needs to pay in? Those are independent decisions. The detailed selection framework belongs in how to choose settlement currencies. Settlement and payout should be mapped separately Currency architecture becomes particularly confusing when teams use “settlement” to mean “money reached our bank.” Provider systems can contain an internal balance or settlement stage before an external bank transfer. Adyen, for example, documents flows where processed funds become available in merchant accounts or balance accounts and are subsequently paid out to a bank account. Stripe's multi-currency model similarly describes accruing currency balances followed by payouts to corresponding bank accounts. For expansion planning, Finance should therefore record both: Provider balance / settlement currency and external bank payout currency Even when a particular provider uses different terminology. That distinction prevents a common planning mistake: “Our PSP can hold EUR”

does not necessarily answer: “Can our entity receive EUR into the bank account we intend to use?” The bank/entity requirements belong in the next pillar section, Local Entities and Bank Accounts. When holding foreign currency becomes a treasury decision Retaining EUR instead of immediately converting to USD can reduce one conversion in some payment architectures. It also gives the merchant another currency exposure to manage. Finance may then need to consider: * forecast inflows in that currency; * refunds or operating expenses in that currency; * bank and provider balances; * conversion policy; * reconciliation; * accounting treatment; * cash concentration; and * when funds ultimately need to move elsewhere in the group. At that point, the question has moved beyond checkout localization and into treasury operations. The relevant deep dive is managing foreign-currency balances. If funds then need to move from foreign operations or overseas accounts into another group entity or home market, repatriating revenue from foreign markets becomes a separate analysis. Country-specific foreign-exchange controls, tax treatment, banking restrictions and corporate requirements should be verified for the actual jurisdictions involved rather than inferred from the payment flow. The currency decision for a new market For each target market, draw the payment path before configuring currencies: Product price → Display currency → Presentment currency → Payment processing → FX conversion point

→ Provider balance currency → Settlement currency → Merchant bank account Then ask at every place where the currency changes: Who converts? When? Using what rate? At what economic cost? Could the conversion be moved or removed? That process forces two separate decisions: Customer decision: Which currency should this customer see and actually pay in? Merchant decision: Which currency should Finance ultimately retain or receive? International currency strategy becomes much easier to reason about once those decisions stop being treated as the same thing.

Regulatory note: This content provides general information and does not constitute legal, regulatory, tax, accounting, or financial advice. Requirements affecting settlement, banking, foreign-exchange controls and movement of funds vary by market, merchant structure, business model, payment provider, acquirer and applicable regulation. Merchants should verify current requirements with qualified advisers, relevant authorities and their payment providers or acquirers. PILLAR SECTION END

Pillar Section 4 — Currencies and Settlement A. Brief interpretation — editorial, not part of the pillar section Section-owned question: Which currency does the customer see and pay in, which currency does the merchant retain or receive, and where does any conversion happen between those points? Merchant problem: “We support EUR” sounds precise but can mean the price is displayed in EUR, the transaction is charged in EUR, the PSP holds EUR for the merchant, or the merchant's bank account receives EUR. Those are different capabilities. Editorial position: Choose the customer-facing currency and merchant settlement currency as separate decisions rather than assuming local-currency checkout requires settlement in the same currency. Key distinction: Presentment currency and settlement currency can differ. Likewise, settlement/balance treatment and the eventual bank payout should be treated as separate operational questions even where a provider's terminology combines them. Evidence anchor: Follow one €100 transaction from product price to checkout, processing, possible FX conversion, merchant balance and bank account. Primary merchant decision: Which currencies should customers pay in, which currencies should the merchant retain or settle in, and at what point should FX conversion occur?

B. C. ORIGINAL SECTION ASSET — INTERNATIONAL CURRENCY FLOW International Currency Flow Product price ↓ Display currency What does the shopper see? ↓ Presentment currency What currency is actually charged? ↓ Payment processing Which payment/acquiring flow handles it? ↓ FX conversion point Does the currency change here? ↓ Provider balance currency In what currency are proceeds retained or recorded? ↓ Settlement currency In what currency does the merchant settle under this setup? ↓ Merchant bank account What currency actually reaches Treasury? At every FX conversion, ask * Who converts? * At what stage? * Which reference or benchmark is relevant? * What rate is actually applied? * Is there an explicit fee? * Is there an embedded markup or spread? * Is another intermediary involved? * Could the conversion be avoided or deferred? Currency architecture worksheet Layer Currency Owner Conversion? Rate/fee source Evidence Product/base price

Product/Finance

Pricing system Display

Checkout Presentment

Payments

PSP/payment request Provider balance

Payments/Finance

PSP balance/report Settlement

PSP configuration Bank payout

Treasury

Bank/PSP setup The asset should be presented as an architecture diagnostic, not as a claim that every provider uses identical settlement terminology.

D. INTERNAL-LINK PLAN — not part of pillar prose Priority Recommended anchor Destination Purpose Type 1 multi-currency settlement explained Multi-Currency Settlement Explained Explain how presentment, retained balances and settlement can differ Specialist cluster page 2 how to choose settlement currencies How to Choose Settlement Currencies Move from conceptual flow to Finance/Treasury decision criteria Specialist cluster page 3 how cross-border settlement works How Cross-Border Settlement Works Explain movement from international processing into merchant settlement Specialist cluster page 4 local settlement versus international settlement Local Settlement vs International Settlement Connect currency architecture to settlement geography Specialist cluster page 5 managing foreign-currency balances Managing Foreign-Currency Balances Deep dive once the merchant deliberately retains multiple currencies Specialist cluster page 6, optional repatriating revenue from foreign markets Repatriating Revenue From Foreign Markets Use only when movement from foreign balances/accounts back to another group market is discussed Specialist cluster page 7, optional foreign-exchange controls by country Foreign-Exchange Controls by Country Use only where country restrictions or regulated currency movement become relevant Country/regulatory specialist page Linking restraint: The first five links are sufficient for the core section. Use the repatriation and FX-controls links only if those paragraphs remain in the assembled pillar.

Recommended reciprocal link: Multi-Currency Settlement Explained and How to Choose Settlement Currencies should link back to the pillar with natural variants such as international payment expansion or currency decisions when entering new markets.

E. SEO SUPPORT — not part of pillar prose Suggested H2: Currencies and Settlement Suggested H3s: * “Local currency” can mean several different things * Where conversion actually happens * Choosing settlement currencies * When holding foreign currency becomes a treasury decision Secondary semantic terms: * display currency * presentment currency * transaction currency * processing currency * settlement currency * payout currency * holding currency * merchant balance * multi-currency settlement * foreign exchange * FX conversion * exchange-rate markup * FX spread * local pricing * dynamic currency conversion * DCC * foreign-currency balance * cross-border settlement * revenue repatriation Featured-snippet opportunity: What is the difference between presentment and settlement currency? Presentment currency is the currency in which the customer is charged. Settlement currency is the currency in which payment proceeds are settled for the merchant under the provider's setup. They can be the same or different, and a conversion can occur when they differ. Provider terminology and supported configurations vary. Supporting visual: International Currency Flow Alt text: “International currency flow showing product price, display currency, presentment currency, payment processing, FX conversion, provider balance currency, settlement currency and merchant bank payout.”

F. EVIDENCE AND VERIFICATION PLAN — not part of pillar prose Current primary sources used Stripe — Supported currencies Useful for the distinction between customer/payment-method currency, presentment currency and settlement-bank currency, and for showing that a charge can be converted when presentment and settlement differ. Stripe — Multi-currency settlement Useful as a current provider-specific example of retaining balances and receiving payouts in additional settlement currencies rather than automatically converting all relevant funds to one default currency. Availability, currencies and pricing are time-sensitive. Stripe — Localize prices Useful for separating merchant-set static local prices, FX-quote-based prices and automatically FX-derived localized prices. Product availability and current pricing should be rechecked before publication if specific capabilities or costs are mentioned. Adyen — Currency conversion for payments Useful for the direct distinction between processing currency—the currency the customer pays—and settlement currency—the currency the platform user receives—in that provider-specific product context. Adyen — Settlement/payout documentation Useful for illustrating that provider balances and external bank payouts can be distinct operational stages. Adyen — Foreign-exchange fee transparency Useful for distinguishing exchange rates, markups and explicit fees rather than collapsing all FX economics into one undefined “FX fee.”

Checkout.com — Processing and settlement currencies Useful current provider-specific evidence that processing currency and settlement currency can be configured as different concepts and that settlement-currency availability can vary. Visa — Dynamic Currency Conversion Primary network source for the high-level DCC distinction: the cardholder is offered conversion into their home currency, with rate and markup/fee disclosure and the choice to accept or decline. Claims requiring current verification before publication Recheck any claim involving: * PSP-supported presentment currencies; * settlement currencies; * multi-currency balance availability; * bank-account requirements by settlement currency; * specific FX rates, fees or spreads; * FX quote duration; * automatic currency-conversion behavior; * DCC requirements; * payout currencies; * country-specific settlement limitations; * cross-border bank-transfer mechanics; * foreign-exchange controls; and * country-specific repatriation requirements. Avoid putting provider currency counts or specific pricing percentages into the pillar unless they are editorially necessary; those values change and are not needed to establish the section's central argument. Recommended authoritative source types For the specialist pages that follow this section, prioritize: 1. card/payment-network rules where network behavior is discussed; 2. official PSP/acquirer currency and settlement documentation;

3. central banks or financial authorities for exchange-control questions; 4. tax authorities for repatriation-related tax claims; 5. official banking documentation for payout/receiving-account requirements; and 6. merchant first-party treasury data when comparing actual conversion economics. Regional/country claims needing separate research This section intentionally makes no claim that: * a merchant must settle locally in any country; * a local bank account is universally required; * a particular currency can always be retained; * revenue can always be freely repatriated; * a particular PSP provides the same FX configuration everywhere; or * one currency structure is optimal in every market. Those questions require market-specific research.

* processes specific currencies; * supports particular settlement currencies; * provides multi-currency merchant balances; * offers like-for-like settlement; * provides FX conversion; * uses a particular FX benchmark or markup; * supports local or international settlement in named countries; * pays out to particular bank-account geographies; * supports DCC; * enables merchants to retain foreign currencies; * offers revenue-repatriation functionality; or * provides particular reconciliation/reporting features for multi-currency payments.

G. HUMAN REVIEW RECOMMENDATION — not part of pillar prose Primary reviewer: Treasury or finance specialist experienced in multi-currency merchant flows. Payments reviewer: Head of Payments, payments architect or payment operations lead who can confirm that presentment, provider balance, settlement and payout terminology is technically precise without implying one PSP's architecture is universal. FX review: Treasury/FX specialist to review the framework for rate, markup, spread and conversion-point terminology. Regional review: Required only if the finished pillar adds specific claims about settlement, bank accounts, FX controls or repatriation in named countries. Legal/tax review: Required for any market-specific claims about exchange controls, revenue repatriation, tax treatment or legal restrictions on currency movement. Recommended last-reviewed practice: Recheck provider currency and settlement documentation whenever the pillar receives a substantive update, because supported currencies, settlement configurations and FX products are time-sensitive.