Response

What moat returns when you create or query a transaction — response codes, AVS and CVV responses, and the correlation ID for support.

Every transaction response carries a consistent envelope and a set of specific fields that tell you how the transaction was handled. This page is the reference for interpreting those fields.

Envelope

{
  "status": "success",
  "msg": "success",
  "data": {
    "id": "txn_abc123",
    "response": "approved",
    "response_code": 100,
    "amount": 1299,
    "amount_authorized": 1299,
    ...
  }
}

Field	Description
`status`	`success` or `failed`. Reflects whether the API accepted and processed the request, not whether the issuer approved it.
`msg`	Human-readable summary. Safe to log; not safe to show to cardholders verbatim.
`data`	The transaction record, populated on success.

Status vs. response

status: "success" means the request was processed. The issuer's decision lives in data.response and data.response_code. A declined card returns status: "success" with response: "declined" — that is a successful API call with a declined outcome.

Response codes

The response_code field indicates how the processor handled the transaction. Codes fall into four ranges.

Range	Meaning
`100`	Approved
`200–299`	Declined by the issuer
`300–399`	Gateway / processor error (not a decline — a problem reaching the issuer)
`400+`	Miscellaneous and extended codes (see full reference below)

Common codes

Code	Meaning	Customer action
`100`	Approved	None
`200`	Declined	Try a different card
`201`	Declined — call issuer	Contact card-issuing bank
`202`	Insufficient funds	Try a different card or fund the account
`203`	Over limit	Try a different card
`204`	Transaction not allowed	Use a different card or method
`220`	Incorrect payment data	Verify card number, expiration, CVV
`221`	No such card issuer	Check the card number
`222`	No card number on file	Try a different card
`223`	Expired card	Update the card
`224`	Invalid expiration date	Correct the expiration
`225`	Invalid card security code	Re-enter CVV
`240`	Call issuer for further information	Contact card-issuing bank
`250`	Pick up card	Do not reattempt; possible fraud
`251`	Lost card	Do not reattempt
`252`	Stolen card	Do not reattempt
`253`	Fraudulent card	Do not reattempt
`260`	Declined with further instructions	Read `msg` field
`261`	Declined — stop recurring	Halt any recurring schedule
`262`	Declined — stop recurring for two	Halt recurring, retry a limited number of times
`263`	Declined — updated cardholder data available	Try Account Updater
`264`	Declined — retry in a few days	Retry with backoff
`300`	Gateway error	Retry with exponential backoff
`400`	Transaction error returned by processor	Inspect `msg`
`410`	Invalid merchant configuration	Contact support
`411`	Merchant account inactive	Contact support
`420`	Communication error with processor	Retry

Reading declines

Use the response_code to drive behavior: retry, pause recurring, or stop permanently. Use the msg field for human-readable logs. Do not show raw processor messages to the cardholder — most are confusing and some imply information you shouldn't share.

AVS response

Address Verification System checks your submitted billing address against what the issuing bank has on file. The avs_response_code field in the response tells you the result.

Code	Meaning	Recommended action
`M`	Full match (address + postal code)	Proceed
`N`	No match	Elevate fraud risk; consider declining
`U`	Unavailable	Use other fraud signals
`S`	Not supported by issuer	Use other fraud signals
`I`	Address not provided	Consider requiring billing address

CVV response

Code	Meaning	Recommended action
`M`	Match	Proceed
`N`	No match	Consider declining; possible fraud
`U`	Not verified	Use other fraud signals
`S`	Not supported by issuer	Use other fraud signals
`I`	CVV not provided	Consider requiring CVV

Partial authorization

When you submitted allow_partial_payment: true and the issuer partially approved the transaction, compare amount_authorized to amount. They will differ. Your integration should either accept the partial amount and collect the rest another way, or void the authorization and prompt for a different payment method.

Correlation ID

Each response carries an x-correlation-id header. This is the one value support asks for first. Log it alongside the rest of the response — especially on failures — and include it when you open a ticket.

3DS response fields

If 3D Secure was used, the response includes the ECI indicator, CAVV, and version fields. See 3D Secure for what each field means.