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)

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