Retrieval Reference Number

A retrieval reference number (RRN) is a reference code attached to a card transaction so that the parties handling it can find and match it later. It is generated, usually by the acquirer or the terminal's processing host, when the transaction is first sent for authorisation, and it travels with the transaction through the card network to the issuer. Customer service staff, merchants, processors and dispute teams use it to locate a specific payment among millions of others.

In the ISO 8583 message standard used by most card systems, the retrieval reference number is carried in data element 37, a 12-character field. It is one of several identifiers attached to a card payment, alongside the systems trace audit number, the authorisation code, the network's own transaction identifier and the acquirer reference number used in clearing. Each serves a different purpose, and confusing them is a common source of delay when tracing payments.

The RRN is assigned when the authorisation request is created and is returned in the authorisation response, so both sides hold the same value. It then appears in several places:

• Receipts. Many terminal and ATM receipts print the RRN, sometimes labelled "Ref" or "RRN", so the cardholder or merchant can quote it.
• Merchant reports. Acquirers include it in transaction and settlement reports so merchants can match authorisations to settled items.
• Reversals and adjustments. When a transaction is reversed, voided or adjusted, the follow-up message refers back to the original using the RRN and other data, so the systems can link the two.
• Disputes and enquiries. Issuers and acquirers use it to find the original record when handling a retrieval request or a dispute.

In some markets the RRN also appears on bank statements or in banking apps for card and ATM transactions, and in India it is widely used as the reference for UPI transactions, where customers quote it when raising complaints.

Within ISO 8583, the field holds 12 alphanumeric characters, though many systems use digits only. There is no single global rule for how the value is built. A common convention combines elements of the date or time, the terminal or host identifier and a sequence number, for example using a digit for the year, three digits for the day of the year, two for the hour and a six-digit sequence. Because each acquirer or processor chooses its own method, an RRN is unique only within the context of the system that created it, usually in combination with other fields such as the date, terminal and merchant identifiers.

The RRN is often confused with related references:

• Systems trace audit number (STAN). A six-digit number assigned by the message sender to each message, used to match requests with responses in real time. Unlike the RRN, it can change between related messages.
• Authorisation code. A short code returned by the issuer when it approves a transaction, which proves approval but is not unique across issuers.
• Acquirer reference number (ARN). A longer number, commonly 23 digits, assigned when the transaction is submitted for clearing. It is the main reference for tracking refunds and chargebacks between acquirer and issuer.
• Network transaction identifier. A value assigned by the card network to link related transactions, such as the initial and subsequent payments in a stored credential series, a function covered in transaction identifier.

For merchants and processors, the RRN is a key field in settlement reconciliation: it links what the terminal or gateway recorded at authorisation to what the acquirer later settled. Mismatches, such as an authorisation with no matching settled item, show up as exceptions that need investigation. In ATM networks, the RRN helps resolve cases where cash was not dispensed but the account was debited. In customer service, quoting the RRN lets the issuer find a transaction quickly instead of searching by amount and date.

When a cardholder asks for a refund to be traced, however, the ARN is usually more useful than the RRN, because it identifies the credit as it moves through clearing to the issuer. Merchants handling chargebacks therefore record both values for each transaction, together with the authorisation data, so that any later query can be answered from a single record.