Skip to main content
Commerce Security Authority
Category: Transaction Processing

Authorization Response Code

Also known as: ARC, Authorization Response, Response Code, Transaction Response Code
Simply put

An Authorization Response Code is a value that a card issuer sends back after a merchant submits a payment authorization request, indicating whether the transaction was approved or declined. It communicates the issuer's decision and, in some cases, the reason behind it, such as a referral or a request to review the transaction. The specific codes and their meanings vary by card network and processor.

Formal definition

The Authorization Response Code is a value returned by the card issuer to the acquirer or merchant that indicates the issuer's decision on an authorization request, typically approval, decline, referral, or hold for review. In the Mastercard network, this value is carried in ISO 8583 Data Element (DE) 39 of the issuer's response message and reflects the issuer's reason for approving or declining. Individual card networks and payment gateways define their own code sets and meanings (for example, an APPROVAL code of '01' in some processor mappings), so the exact value, format, and interpretation depend on the network, processor, and API involved; readers should confirm code definitions against the relevant network or processor specification. The response code conveys the authorization outcome only and is distinct from an authorization (approval) code identifier and from settlement or clearing results.

Why it matters

The Authorization Response Code is the mechanism by which an issuer's decision on a payment authorization request is communicated back to the acquirer or merchant. Because it conveys whether a transaction is approved, declined, referred, or held for review, it directly drives the merchant's next action at the point of sale or checkout. Misinterpreting a response code, or treating a decline as an approval, can result in fulfilling orders that will not settle, or in unnecessarily rejecting legitimate customers, so accurate handling is operationally significant for both revenue and risk.

A recurring source of confusion is that code sets and their meanings are not universal. The specific values, formats, and interpretations vary by card network, processor, and API. As the evidence shows, Mastercard carries the value in ISO 8583 Data Element 39, while processors such as Galileo, Authorize.Net, and North each publish their own response code mappings (for example, an APPROVED value of '01' in one processor's mapping). Building logic against an assumed universal code set, rather than the relevant network or processor specification, is a common integration error.

It is also important to distinguish the Authorization Response Code, which conveys the authorization outcome only, from an authorization (approval) code identifier and from settlement or clearing results. An approval at authorization does not by itself guarantee that funds will clear, and reason-carrying response codes such as referral or hold-for-review are intended to prompt further action rather than to indicate a final financial disposition. Treating any of these as interchangeable can lead to reconciliation and fraud-handling gaps.

Who it's relevant to

Payment Processors and Gateways
Processors and gateways define and publish the response code sets returned to merchants and must map issuer and network responses (such as Mastercard DE 39 values) into their own documented code sets. Accurate, well-documented mappings help merchants interpret outcomes correctly and reduce integration errors.
Acquirers
Acquirers relay authorization decisions between issuers and merchants and rely on the response code to communicate the issuer's outcome. They are responsible for ensuring the response is passed through faithfully and interpreted consistently with the relevant network specification.
Merchant Integration and Engineering Teams
Developers building checkout and point-of-sale flows must handle approval, decline, referral, and hold-for-review outcomes distinctly, coding against the specific processor or network specification rather than an assumed universal code set. Correct handling helps avoid fulfilling non-settling orders or rejecting legitimate transactions.
Fraud Analysts and Risk Teams
Response codes such as decline, referral, and hold for review can inform risk workflows, but they convey the authorization outcome only and are distinct from settlement results. Analysts should treat these codes as one input among several and confirm code meanings against the relevant processor or network documentation.
Reconciliation and Finance Teams
Because an authorization outcome is distinct from settlement or clearing results, finance and reconciliation staff need to distinguish the Authorization Response Code from the authorization (approval) code identifier and from downstream clearing outcomes to reconcile transactions accurately.

Inside ARC

Response Code Value
A code returned by the issuer (relayed through the network and acquirer) that indicates the outcome of an authorization request, such as an approval or one of several categories of decline. The specific values and their meanings are defined by card brand and network specifications and may vary by message format.
Approval Indication
A value signaling that the issuer authorized the transaction for the requested amount. An approval reflects the issuer's decision at the time of authorization and does not, by itself, guarantee final settlement or immunity from later chargebacks under card brand and network rules.
Decline Indication
A value signaling that the issuer did not authorize the transaction. Declines can reflect different reasons, such as insufficient funds, suspected fraud, or invalid account data, and the granularity of reason information depends on the network message and issuer response.
Referral or Additional-Action Indication
Some response codes indicate that further action is required rather than a straightforward approval or decline. Handling of these depends on the acquirer, processor, and card brand rules.
Relationship to Authentication Results
The authorization response code is distinct from authentication results such as EMV chip authentication outcomes, 3-D Secure results, or CAV2/CVC2/CVV2/CID verification. These address different risks and are carried in separate data elements; an approval does not confirm that any given authentication check passed.
Data Classification Context
The response code itself is a transaction result value and is not cardholder data such as PAN, nor sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, or PIN blocks. It is often processed alongside such data, so surrounding message handling still falls within PCI DSS scope where cardholder data or sensitive authentication data is present.

Common questions

Answers to the questions practitioners most commonly ask about ARC.

Does an approval authorization response code mean the transaction is guaranteed to be legitimate and free of fraud?
No. An approval response indicates the issuer authorized the transaction at that moment based on factors such as available funds or credit and account status. It does not confirm that the cardholder is legitimate or that the transaction is not fraudulent. Card-not-present fraud, account takeover, and other fraud types can occur on approved authorizations, and an approval does not by itself determine chargeback liability, which is governed by card brand and network rules that vary by region and change over time.
Is the authorization response code the same as the response returned by address or card verification checks like AVS or CVV2?
No. The authorization response code communicates the issuer's overall decision on the authorization request, while AVS results and card verification results (such as CVV2/CVC2/CAV2/CID matching) are separate response elements addressing different checks. These verification data elements belong to sensitive authentication data or address-matching processes and must be handled accordingly; notably, sensitive authentication data such as the card verification value must not be stored after authorization even if encrypted. Reviewing the authorization response code alongside these separate results gives a fuller picture, but they are distinct fields with distinct meanings.
How should a system handle a decline response code versus a referral or hold response?
Response codes can convey different outcomes, and handling should follow the specific meaning defined by the card brand and network specifications rather than treating every non-approval identically. A hard decline may indicate the transaction should not be retried, while other responses may indicate a different action is expected. Implementers should map response codes to appropriate handling logic based on current network specifications and issuer guidance, and confirm behavior against the applicable published rules, which can vary by region and change over time.
Can authorization response codes be stored, and what data-protection considerations apply?
The response code itself is a transaction outcome value, but authorization messages and logs often accompany cardholder data such as the PAN. Any storage of cardholder data must follow defined controls, and sensitive authentication data must not be retained after authorization even when encrypted. Where the PAN appears in logs or records tied to a response, techniques such as truncation, masking, tokenization, or encryption may be applied; their effect on PCI DSS scope depends on implementation and validation, not on the label alone. Confirm applicable requirements against the current published PCI DSS.
Should authorization response codes be used as a fraud-detection signal, and what are the limitations?
Response codes and associated patterns can be one input among many in fraud analytics, for example observing repeated declines that may suggest card testing. However, they are intended to reflect issuer authorization decisions, not to serve as standalone fraud verdicts. Relying on them alone can produce false positives and false negatives, and they should be combined with other signals. No single control eliminates fraud, and detection thresholds involve trade-offs that teams should tune to their risk tolerance.
How consistent are authorization response code values across card brands and processors?
Response code sets and their meanings are defined by card brand and network specifications and by processor or acquirer implementations, so values and interpretations can differ across brands, processors, and regions, and they can change over time. Implementers should not assume a fixed mapping is universal and should validate the exact codes and their intended handling against the current specifications provided by each relevant network and processor.

Common misconceptions

An approval response code means the transaction is final and cannot be reversed or charged back.
An approval reflects the issuer's authorization decision at that moment. Final settlement, disputes, and chargeback outcomes are governed by card brand and network rules, which vary by region and change over time, and an approved authorization can still be subject to a later chargeback.
An approval response code confirms that the cardholder was authenticated and that the transaction is not fraudulent.
Authorization and authentication are separate. EMV chip authentication, 3-D Secure, strong customer authentication, and CVV2/CVC2/CAV2/CID checks address different risks and are conveyed in distinct data elements. An approval does not guarantee any of these succeeded and does not by itself eliminate fraud risk such as account takeover or card-not-present fraud.
Because it is just a result code, the authorization response is out of PCI DSS scope and needs no protection.
The response code alone is not cardholder data or sensitive authentication data, but it is typically handled within authorization messages that contain such data. Systems that process, transmit, or store cardholder data remain in PCI DSS scope, and sensitive authentication data must not be stored after authorization even if encrypted.

Best practices

Interpret response codes strictly according to the applicable card brand and network specifications, and confirm meanings against current documentation rather than assuming values are uniform across brands or message formats.
Treat authorization and authentication as separate outcomes; correlate the response code with EMV, 3-D Secure, and card verification results held in their own data elements rather than inferring authentication status from an approval.
Do not rely on an approval alone as fraud assurance; layer detection and risk controls appropriate to the channel, and account for false-positive and false-negative trade-offs when tuning decline handling.
Ensure that authorization messages carrying cardholder data or sensitive authentication data are handled within PCI DSS scope, and confirm that sensitive authentication data is not retained after authorization even in encrypted form.
Log authorization outcomes with sufficient detail for reconciliation, dispute handling, and fraud analysis while applying masking, truncation, or tokenization as appropriate to any accompanying cardholder data, validating that the chosen technique actually reduces scope as implemented.
Base decisions about liability shift, chargeback handling, and referral or additional-action responses on current, region-specific card brand and network rules, and review procedures when those rules change.