> ## 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. # Billing for Failed Card Transactions > Why a card payment that never succeeded can still appear on your settlement bill: which failure stages are billable, how the Event Type column works, why failed rows carry no order amount, and how to find and export these transactions in the Merchant Portal. Most merchants meet this topic through a support ticket that starts *"there is a fee on my bill for a transaction that failed"*. That is expected behaviour under some contracts, and this page explains when and how. For how each amount on a settlement row is computed, see [Settlement Calculation Explained](/docs/en/support/settlement-calculation-explained). For the reports themselves, see [Settlement Reports & Exports](/docs/en/support/settlement-reports-faq). ## Can I be charged for a card transaction that failed? Yes — if your contract has a fee configured for the failure in question. Billing for failed transactions is a **per-contract, per-payment-method setting**, not a platform-wide policy. Waffo looks up a fee for the specific failure stage against your agreement at settlement time: * **A fee is configured** → the failed attempt enters settlement and is billed. * **No fee is configured** → nothing is created and nothing is billed. The transaction never appears as a settlement row. So two merchants can have identical failed transactions and only one of them sees a charge. If you are unsure which applies to you, check whether your settlement detail contains any rows with an `Event Type` (see below) — if it does not, you are not being billed for failures. Two further scope limits apply regardless of your fee configuration: | Limit | Detail | | - | - | | Transaction type | Only `PAYMENT` transactions. Refunds and chargebacks have no failure-stage billing. | | Failure location | Only failures that happened in the **interaction with the payment network**. A request rejected by Waffo's own validation before it ever reached the network is not billable and carries no failure stage. | ## Which failure stages are billable, and what is the difference? There are exactly two: | Stage | What failed | Typically | | - | - | - | | `AUTHENTICATION_FAILURE` | The cardholder authentication step | 3-D Secure did not complete or did not match | | `AUTHORIZATION_FAILURE` | The authorization step, after authentication had passed | The card was refused, expired, or the attempt errored | They are separate fee items in a contract. You can be billed for one and not the other, at different amounts. The distinction matters commercially, because the two stages carry different costs upstream: an authentication failure is stopped earlier than an authorization failure. Note the ordering implication — an attempt that fails authorization has already been through authentication successfully, so it is billed as `AUTHORIZATION_FAILURE` only. A single attempt never produces two failure fees. ## How do I tell which of my transactions were billed as failures? By the **`Event Type`** column. It sits immediately after `Transaction Type` and appears in your settlement detail export, your settlement estimation export, and the Portal list. | `Event Type` value | Meaning | | - | - | | `PAY_SUCCESS` | A normal successful payment | | `AUTHENTICATION_FAILURE` | Billed failure at the authentication stage | | `AUTHORIZATION_FAILURE` | Billed failure at the authorization stage | Filter or sort on this column and you have your complete list of failure-billed transactions for the period. There is no separate report to request. ## Why do failed rows have no order amount? Because there was no order. Nothing was collected, so there is no amount to report — reporting one would imply money that never moved. On a row whose `Event Type` is `AUTHENTICATION_FAILURE` or `AUTHORIZATION_FAILURE`, these three columns are **deliberately blank**: * `Order Amount` * `Order Currency` * `Order Amount (Settlement Currency)` What the row *does* carry is the fee side: | Report | Columns populated on a failed row | | - | - | | Settlement detail | `Fee Amount`, `Fee Currency`, `Fee Amount (Settlement Currency)`, `Settlement Amount` | | Settlement estimation | `Est Fee Amount`, `Est. Tax Amount`, `Tax Currency`, `Est Settlement Amount` | The `Settlement Amount` on such a row is therefore **negative** — it is a fee with no offsetting order amount. This is the correct reading, not a data error, and it is one reason a settlement period can net out lower than your successful-payment total suggests. If you reconcile by summing `Order Amount` and comparing against `Settlement Amount`, failure rows will look like an unexplained gap. Reconcile by summing the fee columns as well. ## Is the failure fee a percentage of anything? No. A failure fee is a **fixed amount** — there is no order amount for a percentage to apply to. One constraint follows from this and occasionally surprises people: the currency of a failure fee **must be the same as the currency of your payment fee** on that payment method. A failure fee cannot be billed in a different currency from the successful-payment fee it sits alongside. ## My customer retried and the payment eventually succeeded. Was I billed for the failures too? Each **attempt** is recorded and evaluated separately. A successful payment preceded by failed attempts produces a successful-payment row for the attempt that worked, and — if your contract prices that failure stage — a failure row for each attempt that did not. So the answer depends on your contract, but the structure is unambiguous: the eventual success does not retroactively cancel the earlier failures. They are separate events on the same order, each carrying its own sequence number, and they are deduplicated per attempt rather than per order. This is the single biggest driver of unexpected failure-fee totals. A checkout flow that encourages rapid re-tries — or a card-on-file retry schedule that fires several attempts in short succession — multiplies the failure count for one eventual sale. If failure billing applies to you, the cost of a retry is not zero, and retry strategy becomes a commercial decision rather than purely a conversion one. ## Can I see failure fees before the settlement date? Yes, in your **settlement estimation** data, which carries the same `Event Type` column. Failed attempts appear there as soon as they have been picked up, with their estimated fee, so you can accrue for them rather than discovering them on the settlement date. The same amount-suppression rule applies: an estimation row for a failed attempt has no order amount, and shows only `Est Fee Amount`, `Est. Tax Amount`, `Tax Currency` and `Est Settlement Amount`. See [Fee & Tax Treatment](/docs/en/support/fee-and-tax-treatment-faq) for the estimation export's limits and how its figures are estimated. ## What can I do to reduce failure fees? Failure fees are driven by attempt volume, so the levers are all upstream of Waffo: | Lever | Why it helps | | - | - | | Validate the card before submitting | Card number, expiry and CVV format errors caught client-side never reach the network, so they are never billable | | Cap re-tries per order | Each attempt is separately billable, so an unbounded "try again" button converts a single lost sale into several fees | | Space out retries on stored cards | Immediate re-tries against a card that has just refused rarely change outcome, and each one counts | | Watch your authentication failure rate specifically | A high `AUTHENTICATION_FAILURE` share often points at a fixable integration or user-experience problem rather than genuine declines | Use the `Event Type` breakdown described above to see which of the two stages dominates. The two have different causes and different remedies, and the split is usually lopsided. ## Where in the Merchant Portal do I find these transactions? Under **Settlements → Settleable Transactions**. It lists settleable transactions at the individual-transaction level, including the failure-billed ones, and it is the practical starting point for any "what am I being charged for" question. Filters available: | Filter | Notes | | - | - | | Order Id / Merchant Order Id / Payment Request Id / Merchant User Id | Combined search — pick the identifier type, then enter the value | | Sub Merchant Id | Only shown if you have sub-merchants | | Order Currency | | | Transaction Type | `PAYMENT` / `REFUND` / `CHARGEBACK` / `CHARGEBACK_ALERT` | | Settlement Status | `UNSETTLED` / `SETTLED` | | **Event Type** | `PAY_SUCCESS` / `AUTHENTICATION_FAILURE` / `AUTHORIZATION_FAILURE` | | **Payment Date** | Date range, **capped at 31 days** — the picker will not let you select a wider span | `Sub Merchant Id` is also the first column of the result table. The list supports **export**. The exported file follows the same field layout as the list, and finished files appear in the download list on the same page rather than downloading immediately — see [Exports & Report Downloads](/docs/en/support/export-center-faq) for how export tasks behave. ## Can I get the failure stage back on the payment API? Not as a dedicated field. The order APIs return `orderFailedReason` for a failed order, which tells you *why* it failed; they do not return a separate authentication-versus-authorization stage marker. Where you see the stage is **downstream, in settlement data**: as the `Event Type` column in the reports and Portal list described above. If your reconciliation needs to attribute a failure fee to a specific attempt, join on the order identifier from the settlement detail rather than expecting the stage on the payment response. ## I can see the failure in my transaction list but nothing in my settlement. Is something missing? No — that is the expected result whenever the failure is not billable to you. The transaction list and your settlement data answer different questions: | Where you look | What it shows | | - | - | | Transaction list | Every attempt, successful or not, because it is a record of activity | | Settlement data | Only what affects money — successful transactions, and failures **your contract prices** | So a failure visible in your transaction list and absent from settlement means one of three things, all of them normal: 1. **No failure fee is configured** for that stage and payment method on your contract. Nothing is billed, so nothing is created. 2. **The failure was not a network-interaction failure** — it was rejected by validation before reaching the network, and carries no failure stage. 3. **The transaction has not been picked up for settlement yet.** Check the settlement estimation data before concluding it is absent. The reverse — a settlement row you cannot find in your transaction list — would be a genuine discrepancy worth raising. A failure without a settlement row is not. ## Does a failed transaction affect anything other than the fee? Only the fee line. A failure-billed attempt: * does not create an order amount, so it does not enter your `Order Amount` totals; * does not create a payment fee, VAT or WHT on the order amount — the failure fee is the whole charge; * does contribute to your settlement amount, negatively, as described above; * settles on the normal settlement date for the transaction date, like any other settleable transaction. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.