Where Things Go Wrong

Card transactions can fail at every stage, and each failure has a different cause and a different remedy. Authorisation can fail because the card is blocked, the account is over its limit, the terminal is offline, or the issuer's system is down. Clearing can fail because a file is malformed, a transaction is duplicated, or an amount does not match its authorisation. Settlement can fail because an issuer or acquirer does not fund its net position on time. Each of these failures needs a defined exception process, with clear ownership, timelines and customer communication. Offline transactions add another layer of complexity. In some situations, such as on an aircraft or in a location with poor connectivity, a terminal may accept a card without contacting the issuer in real time, based on limits stored on the card or in the terminal. The transaction is then submitted for clearing later, and the issuer may decline it at that point, for example if the card has since been reported stolen. The merchant bears the risk in that case, which is why offline acceptance is only allowed in defined circumstances and with strict limits. Reconciliation is the discipline that catches these problems. Every participant reconciles its own records against the scheme's records at each stage, authorisation, clearing and settlement, and investigates any differences promptly. A difference that is found at authorisation can be fixed before clearing. A difference found at settlement may require a financial adjustment and a customer communication. Strong reconciliation, with automated matching and clear exception queues, is what separates a reliable card operation from one that generates constant complaints and losses. Trace three failures through one day. An acquirer submits a clearing file of 12,000 transactions for the day. Three records fail validation because their amounts do not match the original authorisations, so the scheme returns the file for correction and settlement is delayed by a day. The merchant is not funded on time, and the acquirer's operations team works through the night to fix the three records and resubmit. In a second case, the same file is submitted twice by mistake. Merchants are credited twice, and the duplicate is caught by reconciliation the next morning, when the scheme's totals do not match the acquirer's totals. The duplicate credits are reversed by adjustment, and the merchants receive an explanation. In a third case, a passenger buys a meal for Rs 3,500 on an aircraft, where the terminal is offline and accepts the card without contacting the issuer. Before the transaction reaches clearing, the card is reported stolen, the issuer declines it, and the merchant bears the loss, because offline acceptance puts the risk on the merchant. Reconciliation is the control that catches all three, and the analyst designs it stage by stage. Authorisation reconciliation runs the same day and compares the authorisation log with the merchant submissions, so a missing capture is found before clearing. Clearing reconciliation compares the acquirer's file with the scheme's records and must complete within 24 hours, because a break found later is harder and more expensive to fix. Settlement reconciliation compares the scheme's net settlement figure with the money actually received, and a difference there is escalated immediately, because it means the bank has not been paid. Each stage needs its own exception queue with a service level. Authorisation breaks the same day, clearing breaks within 24 hours, settlement breaks immediately. And each failure type needs a customer communication template, because a customer who is told why their payment failed is far less likely to raise a chargeback. Reversal, refund and void are three different ways to undo a card transaction, and confusing them is one of the most common errors in card operations, because each one has a different message type, a different timing, and a different effect on the money. A reversal undoes an authorisation before the transaction has cleared: the acquirer sends an ISO 8583 0420 reversal advice, the issuer removes the hold on the cardholder account, and no money moves, because no money has moved yet. A void cancels a transaction before the batch has closed: the merchant voids the sale in the terminal, the authorisation is reversed, and the transaction never enters the clearing file, so it never settles. A refund is a new transaction that returns money after the original transaction has settled: the merchant sends a refund, which is a credit to the cardholder account, and the money moves back from the merchant to the cardholder through the clearing and settlement process. Why the distinction matters is timing and money movement. A reversal happens on the same day as the authorisation, before clearing, and it costs nothing except the processing. A void happens before the batch closes, typically the same day, and it also costs nothing. A refund happens after settlement, which may be days later, and it costs the merchant the interchange fee, because the interchange is not refunded when the transaction is refunded, and the merchant may also pay a refund processing fee. A customer who is told they will get a refund must wait for the clearing cycle, which is typically one to three business days, while a customer whose transaction is reversed sees the hold released immediately. The operations team must know which one applies, because telling a customer they will get a refund when the transaction should have been reversed creates a complaint and a delay. A worked example shows the three cases. A customer buys a GBP 80 shirt at 10:00, and at 10:30 they return it to the shop before the batch has closed. The merchant voids the sale in the terminal, the terminal sends a 0420 reversal, the issuer removes the GBP 80 hold, and the transaction never clears. The customer sees the hold disappear within hours. Now suppose the customer returns the shirt three days later, after the transaction has settled. The merchant processes a refund of GBP 80, which is a new credit transaction that clears through the scheme and is credited to the cardholder account in one to three business days. The merchant loses the interchange of GBP 0.24 on this credit card purchase, at the 0.3 percent cap, which is not refunded, and pays a refund fee if the acquirer charges one. Now suppose the terminal loses connectivity during the authorisation and the merchant does not know whether it was approved. The terminal sends a 0420 reversal automatically when it reconnects, to ensure the hold is removed if the authorisation had succeeded, and this is called a reversal for a timeout. For a business analyst, the three mechanisms are a requirements subject. You must specify when each one is used, the message type for each, the timing window for each, the effect on the hold and on the settlement, and the customer communication for each. You must also specify the test cases: a void before batch close, a reversal after a timeout, a refund after settlement, and a refund where the original transaction cannot be found. A common gap is failing to specify the timeout reversal, because a terminal that does not send a reversal after a timeout will leave a hold on the cardholder account for days, and the cardholder will complain to the issuer. Takeaway: reversal undoes an authorisation, void cancels a sale before it clears, and refund returns money after settlement, and each one has a different cost and a different waiting time. Last reviewed 7 November 2026.