STAN vs RRN vs ARN vs Auth Code

Four identifiers, constantly confused. What each one is, who sets it, and when it is unique.

Runs entirely in your browser. Nothing you paste is uploaded, logged or stored.

Try:

When each one comes into existence

Authorisation request

Exists the moment the terminal or gateway builds the message.

STANRRN

Authorisation response

Created by the issuer and only present on an approval.

Auth code

Clearing and disputes

Does not exist yet at authorisation time. Assigned when the transaction is submitted.

ARN

Side by side

Identifier	Field	Format	Set by	Unique?
STAN	DE 11	n6, six digits	The originator of the message, so the acquirer, gateway or terminal.	Only within one originator, and only briefly. Six digits wrap after 999999, and many terminals reset the counter daily or on reboot, so the same STAN recurs constantly.
RRN	DE 37	an12, twelve characters, alphanumeric	The acquirer, and in practice its processor or gateway.	Intended to be unique for the acquirer over a meaningful period, typically well beyond a day. Not unique globally, because two acquirers can and do issue the same value.
Auth code	DE 38	an6, six characters, alphanumeric	The issuer, or whoever authorised on its behalf under stand-in.	Not unique in any useful sense. Six characters, issued independently by every issuer, and issuers reuse them freely.
ARN	not in 8583	23 digits, with a mod-10 check digit at the end	The acquirer, when the transaction is submitted for clearing.	Effectively unique. The acquirer BIN, processing date and an acquirer sequence are all inside it, so it survives as a reference across institutions.

STAN: System Trace Audit Number

DE 11

Format: n6, six digits
Set by: The originator of the message, so the acquirer, gateway or terminal.
Exists from: Authorisation request
Unique: Only within one originator, and only briefly. Six digits wrap after 999999, and many terminals reset the counter daily or on reboot, so the same STAN recurs constantly.
How far it travels: Echoed unchanged in the response, and repeated in DE 90 when a reversal or advice refers back to the original.
Use it for: Matching a response to the request that produced it, and matching a reversal to the transaction it cancels.
Do not use it for: Looking a transaction up later. It is not unique beyond its own short window, and nothing downstream of authorisation carries it.

A STAN is not a counter you can read anything into. Gaps are normal, because a terminal increments it for messages that were never sent onward, including network management.
If a response comes back with a STAN that is not yours, the match is wrong, not the number. Some processors have been known to renumber on the way through, which is exactly the bug this field exists to expose.

RRN: Retrieval Reference Number

DE 37

Format: an12, twelve characters, alphanumeric
Set by: The acquirer, and in practice its processor or gateway.
Exists from: Authorisation request
Unique: Intended to be unique for the acquirer over a meaningful period, typically well beyond a day. Not unique globally, because two acquirers can and do issue the same value.
How far it travels: Echoed in the response and carried through into clearing, which is what makes it the useful one to quote in a support ticket before a dispute exists.
Use it for: Retrieving the original transaction record from the acquirer, which is where the name comes from.
Do not use it for: Proving a transaction is unique on its own, or keying a database across multiple acquirers.

ISO 8583 defines this field as an12 and nothing else. Any structure inside it is an acquirer convention, not a standard.
The widespread convention is a Julian date and hour at the front, then an acquirer sequence. It holds often enough to try, and breaks often enough that you cannot depend on it.
Alphanumeric means alphanumeric. A system that stores the RRN as an integer will corrupt every value an acquirer chooses to put a letter in.

Auth code: Authorisation identification response, the approval code

DE 38

Format: an6, six characters, alphanumeric
Set by: The issuer, or whoever authorised on its behalf under stand-in.
Exists from: Authorisation response
Unique: Not unique in any useful sense. Six characters, issued independently by every issuer, and issuers reuse them freely.
How far it travels: Returned in the approval, then quoted back in the clearing record so the settlement can be tied to the authorisation that permitted it.
Use it for: Proving that an authorisation was approved, and tying a capture to that approval.
Do not use it for: Identifying a transaction. Two unrelated transactions sharing an auth code is ordinary, not a collision worth investigating.

It is only present on an approval. A decline has no auth code, so a missing DE 38 with a DE 39 of 05 is the system working, not a field that went astray.
A voice or offline authorisation produces an auth code obtained out of band, which is then keyed into the capture. That is the one case where a human types this field.
Do not invent one to force a capture through. Issuers and processors do check it against the authorisation, and a mismatch turns into a chargeback with no defence.

ARN: Acquirer Reference Number

clearing record

Format: 23 digits, with a mod-10 check digit at the end
Set by: The acquirer, when the transaction is submitted for clearing.
Exists from: Clearing and disputes
Unique: Effectively unique. The acquirer BIN, processing date and an acquirer sequence are all inside it, so it survives as a reference across institutions.
How far it travels: Clearing, settlement, retrieval requests and chargebacks. It is the identifier a dispute is argued over.
Use it for: Tracing a settled transaction, and everything dispute-related, including telling a cardholder which transaction a refund belongs to.
Do not use it for: Anything at authorisation time. It does not exist yet, which is the single most common misunderstanding about it.

An ARN appears one to three days after the authorisation, once the transaction clears. Asking a gateway for the ARN of an authorisation that has not been captured is asking for a value nobody has created.
An authorisation that is never captured never gets an ARN at all. It expires silently, and there is no dispute trail because there was no settlement.
It is not an ISO 8583 data element. It comes from clearing records, so the auth log has no field for it.

The question behind the question

Almost every ticket that starts "can you look up transaction 048123" is really asking one of two things: which transaction was this, or did it get paid. The four identifiers answer different halves of that, and only one of them is any use for a dispute.

Why the ARN is never available yet

The complaint arrives roughly weekly: the gateway shows an approved transaction but no ARN. The ARN is assigned when the acquirer submits the transaction for clearing, which happens after the day's batch closes. Before that there is nothing to return, and an authorisation that is never captured will never have one at all.

So if you need to trace something today, the RRN is the identifier to quote, because it exists from the moment the request was built and is carried forward into clearing. Come back for the ARN once the transaction has settled.

Why six digits cannot be resolved by looking

A STAN is n6 and an auth code is an6. An auth code containing a letter is unambiguous, but most issuers use digits, so the common case is genuinely undecidable from the value. What settles it is direction: a STAN is something the acquirer put in the request, an auth code is something the issuer sent back, and it only exists on an approval.

So a declined transaction has no auth code. A support system showing an empty approval code beside a decline is not missing data.

None of these is a primary key

The STAN wraps at 999999 and often resets daily. Auth codes are six characters chosen independently by every issuer, so collisions are routine rather than remarkable. The RRN is unique for one acquirer, not across acquirers. Only the ARN carries enough inside it, an acquirer BIN plus a date plus a sequence, to stand on its own, and it does not exist until clearing.

If you need a stable identifier from the first moment of the transaction, use your own. Your processor's transaction id is generated by the system you can actually query, and it is the thing worth putting in a log line. These four are for talking to other institutions.

The RRN date reading is a convention

Many acquirers build an RRN as a Julian date and hour followed by a sequence, and this tool will point that out when the leading digits resolve to a plausible date. ISO 8583 defines the field as twelve alphanumeric characters and says nothing about structure, so treat any reading of it as a hint to confirm, not a fact. Check it against a transaction whose date you already know before you rely on the pattern for your acquirer.

More ISO 8583 tools

All ISO 8583 tools

Message decoder beta

Paste a whole authorisation message and get every data element split out, interpreted and mapped to its bytes.

MTI decoder

Split a 4-digit message type indicator into version, class, function and origin.

Bitmap decoder

Turn a primary and secondary bitmap into the list of data elements present, and back again.

DE reference

All 128 data elements with formats, lengths and the ones processors love to redefine.

Decline codes

DE 39 response codes in plain English, with what to actually do about each one.

POS entry mode

What DE 22 and tag 9F39 mean, from chip to contactless to fallback to e-commerce, and why it changes your interchange.

AVS & CVV

Address and security-code check results in plain English, including which ones are fraud signals.