> ## 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. # Fee & Tax Treatment > How Waffo decides which fee terms apply to a card transaction, what the three tax-bearer modes mean and who pays in each, how disputes and chargebacks differ in their effect on your money, and the limits on chargeback and settlement-estimation exports. This page covers the parts of your fee and tax treatment that are **decided by the transaction, not by your rate card** — which of your contracted terms a given card payment falls under, who bears a transaction tax, and how disputes and chargebacks land in your settlement. Commercial terms themselves — your rates, minimums and caps — are in your contract; your Waffo account manager is the right contact for those. For how a rate becomes an amount, see [Settlement Calculation Explained](/docs/en/support/settlement-calculation-explained). ## Why do two identical card payments carry different fees? Because card payments are classified as **domestic** or **cross-border**, and your contract can price the two differently. The classification is derived from the **card BIN** — the leading digits of the card number, which identify the issuing bank and therefore the issuing country: | Condition | Classification | | - | - | | The card's issuing country matches the country of the Waffo entity processing that card arrangement | `DOMESTIC` | | The issuing country is a different country | `CROSSBORDER` | | The BIN cannot be resolved, or the issuing country cannot be determined | `CROSSBORDER` | | The BIN resolves ambiguously to more than one issuing country | `CROSSBORDER` | So `CROSSBORDER` is the fallback in every uncertain case. This is deliberate and conservative, and it has a practical consequence: **an unrecognised card is priced as cross-border**, which is normally the more expensive of the two. New or recently issued BINs are the usual reason a payment you expected to be domestic was not. The classification is decided at payment time, recorded on the transaction, and then used at settlement to pick the matching fee terms. If your contract happens to have no terms for the classification a transaction was given, the cross-border terms are applied. Two things this classification is **not**: * It is not the cardholder's country of residence, or the billing address country — only the issuing institution's country. * It is not your own country. The comparison is against the Waffo entity handling that card arrangement, which is why the same card can be domestic under one card arrangement and cross-border under another. ## Who pays a transaction tax — me or my customer? There are exactly three possibilities, set per contract and per payment method: | Mode | Who bears the tax | What the customer is charged | Effect on you | | - | - | - | - | | **User-borne** | Your customer | The order amount **plus** the tax, computed at the contracted rate | None — the tax is not deducted from your settlement | | **Merchant-borne** | You | The order amount, unchanged. The tax is **not shown to the payer at checkout** | The tax is deducted from your settlement amount | | **Not applicable** | Nobody | The order amount, unchanged | None — no tax is computed | The mode is recorded on each order when it is created, so it is fixed for that transaction and does not change retroactively if your contract changes. Two consequences worth planning around: * **Under user-borne, the amount collected exceeds your order amount.** The customer sees and pays the higher figure. Your order amount, and therefore your settlement base, is unaffected. * **Under merchant-borne, the customer sees nothing.** The tax is deliberately suppressed from the checkout display, because showing the payer a tax they are not paying is misleading. It surfaces only in your settlement data. The applicable rate always comes from configuration — your contract terms for settlement-time taxes, or the arrangement-level configuration for taxes collected at checkout. **No tax rate is hardcoded**, which is why the correct answer to "what rate applies to me" is always your contracted rate rather than a number in documentation. ## Is a merchant-borne tax broken out as its own column in my settlement file? No. Settlement files carry **generic tax columns**, whoever bears the tax: | Column | Meaning | | - | - | | `Tax Amount` | The tax on that transaction, in the tax currency | | `Tax Currency` | Its currency, as a 3-letter ISO 4217 code | | `Tax Amount (Settlement Currency)` | The same tax converted into your settlement currency | There is no tax-type-specific column — no separate column naming a particular country's transaction tax — and no column that splits merchant-borne from user-borne tax. If you need a specific tax presented as its own column, or need the pre-tax order amount alongside the collected amount, that is a **custom report change**: raise it with your Waffo account manager rather than expecting it in the standard files. Your settlement statement also carries a tax total. Note that where a transaction tax is not invoiceable in its jurisdiction, it will appear in your settlement data but **not** on the invoice. ## What is the difference between a dispute and a chargeback, for my money? The two are distinct record types, and the difference that matters for reconciliation is whether funds move: | | Dispute | Chargeback | | - | - | - | | What it is | A business record of a customer's complaint, with its context | A reversal of the payment | | Moves money | **No.** It books no amount and no fee against you | **Yes.** An amount and a fee are booked | | May lead to | A refund, if you resolve it that way | A settlement debit | | Appears in settlement | No | Yes, as a `CHARGEBACK` transaction | So a dispute appearing in your Portal is not a debit and should not be accrued as one; a chargeback is. For case handling, deadlines, evidence and status flow, see [Chargeback & Dispute FAQ](/docs/en/support/chargeback-faq). ## The dispute amount in my Portal does not match the amount the bank reversed. Why? Because you are shown the amount **in your own order currency**, converted for you, rather than the raw figure from the reversing side. A dispute is raised against the payment as it was processed, which for a cross-currency payment is in a different currency from your order. Rather than show you a figure in a currency you never transacted in, the Portal shows **`Dispute Amount`, populated with the merchant dispute amount** — the same dispute expressed in your order currency. The conversion is deliberately **rounded down** when apportioning against a partially refunded order, so that the amount attributed to you never exceeds what you could actually still be liable for. Two checks are applied when a case is created: the amount claimed cannot exceed what remains disputable on the order, and the amount attributed to you cannot exceed your own remaining refundable amount. The practical implication: on an order you have partially refunded, the dispute amount attributed to you is **less than** the full disputed amount, pro-rated against what you had not yet refunded. Reconciling a chargeback against the original order amount will not tie out on a partially refunded order — reconcile against the merchant dispute amount. The related fee field is labelled `Dispute Fee Amount` with its currency stated in the label, so it is unambiguous which currency the fee is in. ## What currency is my chargeback fee in, and does it need an exchange rate? Your chargeback fee currency is a **contract term**, configured per merchant account alongside the fee itself. It is not derived from the order and it is not fixed to any particular currency by the platform. Where your chargeback fee currency **differs from your settlement currency**, the fee has to be converted, so settlement needs a `SettlementCurrency/FeeCurrency` rate for the period. This is worth knowing because it explains a `Forex Currency Pair` appearing on a chargeback row whose order currency already matched your settlement currency — see [Settlement Calculation Explained](/docs/en/support/settlement-calculation-explained) for how the pair is chosen. Two related rules: * A chargeback fee is taken **as reported for that case**, not recalculated from a percentage. It will never reconcile to a rate × amount formula. * All chargeback fees within one settlement batch must share a single fee currency; the batch is validated for this. A mismatch is a configuration error, not something you need to reconcile around. ## Which exchange rate is used when a chargeback settles? The **original payment's settlement rate**, not the rate of the day the chargeback settles. This is a rate-protection rule: reversing a payment at a different rate from the one it settled at would expose you to FX movement on a transaction you have already reconciled. By reusing the original rate, the chargeback reverses the same settlement-currency amount that the payment produced. One consequence follows directly: **a chargeback cannot settle before its original payment has settled**, because the rate it needs does not exist yet. A chargeback on a very recent payment waits for that payment's settlement date. For the chargeback *fee* leg, where a rate for the fee currency pair already exists in that settlement batch, that same rate is reused — so the fee and the amount on one chargeback are converted consistently. ## How do I export my chargebacks? From the **Chargebacks** tab in the Portal, which lists chargeback cases with their identifiers, type, original order id, dispute amount, reason code, dispute status, settlement status, and created and expiry timestamps. | Constraint | Detail | | - | - | | Date span | **31 days maximum.** A wider range is refused before the export starts | | Scope | Chargebacks only — the export covers this tab, not other dispute types | | Timestamps | Date parameters are `YYYYMMDD` in UTC+8 | ## What are the limits on the settlement estimation export? Settlement estimation lets you see fee, tax and settlement figures for transactions that have **not settled yet**, so you can accrue before the settlement date. | Constraint | Detail | | - | - | | Date span | **31 days maximum**, on payment date. A wider range is refused with a message rather than being truncated | | Searchable by | Payment date range, order id, merchant order id | | Large results | Split across multiple files at **60,000 rows per file** and delivered as a single archive | | Delivery | An export task, not an instant download — see [Exports & Report Downloads](/docs/en/support/export-center-faq) | Estimated figures are estimates, and the reason is the exchange rate: an unsettled transaction has no settlement rate yet, because that rate is not fixed until settlement. Estimation therefore uses: 1. The rate from your **most recent successfully settled** data for the same merchant account, country and currency pair; failing that, 2. A market reference rate. So your estimate is as good as the recency of your last settlement in that currency pair. Expect estimated and actual figures to differ by the FX movement between the two — that difference is not an error, and the actual figures replace the estimates once the settlement runs. ## Which order and settlement currencies can I be set up for? There is **no fixed list**, and in particular your settlement currency options are not limited to your local currency plus one major currency. The currencies you can transact and settle in are determined by your contract and returned dynamically, so the options you see reflect what is actually available for your region and arrangements rather than a static rule. Where a foreign currency is enabled for ordering, it carries its own minimum and maximum order amounts. If a currency you need is not available to you, it is a contract question rather than a platform limitation — ask your Waffo account manager. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.