How do I configure POS system to throttle UPI retries for capital market investments when API response times spike?

So, when NPCI or the PSP slows down (API response >2–3 seconds), you don’t want your POS to spam retry requests that’s how you end up with double debits or ghost orders stuck in pending. You need smart retry throttling that’s aware of UPI network health and your transaction context.

Here’s what works best

• Implement Exponential Backoff (Don’t Hammer the API)

Start with a 1s delay, then 2s, 4s, 8s, and stop after ~5 attempts.

Don’t retry instantly; it only worsens load.

Use jitter (a small random delay) to avoid all your POS instances retrying together.

Example:

Retry Delays: [1s, 2s, 4s ± 200ms jitter, 8s ± 500ms jitter]

• Use NPCI Response Codes to Guide Behavior

If you get 91 – Request in progress, wait 15–20 seconds before polling the status again.

If you get U30 – PSP Down or U42 – Timeout, stop retries and queue the transaction for a later retry job.

If U17 – Customer authentication failed, do not retry prompt the user to reinitiate.

Basically:

Don’t blindly retry every failed call — react based on what the API tells you.

• Rate-Limit Concurrent UPI Requests per Merchant

Cap it at 5 concurrent UPI calls per merchant for capital market transactions.

Queue excess requests and release them as old ones finish.

This helps your PSP avoid blacklisting your handle due to excessive retries.

• Circuit Breakers Around PSP and Bank Handles

If average response time crosses 3 seconds for 10 consecutive calls, trip a circuit breaker.

Temporarily disable UPI routing for that PSP/bank and show:

UPI network is currently slow. Please try Net Banking or RTGS instead.

Auto-reopen the circuit after 60–90 seconds of healthy responses.

This protects both your uptime and the user experience.

• Queue & Reconcile Gracefully

Store failed or delayed UPI attempts in a pending settlement queue with a timestamp.

Use NPCI’s TxnStatus API or PSP’s reconciliation API to check final status every few minutes.

Mark successful payments with ACKNOWLEDGED and failed ones as RETRY_ELIGIBLE for the next off-peak retry cycle.

• Real-Time Messaging for Users

When throttling kicks in, don’t just silently delay.
Show something like:

The UPI network is responding slowly. Your payment is queued safely — you’ll get a confirmation once it’s processed.

Transparency keeps customers from retrying manually, which is what usually creates double debits.

• Monitor Key Metrics

Have dashboards tracking:

Avg UPI API latency (target <2.5s)

Retry success rate

PSP failure rate by bank handle

Duplicate attempt count

If any metric spikes >30% over baseline, switch to fallback payment methods (like Net Banking or RTGS).