> ## Documentation Index
> Fetch the complete documentation index at: https://waffo.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

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

> How currencies and payment methods become usable on a Waffo account: order currency versus user currency, where to read what you are enabled for, which error a currency you are not enabled for actually returns, whether enablement is per merchant ID or account-wide, whether one payment method can be priced locally in one market and in USD in another, and whether adding a method affects the ones already running.

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](/docs/en/developer-docs/core-concepts/currency); the pricing strategies themselves in
[Pricing and currency](/docs/en/developer-docs/use-cases/pricing-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?](/docs/en/support/order-amount-and-currency-fields-faq).
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:

| Currency | What it is | Where you send it |
| - | - | - |
| **Order currency** | The currency you price and are accounted in | `orderCurrency` on order creation |
| **User currency** | The currency the payer is actually charged in | `userCurrency`, optional |

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](/docs/en/support/exchange-rates-faq).

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:

| View | Shows |
| - | - |
| **Service → Payin** in the Portal | One row per contracted combination, with an `Order Currency` and a `User Currency` column |
| `POST /api/v1/paymethodconfig/inquiry` | The same set from code — one entry per contract, each with its `currency` and its `orderAmountMin` / `orderAmountMax` |
| Published [Payment Methods](/docs/en/essentials/payment-methods) | The payment currency each method is offered in generally — useful for planning, **not** a statement about your account |

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](/docs/en/support/payin-agreements-and-limits-faq); the
response fields in
[Payment Method Configuration & Limits](/docs/en/support/payment-method-config-and-limits-faq).

## 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`:

| What you sent | Why it fails |
| - | - |
| An `orderCurrency` no agreement of yours carries | The lookup matches the order currency exactly; nothing matches, so no agreement survives |
| A `userCurrency` that is not contracted for that payment method | The user-currency dimension is matched exactly as well |
| A cross-currency pair for which no rate can be applied | The agreement exists, but the order cannot be priced |

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?](/docs/en/support/order-rejection-self-diagnosis-faq).

## 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](/docs/en/support/errors-troubleshooting-guide); which currency the payer
ends up being charged, and why it can surprise you, is in
[Cashier Redirects & Action Types](/docs/en/support/cashier-redirect-and-action-type-faq).

## 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](/docs/en/developer-docs/use-cases/pricing-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](/docs/en/support/settlement-account-structure-faq) and
[Settlement calculation explained](/docs/en/support/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](/docs/en/support/payment-method-config-and-limits-faq).

## 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](/docs/en/support/cashier-display-rules-faq); how the request progresses in
[Payment Enrollment](/docs/en/support/payment-enrollment-faq).

## 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](/docs/en/support/sandbox-environment-and-access-faq).

Fees are commercial terms and appear only on your own Payin page — they are not published anywhere.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.