Acquirer Reference Numbers: use the ARN to trace a missing card refund

An Acquirer Reference Number, or ARN, is a transaction reference that can help a cardholder's bank trace a card refund as it moves through the payment network. It is most useful after the merchant has already issued the refund but the customer says the credit is not visible on their statement.

The ARN is a payment-network tracing reference

Stripe's current support guidance describes an ARN as a unique number assigned to a card transaction as it moves through the payment flow. For supported Visa and Mastercard refunds, the merchant can give the ARN to the customer so their bank can investigate where the credit sits.

The ARN is not the merchant's order number and not the processor's internal payment ID. Keep each identifier separately because customer service can need all three for different investigations.

The ARN may not be available immediately

A refund can be created before the network tracing reference is final. Processor dashboards can show the ARN as processing and make it available later, sometimes after one to three business days.

Do not tell the customer the refund failed merely because the ARN is not visible on day one. Check the processor refund status and expected posting time first.

STAN or RRN can help where ARN is unavailable

Some networks or transaction types do not support ARN. Stripe notes that a System Trace Audit Number or Retrieval Reference Number can sometimes be used instead, particularly for reversals or single-message networks.

Customer-support teams should know which reference the provider exposes and avoid inventing a number from the merchant order system that the cardholder's bank cannot search.

Use the reference only after normal refund timing has been considered

Card refunds can take several business days to appear. If the expected window has passed, provide the exact refund amount, date, merchant name and ARN so the customer's bank has a precise search request.

This is usually more effective than issuing a second refund because the first one appears missing. A duplicate credit creates a new loss and a later recovery problem.

Store the tracing reference with the original transaction

Keep ARN, refund ID, payment ID, customer order and refund amount linked in the merchant system. This allows another employee to investigate without searching the provider dashboard manually.

For partial refunds, store the reference for each refund event because one purchase can generate several credits with different dates and identifiers.

Separate customer refund tracing from merchant payout tracing

An ARN helps trace a refund toward the cardholder. A missing payout from the processor to the merchant's bank can use a different payout trace ID or banking reference.

Finance should therefore know whether the missing money is customer-side or merchant-side before asking the bank to investigate.

Worked example: a merchant refunds £480 on Monday. Ten days later the customer says nothing has arrived. The processor shows the refund succeeded and provides an ARN. The customer gives that ARN, amount and date to their issuing bank, which can trace the card-network credit without the merchant sending another £480.

Build ARN handling into refund support scripts. Staff should first confirm the original payment and refund status, then provide the network reference only when it is available and useful.

Track how many refund cases need manual tracing. A sudden increase can indicate processor delays, customer communication issues or a system problem that deserves escalation beyond individual support tickets.

For support teams, distinguish a missing refund from a missing original purchase. The ARN is most useful when the refund itself was sent but has not appeared at the issuing bank. If the original charge never captured or the refund failed inside the processor, tracing through ARN is the wrong investigation route.

Worked example: a customer has two £150 refunds from the same merchant on different dates. Each refund can have its own network reference. Customer service should provide the ARN that matches the exact refund date and amount rather than one generic transaction ID, otherwise the issuing bank can trace the wrong credit.

Keep ARN visibility role based. Customer support needs the tracing reference but does not need administrative access to payout settings or API secrets. Expose the minimum transaction data required to resolve the case.

Build a support threshold before escalating to the acquirer. If the processor says refunds normally post within five to ten business days, issuing an ARN investigation after one day adds work without improving the customer's outcome.

Preserve tracing references when customer accounts are deleted under normal retention rules if financial evidence must legally remain. Support history and privacy deletion processes should be designed together.