.svg)
.svg)
.svg)
.svg)
.svg)
The unified orchestration layer for wallets and alternative payments
.svg)
The secure repository for all your payment methods
.svg)
Workflow-driven payments intelligence for smarter routing and higher auth rates
.svg)
A flexible fraud and authentication layer. Instantly add advanced fraud tools and 3DS
One integration to sell inside ChatGPT, Gemini, and every agentic platform
The visual workflow builder that ties fraud, identity, and payment routing together in one place
The unified orchestration layer for wallets and alternative payments
The secure repository for all your payment methods
Workflow-driven payments intelligence for smarter routing and higher auth rates
A flexible fraud and authentication layer. Instantly add advanced fraud tools and 3DS
One integration to sell inside ChatGPT, Gemini, and every agentic platform
The visual workflow builder that ties fraud, identity, and payment routing together in one place
Acquirer Response Code
An acquirer response code is the standardized code returned in an authorization or transaction response that indicates the outcome of the request, whether the transaction was approved, declined, or encountered a system-level error, and provides information about the reason for that outcome. Response codes are returned by the Acquirer or payment gateway as part of the authorization response message and are the primary operational signal for how to handle each transaction.
Response codes are organized around a few broad categories. Approval codes (typically beginning with "00" in ISO 8583 format, or represented as "approved," "success," or similar in modern REST APIs) indicate the transaction was authorized. Decline codes indicate the issuer or acquiring system refused the transaction, each decline code corresponds to a specific reason, from insufficient funds to lost/stolen card to authentication required. Error codes indicate a system-level problem, network timeouts, gateway connectivity issues, invalid request formatting, that prevented the transaction from reaching the issuer at all.
The specific response code format varies by gateway and acquirer. Traditional card processing uses ISO 8583 numeric codes (51, 05, 41, etc.). Modern REST API gateways return string-based or descriptive response codes. International acquirers may use locally-specific code sets. This variation is one of the practical challenges of managing a Multi-Gateway Strategy without an orchestration layer, each gateway speaks a slightly different language for the same underlying event.
Payments Orchestration Platforms normalize response codes across all connected gateways into a consistent taxonomy, allowing merchants to write Retry Logic, Decline Salvage, and alerting rules that work predictably regardless of which gateway processed a given transaction.
Frequently Asked Questions
How are acquirer response codes different from card network response codes?
Card network response codes (those defined by Visa and Mastercard in their issuer response code standards) originate from the issuing bank and are transmitted back through the network and acquirer to the merchant. Acquirer response codes encompass both the issuer-originated codes and acquirer-level codes for conditions that occur at the acquiring side, connectivity errors, batch failures, gateway-specific validation rejections, before the transaction reaches the card network.
What should a merchant's system do when it receives an unrecognized response code?
Unrecognized response codes should be treated as potential errors rather than approvals, defaulting to "unknown outcome" rather than treating silence as consent. The appropriate handling depends on whether the code is closer to an approval or a decline pattern, but in the absence of clear information, the safest operational approach is to treat the transaction as unconfirmed, not fulfill the order, and investigate the response before taking action.
How do response codes inform [Dynamic Routing] decisions?
Response code patterns are a key input into Dynamic Routing logic. A gateway that consistently returns specific decline codes, particularly soft declines, on a transaction type where another gateway succeeds suggests a mismatch between that gateway's acquiring relationships and the transaction profile. Routing logic that monitors decline code distributions across gateways can identify when traffic should shift from a gateway generating excessive specific decline types to one with better performance for those transaction characteristics.
