Skip to main content
Ingo Payments returns numeric status codes across both synchronous API responses and asynchronous webhook events. Understanding the code structure helps you build reliable integrations that handle outcomes correctly — whether the code arrives in a response body or a webhook payload, the category and description apply the same way.
Ingo codes are normalized. Where an outcome originates with an upstream provider — a card network, an issuer, a bank, or a verification vendor — Ingo maps that provider’s response into a single Ingo code set before returning it to you. Integrate against Ingo values rather than provider-specific ones: your contract stays stable when a provider changes its response format and when Ingo adds support for an additional provider.

Code families at a glance

Every response code falls into a family that signals the category of outcome. Use this table to understand the meaning of any code range at a high level and determine the right action for your integration.
Codes in the 1100–1246 range are Notify product event codes. They appear in webhook payloads and, in some cases, synchronous API responses depending on the integration point. Codes in the 130 and 1106–1108 range appear in both contexts depending on your program configuration.

Status & Event Code Reference

These codes indicate the transaction was approved but a verification check returned a partial, inconclusive, or non-matching result. Review the specific code to determine whether downstream action is appropriate for your program configuration.Card — AVS (Address Verification Service)Card — ANI (Account Name Identification)Bank Account — ANV / NAV (Account & Name Validation)
These codes indicate the request was rejected before processing. Correct the issue before retrying — they will not self-resolve.
These codes indicate a timeout, routing failure, or unexpected system error. They are transient and retry-eligible. See the Retry Logic guide for recommended retry intervals based on your customer experience model. Contact Ingo support if the error persists, and include the timestamp and participant_unique_id1 from the failed request.
These codes indicate a field validation failure or a program limit has been reached. Correct the field value, transaction amount, or verify the transaction is within your configured program limits before retrying.
Hard declines from card verification services. These are terminal for the current attempt — the recipient’s card data does not pass the configured verification checks.AVS Hard Declines
An AVS failure may be reported with any of five codes depending on the failure mode. Integrations that only handle 510 should be prepared to also receive 523 (connection error), 524 (parse failure), and 525 (bad structure). 510 and 513 are AVS verification outcomes and are terminal for the current attempt; 523, 524, and 525 are infrastructure-level failures and are retry-eligible. See the Retry Logic guide for retry intervals.A timeout on the AVS call is reported as 510, regardless of what the AVS service returns in the response body.
CVV Hard DeclinesANI Hard DeclinesCard Data & Token Errors
Hard declines from bank account verification services (Routing Number Validation, Account Number Validation, Name on Account Validation). These are terminal for the current attempt.RNV — Routing Number ValidationANV — Account Number ValidationNAV — Name on Account Validation
The card issuer rejected the transaction. Do not retry automatically. Direct the recipient to contact their card issuer for more information. The specific decline reason may indicate a card status issue (lost, stolen, restricted) or an account limit that cannot be resolved without issuer action.
Workflow EventsSystem ErrorsHard Decline
Code 130 is a success-class code — the transaction was accepted but is held pending OFAC review. It is distinct from 752, which is a terminal decline. Codes 1106 (suspended), 1107 (cleared), and 1108 (failure) are the corresponding Notify webhook event codes and are documented in the Notify — Verification & Payment Events section above.
These codes are returned by the Notify API when a staged disbursement is in an incompatible state for the requested action. Check the transaction’s current state before retrying.
Shared across Notify — Classic and Notify — Managed Parties.Party AuthenticationOTAC (One-Time Authentication Code)Overall Authentication Outcome
Shared across Notify — Classic and Notify — Managed Parties.Recipient Verification — RVDMRecipient Verification — OFACAccount Verification — PayPalPayment Events
Codes specific to multi-party disbursement flows. These do not appear in Notify — Classic.
These codes confirm the email or SMS notification that was sent to a recipient, joint recipient, or approver at each stage of the disbursement lifecycle. They appear in webhook event payloads. Codes marked Managed Parties do not appear in Notify — Classic.
Code 1242 (Delegated Payment Confirmation) is reserved for role delegation, which is not yet available. It will be documented here when role delegation ships.
These codes are specific to the Ingo Banking Platform API.
These codes are returned when an ACH debit transaction is submitted for reinitiation and fails an eligibility check. Each eligibility rule has its own code so you can act on the specific reason rather than a generic rejection. Every response is returned with HTTP 200 — the outcome is in response.status.
1310 is also returned when the referenced transaction belongs to a different participant. This is intentional — a distinct “not found for this participant” code would confirm that another client’s transaction ID exists.