# Retry logic

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

KwikPaisa 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

KwikPaisa 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

KwikPaisa 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
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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://developers.kwikpaisa.com/v3-guide/error-handling/retry-logic.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.