Reliability, Idempotency & Recovery EngineSANDBOX / TEST MODE · Razorpay Test ModeDeterministic Policy Engine Active

Reliability & Recovery

Razorpay sends financial events asynchronously. What happens if a webhook arrives twice, arrives out of order, or Mandate crashes halfway through a payment? This page demonstrates how Mandate prevents double-spending and makes financial state converge safely despite those failures.

How Mandate Handles Asynchronous Failures (End-to-End Reliability Flow)

● Cryptographic Verification & Idempotency Pipeline Active

Every financial action follows a strict 7-stage pipeline. If a network packet drops, a worker crashes, or Razorpay sends duplicate webhooks, the pipeline isolates the fault and converges safely without leaking merchant budget.

1. Event InboundRazorpay Event

Webhook or API dispatch

2. SignatureHMAC Verification

Rejects forged payloads

3. PersistenceDurable Event Log

Survives process crashes

4. DeduplicationIdempotency Lock

Prevents double-spending

5. TransitionState Machine

Formal valid states only

6. LedgerSpend Commit

Mandate budget updated

7. Audit SweepReconciliation

Mandate ↔ Razorpay Test

Financial Operation State Machine Lifecycle

Click any state to inspect its financial safety guarantee

|

State: RESERVED● Invariant Enforced by FinancialOperationStateMachine

CRITICAL TWO-PHASE COMMIT: Spend is reserved in PostgreSQL before invoking external Razorpay REST API. If the API crashes or network drops, this reservation guarantees another agent cannot double-spend the budget.

Failure Testing Lab (Live Fault Injection)

● Click Run Test to execute live on backend

Test Mandate's failure handling in real time. Click any of the 4 test scenarios to inject live fault conditions into the running control plane and inspect the before/after state transition, gateway effect, and budget delta.

Idempotency Lock

1. Duplicate Webhook Replay

Simulates Razorpay sending the exact same payment.captured webhook twice due to network retry.

Expected Behavior:Second webhook detected & ignored; 0 duplicate budget deductions.

Auto-Convergence

2. Out-of-Order Webhook Event

Simulates webhook arriving before the synchronous client API call completes.

Expected Behavior:State auto-converges from RESERVED to SUCCEEDED seamlessly.

Reconciliation

3. Ambiguous Gateway Timeout

Simulates network dropping right as Razorpay is processing order creation.

Expected Behavior:Idempotency key prevents duplicate order creation on retry.

Orphan Recovery

4. Process Crash & Orphan Sweep

Simulates worker crashing after funds are reserved but before order creation completes.

Expected Behavior:Worker sweep identifies stale reservation and releases funds back to pool.

Mandate Ledger ↔ Razorpay Test Mode Reconciliation

Continuous background worker cross-checks internal PostgreSQL state against Razorpay Test Mode APIs

• Orphan Reservation Sweep: Identifies operations stuck in RESERVED state for longer than 10 seconds (e.g. from container crashes) and releases uncommitted funds back to the mandate budget.

• Status Cross-Check: Ensures every order marked SUCCEEDED in Mandate corresponds to an authorized or captured payment in Razorpay Test Mode.

What Happens When Something Goes Wrong?

Common failure modes and how Mandate deterministically isolates them