Card transaction codes explained: RRN, ECI, MCC, MDES and VROL
The RRN is the 12-digit reference on a card receipt that finds a payment, refund or dispute. ECI shows how far a payment was authenticated, MCC names the business, MDES tokenises cards.
Five codes follow a card payment from the checkout to a dispute. The RRN, or retrieval reference number, is the 12-digit reference printed on many card receipts, and it is what a merchant, an acquirer or an issuer uses to find the payment, refund it or answer a dispute. The ECI says how far an online payment was authenticated (ECI 7 means it was not), the MCC is the four-digit code for the merchant's business, MDES is Mastercard's token service, and VROL, Visa Resolve Online, is where Visa disputes are worked.
Where each code sits in one payment
Each code is added at a different moment, and only one usually reaches the receipt:
At checkout. 3-D Secure returns an ECI value with a proof of authentication.
At authorisation. The request carries the MCC, the ECI and, for a saved card, a token instead of the card number. The acquiring side gives it an RRN.
On the receipt. The RRN is printed beside the authorisation code.
At clearing. The acquirer adds an acquirer reference number (ARN).
In a dispute. For Visa, the issuer and the acquirer work the case in VROL.
What is the RRN on a receipt?
A retrieval reference number is a 12-digit reference that the acquiring side gives a card transaction and that travels with every message about it. On a printed receipt it usually sits near the bottom, beside the authorisation code and the terminal ID, labelled "RRN", "Ref. No." or "Retrieval ref".
Visa does not require it. Its Core Rules of 18 April 2026 list what every receipt must show, from the masked card number and the authorisation code to the amount, the date and the merchant's name (Visa Core Rules, section 5.9.2.2). The RRN is not on that list; acquirers and terminals add it because it makes the payment easy to find.
The same rules limit what the customer's copy may show. For terminals and gateways deployed since 15 October 2022, and for all of them from 16 October 2027, the full card acceptor ID, merchant ID and terminal ID must not appear on it; the last four digits may (section 5.9.2.1). That is why a receipt shows "MID ****4821" while the RRN is printed in full.
How an RRN is built, and what it finds
Visa's developer documentation describes the field as a 12-digit number "used with other data elements as a key to identify and track all messages related to a given cardholder transaction", and says the same number appears in the "response, advice, reversal, chargeback, chargeback reversal, or representment" (Visa Direct API reference). Mastercard's documentation calls its field DE 37 a system-supplied document reference that helps "Locate the original transaction source document" (Mastercard Developers).
Visa recommends the format ydddhhnnnnnn: the last digit of the year, the day of the year, the hour on a 24-hour clock, then a six-digit number such as the trace number. The illustrative RRN 628714052931 reads as 6 (2026), 287 (14 October), 14 (between 14:00 and 14:59) and 052931. It is a recommendation, and acquirers may build it differently.
What the RRN is used for:
Finding a transaction. A customer calls with a receipt, and the merchant or the acquirer searches by RRN, date and amount.
Refunds. The refund is matched to the original payment through its references. A refund is a clearing record of its own, with its own ARN, which is what the cardholder's bank needs to trace it.
Disputes. A chargeback carries the payment's RRN, so the merchant can match it to the order and its evidence.
One limit: an RRN is unique only together with other data, such as the date and the terminal. Two terminals can produce the same 12 digits, which is why a search adds the date.
ECI values: what ECI 5, 6 and 7 mean
The electronic commerce indicator is a short code in the authorisation request that says how far the cardholder was authenticated. Visa's developer documentation lists the values (Visa Developer, codes):
ECI 5: a "Secure electronic commerce transaction", authenticated by the issuer through Visa Secure. Issuers must answer with ECI 05 "only for fully authenticated transactions (including risk-based authentication)" (Visa Secure processing requirements).
ECI 6: an attempt. The merchant tried to authenticate at a 3-D Secure-capable checkout, and the issuer, or Visa on its behalf where the issuer does not support EMV 3-D Secure, answered with an attempt.
ECI 7: a "Non-authenticated Security Transaction". The payment was online, but no authentication result stands behind it: 3-D Secure was not run, or it did not complete.
ECI 8: a "Non-secure transaction".
The dispute rules are why it matters. An acquirer may use ECI 5 or 6 in clearing only if the authorisation carried the authentication value, the CAVV (Visa Core Rules, section 5.8.4.4). An issuer's fraud dispute under condition 10.4 is invalid on an ECI 5 payment authenticated with EMV 3-D Secure and carrying the CAVV, and on an ECI 6 attempt with a CAVV, outside non-reloadable prepaid cards (Table 11-28).
ECI 7 is not on that list, so a card-absent fraud dispute on it stays open to the issuer. In the Europe region, where a merchant authenticates under Visa's Delegated Authentication Program only, it sends ECI 07, and the rules say plainly: "An Acquirer will accept liability in line with Transactions that contain ECI value 07" (section 7.9.3.3).
Mastercard's values: ECI 02, 01 and 00
Mastercard uses its own numbers, and the same digit can mean something else at Visa:
Value | Visa | Mastercard |
|---|---|---|
00 or 0 | Not a mail or phone order | Not authenticated |
01 or 1 | A single mail or phone order | Authentication attempted |
02 or 2 | A recurring mail or phone order | Authenticated |
05 or 5 | Authenticated through Visa Secure | Not listed |
06 or 6 | Attempted at a 3-D Secure merchant | Merchant risk, an accepted exemption |
07 or 7 | Not authenticated | Merchant-initiated or recurring |
Mastercard's checkout documentation gives "01 - Authentication Attempted", "02 - Authenticated" and "06 - Merchant Risk" (Mastercard Checkout Solutions). Its fraud-reporting reference describes 0 as a "Non-authenticated payment" and 7 as "Merchant-initiated transactions" (Mastercard Developers).
The Identity Check Program Guide adds that an accepted exemption returns ECI 06, that ECI 07 was "specially introduced for recurring payments", and that liability shifts either "merchant only" (attempts) or "fully authenticated", with the Chargeback Guide holding the current rules.
MCC: the merchant category code
A merchant category code is, in Visa's words, "a four-digit number assigned to describe a Merchant's primary business based on annual sales volume" (Visa Merchant Data Standards Manual, October 2026). The acquirer assigns it, Visa and its members use it for "activity tracking, reporting, and risk management", and Visa can require a wrong one to be corrected.
The manual's rules decide which code a business gets:
The main business. A merchant with several lines of business uses the MCC of the one with the highest sales, or a different MCC for each line.
"Miscellaneous" last. Codes ending in 99, such as 5999 (Miscellaneous and Specialty Retail Shops), only when nothing specific applies.
Each outlet, each website. A coffee shop inside a supermarket with its own name and tills has its own MCC; so does each website selling distinct goods.
Some activities override the rest. Online gambling uses 7995 for every transaction, even when gambling is not the merchant's main business.
A payment facilitator assigns the code for each sponsored merchant. Common examples are 5411 Grocery Stores and Supermarkets, 5812 Eating Places and Restaurants and 5942 Book Stores.
MDES and what MDES for Merchants (M4M) does
The Mastercard Digital Enablement Service (MDES) is "a single integrated platform for Issuers, Wallet Providers, Merchants, and other Token Requestors" to digitise Mastercard cards (Mastercard Developers, MDES). Tokenisation replaces the card number with a token that is specific to a platform, a wallet or a device.
MDES for Merchants, M4M, is the part that serves merchants and their payment providers. Mastercard's page says it lets a merchant tokenise card numbers entered by customers or already on file, "subject to issuer participation" (MDES for Merchants). What it does for a merchant:
No card numbers on file. It "Reduces the risk of fraud in case of a data breach", since the merchant stores tokens instead, which also narrows what falls inside PCI DSS.
A cryptogram for each payment. Customer-initiated payments use the token with fresh dynamic data, a cryptogram, requested through the API's transact call.
Cards that keep working. Mastercard notifies the merchant of token updates, and "Consumers do no need to re-add a replaced card".
M4M is ending. "Mastercard will globally decommission MDES for Merchants effective 31 December 2026", and every M4M customer must first integrate with Secure Card on File (SCOF) and migrate its tokens (MDES Digital Enablement API). Mastercard's FAQ says tokens migrate without merchants or consumers having to tokenise cards again, that SCOF needs its own credentials and onboarding first, and that new integrations should go to SCOF (MDES support). The migration exchanges each token's unique reference for an SCOF card ID (M4M to SCOF tutorial).
VROL: Visa Resolve Online, and who uses it
Visa calls Visa Resolve Online "an end-to-end dispute processing platform", offered "to all issuers, issuer processors, acquirers, and acquirer processors" (Visa Resolve Online). The Visa Core Rules define it as "An online Visa service for the retrieval and transmission of dispute resolution information and documentation".
Its use is not optional. A Visa member must use VROL to raise a dispute, respond to one or reverse it, send the documents, make a pre-arbitration attempt, and file, withdraw or appeal an arbitration or compliance case (section 11.3.1). It runs in a browser or through APIs, and add-ons such as Order Insight give issuers' call centres detailed digital receipts, to head off a chargeback over a charge the customer did not recognise.
Merchants do not log in to VROL. Visa says acquirers use it to "help their merchant clients deflect unnecessary disputes and resolve valid disputes", so a merchant answers a Visa dispute through its acquirer or payment provider, with the RRN or ARN, the receipt, the ECI and authentication result, and proof of delivery.
Frequently asked questions
Is the RRN the same as the authorisation code? No. The authorisation code comes from the issuer when it approves the payment, and Visa requires it on the receipt. The RRN comes from the acquiring side and tracks every message about the payment.
What does ECI 7 mean on an approved payment? The payment went through with no cardholder authentication behind it. If fraud is reported later, the issuer's fraud dispute is not blocked as it would be for ECI 5 or 6 with a CAVV.
Is MDES for Merchants still available? Until 31 December 2026, when Mastercard decommissions it. Existing integrations move to Secure Card on File, and new ones should start there.
See how a gateway handles them
A gateway is where these codes meet: it passes the ECI into authorisation, keeps the RRN and ARN on each payment, and holds the evidence a dispute asks for. Our white-label payment gateway shows each payment with its timeline, risk score and 3-D Secure result, keeps refunds and receipts in one place, and alerts the merchant to disputes; its ledger is reconciled daily with processors and banks, and the full source code is handed over. To plan one around your own acquirers, start your project at paynoramic.com.
