Retrieval Reference Number
A retrieval reference number is the 12-digit reference assigned to a card transaction at authorisation — by the acquirer, processor or terminal, under ISO 8583 — and carried in subsequent messages so all parties can refer to the same transaction: on a receipt, in a reversal, in an issuer's retrieval request. It exists from authorisation, unlike the acquirer reference number, which is assigned at clearing.
- Also known as
- RRN, Retrieval reference, Authorisation reference
- Used at
- authorisation messages and their responses, reversals and voids (which reference the original by RRN), terminal receipts, issuer retrieval requests, processor and gateway logs, and the first step of any investigation before the item has cleared
- Binding
- the ISO 8583 standard (field 37) and the schemes' message specifications; the format is 12 characters, commonly the Julian date, an hour and a sequence, generated by the acquiring side
- Typical uses
- a customer's receipt shows it, and a support agent can find the authorisation in the acquirer's system by it; a void or a reversal cites it; an issuer that needs a copy of the transaction record (a retrieval request, the pre-dispute step) cites it
- Typical confusion
- with the ARN (23 digits, clearing), the PSP's own transaction ID (internal), the authorisation code (6 characters, the issuer's approval code), and the terminal's transaction counter
- Parties
- the terminal or gateway that generates it, the acquirer and processor that log it, the network and issuer that carry it, and the merchant and cardholder who see it on a receipt
How a retrieval reference number works in practice
A card is tapped at a terminal. The terminal builds an authorisation message with an RRN — 12 characters encoding the date and a sequence — and sends it; the response carries the same RRN and, if approved, the issuer's authorisation code. Both print on the receipt. Later that day the cashier voids the sale in error; the void message cites the RRN so the acquirer knows which authorisation to reverse. Three weeks later the issuer, asked by the cardholder what the charge was, sends a retrieval request citing the RRN; the acquirer's processor finds the transaction and returns the record. The ARN, assigned when the transaction cleared that night, is a different number for the same event, and the issuer's chargeback, if one follows, will cite that.
The two references map to the transaction's two lives: authorisation (the promise, referenced by RRN) and clearing (the money, referenced by ARN). A PSP's dashboard shows a third — its own ID — and a merchant's support team must know which to give whom: the RRN to find an authorisation or a void, the ARN to trace a settled refund at the customer's bank, the PSP ID to ask the PSP. Reconciliation systems store all three.
For payments engineers the RRN is a field in every message; for support teams it is the number on the receipt the customer is holding.
Example
A hotel's front desk pre-authorises €500 on a guest's card at check-in and captures €380 at check-out; the €120 difference should release within days but the guest sees a €500 hold a week later. The guest calls with the receipt. The desk gives the RRN to the acquirer's support line, which finds the authorisation, confirms the capture for €380 was submitted against it, and sees that the issuer has not released the excess — an issuer-side hold. The acquirer sends a reversal for €120 citing the RRN; the issuer releases it within a day. Without the RRN the acquirer would have searched by card number and date across a hotel's 400 authorisations that day.
Common mistakes
- Giving a customer's bank the RRN to trace a refund, when the bank needs the ARN. - Voids and reversals sent without the original RRN, which the acquirer cannot match. - Support tools that show the PSP's internal ID only. - Assuming the RRN is unique forever; it is unique within the acquirer's date and sequence, and reused across years. - Confusing it with the authorisation code on the same receipt.