Razorpay Test Card: Sandbox Numbers for Test Mode

Razorpay's test card 4111 1111 1111 1111 is the fastest way to get a successful payment through Razorpay test mode: any future expiry date, CVV 123, and the checkout returns a success state without touching real money. It wins on three things that matter for sandbox work. It is published by Razorpay itself, it works in the standard checkout flow, and it needs only a test key pair, not a live merchant account. The sections below cover the card set by network, when to reach for each one, and how to force the failure paths you actually have to code against.

How Razorpay test mode works

Test mode is a separate environment behind a separate key pair. A test key starts with rzp_test_ and a live key starts with rzp_live_. Payments created with the test keys never reach a bank, never settle, and never appear in your live settlements. That separation is the whole point: you can drive the full order to capture flow, webhooks included, without handling a real card number at any stage.

Two habits keep that environment honest. First, keep test and live keys in different configuration files so a staging build can never charge a real customer. Second, treat the test card numbers as fixtures, the same way you treat seeded user accounts. They belong in your test suite, not in your database.

Visa test card: 4111 1111 1111 1111

This is the default choice for most sandbox work.

• Pros: Accepted in the standard checkout for card payments, works with any future expiry date, and returns success without extra configuration. It is the number most tutorials and internal runbooks assume, so handoffs are easy.
• Cons: It only tells you the happy path works. It proves nothing about declines, 3D Secure challenges, or network-specific quirks.

Use it when: you are wiring up the order creation, checkout callback, and webhook handler for the first time and you want a clean success to build against.

Mastercard test card: 5267 3181 8797 5449

Razorpay's documentation also lists Mastercard test numbers, and 5267 3181 8797 5449 is the one most commonly published for test mode, paired with CVV 123 and a future expiry. Some versions of the docs list an additional Mastercard PAN for alternate flows, so confirm the current list inside your dashboard before you hardcode anything.

• Pros: Lets you verify that your integration is not accidentally tied to Visa-specific behavior, such as card-length validation or brand detection in your own UI.
• Cons: The published Mastercard set changes more often than the Visa one, so a stale copy in your repo can fail without explanation.

Use it when: you have a brand selector, a saved-card flow, or any logic that branches on card network.

American Express test card: 3782 822463 10005

Amex is the useful odd one out because the format differs: 15 digits instead of 16, and a 4-digit CVV instead of 3.

• Pros: Exposes input masking and validation bugs that a 16-digit Visa number hides. If your form clips a 15-digit PAN or rejects a 4-digit CVV, you will see it here.
• Cons: Not every merchant account or test flow enables Amex, so a failure here may be configuration rather than a bug in your code.

Use it when: you are testing form validation, and any time you touch the card input component.

UPI and netbanking test instruments

Cards are not the only fixture in test mode. Razorpay publishes test UPI handles for the sandbox, commonly success@razorpay and failure@razorpay, which let you simulate a collect request that clears and one that does not. Test netbanking lets you pick a bank and drive the redirect for both outcomes.

• Pros: Covers the payment methods most Indian customers actually use, without a card in the loop.
• Cons: UPI test flows still take a few seconds and behave asynchronously, so your polling and webhook logic has to be correct rather than instantaneous.

Use them when: your checkout offers more than cards, which for a Razorpay integration is close to always.

Forcing declines and edge cases

A good test plan needs failures, not just successes. Razorpay test mode gives you ways to produce authorization failures, and the exact triggers live in the current sandbox docs, so read them in the dashboard rather than trusting a copied list. Build tests for a declined authorization, a payment abandoned at checkout, a webhook delivered twice, and a refund issued against a captured test payment. Those four cover most of what breaks in production.

Because test numbers are published, anyone can call the sandbox API with them. Do not let that shape your security model. Your production path should still route card entry through the hosted checkout or a PCI-compliant component, so raw card data never lands on your servers.

What test cards are not

Published test PANs are inert. They authorize against a sandbox and nothing else, which is why sharing them is harmless and why they are useless anywhere else. Real card numbers, CVVs, and full magnetic-stripe data are governed by PCI DSS, and buying, selling, or storing them outside a compliant environment is a crime in the United States and most other jurisdictions. If you ever find a live card number in a test fixture, log or log-adjacent file, delete it and trace how it got there.

The practical rule is simple: test keys with test cards, live keys with the hosted flow, and never the two in the same build.