Acquirer Reference Number
An acquirer reference number is the 23-digit identifier the acquirer assigns to a card transaction when it submits it for clearing — the acquirer's identity, the date and a sequence — travelling with the transaction to the network, the issuer and the cardholder's bank, so a refund, a chargeback or a missing credit can be traced to one cleared item. It is what a cardholder's bank asks a merchant for.
- Also known as
- ARN, Acquirer reference, Trace number
- Used at
- clearing and settlement records, refund tracing, chargeback and representment cases, reconciliation between the merchant's records and the acquirer's settlement, and customer service on missing refunds
- Binding
- a scheme-defined field (Visa's ARN, Mastercard's equivalent) with a fixed structure: an acquirer identifier, the Julian date, a sequence number and a check digit; assigned at clearing, not at authorisation
- Typical use by a merchant
- obtained from the acquirer's or PSP's transaction report after settlement; given to a customer whose refund has not shown, so their bank can locate the incoming credit; quoted in a dispute response to identify the transaction being defended
- Typical confusion
- with the retrieval reference number (assigned at authorisation, 12 digits, used for authorisation lookups) and with the PSP's own transaction ID (internal to the PSP)
- Parties
- the acquirer (which assigns), the network and the issuer (which carry and use it), the merchant (which reports it), and the cardholder's bank (which searches for it)
How an acquirer reference number works in practice
A merchant refunds a customer €120. The refund is submitted to the acquirer, cleared to the network and posted to the issuer, and appears on the customer's statement in three to five days — usually. The customer calls on day seven: nothing has arrived. The merchant's support agent looks up the refund in the PSP dashboard, finds its ARN — 23 digits assigned when the refund cleared — and gives it to the customer, whose bank searches its incoming items for that reference and finds the credit pending in a queue. Without the ARN the bank has a name and an amount and a week of similar refunds; with it, the exact item.
The number also anchors disputes and reconciliation. A chargeback notification cites the original transaction's ARN; the merchant's representment cites it back; the network matches the two. An acquirer's daily settlement file lists every cleared item by ARN, and a merchant's reconciliation matches those to its orders through the PSP's mapping — the join key between "what we sold" and "what we were paid". A PSP that does not expose ARNs to merchants leaves them unable to answer the customer's call or reconcile beyond totals.
For payments operations the ARN is the lowest-level reference; for a buyer of a merchant business, the ability to reconcile at ARN level is evidence that the finance function knows where its money is.
Example
A marketplace processes 90,000 refunds a month and receives 1,400 "refund not received" tickets. Its support tool shows only the PSP's internal reference; agents tell customers to wait. Average resolution eight days, and 5% of tickets become chargebacks for "credit not processed" — €31,000 a month of disputes on refunds already sent. It surfaces the ARN in the support tool and in the refund confirmation email ("your bank can locate this refund with reference …"). Tickets fall to 600 a month, resolution to two days, "credit not processed" chargebacks by 80%. The engineering was a field mapping; the number had been in the settlement file all along.
Common mistakes
- Giving a customer the PSP's internal ID, which their bank has never heard of. - Confusing the ARN with the retrieval reference number in a dispute response. - Reconciliation at the level of daily totals, so a missing item is invisible. - PSP integrations that never store the ARN, so it must be requested case by case. - Expecting an ARN at authorisation; it exists only once the transaction has cleared.