Stripe and Multi-Currency Payments for US and European Products

Why local currency matters

A US product expanding into Europe — or a European product selling into the US — faces a decision that looks cosmetic and is not: what currency customers see at checkout. Pricing a German customer in dollars signals "not built for you," adds conversion-fee surprise to their statement, and depresses conversion. Localized pricing is one of the cheapest growth levers cross-Atlantic products have.

Multi-currency is more than display formatting. It touches how prices are set (fixed per market versus converted from a base price), how refunds are valued when exchange rates have moved, how subscriptions renew, and how revenue is reported. Deciding these explicitly at design time is dramatically cheaper than untangling them after finance finds discrepancies.

Stripe handles much of the mechanical burden — 135+ presentment currencies, automatic conversion, local payment methods — but the structural decisions remain yours, and they are the ones that show up in fees and reporting.

Entities and settlement

Presentment currency is what the customer pays; settlement currency is what lands in your bank account. If you charge in euros and settle in dollars, conversion fees apply on every transaction. At meaningful European volume, adding a EUR bank account — or a European entity with its own Stripe account — often pays for itself quickly.

US companies selling into Europe commonly start with a single US entity and accept conversion costs, then add a European entity when volume justifies it. European companies selling into the US face the mirror decision. Model the fee difference at your projected volume before choosing — it is a spreadsheet exercise, not a mystery.

Marketplaces and platforms have an extra layer: paying out sellers or drivers in their currency. Stripe Connect supports cross-border payouts, but supported countries, payout timing, and KYC requirements differ per market — verify the exact corridor (for example, US platform paying EU sellers) before promising it in a contract.

SCA and local payment methods

Strong Customer Authentication is the sharpest US–EU difference. Under PSD2, European card payments generally require two-factor authentication (3D Secure). Checkout flows designed only for US behavior — charge the card server-side, assume success — fail in Europe because they cannot handle the authentication redirect. Using Stripe's Payment Element and Payment Intents handles SCA flows natively; hand-rolled charge logic usually does not.

Cards also matter less in parts of Europe than US teams assume. iDEAL dominates the Netherlands, SEPA Direct Debit is standard for European B2B and subscriptions, and bank-transfer methods are common in Germany. Offering the local method is often worth more conversion than any checkout copy change.

Subscriptions add renewal wrinkles: off-session renewals under SCA rely on exemptions and saved-card mandates, and some renewals still require the customer to re-authenticate. Build the dunning path — email with an authentication link, grace period, retry schedule — before launch in Europe, not after the first failed-renewal spike.

Modeling money correctly

Store amounts as integers in minor units (cents, pence) with an explicit currency code on every monetary value. Floating-point money is the classic slow-motion bug: individual roundings are invisible, and the books drift apart over months. Never store an amount without its currency, and never add two amounts without asserting their currencies match.

Record the exchange rate and both amounts at transaction time for any conversion. When a customer paid €50 that settled as $54.20, both numbers are facts you will need — for refunds valued correctly, for disputes, and for revenue reporting. Deriving historical conversions from current rates is a reconciliation nightmare.

Refunds after rate movement, partial refunds, and disputes are where naive models break. The refund should return the presentment amount the customer paid; your books absorb the rate difference. Encode that as an explicit rule with tests, because support teams will otherwise improvise it per ticket.

Store:   amount_minor=5000, currency=EUR, settled_minor=5420, settled_currency=USD, fx_rate=1.084
Never:   amount=50.00  (float, no currency, no settlement record)

VAT and sales tax

Selling to European consumers means charging VAT at the customer's local rate and remitting it — for digital services, typically via the One Stop Shop (OSS) scheme rather than registering in every country. B2B sales within the EU usually reverse-charge with a validated VAT ID. Your checkout therefore needs to know customer country, business status, and evidence for both.

US sales tax is its own maze: state-by-state economic nexus thresholds mean obligations appear as you grow. Stripe Tax (or a dedicated engine like Avalara) automates calculation for both regimes; what it cannot automate is the decision to collect the right customer data at checkout — country, postal code, VAT ID — from the first transaction.

The engineering rule: tax appears as an explicit line item computed by one service, never spread across ad-hoc calculations. Prices may be tax-inclusive in Europe (consumer expectation) and tax-exclusive in the US — model "price" and "tax treatment" separately so the same catalog serves both markets.

Reconciliation and reporting

Engineering sees payments as API events; finance sees them as bank settlements. The gap between those views is where month-end pain lives. Stripe payouts bundle many transactions, minus fees, minus refunds, possibly across currencies. Build an internal ledger that ties every payout line back to your orders — Stripe's payout reconciliation reports make this tractable if you ingest them from day one.

Webhooks are the backbone of payment state, and they arrive out of order, duplicated, or delayed. Process them idempotently, persist raw events before acting on them, and run a daily job that compares Stripe's view of the world with yours. Silent divergence is the failure mode; the daily diff turns it into a ticket instead of a quarter-end crisis.

Finally, give finance read access to dashboards that speak their language: gross volume, fees, refunds, and net by currency and by entity. Payment systems that only engineering can interrogate become a support bottleneck — and a trust problem — as soon as the business scales.