Acquirer Reference Number Guide for Merchants
Written by François Savard
A cashier sees a card payment go through, the receipt prints, and the customer walks away. Later, the cardholder says the charge looks duplicated, or the day's settlement file doesn't match what landed in the business account. In that moment, the acquirer reference number, or ARN, is the reference that tells the bank where the transaction sits and how to trace it across the payment chain.
For Singapore merchants, that matters because the ARN is not a customer-facing tracking number. It is a back-office traceability key that helps the acquirer, card network, and issuer line up the same transaction record when something needs checking. The practical question is simple, what should staff capture first so the bank can find the right payment fast?
Table of Contents
- Understanding the Acquirer Reference Number
- How ARN Differs from Other Payment Identifiers
- Where to Find the Acquirer Reference Number
- Using ARN for Transaction Tracking and Reconciliation
- Resolving Customer Disputes and Chargebacks with ARN
- Handling Refunds and Voids Using Reference Numbers
- Best Practices for Storing and Managing ARN Data
- Quick Reference Guide for Payment Identifiers
Understanding the Acquirer Reference Number
A merchant can have a perfect receipt and still be unable to prove where a payment went. That usually happens when staff rely on the terminal slip alone and ignore the reference that links the payment to the wider card system. The ARN is the identifier that carries that link.
What the ARN actually does
MAS treats a unique transaction reference number as a formal traceability mechanism, defined as a combination of letters, numbers, or symbols assigned under the relevant payment or messaging rules, with the purpose of letting a value transfer be traced back to both originator and beneficiary. That principle is directly relevant to card acceptance, because it shows why the ARN matters more than a simple merchant order number or a printed receipt code. MAS guidance on transaction reference traceability
For a Singapore SME, the ARN should be treated as the reference that anchors the transaction record across the acquiring bank, card network, and issuer. It becomes especially useful when a payment is refunded, disputed, delayed, or missing from settlement. That is why the ARN belongs in the transaction file, not just in a support note.
Practical rule: if the payment problem crosses bank boundaries, the ARN belongs in the first line of the support checklist.
The merchant's job is to preserve the reference exactly as received, then pair it with the transaction date, amount, terminal identifier, and merchant reference. That gives the bank a path to reconstruct the payment without guessing. The ARN is not decorative data, it is the coordination point.
How ARN Differs from Other Payment Identifiers
Staff often grab the first number they can find and hope it solves the issue. That approach wastes time because different identifiers serve different jobs. The ARN is the trace key, while the other numbers usually prove something narrower.
The numbers staff mix up most often
An approval code shows that the issuer approved the transaction at that moment. It does not follow the payment through clearing and settlement, so it won't help much when a bank needs to investigate where the money moved later. A terminal receipt number is usually local to one device or one session, which makes it useful at the till but weak for cross-bank tracing.
A merchant order ID is even more limited because the business creates it for its own internal workflow. It can be useful for matching a sale to a customer visit, but it doesn't tell the acquirer or issuer where the card transaction went. That distinction matters because the merchant's acquirer is the primary contact for payment problems, not the terminal printer or the customer's copy of the receipt. MAS merchant guidance on payment references
| Identifier | Primary use case | Requested by |
|---|---|---|
| Acquirer Reference Number | Traces the card transaction across banks and networks | Acquirer, issuer, card network, support team |
| Approval Code | Confirms the issuer approved the payment at authorisation | Front-line cashier, customer asking whether payment went through |
| Terminal Receipt Number | Identifies the local terminal session or printed receipt | Store staff checking the slip |
| Merchant Order ID | Matches the sale to the business's internal record | Internal ops, bookkeeping, customer service |
The fastest way to avoid confusion is to train staff to ask, “Is this an internal lookup, or does the bank need to trace the payment?” If it's the second one, the ARN is the number that matters.
For a deeper view of how processors fit into that chain, a guide for finance teams on reconciliation is useful background because it shows why matching the right reference at the right step saves hours later.
Where to Find the Acquirer Reference Number
The ARN is only useful if the merchant can retrieve it without hunting through the wrong screen. In a busy shop, that usually means knowing which document or dashboard holds the number for the exact transaction. The right workflow depends on how the card went through.
On receipts, portals, and settlement records
On a physical terminal receipt, the ARN may appear alongside payment details or in a settlement-related field, depending on the processor. On a merchant dashboard, it is often attached to the captured payment, refund, or adjustment record. The key point is not the label's position on the page, it is making sure staff copy the exact reference from the correct transaction.
ISO 8583 standardises the interchange framework for card-originated messages, but it does not prescribe one universal ARN format or guarantee that a portal will show the identifier immediately after authorisation. ISO 8583 standard overview That means a cashier should not assume the ARN will be visible the second a card tap succeeds.
What to check before calling the bank
The best lookup process is usually a quick filter by date, amount, terminal ID, and merchant reference. If the transaction was reversed, refunded, or delayed, staff should check the settlement batch tied to that day rather than relying on a single receipt. That gives the acquirer enough context to find the transaction even when one field is missing or partially truncated.
A bank can only trace what the merchant can describe cleanly.
The merchant should also remember that identifier formats and timing can vary by scheme and processor. Visa, Mastercard, American Express, and wallet-originated card transactions do not always surface data in the same way, so the safest rule is to capture the ARN from the processor record rather than assuming the terminal printout is complete. When in doubt, keep the transaction date, amount, terminal ID, and authorisation code ready before opening the support case.
Using ARN for Transaction Tracking and Reconciliation
Daily reconciliation in a retail, clinic, salon, or restaurant environment is not optional. The card machine says one thing, the settlement file says another, and the bank balance has to be right by end of day. The ARN is the reference that lets finance staff line those records up without relying on memory or a customer's description.
The reconciliation workflow that holds up in practice
Start with the terminal sale and capture the ARN as soon as the transaction is visible in the merchant system. Then map that ARN to the settlement batch, because that is where the acquirer's reporting and the bank credit should align. This is also the point where a support team can see whether the issue is an authorisation, clearing, or settlement problem rather than treating every missing deposit as the same case.
Next, flag anything that does not match by amount, date, or terminal. That saves time because the staff member can escalate only the genuinely unmatched items instead of opening a ticket for every line in the file. For teams that want to automate part of that discipline, the finance teams on reconciliation resource gives a useful framework for matching references consistently.
A merchant who keeps ARNs indexed by date and terminal can usually answer three questions quickly: was the payment captured, did it settle, and was it later refunded or reversed. That makes cash-flow planning more reliable, because the store is not waiting on vague bank feedback before closing the books. It also reduces the chance of duplicate investigation when a customer asks for the same payment to be checked twice.
The settlement view should stay linked to the transaction record, not copied into a loose spreadsheet with renamed fields. A clean internal record makes the acquirer conversation much shorter, especially when the bank needs the supporting terminal data. Card settlement reference for merchants
Resolving Customer Disputes and Chargebacks with ARN
A customer walks back in and says the payment was wrong, or the cardholder calls the issuing bank and disputes an in-store charge. At that point, the merchant needs more than a receipt. The bank needs enough evidence to route the investigation to the right transaction, and the ARN is the main identifier that makes that possible.
Build the evidence bundle first
The strongest support pack includes the ARN, transaction date and time, masked card details, terminal ID, merchant ID, approval code, retrieval reference number, response code, and any refund or void reference. That bundle gives the acquirer and issuer enough structure to search the card rails without mixing the case up with another sale. Merchant services support for Singapore businesses
The merchant's acquirer is the right channel for payment problems, while the customer usually starts with the card-issuing bank. For disputes, the Association of Banks in Singapore directs consumers to contact the issuer promptly and notes that banks commonly require a dispute form within 14 days of the statement date. The merchant side should therefore focus on clean evidence rather than arguing with the customer at the counter. Association of Banks in Singapore dispute guidance
A useful habit is to capture the settlement batch and correspondence history before any duplicate refund is attempted. That helps staff avoid sending the same money twice while the original transaction is still being reviewed. It also reduces misrouting between authorisation, clearing, settlement, and chargeback handling.
Keep the evidence bundle tight, factual, and complete. Missing one reference can slow the whole case.
For merchants who want external monitoring support, Disputely chargeback alerts is a relevant reference point because it reflects the same operational truth, speed depends on having the right data before deadlines start tightening.
Handling Refunds and Voids Using Reference Numbers
Refunds sound simple at the terminal. The main issue is whether the refund can be tied back to the original card transaction without creating a second problem for accounting later. That is where the ARN and the related transaction references matter most.
Link the refund to the original transaction
Before pressing refund or void again, staff should confirm the original ARN, transaction state, settlement batch, refund status, and correspondence history. MAS materials on payment traceability point to that sequence because it lowers the chance of confusion between authorisation, clearing, settlement, and chargeback processes. MAS notice on transaction handling
The operational danger is an orphaned credit, which is a refund that no one can cleanly match to the sale it was meant to reverse. Once that happens, end-of-month close gets messy fast because finance staff are left reconciling a credit with incomplete context. The better approach is to document the original ARN, then carry the refund reference alongside it so both sides of the transaction stay connected.
A void is different from a refund in timing, but the same discipline applies. If the original payment was already moving through settlement, the merchant should not assume the void instruction solved everything unless the processor confirms the status. That confirmation becomes much easier to read when the ARN is present in the same note set.
The safest habit is to treat refund handling as a record-keeping exercise first and a cashier action second. The terminal button matters, but the audit trail matters more when a cardholder later asks where the money went. In a busy outlet, that discipline saves time and protects the store from duplicate payout errors.
Best Practices for Storing and Managing ARN Data
An ARN that lives only in someone's inbox is already at risk. When staff rotate shifts, terminals change, or a dispute arrives weeks later, the business needs the reference to be searchable, protected, and intact. That is the difference between a quick answer and a lost afternoon.
Store it exactly as received
MEPS+ documentation requires the reference to be unique for the sender, and that is a useful benchmark for handling merchant records properly. The practical lesson is simple, store the complete ARN exactly as supplied by the acquirer, and do not reformat or truncate it in spreadsheets or POS workflows. MEPS+ reference handling requirements
Keep access narrow, but lookup easy
Customer-support staff should be able to search the ARN without seeing full PAN data. That balance matters because the merchant needs fast access for disputes and refunds, but not at the cost of exposing unnecessary card details. A role-based setup with indexed search by transaction date, amount, and terminal gives staff the context they need while keeping sensitive data controlled.
- Store the original ARN with the transaction record. Copying it into separate notes invites version drift.
- Index by date, terminal, and amount. That makes support lookups usable during busy trading hours.
- Restrict access to authorised staff. The number should help trace a payment, not spread card data wider than needed.
- Log every access event. If a dispute escalates, the business needs to know who checked what.
A merchant that treats ARN storage as part of its payment control system ends up with cleaner refunds, faster bank conversations, and fewer blind spots during audits. The habit looks small on paper. In practice, it keeps payment support from turning into guesswork.
Quick Reference Guide for Payment Identifiers
Front-line teams need a short reference they can use under pressure. The table below is the easiest way to stop staff from handing the bank the wrong number and hoping it will work out.
Payment Identifier Quick Reference
| Identifier | Primary Use Case | Requested By |
|---|---|---|
| Acquirer Reference Number | Trace a card payment across the acquiring bank, card network, and issuer | Acquirer, issuer, chargeback team |
| Approval Code | Confirm that the issuer approved the transaction at authorisation | Cashier, customer, support desk |
| Retrieval Reference Number | Support retrieval of transaction details in bank and processor systems | Processor, issuer, dispute team |
| Terminal ID | Identify the physical device used for the transaction | Store ops, acquirer support |
| Merchant ID | Identify the merchant account or business entity | Acquirer, processor, finance team |
The practical rule is straightforward. If the question is, “Did the card go through at the terminal?”, the approval code or receipt details may be enough. If the question is, “Where did the payment go after it left the terminal?”, the ARN is the number that belongs in the conversation.
Sambapay helps Singapore merchants run card acceptance with clearer operational control, so payment records, settlement checks, and dispute follow-ups don't become a daily headache. For a setup that fits brick-and-mortar trading and makes reconciliation easier to manage, visit Sambapay.