What a Razorpay test card is
A Razorpay test card is a card number that works only in Test Mode. It simulates a real card payment so you can verify order creation, checkout behavior, webhook delivery, and failure messages without moving money. These numbers are sandbox artifacts. They fail in Live Mode, they are not tied to a bank account, and no funds change hands.
Test Mode is a separate environment with separate API keys. Anything you build against it stays isolated from your live account until you swap the key pair.
Prerequisites
- A Razorpay account with the Test Mode toggle available in the dashboard.
- Test Mode API keys copied from the dashboard, not the Live Mode key pair.
- A checkout integration or hosted payment page that loads in Test Mode.
- An expiry date in the future and any three digit CVV. The sandbox does not check these against an issuer.
How to run a test payment
- Sign in to the Razorpay dashboard and switch the mode toggle from Live to Test.
- Open the API keys section and copy the Test Mode key ID and key secret into your application config.
- Restart your application so it loads the test key pair, then open your checkout page.
- Enter one of the test card numbers listed below, plus a future expiry date and any three digit CVV.
- Submit the payment. If a 3D Secure simulation screen appears, enter the test OTP shown on that screen. In most Test Mode flows the accepted value is 1234.
- Wait for the checkout to return to your site or app, then confirm the order status in the dashboard Payments section.
- Check your server logs for the webhook event and confirm the signature verification step passes.
- Repeat the run with a failure card to confirm your error handling path.
Test card numbers
Razorpay documents a small set of sandbox cards. The set changes over time, so treat the list in your dashboard Test Mode panel as the source of truth.
- 4111 1111 1111 1111 (Visa): completes a successful payment in most flows.
- 5267 3181 8797 5449 (Mastercard): success path.
- 5104 0600 0000 0008 (Mastercard): success path.
- 4000 0000 0000 0002: triggers a card declined response.
- 4000 0000 0000 0069: triggers an expired card response.
- 4000 0000 0000 0127: triggers an incorrect CVV response.
Use the same values with a different expiry or CVV and the result should not change for the success cards.
Test UPI and netbanking
Test Mode also includes UPI handles and netbanking options. For UPI, use success@razorpay to force a captured payment and failure@razorpay to force a failed one. Netbanking test banks appear in the selection list in Test Mode and their behavior is simulated, so the bank page you see is not a live banking site.
Troubleshooting
- If the card is rejected in Test Mode, confirm the toggle is still set to Test and that your app is using the test key pair.
- If the payment succeeds but your order stays pending, inspect the webhook endpoint and the signature check, since the client callback and the webhook are separate signals.
- If the OTP screen rejects 1234, read the hint text on that test screen and use the value shown there.
- If a decline card returns success, check whether a mock or stub in your own code is short circuiting the request.
Rules to follow
Never paste a test card into a live payment form, and never ship test keys in a production build. Test card numbers are public by design, which means they cannot be used to pay for anything, and using them outside the sandbox is pointless. Keep Test Mode data in a separate database so test orders do not pollute live reporting, and purge it before you go live.