> ## 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.

# Which Amount and Currency Fields Do I Check?

> An order carries several amounts — orderAmount, originalAmount, finalDealAmount, the amount the user actually paid, and a user fee — in up to three currencies. This page says which field to compare when you verify an order, which one to ship goods against, why finalDealAmount legitimately differs from orderAmount, and which currency to create the order in.

Most amount questions turn out to be the same question: *there are several amounts on the
order and I do not know which one is mine.* This page is the field-by-field answer.
Two neighbouring pages cover the adjacent ground and are the faster read for their topic:

| Page | Use it for |
| - | - |
| [Amounts and currencies](/docs/en/developer-docs/core-concepts/currency) | Decimal-place rules per currency, and the same-currency vs cross-currency definition |
| [Order Amounts, Limits & Declines](/docs/en/support/order-amount-precision-and-decline-faq) | Amount **rejected** at order create — precision, rounding, limits |
| [Exchange Rates in Payments & Settlement](/docs/en/support/exchange-rates-faq) | Which rate is used, when it is fixed, and where to see it |
| **This page** | Which amount field means what, and which one to compare |

## Which amount fields does an order carry?

| Field | Where it appears | What it is |
| - | - | - |
| `orderAmount` | You send it on create; echoed on inquiry and in the payment notification | **The amount you asked for**, in `orderCurrency` |
| `orderCurrency` | Same | The currency you priced in |
| `originalAmount` | Inquiry / notification | The order amount **before** a discount was applied. Absent when no discount applied |
| `finalDealAmount` | Inquiry / notification | The final amount the user paid — see below for why it can differ from `orderAmount` |
| `userCurrency` | Optional on create; echoed back | The user's payment currency, when it is not `orderCurrency` |
| `payMethodResponse.userPaymentAmount` | Inquiry / notification, inside `paymentInfo.payMethodResponse` | The amount the user actually paid **on the payment method's side** |
| `payMethodResponse.userPaymentCurrency` | Same | The currency of that payment |
| `orderAction.actionData.paymentAmount` / `paymentCurrency` | Order-create response only | What the user is being asked to pay, for merchants rendering their own checkout |
| `orderAction.actionData.userFeeAmount` / `userFeeCurrency` | Order-create response only | A fee charged to the **payer** on top of your amount, itemised |
| `remainingRefundAmount` | Refund response / refund inquiry | How much of the order you can still refund |

All amounts are **strings**, not numbers — the published reason is float precision: `0.1 + 0.2`
is not `0.3`, which is unacceptable for money. Parse them as decimals.

## How should I verify that an order is the one I created?

Compare **`orderAmount` + `orderCurrency`** against the values you sent, keyed by your own
`paymentRequestId` or `merchantOrderId`. Those two fields are your own input echoed back, so
they are the only pair that is guaranteed to equal what you asked for.

Do **not** verify by comparing `finalDealAmount` to your expected amount. It is a different
quantity by design, and two entirely normal situations make it differ — which is the next
question.

> [!WARNING]
>
> Verify against `orderAmount`, but do not treat a redirect back to your site as the result.
> The authoritative result is the webhook or [Order Inquiry](/docs/en/support/payment-results-faq),
> whatever the amounts say.

## Why is `finalDealAmount` different from `orderAmount`?

The API contract names two reasons, and both are normal:

1. **Your order currency is not the user's payment currency.** A cross-currency order is
   priced by you in one currency and paid by the user in another, so the two numbers are in
   different units and will not match.
2. **The user paid an additional service fee.** Where the payment method charges the payer a
   fee, that fee is included in `finalDealAmount`, so it is larger than your amount.

So `finalDealAmount` answers *"what did this cost the user"*, and `orderAmount` answers
*"what did I charge"*. Ship goods and run business validation against `orderAmount`; use
`finalDealAmount` only when you want to show the user what they paid.

## Can `orderCurrency` and `userCurrency` really be different?

Yes — that is exactly what a cross-currency order is: you price in your own currency and the
user pays in theirs. It is not an error state and it is not limited to any one payment-method
category. The published definition and the parameters that go with it are in
[Amounts and currencies](/docs/en/developer-docs/core-concepts/currency); the practical rule for
order creation is that a cross-currency order needs `payMethodCountry` when you have not
pinned `payMethodType` or `payMethodName`, while `userCurrency` itself stays optional.

If your reconciliation assumes one currency per order, build for three fields from the start:
`orderCurrency` (yours), `userCurrency` / `userPaymentCurrency` (the user's), and your
settlement currency (see [Settlement calculation explained](/docs/en/support/settlement-calculation-explained)).
They are three separate things and only the first is under your control at order time.

## What exactly did the user pay, in their own currency?

`paymentInfo.payMethodResponse.userPaymentAmount` with
`paymentInfo.payMethodResponse.userPaymentCurrency`. That block is the payment method's own
view of the transaction and also carries:

| Key in `payMethodResponse` | What it is |
| - | - |
| `payMethodRefId` | The reference the **user** sees in their own payment history — quote this one when a user disputes whether they paid |
| `exchangeRate` | The rate the payment method used during the user's payment |
| `maskCardData` | For a successful card payment, the first six and last four digits |
| `userOpenId` | The user's unique id at that payment method |
| `userPaymentAmount` / `userPaymentCurrency` | The amount and currency actually paid |

It is a JSON string, and which keys are present depends on the payment method — read it
defensively rather than assuming a fixed shape.

## Can I compute the user's net payment as `finalDealAmount` minus the user fee?

No — not from the inquiry response. `userFeeAmount` and `userFeeCurrency` are returned in
**`orderAction.actionData` on the order-create response**, not as top-level fields on Order
Inquiry or in the payment notification. So at the moment you are reconciling, you generally
do not have the fee as a separate number to subtract, and a subtraction across two currencies
would be wrong anyway.

Use instead:

* **Did I get charged the right amount?** → `orderAmount` + `orderCurrency`.
* **What did the user pay in total?** → `finalDealAmount`, or `userPaymentAmount` for the
  payment-method-side figure.
* **What was the fee?** → capture `actionData.userFeeAmount` at create time and store it, if
  you need it later.

## Is a user fee only charged on over-the-counter payments?

The API does not scope it that way. `userFeeAmount` / `userFeeCurrency` live in
`orderAction.actionData`, which is the block for merchants building their own checkout, and
nothing in the contract restricts them to one `payMethodType`. Treat a payer fee as *possible*
on any method and read the field, rather than deciding by method category — the same advice as
for `finalDealAmount`: read it, do not infer it.

If you use the Waffo checkout page, the user sees the fee on the checkout itself; you do not
have to render it.

## What is `originalAmount`, and which amount do I validate a discount against?

`originalAmount` is the order amount **before** a discount was applied. When a promotion code
or coupon has been used, `orderAmount` is the discounted, payable amount and `originalAmount`
is the pre-discount figure you priced.

So for business checks — entitlement, fulfilment, "did they pay enough for this SKU" — use
`orderAmount`, because that is what was actually charged. Use `originalAmount` only for
display or for measuring discount impact. Coupon and promotion-code mechanics, including what
happens to a discount on refund, are in
[Coupons & Promotion Codes](/docs/en/support/coupons-and-promotion-codes-faq).

## Which amount should I reconcile my finances against?

Neither `orderAmount` nor `finalDealAmount` on its own — those are order-level fields, before
fees and before settlement conversion. For money reconciliation use the settlement reports,
which carry the amount, the fees and the settlement currency together:
[Settlement reports](/docs/en/support/settlement-reports-faq) and
[Settlement calculation explained](/docs/en/support/settlement-calculation-explained).

The order-level fields are for *order* reconciliation — proving that the order you created is
the order that was paid. Keep the two exercises separate; that is the single most common cause
of "your numbers do not match mine".

## Do I have to create the order in the local currency?

No. `orderCurrency` is **your pricing currency**, and a cross-currency order — you price in
one currency, the user pays in another — is a supported, first-class flow. Whether a
particular payment method can serve a particular order currency depends on the contracts on
your account, which is a lookup, not a guess:

| Where to look | What it tells you |
| - | - |
| `/api/v1/paymethodconfig/inquiry` | One entry per payment-method contract in force on your account, each with its `currency` and its `orderAmountMin` / `orderAmountMax` |
| Portal → Payin | The same contracts, as a screen you can read and filter — see [Payin Agreements & Transaction Limits](/docs/en/support/payin-agreements-and-limits-faq) |
| [Payment methods](/docs/en/essentials/payment-methods) | The public list, filterable by country, type and payment currency |

Because that response is keyed on **contracts**, one payment method can appear several times —
once per currency. `payMethodName` is not a unique key. Details in
[Payment Method Config & Limits](/docs/en/support/payment-method-config-and-limits-faq).

## A payment method is listed in one currency. Can I still price in another?

Read the two currencies separately:

* **Payment currency** — what the user is charged in. For a local payment method this is
  effectively fixed by the method itself.
* **Order currency** — what you priced in, and what you are billed and settled on.

A method whose payment currency is a single local currency can still serve an order you priced
in a different currency; that is the cross-currency case, and the conversion is what the
exchange rate is for. What you cannot do is assume it: check the contract entry for the
combination you intend to send, and handle the rejection codes for the case where the
combination is not configured — it comes back as `A0018`, the contract-mismatch code, not as
a currency-specific error; see
[Limits, Currency & Configuration Errors](/docs/en/support/error-codes-and-limits-supplement).

## Where do I see the exchange rate for a cross-currency order?

Two different rates, two different fields:

| Field | Meaning |
| - | - |
| `orderAction.actionData.exchangeRate` | Defined in the contract as `paymentAmount / orderAmount`, present when `orderCurrency` differs from `paymentCurrency` |
| `payMethodResponse.exchangeRate` | The rate the payment method itself used when the user paid |

They answer different questions and can differ. When the rate is fixed, for how long, and
which rate a refund uses are all in
[Exchange Rates in Payments & Settlement](/docs/en/support/exchange-rates-faq).

## How many decimals may I send, and does it depend on the currency?

Yes, it depends on the currency, and the rule differs between same-currency and cross-currency
orders. The published rule: most currencies take two decimals per ISO 4217, a set of
currencies must carry **no** decimals at all in a same-currency order, and in a
cross-currency order every currency must follow its ISO 4217 precision with no exceptions.
The full list and the rejection behaviour are in
[Amounts and currencies](/docs/en/developer-docs/core-concepts/currency) and
[Order Amounts, Limits & Declines](/docs/en/support/order-amount-precision-and-decline-faq).

Per-payment-method amount ranges are a separate check from precision: they come from
`orderAmountMin` / `orderAmountMax` on the contract, so validate against those before you
create the order rather than discovering the limit from an error code.

## Which amount fields does a refund carry?

| Field | Meaning |
| - | - |
| `refundAmount` | What you asked to refund, in the order currency |
| `finalDealAmount` | The amount the **user receives**. It may exclude a service or tax fee the user originally paid, so it can be smaller than the corresponding order amount |
| `remainingRefundAmount` | What is still refundable on that order after this refund |
| `userCurrency` | Present when the order currency is not the user's payment currency |

`remainingRefundAmount` is the field to drive your own "can I still refund" logic from, rather
than recomputing it from your records — it already accounts for every refund on the order,
including ones you did not initiate yourself. Refund rules themselves are in
[Refund FAQ](/docs/en/support/refund-faq) and
[Refund Limits by Payment Method](/docs/en/support/payment-method-refund-limits-faq).

***

Still not sure which field to compare? [Contact support](mailto:support@waffo.com) with your
`paymentRequestId` and the two numbers that disagree.


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