Multi-Currency Payment Systems

Multi-currency adds complexity to every payment flow. Understanding the concepts is essential.

Presentment currency: What the customer sees and pays. "€49.99" or "£42.00"

Settlement currency: What arrives in your bank account. May differ from presentment.

Conversion point: When the exchange rate is applied. At checkout, at settlement, or both.

Example flow: - UK customer pays £42.00 (presentment) - Payment provider converts at 1.16 EUR/GBP - You receive €48.72 (settlement) - You record revenue in EUR

FX spread: Payment providers add margin to exchange rates. Typically 1-2% above market rate. Factor into pricing decisions.

How you price across currencies significantly impacts customer experience and your revenue.

Single currency (EUR only): - Simplest to implement - Customers in non-EUR countries pay FX fees - Their bank converts at their rate - You receive consistent EUR amounts

Local pricing: - Set explicit prices per currency - €49, £42, 499 SEK, 449 DKK - Customers see familiar round numbers - You bear FX risk between pricing updates

Dynamic conversion: - Convert your base price at checkout - Customer sees £42.15 (dynamic) - You receive EUR equivalent - Rates change constantly

Hybrid approach: - Local pricing for major currencies (EUR, GBP, CHF) - Dynamic conversion for others - Balance customer experience and complexity

Recommendation: For most European SaaS: price in EUR as primary, with fixed local pricing for GBP (UK market is significant). Use dynamic conversion for other currencies.

Payment providers handle the complexity of multi-currency processing.

Stripe multi-currency: - Present in 135+ currencies - Settle in your preferred currency - Automatic conversion at Stripe's rates - ~1% conversion fee above market rate

Multi-currency settlement: - Receive payouts in multiple currencies - Useful if you have costs in those currencies - Requires bank accounts in each currency

Implementation steps: 1. Create prices in each currency 2. Detect customer's preferred currency 3. Display appropriate price 4. Charge in that currency 5. Receive settlement (converted or multi-currency)

Currency detection: - Browser/device locale - IP geolocation - Customer preference (let them choose) - Account settings for returning customers

Display considerations: - Show currency symbol clearly - Format numbers per locale (€1.234,56 vs €1,234.56) - Indicate if price will be converted

Refunds in multi-currency require careful handling to avoid customer confusion and FX losses.

The problem: Customer paid £42.00 when rate was 1.16. Now rate is 1.14. What do you refund?

Options:

Original currency (recommended): - Refund exactly £42.00 - Customer receives what they paid - You absorb FX difference - Best customer experience

Settlement currency: - Refund EUR equivalent - Customer may receive more or less GBP - Customer confusion guaranteed - Avoid this approach

Implementation: - Store original charge amount AND currency - Refund API call specifies original currency - Payment provider handles conversion

Partial refunds: - Proportional in original currency - £42 order, £10 item refund = £10 refund - Not €10 converted to GBP

Disputes/chargebacks: - Always in original currency - Track by original transaction - Accounting gets complex

Multi-currency creates accounting complexity. Plan for it from the start.

Functional currency: - Your primary accounting currency - Usually where you're headquartered - All reporting converts to this

Transaction recording: - Record in original transaction currency - Record converted amount in functional currency - Store exchange rate used

Revenue recognition: - Convert at rate on transaction date - Or use average rate for period - Consistent policy required

Balance sheet items: - Receivables in foreign currency - Revalue at period end - FX gains/losses flow through P&L

Reporting requirements: - Revenue by currency - FX impact on revenue - Reconciliation to bank statements

Tools: - Accounting software with multi-currency (Xero, QuickBooks) - Treasury management systems - Payment provider reporting exports

Best practice: Work with your accountant to set up multi-currency handling before you start processing. Retrofitting is painful.

When you price in customer's currency, you take on FX risk. Manage it appropriately.

Understanding exposure: - Revenue in non-functional currency - Time between pricing and settlement - Volatility of currency pairs

Risk scenarios: - Price at £42 (worth €49 today) - GBP drops 5% before settlement - Receive €46.55 instead of €49 - Margin erosion

Mitigation strategies:

Frequent price updates: - Review local pricing monthly/quarterly - Adjust based on rate movements - Balance stability and accuracy

Natural hedging: - Match revenue currency with cost currency - If you pay UK contractors in GBP, GBP revenue hedges naturally

Currency buffers: - Price slightly higher to absorb FX movements - £43 instead of £42 (5% buffer) - Trade-off with competitiveness

Financial hedging: - Forward contracts lock in rates - Options provide downside protection - Usually only worthwhile at scale

For most startups: Keep it simple—frequent price reviews and modest buffers. Formal hedging rarely makes sense until you have significant, predictable foreign currency flows.