Do I Have to Enable a Currency Before I Can Use It?

Short answer: there is no separate “enable this currency” switch. A currency is usable when it is on one of your payment-method agreements, so “is my currency enabled?” and “am I enabled for this payment method?” are the same question asked twice. This page works through the consequences, including the error code that catches everybody out. Amount formats, decimal-place rules and the full currency list are in the published Currency handling; the pricing strategies themselves in Pricing and currency. Which of an order’s several amount fields to verify, ship against and reconcile — and why finalDealAmount legitimately differs from orderAmount — is in Which amount and currency fields do I check?. What follows is about enablement, not fields or formatting.

​

Which two currencies does an order have?

Every payin agreement carries both, and they do different jobs: When the two are the same, the order is same-currency. When they differ, it is cross-currency and an exchange rate is applied — see Exchange Rates. The distinction matters for enablement because each is checked separately: your agreement has to carry the order currency, and — if you pin the user currency yourself — the pair has to be contracted too.

​

Where do I see which currencies I can use?

Three views of the same configuration: Use the first two to answer “can I do this today”, and only those two. Column-by-column reading is in Payin Agreements & Transaction Limits; the response fields in Payment Method Configuration & Limits.

​

Does a given payment method take USD, or only the local currency?

It depends on the row, not on the method. The same payment method can be contracted in more than one order currency, and it is normal for a method to appear several times on Service → Payin — one row per currency — with different limits on each. So the question is answered per row: find the method, read its Order Currency, and if you intend to pin what the payer is charged, read its User Currency too. Do not generalise from one market to another, and do not cache the answer in your integration — read it from the inquiry call.

​

I sent a currency I am not contracted for. Which error do I get?

A0018 — “Payment method in merchant order does not match with current merchant contract.” Not a currency-specific code. This is the single most misleading thing about currency enablement: the message talks about the payment method, but the rejection may be entirely about the currency. Three currency-shaped ways to get A0018: Reading A0018 as “the payment method is wrong” sends you off to check the wrong thing. Treat it as “no agreement of mine matched this whole request”, then work through the dimensions — see When my order is rejected, what do I check?.

​

How do I avoid the currency-pair version of this?

Omit userCurrency. If you do not pin it, the checkout resolves what the payer is charged and converts your order amount at the current rate, so you only need the order-currency half to be contracted. Send userCurrency only when you have a reason to fix the payer-facing currency yourself, and only for pairs you can see on Service → Payin. Existing guidance on the same code from the payment-method side is in Common Errors Troubleshooting; which currency the payer ends up being charged, and why it can surprise you, is in Cashier Redirects & Action Types.

​

Can I price locally in one market and in USD in another?

Yes. Pricing lives on the agreement row, and rows are per country and per currency, so different markets can be set up differently — local-currency pricing in some, a single global currency in others — including for the same payment method. There is no account-wide setting that forces one choice on all of your markets. What you cannot do is decide it per request: you send an orderCurrency that one of your rows carries. If a market is contracted only in its local currency, an order priced in USD for that market is an A0018, and the fix is a contract change, not a parameter change. The three pricing shapes and the parameters each implies are in the published Pricing and currency.

​

Is the currency my money is settled in the same thing?

No — settlement currency is a third, separate dimension, configured on your settlement setup rather than on the payin agreement. An order can be priced in one currency, charged to the payer in a second, and settled to you in a third. See Settlement account structure and Settlement calculation explained.

​

Is a payment method enabled for my whole account, or per merchant ID?

Per merchant ID. An agreement belongs to one merchant ID, and order creation looks up agreements for the merchant ID you signed the request with. So enabling a method for one of your merchant IDs does not enable it for another, and if you run several — one per business line, one per region — name every merchant ID that needs it when you ask. The practical consequences:

• The same request that works against one merchant ID can return A0018 against another. Check which merchant ID your API key belongs to before you suspect the payload.
• Service → Payin and the inquiry call always answer for one merchant ID at a time.
• If you got a parameter error naming your merchant ID, the mismatch is between the ID in the body and the ID the key belongs to — see Payment Method Configuration & Limits.

​

Can I be enabled by region rather than country?

The dimension on an agreement row is a country, plus a distinct Global entry for the payment methods that do not belong to any one country. There is no region unit in between, so “Europe” or “Japan and Korea” is expressed as the set of countries you want, each becoming its own rows. That is worth knowing when you plan a rollout: ask for a list of countries rather than a region name, and expect the resulting Service → Payin page to have one row per country and currency combination rather than one row per region.

​

Will adding a payment method disturb the ones I am already running?

No, and no downtime is involved. Agreements are independent rows: adding one creates new rows and leaves the status, limits and refund rules of your existing rows untouched. Live traffic on the methods you already run is unaffected while the new one is being set up. On your side, nothing has to change either — unless you want to name the new method explicitly. If you let the checkout show whatever you are contracted for, a newly Active row simply starts appearing; if you pass payMethodName / payMethodType yourself, you decide when to start sending the new value. Where newly signed methods show up on the checkout is in Cashier Display Rules; how the request progresses in Payment Enrollment.

​

Are the limits and currencies I saw in the sandbox the same in production?

No — and nothing you read in the sandbox should be treated as a production value or as a quotation. Read the production values from your production Portal, or from /api/v1/paymethodconfig/inquiry against production credentials, and validate against those before you create an order. Why the sandbox figures exist at all, and what they are and are not evidence of, is in Sandbox Environment & Access. Fees are commercial terms and appear only on your own Payin page — they are not published anywhere.