Authorisation, Clearing, Settlement

30.0 What this chapter gives you#

1. You will be able to explain why a customer’s available balance falls in under two seconds while not one unit of currency has moved anywhere.
2. You will be able to separate authorisation, capture, clearing, settlement and merchant funding as five events with five different units of work, and say which of them actually move money.
3. You will be able to answer the question every support queue receives — why a refund takes days when the payment took seconds — without blaming the merchant, who in most cases did the work on day zero.
4. You will be able to explain to a driver at a motorway pump why £99.00 became £68.40 and why nobody has refunded them £30.60.
5. You will be able to say why a hotel that has cleared and reversed correctly can still leave a hold sitting on a customer’s card, and why the customer’s own bank is the only party that can lift it.
6. You will be able to code an estimated authorisation and its increments so that the indicators and the linking identifiers survive into clearing, which is the difference between a clean transaction and dispute liability.
7. You will be able to say why a reversal carries the original total in the amount field with the corrected figure in the replacement amount field, and what happens to the hold when those two are swapped.
8. You will be able to explain why storing a card for later use should be done with a zero-amount account verification rather than a one-pound test, and what the schemes now charge for the latter.
9. You will be able to model an authorisation as three joined records with three lifecycles rather than one row with a status column, and explain why a partly captured, partly reversed authorisation cannot fit in one row.
10. You will be able to recognise when you are in a single message system and stop applying dual-message vocabulary such as capture, void and batch cut-off, several of which do not exist there.

The plain version#

On Amira’s street the pocket money does not live in the children’s pockets. It lives in a biscuit tin on Mrs Bello’s kitchen shelf.

Mrs Bello has kept the tin for thirty years. Every child on the street has a page in a notebook beside it, and the page says how much of the tin is theirs. Amira’s page says £62.30. There is no envelope in the tin with Amira’s name on it. There is no separate £62.30. There is one tin with a great deal of money in it and a notebook that says who it belongs to. This matters later, so hold onto it.

On Thursday the ice cream van comes round. Amira wants a lolly. She does not have £62.30 in her hand; her money is in the tin. So the driver leans out of the window and shouts down the street to Mrs Bello: “Amira, up to six pounds, is that all right?”

Mrs Bello looks at the notebook, sees £62.30, and says yes. Then she does something very specific. She does not open the tin. She does not take out any money at all. She writes on a slip of paper “up to £6.00 promised to the ice cream van”, clips it to Amira’s page, and calls back “yes, that’s fine”.

Now look at what has and has not happened. The tin still contains exactly as much money as it did a minute ago. Not one coin has moved. But Amira’s page now reads £62.30 with a £6.00 slip clipped to it, which means the most she can spend on anything else today is £56.30. Ask her how much money she has and the honest answer is two different numbers at once. She has £62.30. She can spend £56.30.

That is the whole trick, and it is the thing almost nobody knows. When your banking app says your money is gone, your money is usually not gone. A promise has been made about it. The promise is instant. The money is slow.

Why did the driver ask for six pounds when a lolly is four? Because he did not know yet. Amira might want a flake in it. She might buy one for her brother. He asked for enough to cover the likely worst case, because if he hands over the ice cream and then finds there is no money, the ice cream is not coming back. This is exactly why a hotel puts a hold on your card that is bigger than the room rate, and exactly why a petrol station holds an amount you never spent. Nobody knows what the final number is at the moment they have to commit.

That evening, at six o’clock, the driver goes back to the depot and writes out the day’s notes. He does not write one note per ice cream and post them one by one. He writes the whole day at once, all forty-one sales, in one bundle, and puts the bundle in the post. Amira’s line in the bundle says: £4.20.

The next morning the bundle arrives. Mrs Bello reads Amira’s line, takes the slip off the page, opens the tin, and takes out £4.20. Only now has money moved. Amira’s page reads £58.10, and she can spend £58.10, because the two numbers have finally become one number again.

Notice three separate events, at three completely different speeds.

The shout down the street took two seconds. That is authorisation. It reserves.

The bundle of notes took a day. That is clearing. It presents the real amount and says what actually happened.

And Mrs Bello opening the tin is settlement. That is the only step at which money actually moves.

There is one more layer, and it is the one that explains why nothing in this business is ever as fast as it looks. Mrs Bello does not walk £4.20 down to the ice cream depot. The depot has its own tin, kept by Mr Doyle, and on Friday afternoon Mrs Bello and Mr Doyle meet on the corner and square up the entire week. Amira’s £4.20 has by then been added to four hundred other people’s ice creams, and subtracted from the eleven that got returned, and the whole street’s week has become one figure and one handshake. Amira’s £4.20 never made a journey of its own. It was absorbed into a number.

Now some things that go wrong, because they all follow from the same picture.

Amira changes her mind before the driver hands anything over. He shouts “cancel that one” and Mrs Bello unclips the slip immediately. Her page goes back to £62.30 within the minute. That is a void, or in the trade, a reversal, and it is the only fast way to undo a hold.

The driver forgets to shout. The slip stays clipped. There is no note in the bundle that evening, or the next, or the next. Amira’s page still says she can only spend £56.30 and she cannot understand why. Mrs Bello has a private rule about this: if no note arrives within a week, she takes the slip off anyway. That is an authorisation expiring. It is worth being precise about whose rule that is. It is Mrs Bello’s rule. Not the driver’s, not the depot’s. The person holding the money decides when to stop holding it, and everybody else can only ask.

Amira buys her lolly at five past six, just after the driver has sealed the bundle. Her line goes in tomorrow’s bundle, which arrives the day after. That is a batch cut-off, and it is why something you bought on Friday evening appears on your statement on Tuesday.

And now the question everyone actually asks. Amira brings the lolly back unopened. The driver agrees to refund her. Why does it take four days when buying it took two seconds?

Because there is no shouting down the street in the other direction. The whole reason the payment felt instant is that a promise was made instantly, and a promise costs nothing. Giving money back is not a promise. It is the money itself, and the money has only ever had one speed. The driver writes a line in tomorrow’s bundle saying “minus £4.20”. The bundle goes in the post. It arrives. It gets read, checked and totalled against everything else. Then Mrs Bello puts £4.20 back in Amira’s page.

Buying was fast because it was fake. Refunding is slow because it is real.

Here is the whole thing with real numbers. Tunde, Amira’s father, fills up at a motorway service station on Thursday. The pump reads £68.40. He looks at his phone in the car park and it says £99.00 pending. He has not bought ninety-nine pounds of anything. The pump had to commit to a number before it knew what he would take, so it committed to a ceiling. On Friday the £99.00 disappears and £68.40 appears in its place, and he assumes he has been refunded £30.60, which he has not, because the £99.00 was never taken.

The following Monday he checks into a hotel for two nights at £120 a night. Reception takes his card and authorises £300.00, being the £240 of room plus what the hotel genuinely expects him to spend on dinner. On Tuesday night he spends more than that, and at 21:10 the hotel quietly asks for another £75.00 on top. He is now holding £375.00 of promises against a card he has used exactly once. On Wednesday morning the bill comes to £341.20. The hotel puts £341.20 into that night’s bundle, and within twenty-four hours it is obliged to send a message releasing the £33.80 difference. If it forgets, the £33.80 sits on his card for a fortnight and he blames the hotel, which is fair, and phones his bank, which cannot help him, which is not obvious but is true.

Three events. Three clocks. One tin.

Where the plain version stops being true#

The slip of paper is not a ring fence, and there is no tin. The picture of a hold as money set aside is comforting and wrong. An authorisation hold is not a transfer between two ledgers and it does not create a fund earmarked for the merchant. It is an adjustment to a derived figure — your available balance — held in the issuer’s authorisation system, sitting on top of a posted balance that has not changed at all. The merchant has no claim on it, no security interest in it, and no ability to reach it. If your issuer becomes insolvent overnight, the hold protects the merchant not at all. And on a credit card there is no money involved at any point: the hold reduces your open-to-buy, which is a permission to borrow, not a sum you own. Two different things wear the same word.

Nothing in the picture obliges the person holding the money to let go of it. This is the correction that matters most, because it is the one that misdirects a million customer complaints a year. The card schemes publish rules about when a merchant must clear or reverse an authorisation. They do not, in the general case, publish rules obliging an issuer to drop a hold at a given hour. Those are different obligations pointing in different directions. So the merchant can do everything correctly — clear on the day, reverse the excess within twenty-four hours — and the hold can still sit on your account for days, because the issuer’s matching logic did not connect the two records, or because its release policy runs on a timer. When a hotel tells you “we’ve released it, it’s with your bank now”, that is very often the literal truth and it helps you not at all.

“Three events” describes one architecture, not all of them. The separation of authorisation from clearing is what the industry calls a dual message system, and it is the architecture of most credit card traffic. There is another architecture, the single message system, in which one message both asks permission and moves the money, and there is no separate presentment at all. ATM withdrawals work that way. So does a great deal of debit traffic in various markets. Once you are in single-message territory, “capture”, “void” and “batch cut-off” are not merely different — several of them do not exist as concepts, and a reversal is a different animal with a different deadline. Any statement in this chapter about three timescales is a statement about dual message processing.

Settlement between the banks is not the merchant being paid. These are two distinct events, days apart, and the industry uses the same word for both, which is a permanent source of confusion in merchant support queues. The scheme calculates a net position and moves funds between the issuer’s and the acquirer’s settlement banks. Then, separately, under a commercial contract that the scheme is not party to, the acquirer pays the merchant — net of interchange, scheme fees and its own margin, possibly minus a rolling reserve, on a schedule that might be the next working day or might be five days, and which travels over Bacs or Faster Payments like any other bank payment. A merchant asking “has it settled?” and an acquirer answering “yes” are frequently talking about different days.

The technical version#

Three events, three clocks#

The three events differ not only in when they happen but in what their unit of work is. Authorisation is per transaction. Clearing is per file. Settlement is per institution. Losing track of which unit you are in is the root of most reconciliation failures.

Only the last two rows move money, and only the last row moves it to the party the customer thinks they paid.

Authorisation: what the message does and does not do#

An authorisation request is an ISO 8583 0100, answered by a 0110. Its four-digit message type indicator decomposes as version, class, function, origin: 0 for the 1987 edition, 1 for authorisation class, 0 for request, 0 for acquirer origin. In single message systems the equivalent is a 0200 financial request answered by a 0210, and the distinction is exactly the one drawn above — a 0200 is understood to post.

The fields that carry the commercial substance of the request are the ones catalogued earlier in this volume. DE2 carries the primary account number. DE3 carries the processing code, six digits of transaction type plus from-account plus to-account. DE4 carries the amount in minor units of the currency named in DE49, itself an ISO 4217 numeric code, 826 for sterling, 978 for euro, 840 for US dollars. DE7 carries transmission date and time, DE11 the six-digit system trace audit number, DE12 and DE13 the terminal’s own local time and date. DE37 carries the twelve-character retrieval reference number and DE41 the eight-character terminal identifier. DE55 carries the EMV data. On the way back, DE38 carries the six-character authorisation identification response, DE39 the two-character response code.

What the 0110 does is create an obligation with an expiry. It does not create a payment instruction. Nothing in the authorisation pair causes a single unit of currency to change hands, and an acquirer that never follows it with a presentment will never be paid, however emphatically the 0110 said approved.

ISO 8583 has an explicit field for the lifetime of that obligation. DE57, the authorisation life cycle, is three characters: position one is a time code, where 1 denotes calendar days, 2 hours and 3 minutes, and positions two and three carry an interval of 01 to 99. So 102 is two calendar days and 224 is twenty-four hours. The standard’s action code list likewise carries 1033 (authorization lifecycle unacceptable) and 1034 (authorization lifecycle has expired), which tells you that the drafters expected disagreement about lifetimes to be a normal, coded outcome rather than an operational incident. In practice the schemes largely govern this through their own rulebooks rather than through DE57, but the field exists and some domestic switches use it.

What the issuer actually does to the balance#

An issuer holds at least two figures against an account and returns different ones to different channels.

The posted or ledger balance is the sum of transactions that have actually been applied to the account. It changes when clearing arrives, not when authorisation happens.

The available balance is a derived figure: posted balance, plus or minus any credit line, minus the total of outstanding authorisation holds, minus any uncleared-funds or fraud-related restraints. This is the number the authorisation system tests a 0100 against, and it is the number your app shows you.

The pending items you see listed in a banking app are outstanding authorisations, not transactions. They can change amount. They can vanish without ever posting. They can post at an amount that never appeared in the pending list at all. Support scripts that tell customers a pending item “will be taken tomorrow” are asserting something the issuer does not actually know.

When the presentment eventually arrives, the issuer must decide whether it corresponds to an existing hold. If it matches, the hold is released as the posting is applied and the customer sees one clean line. If the matching fails, the issuer applies the posting and leaves the hold in place until it ages out, and the customer sees the same amount twice. That is the mechanism behind the overwhelming majority of “I’ve been charged twice” calls, and it is why the scheme processing rules are so preoccupied with identifiers.

Estimated and incremental authorisation#

Where the final amount is genuinely unknown at the point of commitment, Visa’s rules permit an estimated authorisation followed by any number of incremental ones. The important word is genuinely: Visa’s own merchant guidance states that an estimated authorisation “must be a genuine estimate and must not be an arbitrary amount”, must not include incidental amounts such as tips or a damage buffer, and must not be used to check the status of a credential — that is what account verification exists for.

The coding requirements are specific, and they are the difference between a clean transaction and a hold the issuer cannot match. In Visa’s message structure the fields are private-use subelements:

The amount semantics differ between message types and this trips people up constantly. In an incremental authorisation, the amount field carries the additional amount being requested, not the new total. In an authorisation reversal, the amount field carries the original total authorised — the sum of the estimate and all increments — and the corrected figure goes in the Replacement Amount field.

Failure to code these correctly is not merely untidy. Visa states that acquirers and merchants may carry dispute liability under Dispute Condition 11.3, No Authorization / Late Presentment, where there is no estimated indicator on the first message, no incremental indicator on subsequent messages, a mismatched Transaction Identifier, or processing outside the permitted timeframe.

Those timeframes are, per Visa’s 2024 merchant guidance, the maximum time from a valid estimated authorisation to processing:

Two cautions on that table. First, Visa notes country-specific approval response validity timeframes exist and the rulebook governs. Second, and instructively, the 2023 edition of the same Visa document published a materially different set: 31 days for lodging, vehicle rental and cruise lines, 7 days for other rental categories and other card-absent transactions, 3 or 7 days for commuter transport, and same-day for other card-present transactions. Both documents are Visa’s. If you are hard-coding validity windows, hard-code them against the rulebook edition in force and version them, because they move.

Incremental authorisations do not extend the window. A stay or rental that outlives the validity period must be closed within it and reauthorised, and the new authorisation gets a fresh window of the same length.

Fuel, and why the number is never the number#

Automated fuel dispensers do not use the estimated and incremental framework. They use an older construct, the initial authorisation, in which the terminal sends a fixed amount before the final figure is known, the amount is capped, no incremental is permitted, and the pump must stop if the fill reaches the authorised ceiling. Visa’s guidance notes that from April 2025 only AFDs may use initial authorisations, with laundries, quick copy, car wash, video rental and vending encouraged to migrate to estimates and increments.

The best known variant is the one-dollar status check, in which the terminal authorises a nominal amount and the issuer is expected to place a hold reflecting the segment ceiling rather than the nominal amount. Visa’s own business news of that change, effective 17 October 2020, sets the US AFD status check authorisation limits at USD 125 for non-Fleet cards and USD 350 for Fleet cards, applying only where the transaction is both chip-on-chip and partial-authorisation participating, and leaving them at USD 100 and USD 150 otherwise. Issuers remain liable up to those limits and may dispute the excess under Reason Code 11.3.

Those ceilings have since moved again, and the figure to know now is USD 175. It circulates very widely in acquirer-facing and merchant-facing material as “the” AFD limit, and although it appears nowhere in the 2020 notice it is not folklore. Visa’s own fuel segment update, presented by a Visa senior business leader to the National Petroleum Energy Credit Association in May 2025, gives the maximum US status check amount as USD 175 for non-Fleet cards and USD 1,000 for Fleet cards, and warns in the same deck that issuers who hold the nominal one dollar rather than that maximum are being exploited by fraudsters, which is the whole mechanism stated in reverse. The general point survives the revision: these ceilings are rewritten every few years, so version them against the edition of the rules in force rather than against whatever number the internet is quoting this season.

The same notice describes the mechanism that actually shortens fuel holds, and it is worth knowing because it is the only widely deployed example of a message whose sole purpose is to shrink a hold in real time. Visa asks issuers to activate their BINs for enhanced AFD and real-time clearing confirmation advices, which carry the final amount ahead of settlement, and notes that settlement “can take up to two days following completion of the AFD transaction”. Issuers that apply the advice immediately release the hold in minutes. Issuers that do not, wait for clearing, and their cardholders are the ones writing to the newspapers.

Partial approval#

If the account cannot cover the requested amount, an issuer that supports partial approval may approve a smaller one instead of declining. Under the 1987 response code list DE39 carries 10, approved for partial amount; the third-edition action code list carries 0002 with the same meaning. The approved amount is returned in the amount field, and the terminal is expected to prompt for the balance by another tender.

The terminal has to have declared that it can cope with this, which is what the value 3 in Visa’s Additional Authorization Indicator does: estimated amount and terminal accepts partial authorisation responses. A terminal that has not declared the capability and receives a partial approval anyway will typically treat it as a full approval for the requested amount, which is a genuine and repeatable way to give away goods.

Reversals, voids and cancellations#

A reversal is the only fast instrument in the entire chapter. It is an ISO 8583 0400 reversal request, or a 0420 reversal advice with its 0430 response where the recipient has no discretion to refuse.

Two fields carry the work. DE90, original data elements, is a forty-two digit block that identifies the message being reversed: original MTI (4), original STAN (6), original transmission date and time (10), original acquiring institution identification code (11) and original forwarding institution identification code (11). DE95, replacement amounts, forty-two characters, carries the corrected amounts where the reversal is partial rather than full; Visa’s equivalent in its own message structure is the Replacement Amount field. Sources differ on whether DE95 is specified as numeric or alphanumeric, and scheme implementations vary in how they subdivide it, so treat the subfield layout as scheme-specific rather than universal.

The industry word “void” is a merchant-facing abstraction, not a message. Depending on where the transaction has got to, a void is implemented either as a reversal of an authorisation that has not yet been captured, or as the removal of a record from a batch that has not yet been submitted. Once the batch has gone, there is no void; there is only a refund, with everything that implies about timing.

Visa’s reversal obligations are expressed in hours, not days:

• Where the transaction will not be completed at all, the entire authorised amount must be reversed within 24 hours of the earlier of the merchant becoming aware of that fact or the end of the authorisation validity period.
• Where the transaction completes and the sum of the estimate and any increments exceeds the final amount, the difference must be reversed within 24 hours of completion.

Again, the 2023 edition of the same guidance expressed the second obligation with tolerances — a 15 per cent threshold for lodging, vehicle rental and cruise lines, 20 per cent including tips for taxis — before the 2024 edition stated it flatly. Read the rulebook edition you are actually operating under.

Capture and the batch cut-off#

Between the 0110 and the clearing file sits capture, which is where a merchant declares that the authorisation should become money. In an attended retail environment the terminal accumulates approved transactions locally and closes its batch, either on a schedule or on an operator action. In an integrated or gateway environment the merchant sends an explicit capture instruction, which is why an e-commerce platform can authorise at checkout and capture at despatch three days later.

On the acquirer side, the file that carries this into Visa’s clearing system is the TC 33.A Capture File, whose records are laid out in BASE II Clearing: Interchange Formats, TC 01 to TC 49. It carries purchase and refund transactions that already have approved authorisations, decomposed into transaction code records: CP01 transaction, additional, billing and shipping, merchant, instalment, gateway and supplemental data; CP02 EMV data; CP03 lodging summary; CP04 Level II and Level III purchasing data; CP05 air passenger itinerary; CP10 car rental; and so on. The Edit Package, Visa’s own validation software that acquirers install, wraps the file with a TC90 file header, TC91 batch record and TC92 file trailer, and validates that the TC05 (Sales Draft) and TC06 (Credit) transactions built from the capture file are correct before they go to Visa for clearing and settlement.

The cut-off is a property of every one of these hops, and they are not aligned. A terminal that closes its batch at 23:00 local, an acquirer that assembles its submission at 01:00, and a scheme clearing window that closes at a fixed time in a different time zone together produce the familiar phenomenon whereby a Friday evening purchase is presented on Monday and funded on Wednesday. None of those systems is slow. They are each waiting for the next one’s door to open.

Clearing#

Clearing is the exchange of transaction detail between acquirer and issuer, the assessment of interchange and fees, and the production of the figures that settlement will act on. It is a batch process, it is file-shaped, and it is where the transaction acquires the identifiers that disputes will later be filed under.

Visa clears through BASE II, whose record vocabulary is the transaction code series already described: TC05 for a sales draft, TC06 for a credit. Mastercard clears through the Global Clearing Management System, using the Integrated Product Messages format. In IPM the first presentment is message type 1240 with DE24 function code 200; a financial detail addendum is 1644 with function code 696; the first chargeback is 1442. DE25 carries the message reason code, and Mastercard’s switch rules use reason code 1404, “previously approved authorization — partial amount, final clearing”, to signal that a presentment is the last one against a given authorisation and that the authorisation is now closed, after which no further clearing messages may be submitted against it. Mastercard’s clearing dates are expressed as the Central Site Business Date, which is the date the message cleared into GCMS and not the date anything happened in a shop.

Presentment is not optional and it is not open-ended. Mastercard’s European rules require an ATM presentment within seven calendar days of the transaction date, with late presentment exposed to chargeback under message reason codes 4842, 4880 for Maestro ATM, or 4811 for stale transactions, and transactions presented between forty-six calendar days and one year attracting a fee that is passed in full to the issuer. The same shape of rule, with different windows, applies across the card products.

Two asymmetries in clearing deserve stating plainly, because both break the tidy mental model.

A clearing record can exist with no authorisation behind it. Offline-approved transactions, forced posts and certain fallback flows all produce presentments the issuer never saw a 0100 for. The issuer must post them and argue afterwards.

And a clearing record’s amount is not obliged to equal the authorised amount. Tolerances vary by segment, and where the clearing amount exceeds what the tolerance allows, the issuer’s remedy is a dispute rather than a rejection at the door.

Settlement#

Settlement is the discharge of the obligations that clearing recorded, and it is the only step in this chapter at which value moves between institutions.

Mastercard describes its own architecture in three named systems: the Authorization Platform, the Global Clearing Management System for clearing, and the Settlement Account Management system for settlement, which calculates the net position of each acquirer and issuer arising from clearing and performs two functions, sending advisements and transferring funds. Visa’s equivalent function is performed by the VisaNet Settlement Service, fed by the figures BASE II produces.

Three properties follow, and each of them surprises somebody.

Settlement is net, not gross. An issuer that owes on ten million transactions and is owed on two million settles one figure. This is the netting described in Volume I, applied at institutional scale, and it is why a card scheme’s daily settlement flows are a small fraction of its daily transaction value.

The scheme is not a bank. It computes positions and instructs; the actual transfer happens between nominated settlement banks over ordinary payment infrastructure, in a settlement currency chosen per region and per member. This is the structural reason a scheme outage stops new authorisations but does not destroy value that has already cleared.

And interchange is not invoiced. It is applied as an adjustment inside the clearing figures, so by the time a settlement position exists it is already net of the interchange the acquirer owes. There is no separate interchange bill to pay or dispute.

Then, entirely separately, the acquirer pays the merchant. That payment is governed by the merchant agreement, not the scheme rulebook. It is net of the merchant service charge, it may be net of a rolling reserve, and it travels over whatever domestic rail the acquirer uses — in the United Kingdom, Bacs or Faster Payments, with the timings Volume IV sets out. T+1 and T+3 are both common; new or higher-risk merchants are routinely funded more slowly. A merchant seeing money on Wednesday for a Monday sale is seeing the end of a chain in which the scheme settlement happened on Tuesday and had nothing to do with them.

Why the refund takes days#

Put the two directions side by side and the asymmetry is obvious.

A purchase gets a real-time promise and a slow money movement. The customer experiences the promise. Their available balance drops in under two seconds and they conclude, reasonably, that the payment system is fast.

A refund has historically had no promise at all. The refund was a clearing-side credit — a TC06 in BASE II terms — which meant it travelled at the speed of files: the merchant’s batch, the acquirer’s submission, the scheme’s clearing cycle, the issuer’s posting run. Nothing was reserved, because there is nothing to reserve; the issuer is not going to promise you money it has not received. Worldpay’s own documentation puts the historical position exactly: issuers “accepted and honoured refund transactions when they received them later in the daily clearing files sent to them by processors”, and “typically, this would take 24 hours for a refund transaction to be registered in cardholders’ accounts”, before the rest of the posting cycle ran.

The customer therefore experiences the purchase as instant and the refund as a five-day wait, and concludes that the merchant is stalling. In most cases the merchant did the work on day zero.

Both schemes have addressed this, and it is worth being precise about what they addressed, because it is a common and expensive misreading. Visa Purchase Return Authorization and Mastercard’s equivalent return authorisation mandate require the merchant to obtain an online authorisation for the refund. Verifi, a Visa company, answered the obvious question about it in terms that leave no room: the mandate “is intended to increase consumer visibility to refunds in process by making pending refunds visible via online and mobile banking channels”, and the time between refund issuance and funds appearing “can vary based on the processing timelines for each party”.

In other words, the refund authorisation creates the missing promise. It does not create a faster money movement. Your bank can now show you a pending credit within seconds. The money still arrives when clearing and settlement bring it.

The compliance timeline, as of writing, is worth recording because the deadlines differ by region and by scheme:

Two operational consequences follow that catch integrations out. A refund authorisation can be declined, which was previously impossible, so a point-of-sale application must be able to render a declined refund without falling over. And an approved online refund typically returns a six-digit authorisation code, while an offline-accepted refund may return a five-digit one, which is a useful diagnostic when reconciling a merchant estate mid-migration. Visa publishes suggested merchant actions per decline code for returns, of which the useful ones are 14 invalid account number, meaning request an alternative card; 54 card expired, meaning ask whether a replacement exists; and 55 invalid PIN, meaning retry PIN normally.

The integrity fees, and what they are really for#

The schemes charge for authorisations that never become money. The framing is data integrity, and it is honest framing: an unmatched authorisation is a hold on a customer’s account for which no corresponding value will ever exist.

Visa’s Misuse of Authorization System Fee applies in the US region to approved and partially approved authorisations that cannot be matched to a clearing transaction or an authorisation reversal. It was long assessed at USD 0.09 and was raised to USD 0.15 with effect from January 2025 according to acquirer pass-through bulletins. Visa lists the two most common causes as failure to process estimated authorisations, incrementals and reversals to the technical requirements, and use of one-dollar test transactions where the Account Verification Service should have been used. Visa also operates a separate unmatched clearing fee for the mirror-image failure. The same January 2025 schedule increased the Visa BASE II transmission fee from USD 0.0018 to USD 0.0025 per transaction, a figure worth knowing chiefly because it demonstrates how thin the per-item economics of clearing actually are.

Mastercard’s Processing Integrity Fee turns on authorisation type, and the type is declared by the merchant:

The fee rates are region-specific and revised regularly. Fiserv’s published Canadian pass-through schedule, as one concrete example of the shape of them, lists all three processing integrity non-compliance categories at 0.452 per cent with a USD 0.113 minimum. Do not carry a rate across regions; look it up in the schedule that applies to your acquiring entity.

The design lesson embedded in the final-authorisation rule is the sharpest one in this chapter. Mastercard will charge you if the amount you clear is not the amount you authorised, when you told it the amount was final. The rulebook is not asking you to be accurate. It is asking you to be honest about whether you know.

Account verification, which is not an authorisation#

The correct way to check that a card exists and is in good standing is a zero-amount account verification: a 0100 with the amount field at zero, which Visa exposes as its Account Verification Service. It returns an approval and, on most implementations, address and security code verification results, without creating a hold.

The incorrect way, still widely deployed, is a small-value authorisation — the one-dollar or one-pound test — which creates a real hold on a real customer’s real available balance, and which the schemes now charge for when it is never cleared. If you are storing a card for later use, verify at zero.

Design rules that follow#

Model the three events as three separate records with three separate lifecycles, joined by identifiers, and never as one row with a status column. An authorisation that is partially captured and partially reversed has produced four facts, and a single row cannot hold four facts.

Store the linking identifiers on every message. For an estimated-and-incremental flow this means the scheme transaction identifier, the retrieval reference number and the system trace audit number carried forward from the original approval into every increment, every reversal and the clearing record. This is not good practice; per Visa’s rules it is the difference between a clean transaction and dispute liability under condition 11.3.

Reverse promptly and reverse for the right amount. The obligation is measured in hours from the moment you knew, not days from the moment you got round to it, and the reversal message must carry the original total in the amount field with the corrected figure in the replacement amount field. Getting those two the wrong way round produces a hold that grows rather than shrinks.

Declare your authorisation type honestly. If you know the final amount, say final and then clear that exact amount in that exact currency. If you do not know, say estimated and use increments. The undefined category exists because implementations were vague, and it is being closed.

Never tell a customer that a pending item will be taken. Tell them it is a reservation, that it may change or disappear, and that the amount that will finally post is the amount on the receipt. Every one of those statements is true, and the sentence “it’ll come off tomorrow” is not.

And when a customer asks why the refund is slow, the honest answer is the one this chapter began with. The payment was not fast. The promise was fast. The money has always taken days, in both directions, and the refund is simply the first time anybody notices.

30.98 Common wrong ideas#

Wrong: A hold sets your money aside for the merchant. Right: It adjusts a derived figure, the available balance, inside the issuer’s authorisation system; it creates no fund, gives the merchant no claim and no security interest, and on a credit card no money is involved at any point, only a reduction in a permission to borrow.

Wrong: The merchant is holding the money and the merchant can release it. Right: The scheme rules say when a merchant must clear or reverse; they do not in the general case oblige an issuer to drop a hold at a given hour, so “we’ve released it, it’s with your bank now” is very often the literal truth and helps the customer not at all.

Wrong: Every card transaction has three separate events. Right: That describes dual message processing; in single message systems one message both asks and moves, there is no separate presentment, and capture, void and batch cut-off are not merely different but absent as concepts.

Wrong: Settlement means the merchant has been paid. Right: Scheme settlement moves a net position between the issuer’s and the acquirer’s settlement banks, and the acquirer then pays the merchant days later under a commercial contract the scheme is not party to, net of charges and possibly a rolling reserve.

Wrong: A pending item will be taken tomorrow at the amount shown. Right: Pending items are outstanding authorisations, not transactions: they can change amount, vanish without ever posting, or post at a figure that never appeared in the pending list.

Wrong: “I’ve been charged twice” means the merchant sent the transaction twice. Right: The overwhelmingly common mechanism is that the presentment failed to match the hold, so the issuer applied the posting and left the hold in place until it aged out.

Wrong: The refund authorisation mandates have made refunds faster. Right: They create the promise that refunds never had, so a pending credit becomes visible within seconds; the money still arrives at the speed of clearing and settlement, which has not changed.

Wrong: An incremental authorisation carries the new total. Right: It carries only the additional amount; it is the reversal that carries the original total, with the corrected figure in the replacement amount field, and getting those the wrong way round produces a hold that grows instead of shrinking.

Wrong: An estimated authorisation can be whatever figure is convenient. Right: It must be a genuine estimate, must not include incidentals such as tips or a damage buffer, and must not be used to check the status of a credential.

Wrong: A one-pound test is a harmless way to check that a card is real. Right: It creates a real hold on a real customer’s real available balance and is chargeable when it never clears; the correct instrument is a zero-amount account verification.

30.99 Chapter summary in 20 lines#

1. A card payment feels instant because a promise is made instantly, and a promise costs nothing to make.
2. Authorisation reserves, clearing presents the real amount, and settlement is the only step at which value moves between institutions.
3. A hold is not money set aside but an adjustment to a derived available balance sitting on top of a posted balance that has not changed.
4. That is why a cardholder honestly has two numbers at once: what they have, and what they can spend.
5. Merchants ask for more than they need whenever the final amount is unknown at the moment of commitment, which is why a hotel holds more than the room rate and a pump holds more than the fill.
6. Capture is the merchant declaring that an approval should become money, and it sits between the authorisation response and the clearing file.
7. Clearing is file-shaped and batch-driven, carried by Visa’s BASE II transaction codes and Mastercard’s IPM messages, and it is where a transaction acquires the identifiers that disputes will later be filed under.
8. Settlement is net rather than gross, is computed by the scheme and executed between nominated settlement banks, and already has interchange applied inside it, so there is no interchange bill to pay.
9. The acquirer then pays the merchant separately, under a merchant agreement rather than the scheme rulebook, on a schedule that may be anywhere from the next working day to five days later.
10. Cut-offs exist at every hop and are not aligned, which is why a Friday evening purchase is presented on Monday and funded on Wednesday, and why none of the systems involved is actually slow.
11. A reversal is the only fast instrument in the whole chapter, and the obligation is measured in hours from the moment the merchant knew, not days from the moment it got round to it.
12. Where the final amount is genuinely unknown, an estimated authorisation followed by increments is the sanctioned pattern, on condition that the estimate is genuine and every message carries the linking identifiers forward.
13. Failing to code those indicators and identifiers is not untidiness; it moves dispute liability onto the acquirer and the merchant.
14. Fuel dispensers use an older construct with a segment ceiling instead, and the published ceilings are rewritten every few years, so they must be versioned against the rulebook edition in force rather than against whatever figure is circulating.
15. Partial approval lets an issuer approve a smaller amount than was asked, and a terminal that never declared the capability will treat the smaller approval as a full one, which is a repeatable way to give goods away.
16. Refunds historically had no promise attached at all, because the issuer will not promise money it has not received, so they travelled at the speed of files.
17. Refund authorisation mandates supply the missing promise and make a pending credit visible immediately; they do not make the money arrive any sooner, and a refund can now be declined, which point-of-sale software must handle.
18. The schemes charge for authorisations that never become money, because an unmatched authorisation is a hold on a customer’s account for which no value will ever exist.
19. Mastercard’s final-authorisation rule carries the sharpest lesson in the chapter: the rulebook is not asking a merchant to be accurate, it is asking it to be honest about whether it knows.
20. So the honest answer to a customer asking why the refund is slow is that the payment was never fast — the promise was fast, the money has always taken days in both directions, and the refund is simply the first time anybody notices.

Sources: Visa, Estimated and Incremental Authorization and Reversal Processing Requirements for Visa Merchants (2024 and 2023 editions); Visa Business News, U.S. Automated Fuel Dispenser Authorization Limits Will Be Increased, effective 17 October 2020; Visa Merchant Resource Library; Verifi (a Visa company), Visa Purchase Return Authorization FAQ; Visa Acceptance Solutions Payments Acquirer Implementation Guide, TC 33.A Capture File and Edit Package (BASE II Clearing: Interchange Formats, TC 01 to TC 49); Mastercard, Switching explained (Authorization Platform, GCMS, Settlement Account Management); Mastercard Switch Rules manual; Mastercard Chargeback Guide, clearing and processing cycles; Mastercard IPM Clearing Formats message type and function code tables; ISO 8583 third-edition Annex D code listings as circulated by Accredited Standards Committee X9 (action codes, authorization life cycle codes); ISO 8583 data element definitions for DE90 and DE95; Worldpay Total Hospitality documentation, Online Refund and the online authorisation of refunds mandate; Fiserv Merchant Services published pass-through fee schedule; acquirer pass-through bulletins for January 2025 Visa and Mastercard fee changes.