Free · Intermediate · ~8 min read · Updated 2026-08-15

Matching a Refund Back to Its Original Transaction: Five Candidate Keys

Nothing in a refund message says which purchase it reverses — unless whoever raised the refund carried an identifier across. Five fields can carry it: DE38 approval code, DE37 RRN, DE31 acquirer reference data, Visa's Transaction Identifier and Mastercard's Transaction Link Identifier. Each is generated by a different party, each carries a different guarantee, and each breaks in a different place.

On this page: Refunds, reversals and chargebacks · The five candidate keys · Where each key sits · What decides which one you use · Check which keys your own data carries

Refunds, reversals and chargebacks are three different things

A refund is a new, independent transaction: the transaction-type digits of the DE3 processing code are 20 (refund / credit). It has its own message, its own amount and its own clearing record, and it moves money the other way.

A reversal cancels a message that was already sent (0400/0420). DE90 (original data elements) is a fixed 42-character block carrying the original message's MTI, STAN, transmission time and institution IDs — the reversal states which message it cancels. A chargeback is a third path, initiated by the issuer, carried on Mastercard as 1442.

A refund message carries no such field; at the message level it is just another ordinary transaction. Landing it on the right purchase takes a field that both messages carry with the same value.

The five candidate keys

Key	Generated by	What the rules guarantee	When it fails to match
DE38 Approval code	Issuer, returned in the authorization response	`an 6`. Mastercard's public rules require that for a transaction authorized on its network, DE38 of the First Presentment/1240 carries the same value as DE38 of the related `0110` response	Six alphanumeric characters, generated by each issuer itself and reused after a while; the rules give no cross-issuer, cross-time uniqueness guarantee. Some refunds go straight to clearing without being authorized at all — those carry no approval code, so there is nothing to compare
DE37 Retrieval reference number	Assigned by the acquirer	`an 12`. Used to trace one transaction across systems; stays consistent across request, response and reversal	Numbering schemes are the acquirer's own, so uniqueness is not guaranteed across institutions; a refund is a new transaction and gets its own RRN, different from the purchase's
DE31 Acquirer reference data (ARD/ARN)	Acquirer	The clearing-side trace number; used to find the transaction when there is a dispute or someone requests the receipt	A refund carries its own ARD. Note also that DE31 in an authorization message means acquirer settlement fee — a completely different thing from acquirer reference data in a clearing file. Same field number, but the two sides cannot be read the same way
TID Visa Transaction Identifier	Visa, returned in the authorization response	Visa permits a merchant to send the original purchase's TID in the refund's authorization request; Visa returns the same TID in the response, and the merchant submits that value in settlement	Relies on the merchant or payment service provider putting it on the refund; if they do not, the two records have nothing in common. Only Visa has this field
TLID Mastercard Transaction Link Identifier	Mastercard, issued with the authorization response	22 alphanumeric characters. Every lifecycle event of the same transaction shares one value — authorization, capture, refund, chargeback	A newer mechanism — acquirers and payment service providers only started using it around 2026, so older data has no such field. Only Mastercard has it

Where each key sits

DE38 and DE37 keep the same field number and the same meaning on both the authorization and clearing sides, so they read straight off. STAN vs RRN covers why RRN travels across systems better than STAN, and the way STAN wraps around.

Visa's TID is 15 digits and sits in TCR5, positions 4–19 of a BASE II / CTF record — not in TCR0. Both the purchase (TC05) and the credit (TC06) carry it; whether those two TCR5s hold the same value is exactly what determines if the chain is intact.

Mastercard's TLID is issued on the 0110/0210 response and lands in DE105 of the First Presentment/1240. DE105 is reserved for ISO in the 1987 standard with no assigned meaning; the scheme has taken the position over — see the DE105 example in the field reference, and Mastercard authorization vs clearing for fields that move between message families.

What decides which one you use

Which scheme the traffic runs on. TID exists only on Visa, TLID only on Mastercard. One rule covering several schemes can only use a field both schemes have — DE38, DE37 or DE31.
Whether you are matching history or new traffic. Data from before each party started using TLID has no such field; TID depends on whether whoever raised the refund put it there at the time. The keys available on old data and on new traffic are not necessarily the same.
Whether the column exists in your tables. A field being present in the clearing file does not mean it reached your posting or ledger tables. Before building on it, check the table: is the column there, and is it mostly empty?
Who raises the refund. TID and TLID stay intact only if whoever initiates the refund carries the original identifier. If refunds are raised from a merchant back office or a third-party payment service provider, whether that identifier gets carried is their decision, not yours.
What a miss costs. Whether an unmatched refund is parked for someone to check by hand, or matched on looser criteria at the risk of pairing it with the wrong purchase. That sets how loose a key you can accept, and whether you need a second set of matching conditions at all.

Check which keys your own data carries

Drop a Visa BASE II / CTF file into the Visa clearing file parser — the TCR5 row breaks out the Transaction Identifier on its own, so a purchase and its credit can be read side by side to see whether the value matches.
Drop a Mastercard IPM (T112) file into the IPM file parser — every data element and PDS subelement of the 1240 record is expanded, DE105 among them.
For a single authorization message, the ISO 8583 message parser reads DE37 and DE38 straight out by field number.

Sources: Mastercard's requirement that the clearing message repeat the DE38 from the authorization response, and TLID being issued on the authorization response and landing in DE105 on the clearing side, come from Mastercard's publicly published Transaction Processing Rules. TLID's length and lifecycle coverage follow acquirers' public documentation (for example Stripe and Worldpay). The Visa practice of carrying the original TID on a refund comes from Visa Acceptance's public acquiring documentation. The IPM Clearing Formats and Visa's full BASE II layout are each scheme's licensed specification and are not reproduced here. Values and requirements are revised between versions — check your own counterparty specification before building on any of this.