Views:

Introduction

Visa Acceptance Solutions (including Cybersource) transaction responses return either Reason Codes or Reply Flags, depending on the integration method used. These values indicate the outcome of a transaction, including successful processing, declines, errors, and fraud-related decisions.

Understanding reason codes helps merchants quickly identify transaction status, troubleshoot issues, and determine next steps.

Note: For a streamlined list of commonly encountered reason codes and recommended actions, refer to Payments – Common Reason Response Codes (RRC).

Reason Codes vs Reply Flags

Reason Codes

A reason code is returned for transactions submitted using:

  • Simple Order API
  • Virtual Terminal
  • Secure Acceptance – Hosted Checkout
  • Secure Acceptance – Checkout API
  • SOAP Toolkit API
  • Offline Transaction File Submission

Reply Flags (SCMP)

The SCMP integration method returns a related value called a reply flag (rflag). Reply flags represent similar outcomes but are specific to SCMP messaging.

Reason Code / Reply Flag Descriptions

The tables below list reason codes, corresponding SCMP reply flags (where applicable), descriptions of what each response indicates, and possible follow-up actions.

If you receive a reason code not listed here, please contact Client Services.

Successful Transactions

Reason CodeReply FlagDescriptionPossible Action
100SOKSuccessful transaction—

Request Validation Errors

Reason CodeReply FlagDescriptionPossible Action
101DMISSINGFIELDMissing required fieldsReview missingField_0..N and resend
102DINVALIDDATAInvalid data providedReview invalidField_0..N and resend. 
104DDUPLICATEDuplicate merchantReferenceCodeResend with a unique reference

Partial Approvals

Reason CodeReply FlagDescriptionPossible Action
110SPARTIALAPPROVALPartial amount approvedRefer to Partial Authorization documentation

Issuer & Bank Declines

Reason CodeReply FlagDescriptionPossible Action
120—Transaction not permittedCustomer contacts issuer
200DAVSNOAVS mismatch (soft decline)Capture allowed; review for fraud
201DCALLIssuer requires clarificationContact processor
202DCARDEXPIREDExpired cardRequest updated card
203DCARDREFUSEDGeneral issuer declineRequest alternate payment
204DCARDREFUSEDInsufficient fundsRequest alternate payment
205DCARDREFUSEDLost or stolen cardRefer to support
207DCARDREFUSEDIssuer unavailableRetry after delay
208DCARDREFUSEDInactive or CNP not allowedRequest alternate payment
209 / 211DCARDREFUSEDCVN mismatchRequest alternate payment
210DCARDREFUSEDCredit limit exceededRequest alternate payment
230DCVCVN mismatch (soft decline)Capture allowed; review
231DINVALIDCARDInvalid card numberRequest alternate payment
232DINVALIDCARDCard type not acceptedContact merchant bank
233DINVALIDDATAProcessor declineRequest alternate payment

System & Configuration Errors

Important: Do not repeatedly retry transactions without validating transaction status.
Reason CodeReply FlagDescriptionPossible Action
150ESYSTEM

System Error – A system error occurred during transaction processing.

 

Depending on the payment processor handling the transaction, this response may indicate:

  • A valid temporary system error, or
  • A processor rejection due to invalid or incomplete data.
  • Merchants should design transaction handling logic to correctly manage system errors and avoid endlessly retrying failed requests. Always verify transaction status before retrying and refer to the documentation for the connection method being used.

Verify status; avoid endless retries

If RRC 150 occurs repeatedly for the same merchant or transaction type:

  • This may indicate a configuration issue rather than a transient system error.
  • Confirm the merchant configuration matches the information on the VAR sheet.
    • If using Visa Acceptance Platform (VAP), review the processor setup entered on the platform.
    • If not using VAP, submit the VAR sheet in a support case for configuration validation.
      • After validation, confirm with the Merchant Acquirer that the processor account and VAR sheet details are correct.
151 / 152ETIMEOUTServer timeoutCheck Business Center before retry
154ESYSTEMBad MAC keySafe to retry payout
234DINVALIDDATAConfiguration errorContact Client Services
236DINVALIDDATAProcessor failureRetry after delay
250 / 268ETIMEOUTProcessor timeoutVerify transaction status
261—Invalid processor setupContact Client Services

Fraud & Authentication Responses

Reason CodeReply FlagDescriptionPossible Action
400DSCOREFraud score exceededReview before capture
474DAUTHENTICATEPIN requiredCollect PIN
475 / 476DAUTHENTICATEPayer authentication required/failedAuthenticate cardholder
478DAUTHENTICATESCA requiredResubmit with SCA
480DREVIEWDecision Manager reviewReview in DM
481DREJECTRejected by Decision ManagerFollow DM guidance

Aggregator & Regulatory Restrictions

Reason CodeReply FlagDescriptionPossible Action
490–494DAGGDENIED / DSYSREJECTEDAcquirer or safeguard rejectionContact acquirer
700–703DRESTRICTEDDenied parties / export controlsReject order

Refunds and Credits

Some reason codes require issuing refunds or credits after authorization or settlement. Refer to:

Payments – How to Issue a Refund or Credit

Recommended Merchant Workflow

  1. Identify the reason code in the API response or Business Center
  2. Determine the category (success, decline, error, fraud)
  3. Apply the recommended action
  4. Escalate when required (issuer, processor, Client Services)
  5. Prevent recurrence through validation and configuration review

Related Resources