Billing for Failed Card Transactions

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. For the reports themselves, see Settlement Reports & Exports.

​

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:

​

Which failure stages are billable, and what is the difference?

There are exactly two: 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. 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: 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 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: 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: 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 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: 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.