A Razorpay test card is a card number that Razorpay publishes for use in test mode only. It lets you run a complete payment flow, including card entry, 3D Secure authentication, webhooks, and refunds, without moving real money. Test cards are public sandbox values, not real account numbers, and they stop working the moment you switch to live API keys.
What test mode actually does
Test mode is a parallel environment that mirrors the live payment APIs but connects to simulated banking rails. A few things change when you move your integration into it:
- Your key ID starts with
rzp_test_instead ofrzp_live_. - Charges, refunds, and settlements are simulated and never reach a real bank.
- The dashboard shows test payments separately from live transactions.
- Webhooks still fire, so you can verify your server side handling end to end.
Because the API calls are identical, code written against a Razorpay test card flow usually works in production without changes beyond swapping keys.
Types of test cards you will use
Gateway sandbox sets are built around scenarios rather than one universal number. Expect to find cards for each of these cases:
- Successful payment: a domestic Visa or Mastercard value that completes with no friction.
- Authentication required: a card that forces the 3D Secure step so you can test the OTP screen and the post authentication redirect.
- Declined payment: a value that returns a failure response, useful for testing error states in your UI.
- CVV or expiry failure: a card that succeeds on the number but fails validation, so you can test field level messages.
- International behavior: cards that mimic cross border transactions and currency conversion.
The long standing sandbox Visa number 4111 1111 1111 1111 appears in many gateway test sets, including Razorpay's, for a straightforward success case. Treat any specific number as a starting point and confirm the current list inside your Razorpay dashboard or documentation, since test values are occasionally retired or replaced.
Running a test payment step by step
- Generate your test mode API keys in the Razorpay dashboard.
- Open your checkout with the test key so the request routes to the sandbox.
- Enter a test card number, any future expiry date, and the CVV shown with that test value.
- Complete the simulated 3D Secure page using the OTP displayed on screen.
- Confirm the result in the dashboard and check that your webhook received the matching event.
- Trigger a test refund to verify the reverse flow.
Why a test payment fails
Most sandbox failures come from configuration, not from the card itself:
- Live keys were used in the checkout call, so the test card was rejected.
- The payment method was not enabled for your test account.
- The 3D Secure step was closed before authentication completed.
- The order currency or amount did not match what your backend sent.
- A real card number was entered into a sandbox field.
Test cards and data handling
Sandbox values are not cardholder data, but the same rules that protect real card information apply to your live integration. Never paste a real card number into a test environment, and never store a full card number or CVV on your own servers unless your business is certified for it. If you only need to charge customers, tokenization through your gateway keeps sensitive data out of your codebase and reduces your compliance burden.
Common questions
Can a test card ever charge a real account?
No. Test mode never reaches a real issuer network, so no funds move in either direction.
Do test cards work in other currencies?
Test mode supports the currencies your account is configured for, and the published card list notes which values apply to each scenario.
Is a Razorpay test card safe to share publicly?
Yes, these values are documented for developers. Sharing them is normal practice, while sharing live card data is a serious offense under card network rules and local law.