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.