SAAS PAYMENTS
Multi-Currency Payments for SaaS: How to Accept Global Payments
Anyway Team
· 9 min read ·
To accept multi-currency payments for SaaS, separate the currency shown to the buyer, the currency used for the transaction, and the currency you receive in settlement. Then define a price catalog, renewal rule, refund rule, and accounting record for each market. A hosted MoR checkout can reduce payment and tax work while your application keeps the original transaction record.
Multi-currency payments for SaaS: the three currencies
The word "currency" hides several different values. Name them in your architecture:
Presentment currency: the amount and currency the buyer sees on your pricing page and checkout.
Transaction currency: the currency in which the payment is authorized and recorded for the order.
Settlement currency: the currency in which the provider sends your payout.
They can be the same, but they do not have to be. A buyer may see EUR, a card network may authorize EUR, and your payout may arrive in USD. Your invoice, webhook, finance export, and product entitlement should preserve the original order currency even when you report revenue in a base currency.
This distinction is more useful than simply adding a currency selector. It tells engineering, finance, and support what each number means.
Multi-currency payment models
Model: Fixed local price; Buyer sees: A market-specific amount; Internal price rule: A separate price for each market; Best fit: You want predictable customer-facing prices
Model: FX-derived price; Buyer sees: A converted amount from a base price; Internal price rule: Exchange rate plus rounding rule; Best fit: You want a fast first version
Model: Single settlement currency; Buyer sees: Local or base presentment, one payout currency; Internal price rule: Provider converts before payout; Best fit: You want simpler treasury operations
Model: Multi-entity settlement; Buyer sees: Several payout currencies or entities; Internal price rule: Entity and market routing rules; Best fit: Finance has established regional structures
Start with a small list of currencies that matches your current buyer demand and support capacity. Add a currency only when you can display it, charge it, refund it, reconcile it, and answer a customer question about it.
Step 1: Choose a base price and market prices
Create a product catalog with a canonical internal price. The catalog should include:
Product ID and plan ID.
Base price and base currency.
Market-specific price and currency.
Billing interval.
Effective date for a price change.
Tax display rule for the customer-facing page.
Rounding precision.
For a first launch, you can derive local prices from a base amount and then round to a familiar price point. For a mature product, maintain market prices independently so a change in one region does not unexpectedly change another region's renewal amount.
What can go wrong: A checkout recalculates an FX amount on every page load, while the product database stores only the base price. The buyer sees one amount and the invoice records another. Store the price and currency used for the order as immutable line-item data.
Step 2: Decide when FX is calculated
There are two common rules:
At purchase: the amount is calculated when the buyer starts or completes checkout.
At catalog publication: the local amount is calculated in advance and remains stable until you publish a new price.
The second rule is easier for subscription communication. A customer can understand that a monthly plan renews at a stated amount in the same currency. The first rule can follow market rates more closely, but it needs clear display and a record of the rate used.
Do not promise that a buyer will always be charged the same base-currency equivalent. State the billing currency and show the amount that will be charged for the order.
What can go wrong: A team changes the FX rule without versioning the catalog. Existing subscribers can renew at an amount that was never shown to them. Store the price version with the subscription and define a communication path for future changes.
Step 3: Configure checkout and buyer display
A localized checkout should show the currency code or symbol, amount, billing interval, tax treatment, and support route. Use ISO 4217 codes in APIs and internal records even when the page uses a symbol. The symbol $ alone does not tell a buyer whether the amount is USD, CAD, or another dollar currency.
Anyway's webhook documentation includes the order currency as an ISO 4217 code. Pass that value through your order and finance records. Your account page can show a converted reporting amount, but the original transaction amount should remain visible for support and refunds.
Read SaaS checkout localization for the broader language, form, and payment-method decisions that sit around the currency choice.
What can go wrong: The pricing page localizes the currency, but the checkout returns to a default currency after a browser refresh. Test the complete path from landing page to receipt in a clean session.
Step 4: Multi-currency payments for SaaS: subscription renewals
Subscriptions need a currency rule that survives time. Choose one of these policies and document it:
Keep the subscription in the original currency and price.
Keep the currency but update the local price on a scheduled date.
Recreate the subscription when the buyer changes market or currency.
The first policy is easiest to explain. If a customer changes country, do not silently change their currency on the next renewal. Ask for an explicit plan or billing update and create a new subscription record when necessary.
Anyway lists recurring subscriptions and sends payment events that include order type, currency, and subscription ID when applicable. Use the subscription ID as the stable link to your entitlement, while retaining each renewal's order currency and amount.
What can go wrong: A renewal job uses the customer's current browser locale instead of the subscription's stored currency. The customer travels, changes a device, or changes language and receives an unexpected amount. Make the subscription record authoritative.
Step 5: Handle refunds and partial adjustments
Refunds should use the original transaction currency whenever the provider and payment method allow it. Store the original amount, refunded amount, refund date, and provider reference. If your finance report converts the refund to a base currency, keep the conversion rate and date as a reporting detail rather than replacing the original value.
Explain your refund policy in the same currency language as your checkout. A sentence such as "refunds are returned to the original payment method in the transaction currency" is easier to understand than a promise about a buyer's bank conversion.
Link to your SaaS refund policy guide for a broader operational checklist.
What can go wrong: Support refunds an order by calculating a new FX amount manually. The customer receives a different value and the accounting record cannot tie the adjustment to the original order. Use provider order IDs and an auditable refund action.
Step 6: Reconcile payouts and FX differences
Build two views:
Order view: gross amount, tax, fee, refund, currency, and customer.
Payout view: payout currency, net amount, payout date, and provider reference.
Join them through order and payout IDs. A difference between order value and payout value can come from tax, fees, refunds, timing, or currency conversion. Do not label every difference as an FX loss until the record identifies the cause.
Anyway's finance and payouts documentation describes payout account types and minimum payout rules. Review the current page for your account rather than hard-coding a payout currency or bank method into your public pricing copy.
What can go wrong: The dashboard reports revenue in USD while the payout arrives in another currency, and the team compares the two without a rate or date. Add a reporting currency column and a source timestamp.
Step 7: Add currencies gradually
Use a launch gate for each new currency:
The pricing page can display the amount correctly.
Hosted checkout accepts and confirms the currency.
The invoice and webhook contain the same currency code.
Renewals use the intended stored rule.
Refunds can reference the original order.
Finance can reconcile the payout.
Support can answer a currency question without manual calculation.
Run a small test order and a test renewal before announcing the currency. Keep test and production products separate so a test price cannot be purchased accidentally.
A simple data model
Store amounts in minor units where the currency supports that representation, and use the currency's precision from the provider event. Do not assume every currency has two decimal places.
Common mistakes to avoid
Treating a currency selector as a full localization strategy
Currency is only one part of checkout. Language, address fields, payment methods, tax display, receipts, and support matter too.
Repricing active subscriptions silently
A new FX rate is not a customer communication policy. Version the plan and explain when a new amount applies.
Losing the original transaction currency
A base-currency report is useful for management, but support and refunds need the original amount and code.
Hard-coding payout assumptions
Payout availability is account-specific. Read the official finance documentation and confirm the account during verification.
FAQ
What is the best currency for a SaaS subscription?
There is no universal best currency. Use the currency your target buyer understands and your payment and finance setup can support. Start with a small, measurable set instead of publishing every possible currency.
Should I use fixed local prices or live exchange rates?
Fixed local prices make renewals and customer communication easier. Live rates can reduce manual catalog work but require rate records, rounding rules, and a clear renewal policy. Choose the rule that your support and finance teams can explain.
Does Anyway support multi-currency payments?
Anyway's payment events include an ISO 4217 currency field, and its public product is designed for global checkout. Supported currencies, payment methods, and payout handling depend on the product and account. Confirm the current configuration before publishing a currency list.
How should I report multi-currency SaaS revenue?
Keep the original order currency and amount, then add a separate reporting-currency value with the conversion rate and date. Reconcile the order view to the payout view using provider references.
Can a customer change currency after subscribing?
Treat a currency change as an explicit billing change. Keep the old subscription record, create the new price or subscription according to your provider's flow, and explain the effective date to the customer.
Final checklist
Before you announce multi-currency payments, confirm that your system can:
Display a clear currency code and amount.
Store transaction amounts without losing precision.
Preserve the subscription's original currency.
Process renewals and refunds against the original order.
Record provider event and order IDs.
Reconcile gross orders with net payouts.
Explain tax and FX treatment without making universal claims.
Create an Anyway product and review the finance and payouts documentation before you select your first settlement path.