A Razorpay test card is a dummy card number that works only in Razorpay test mode. It lets you run a full payment through the checkout without moving real money. Razorpay publishes a fixed list of these numbers, and any future expiry date with any three-digit CVV is accepted.

Which test card numbers does Razorpay publish?

The list is short. Each number maps to a card network, and the name field accepts any value you type.

  • Visa: 4111 1111 1111 1111
  • Mastercard: 5267 3181 8797 5449
  • Other networks: the dashboard list shows the current set, including RuPay and Amex where available

You will find the same numbers under Account & Settings, then Test card details, in the Razorpay dashboard. Check that page before you hard-code a number into a test suite, because Razorpay adds and retires test cards over time.

What expiry date and CVV should I use?

Any date in the future works, such as 12/34. The CVV can be 123, 999, or any other three digits. Test mode does not match the CVV against a real issuer record, so the field only needs the right length.

Which OTP do Razorpay test cards use?

Razorpay's documented test OTP is 1234 for a successful 3-D Secure step. Some test scenarios use a different value to trigger a failure, and the dashboard labels those next to each card.

How do I use a Razorpay test card?

  1. Flip the dashboard toggle to Test Mode.
  2. Copy the test key ID, which starts with rzp_test_, into your integration.
  3. Open your checkout page and enter a published test number with a future expiry and any CVV.
  4. Submit OTP 1234 on the bank page.
  5. Confirm the payment shows under Payments while test mode is on.

Test payments skip the settlement cycle. Balances, refunds, and reports stay inside a sandbox you can clear whenever you want a clean slate.

Test card vs live card: what actually changes?

A test card exists only inside the gateway sandbox. A live card is issued by a bank and tied to a real account with a real balance.

  • Test charges are simulated. Live charges move money and settle to your account.
  • Test keys (rzp_test_) fail against live servers, and live keys fail in test mode.
  • OTP 1234 works in test mode. Real OTPs go to the cardholder's phone.
  • Test numbers often fail Luhn or bank prefix checks outside the sandbox.

How do I test declines and edge cases?

Razorpay ships test numbers that produce specific outcomes, including a declined payment and a 3-D Secure step that does not complete. The dashboard list labels each number with the result it triggers. Use those labels instead of guessing, then check that your UI shows a clear message for each failure type.

Also test the boring paths: a network timeout, a user who closes the checkout mid-flow, and a retry on the same order. These break more integrations than declined cards do.

Why does a Razorpay test card fail?

  • Live keys running in a test environment, or test keys running against production.
  • Test mode switched off in the dashboard, so the checkout hits the live account.
  • A card number copied from an old blog post that Razorpay no longer supports.
  • A saved browser session still holding the previous mode's config.

Wrong-mode keys cause most "card declined" reports in test mode. Confirm the key prefix and the dashboard toggle before you debug anything else.

What should a pre-launch checklist cover?

  • A successful payment with a Visa test card and a separate run with Mastercard.
  • A decline path, plus the exact wording your page shows the user.
  • A full refund and a partial refund in test mode.
  • Webhook delivery for payment.captured and payment.failed, including a retry.
  • Idempotency on retried requests so a double click does not create two orders.

Run the checklist after every change to your checkout code, not once at launch. Card network rules and gateway behaviour shift, and the test set is the cheapest place to catch a regression.

Is it safe to store card numbers and CVVs?

Test numbers are harmless, but the copying habit is not. Real card data falls under PCI DSS, and storing it outside an approved vault creates compliance risk that a small merchant cannot absorb.

PCI DSS forbids keeping the CVV after authorization, even in encrypted form. The field is a pass-through, so your server should never write it to a log, a database, or an analytics event.

Frequently asked questions

Do Razorpay test cards work in live mode?

No. Live mode sends the number to real bank networks, and those numbers belong to no real account. The payment fails at authorization.

Is a Razorpay test card a real card?

No. It is a placeholder number that passes the gateway's format checks in the sandbox. There is no bank behind it, no balance, and no owner.

Does using a test card charge money?

No. Test charges appear only in the test mode dashboard. No settlement, no invoice, no money movement.

Can I use any random 16-digit number?

Not with confidence. A random number can trip the Luhn check or the network prefix rules. Use the published list and you avoid the noise.

Why is OTP 1234 rejected?

You are likely on a live key or a stale session from live mode. Reload the checkout after switching keys and the test OTP will pass.

Where do I get the current test card list?

The Razorpay dashboard's test card page is the source of truth. Razorpay's public documentation mirrors it, but the dashboard updates first.