Retry Logic

Documentation Index

Fetch the complete documentation index at: https://developers.ingopayments.com/llms.txt

Use this file to discover all available pages before exploring further.

Implementing retry logic is strongly recommended for all Ingo Payments integrations. A subset of status codes represent transient infrastructure failures — timeouts, routing issues, and temporary system errors — that are recoverable with a subsequent attempt. Failing to retry these codes results in unnecessary transaction failures that require manual intervention and degrade the customer experience. The retry codes and strategy below apply to IngoPay API integrations. Clients using Notify products should work with their Integration Manager to confirm how retry handling applies to their specific flow.

---

​

Stand-In Responses and No-Response Handling

For push and pull transactions where Ingo makes a real-time downstream call to a payment network, Ingo holds awaiting a response from the network before issuing a stand-in. The hold duration is generally up to 60 seconds, though the specific timeout varies depending on the payment network your program is configured to use. To prevent your application from waiting indefinitely, Ingo issues a stand-in response when the network has not responded within your program’s configured threshold. Stand-in settings are configured once at the program level during onboarding with your Integration Manager. Push and pull thresholds are configured separately. This behavior is most prevalent for real-time transactions — card push disbursements and RTP — where a synchronous downstream network call is required. ACH, check, and similar rails process asynchronously and are less likely to encounter stand-in conditions.

​

Push — Stand-In Success (102)

If the downstream network does not respond within your configured push stand-in threshold, Ingo returns code 102 (Success — Pending Issuer Response). Treat 102 as a success equivalent to 100. The transaction is considered complete and no additional webhook follows. The 102 is the final, definitive response for that request. Ingo recommends a push stand-in threshold of 15 seconds or higher. The longer your program can hold, the more actual network outcomes your integration receives directly rather than stand-in responses. Work with your Integration Manager to align the threshold to your customer experience model.

​

Pull — Stand-In Decline (790)

If the downstream network does not respond within your configured pull stand-in threshold, Ingo returns code 790 (Declined — Stand In) and reverses the transaction. The reversal typically appears as a refund in reporting. A 790 stand-in decline can be safely retried using the same participant_unique_id1. Because the original transaction was declined and reversed, the retry is treated as a fresh attempt. A successful retry returns 100. Ingo recommends a pull stand-in threshold of 30 seconds or higher for the same reasons described above.

​

If no response is received after the stand-in window

Ingo will always issue a stand-in response before your configured threshold elapses. Clients should wait for that response before initiating any retry — do not retry based on an immediate connection error or timeout on your side. If your stand-in window has elapsed and no response has been received, retry using the same participant_unique_id1. Possible outcomes on the retry: Idempotency codes 101, 102, and 103 only emit when the original request was previously marked successful. Receiving any of these on a retry confirms the original transaction was processed — no further action is needed.

---

​

Code 104 — In-Progress Transactions

Code 104 requires special handling. It is not a failure — it means a prior request with the same participant_unique_id1 is still processing and a new posting attempt was not initiated. When you receive a 104:

• Do not generate a new participant_unique_id1. The original transaction is active. Submitting a new ID will create a second transaction attempt, which is likely not your intent.
• Retry with the same participant_unique_id1 after a brief wait. The transaction will either complete and return a success code, or fail and return a terminal code on a subsequent attempt.
• If you are subscribed to webhooks, the outcome will also be delivered asynchronously when processing concludes.

---

​

Retry-Eligible Codes

The following codes represent transient conditions. A retry with the same request is appropriate for all of them. If all retry attempts are exhausted on any of these codes, contact Ingo Payments support and include the participant_unique_id1 and timestamp from the failed request.

---

​

Retry Strategy

The right retry interval depends on your customer experience model — specifically, whether your end customer is actively waiting for a response or has already been acknowledged and released from the interaction.

​

Customer is waiting on screen

If your program holds the customer on a confirmation or loading screen while awaiting a result, retries need to complete quickly. The customer has no feedback and every second of delay increases drop-off risk. Recommendation: 3 retry attempts within a 1 to 2 minute window. Space attempts progressively — for example, retry at 15 seconds, 30 seconds, and 60 seconds. If all three attempts fail, surface a meaningful response to the customer rather than leaving them on a loading screen. This model applies to programs where a customer initiates a payment in real time and stays in the flow until receiving a confirmation.

​

Customer has been acknowledged and released

If your program has already confirmed receipt of the request to the customer — for example, displaying a message such as “We have received your request and will process it shortly” — there is no active wait and retry intervals can be much wider. Recommendation: 3 retry attempts with intervals up to one hour between each attempt. This accommodates programs that queue requests internally before submitting to Ingo, batch and submit payment requests at set intervals, or stage payments for a scheduled processing run. In these flows, the customer’s expectation has already been set and a delay in processing does not create an immediate experience gap.

​

High-volume programs

If your program submits high transaction volumes and experiences a burst of retry-eligible errors simultaneously — for example, during an OFAC service timeout — avoid retrying all requests at the exact same interval. Staggering retry timing across your queue reduces the risk of compounding load on the same endpoint. A small random offset added to each retry interval (commonly called jitter) is an effective way to achieve this automatically.

---

​

What Not to Retry

Not all failures are transient. Retrying the following code families will not produce a different outcome and may trigger rate limiting or flag your integration for unusual behavior. Request and auth errors (4xx) indicate the request was rejected due to bad input, invalid credentials, or a suspended account. Correct the request before retrying. Validation and velocity errors (600-616, 711-725) indicate a field failed validation or a program limit was reached. Correct the field value or transaction amount, or verify the transaction is within your configured program limits. OFAC match (130) indicates the recipient was matched against the OFAC sanctions list. This is a compliance-level outcome and is terminal. Do not retry. Card issuer declines (851-867) indicate the card issuer rejected the transaction. These cannot be resolved by retrying — the recipient needs to contact their card issuer. Hard verification declines (753-815) indicate card or account data failed a configured verification check. Correct or re-verify the account data before attempting again. Notify authentication and verification failures (1100-1170) indicate the recipient did not pass authentication or identity verification. These are event-driven outcomes, not transient errors. If you are uncertain whether a specific code warrants a retry, refer to the recommended action column in the Code Reference or contact your Integration Manager.