> ## Documentation Index
> Fetch the complete documentation index at: https://docs.eliteneobank.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Retry logic

# Retry logic

Retry logic helps merchants handle temporary transaction failures, delayed banking responses, network interruptions, and processing states safely and reliably.

Elite Neo Bank recommends implementing controlled retry mechanisms for:

* Payment verification
* Payout status tracking
* Webhook processing
* Temporary API failures
* Processing transactions

Proper retry handling improves:

* Transaction reliability
* Reconciliation accuracy
* System stability
* Customer experience
* Banking workflow resilience

***

## Why Retry Logic is Important

Banking and payment systems may occasionally experience:

* Delayed bank confirmations
* Temporary downtime
* Processing queues
* Network interruptions
* Timeout issues

Without proper retry logic:

* Transactions may remain unresolved
* Duplicate processing may occur
* Incorrect settlement assumptions may happen
* Reconciliation mismatches may increase

***

## Recommended Retry Scenarios

Retry handling is recommended when transactions are in temporary states.

| Status | Retry Recommended |
| - | - |
| `PROCESSING` | Yes |
| `PENDING` | Yes |
| `QUEUED` | Yes |
| `SUCCESS` | No |
| `FAILED` | Limited |
| `REVERSED` | No |

***

## Payment Retry Logic

Retry payment status verification when:

* Payment is still processing
* Banking confirmation is delayed
* Webhook is delayed temporarily

Always verify payments using:

* Order Status API
* Webhook notifications

before marking orders as failed.

***

## Payout Retry Logic

Retry payout status verification when:

* Bank settlement is delayed
* UTR generation is pending
* Transaction is under processing

Avoid:

* Re-initiating duplicate payouts
* Creating duplicate payout IDs
* Blind retry loops

***

## Webhook Retry Logic

If your webhook server:

* Times out
* Returns non-200 responses
* Becomes temporarily unavailable

Elite Neo Bank may retry webhook delivery automatically.

Merchants should implement:

* Idempotent webhook handling
* Duplicate event protection
* Retry-safe processing

***

## Idempotent Processing

Idempotency prevents duplicate transaction processing during retries.

Always use:

* Unique `order_id`
* Unique `payout_order_id`
* Unique transaction references

before retrying any request.

***

## Recommended Retry Strategy

### Suggested Retry Delays

| Retry Attempt | Delay |
| - | - |
| 1st Retry | 5 seconds |
| 2nd Retry | 15 seconds |
| 3rd Retry | 30 seconds |
| 4th Retry | 1 minute |
| 5th Retry | 5 minutes |

***

## Exponential Backoff

Elite Neo Bank recommends using exponential backoff to reduce:

* API overload
* Banking congestion
* Duplicate requests
* Infrastructure strain

Recommended retry pattern:

```
5s → 15s → 30s → 1m → 5m
```

## Maximum Retry Recommendations

Avoid excessive retry attempts.

Recommended limits:

| Transaction Type | Recommended Retries |
| - | - |
| Payments | 5–10 |
| Payouts | 5–15 |
| Webhooks | Controlled retries |

***

## Example Retry Logic (Node.js)

```js theme={null}
async function retryStatusCheck(retries = 5) {
  for (let i = 0; i < retries; i++) {
    const response = await fetchStatus();
    if (response.status === 'SUCCESS') {
      console.log('Transaction completed');
      return response;
    }
    if (response.status === 'FAILED') {
      console.log('Transaction failed');
      return response;
    }
    await new Promise(resolve =>
      setTimeout(resolve, (i + 1) * 5000)
    );
  }
  console.log('Maximum retries exceeded');
}
```

***

## Recommended Retry Workflow

1. Initiate transaction
2. Receive processing response
3. Retry status verification carefully
4. Process webhook notifications
5. Verify final transaction status
6. Update internal systems

***

## Duplicate Transaction Protection

Before retrying:

* Verify transaction status first
* Check existing transaction references
* Avoid duplicate payout initiation
* Avoid duplicate payment orders

***

## Common Retry Mistakes

Avoid:

* Infinite retry loops
* Aggressive retry intervals
* Duplicate payout creation
* Reusing expired timestamps
* Ignoring webhook events

***

## Security Recommendations

* Generate fresh timestamps for retries
* Regenerate signatures for every request
* Verify webhook signatures
* Store retry logs securely
* Use HTTPS only

***

## Logging Recommendations

Always log:

* Retry attempts
* API responses
* Transaction statuses
* Error responses
* Webhook events

This helps with:

* Reconciliation
* Audit tracking
* Failure investigation
* Debugging

***

## Best Practices

* Use idempotent transaction IDs
* Implement exponential backoff
* Verify transaction status before retries
* Handle webhooks asynchronously
* Maintain reconciliation logs
* Monitor retry failures continuously

***

## Important Notes

* Banking delays are normal in some scenarios
* Processing transactions may take time
* Final confirmation should always happen server-side
* Webhooks may arrive after API responses


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.