Can you make it
refund twice?

A provider may complete a financial action even when your application never receives the response. Break the execution and see what actually happens to the money.

Demo refund

₹100

Payment: pay_demo_123
Status: Ready

Choose how it breaks

Why trust this?

This public playground runs against a deterministic provider fixture modelled from measured Razorpay Test Mode behaviour. It makes no live Razorpay transactions and moves no real money.

Real provider measurement Razorpay Test Mode Response loss followed by a same-key retry recovered the original refund. Captured separately from this playground. Deterministic verification Response loss · crash recovery · concurrency · intent conflict The four experiments here mirror tests in the public repository. Upstream contribution razorpay/razorpay-mcp-server #114 Refund idempotency-key support. Open for review.

The left-hand comparison is a deliberately weak retry strategy that regenerates the provider identity. A disciplined caller that persists and reuses that key avoids this specific duplicate path; Financial Operation Core additionally binds it to durable business-operation state across attempts and recovery.