47 Currencies: Choosing a Multi-Currency WooCommerce Payment Gateway

Multi-currency in WooCommerce usually gets discussed as a display problem: show prices in the visitor's currency. The harder problem is the payment one. Can your gateway actually charge in that currency, or does it quietly convert, round oddly, and hand your customer a total that does not match what they were just looking at?

Display currency vs charge currency

These are two different things, and mixing them up causes most multi-currency complaints:

• Display currency is what a currency-switcher plugin shows on your product pages. It is presentation.
• Charge currency is what the processor actually bills. If your gateway cannot charge in the currency you displayed, something has to give, and it is usually your customer's trust when the total changes at the last step.

Broad native charge support means the two agree. That is the only version of multi-currency that does not generate support email.

The 47 natively charged currencies

These reach Whop exactly as your store prices them, with no conversion step:

USD · EUR · GBP · CAD · AUD · JPY · CHF · SEK · NOK · DKK · NZD · SGD · HKD · MXN · BRL · INR · PKR · AED · SAR · QAR · KWD · BHD · OMR · JOD · EGP · TRY · PLN · CZK · HUF · RON · BGN · ILS · ZAR · NGN · MYR · THB · PHP · IDR · COP · CLP · PEN · ARS · TWD · VND · KES · GHS · MAD

What happens outside that list

Anything not listed converts to USD at a live rate at payment time. Two things follow, and both are good:

1. You never maintain a manual price table per currency. Your WooCommerce prices stay the single source of truth.
2. You do not get rounding surprises from a stale conversion rate sitting in a settings field somewhere.

The trade-off is that customers in those markets get billed in USD, which their bank may convert again. If a currency matters commercially and it is on the native list, price in it.

Where this list is unusually strong

The interesting part is not USD and EUR. Everyone has those. It is the coverage in markets the big processors serve badly:

• Gulf: AED, SAR, QAR, KWD, BHD, OMR, JOD
• South Asia: INR, PKR
• Africa: NGN, KES, GHS, EGP, ZAR, MAD
• Latin America: BRL, MXN, COP, CLP, PEN, ARS
• Southeast Asia: SGD, MYR, THB, PHP, IDR, VND

If you have been pricing everything in USD because your processor only speaks USD and EUR, and absorbing the complaints that come with that, this is the part of the spec that changes how you operate.

How the plugin picks a currency

It reads your WooCommerce store currency at the moment the checkout is created and sends it along with the cart total. Because the checkout is built per order rather than mapped to a pre-made plan, there is no currency stored anywhere that can drift out of sync with your settings. That architecture is described in why manual plan IDs are obsolete, and the older currency-matching mechanics in syncing cart currencies in WooCommerce checkout.

Testing multi-currency properly

1. Set your store currency to each one that matters and place a sandbox order in each.
2. Check the amount charged equals the cart total to the minor unit. Test a zero-decimal currency like JPY specifically, because that is where assumptions break.
3. Test a coupon and a shipping cost together. Rounding errors surface there.
4. Test one currency outside the native list and confirm the USD conversion does what you expect.
5. Check the payment form language follows the locale too. See the 28-language list.

Currency and language are the same problem

Someone in Jakarta seeing IDR pricing and then an English-only payment form is only half served. Native currency removes the pricing friction; a localised form removes the comprehension friction. You want both, and both are in every licence.