Multi-Currency Payment Processing: Technical Challenges and Solutions

Multi-Currency Goes Beyond Display Formatting

When your SaaS serves customers across currency zones, multi-currency support affects payment processing, revenue recognition, reconciliation, and financial reporting. Getting it wrong leads to margin erosion through unfavorable exchange rates and accounting complications.

The Three Currency Concepts

Every multi-currency payment involves three potentially different currencies:

Presentment currency: what the customer sees and pays. Customers expect their local currency.

Processing currency: what the card network or payment scheme uses. For European cards, usually the presentment currency.

Settlement currency: what your PSP deposits in your bank account. If different from presentment, FX conversion happens at the PSP level.

Store Amounts in Minor Units

Always store monetary amounts as integers:

// Correct: 29.95 EUR stored as 2995 cents
$payment->amount = 2995;
$payment->currency = 'EUR';

// Wrong: floating point leads to rounding errors
$payment->amount = 29.95;

Currency Precision Varies

Not all currencies use 2 decimal places. JPY has 0 (no minor unit). BHD has 3. Your system must handle this:

function minorUnits(string $currency): int {
    return match($currency) {
        'JPY', 'KRW' => 0,
        'BHD', 'KWD', 'OMR' => 3,
        default => 2,
    };
}

Exchange Rate Strategy

You have three options:

1. PSP-managed conversion. Let your PSP handle FX. Simple but you have no control over rates or margins.
2. Fixed-rate pricing. Set prices per currency manually. No FX risk but requires regular price reviews.
3. Dynamic conversion. Fetch rates from an API and convert at checkout. Most flexible but adds complexity.

For most European SaaS companies, fixed-rate pricing per major currency (EUR, GBP, USD, SEK, PLN) combined with PSP conversion for everything else is the practical sweet spot.

Settlement and Reconciliation

When you accept 5 currencies but settle in EUR, you need to track the FX rate applied to each transaction. Without this, your revenue reporting will never match your bank statements.

$transaction->presentment_amount = 2995;
$transaction->presentment_currency = 'PLN';
$transaction->settlement_amount = 693;
$transaction->settlement_currency = 'EUR';
$transaction->exchange_rate = 4.3234;

Store all three values. Your accounting team will thank you.

How a Multi-Currency Payment Flows From Checkout to Ledger

Presentment, processing and settlement currency describe the payment. Your books add a fourth: the functional currency, the one your company reports in. For a eurozone company settling in EUR they are the same. A UK company that settles in EUR reports in GBP, so it needs one more conversion before anything reaches its accounts.

Each conversion needs its own record. Store the rate as a decimal string or DECIMAL column, never a float, together with its source (your PSP, the ECB reference rate, your own price table) and the time it applied. Many PSPs fix the conversion only when the payment settles, so book the settlement amount when the PSP reports it, not when you authorize the payment.

Convert in minor units with decimal math and round once, at the end:

// 2995 PLN to EUR at 4.3234 PLN per EUR
$exact = bcdiv('2995', '4.3234', 6);        // "692.741823"
$settled = (int) bcadd($exact, '0.5', 0);   // 693, half-up for positive amounts

Both currencies here have two decimals. Between currencies with different precision, such as JPY and EUR, scale by the difference in minor units before you divide.

Refunds are where most multi-currency bugs show up. Refund the customer the presentment amount they paid, 29.95 PLN. If your PSP converts, it uses the rate on the refund date, so the EUR leaving your balance will rarely be exactly 6.93. Book that difference as an FX gain or loss on its own ledger line instead of adjusting revenue.

Payouts add the last step. A PSP payout bundles many payments, minus fees, refunds and chargebacks, into one bank transfer. Match each payment to the PSP's settlement report first, then match the report total to the bank line. See automating payment reconciliation and double-entry ledger architecture for how to structure that.

Practical Recommendations

1. Start with EUR + USD + GBP. Cover 80% of European SaaS customers with three currencies.
2. Use fixed pricing where possible. Less complexity, more predictable margins.
3. Always store minor units as integers. Never use floats for money.
4. Track settlement amounts separately. You need both presentment and settlement for reconciliation.
5. Review exchange rates quarterly if using fixed pricing. Currency markets move.

Multi-currency is a business decision as much as a technical one. Start simple with fixed pricing in major currencies, and only add dynamic conversion when transaction volume justifies the complexity.