What is a Razorpay test card?
A Razorpay test card is a synthetic card number that Razorpay publishes for use in test mode only. It lets developers and sellers complete a fake checkout to verify payment flows without charging a real account. These numbers are declined in live mode and produce no real money movement.
Razorpay Test Card for Testing: Ultimate Buying Guide
Which Razorpay test card numbers are commonly used?
Razorpay documents a small set of sandbox numbers that cover the major card networks and result codes. Gateways add or rotate numbers over time, so confirm the current list on Razorpay's official test card reference before you ship.
- Visa, payment success: 4111 1111 1111 1111
- Mastercard, payment success: 5267 3181 8797 5449
- 3D Secure flow, succeeds after authentication: 4000 0000 0000 3220
- Payment failure: 4000 0000 0000 0002
How do you use a Razorpay test card?
- Switch your Razorpay dashboard to test mode and generate test API keys.
- Open your checkout in a staging build that uses those test keys.
- Enter a test card number, any future expiry date, and any three digit CVV.
- Complete the authentication step with the sandbox OTP, then confirm the payment status in the dashboard.
What CVV, expiry, and OTP should you enter?
In test mode the CVV can be any three digits, such as 123, and the expiry can be any future date. Sandbox OTP prompts usually accept 1234. None of these values is validated against a real issuer.
How do you simulate a failed payment?
Use the failure card number that Razorpay lists, or trigger the failure test UPI handle failure@razorpay. The success UPI test handle is success@razorpay. Failure cases let you verify retry logic, error copy, and webhook handling.
How to Use Razorpay Sandbox Test Card
Test mode versus live mode
Test cards only work with test API keys in the sandbox environment. Live keys reject every test number, and real card numbers should never be entered in test mode. Keeping the two environments separate prevents accidental charges and protects cardholder data.
Why test cards matter for integration work
Test cards let you exercise the full payment lifecycle before launch: authorization, capture, refund, and webhook delivery. They also give you repeatable inputs for automated test suites. Teams that skip this step often find broken error handling only after real customers hit it.
Security rules to follow
- Use synthetic test numbers only, never a customer's real card.
- Keep test keys out of production builds and public repositories.
- Log only non-sensitive fields, and never store full card numbers or CVVs in your own database.