Retry Mechanism

When the seller's callback endpoint returns a non-200 status code, the iGV platform will automatically retry.

Retry Rules

Item	Description
Maximum Attempts	3 (initial attempt + 2 retries)
1st Retry	5 minutes after the initial failure
2nd Retry	30 minutes after the 1st retry failure
Cancel Condition	Retries stop upon receiving a 200 response

Timeline

T+0min    → Initial push
T+5min    → 1st retry (if initial returned non-200)
T+35min   → 2nd retry (if 1st retry still returned non-200)

Idempotency Requirement

Idempotency Is Mandatory

Due to the retry mechanism, sellers must implement idempotency based on X-Request-Id:

• If the same X-Request-Id has already been processed → return 200 immediately without executing business logic
• This prevents duplicate order processing, duplicate charges, or duplicate status changes

Idempotency Implementation

Receive callback → Check if X-Request-Id has been processed
  ├── Already processed → Return 200
  └── Not processed → Verify signature → Execute business logic → Record X-Request-Id → Return 200

Storage Recommendations

Approach	Use Case
Redis SET	High concurrency; set TTL for automatic expiration
Database unique index	When persistent records are needed
In-memory Map + periodic cleanup	Small scale, single-node deployment

Timeout Handling

If all 3 attempts fail, the platform will no longer push that callback. Sellers can use the Order Query API to actively poll for the latest order status as a fallback.