Razorpay Card Testing: Test Mode Guide

Short answer

Razorpay card testing means running your checkout in test mode with sandbox card numbers that Razorpay publishes, not with real card data. You flip the dashboard to test mode, swap in your test key ID, submit one of Razorpay's documented test cards, and then confirm the payment appears in the dashboard and fires the webhook your server expects. No funds move and no live card is used.

Prerequisites

• A Razorpay account with access to test mode
• Test API keys from Dashboard > Account & Settings > API Keys
• A staging build of your checkout, order creation call, and webhook handler
• A public HTTPS URL for webhooks

Step by step

1. Open the Razorpay Dashboard and switch the mode toggle to Test Mode.
2. Generate a test Key ID and Key Secret, and store them outside your repository.
3. Point your staging environment at the test keys instead of the live keys.
4. Create an order through the Orders API and log the returned order ID.
5. Open your checkout, paste the order ID, and load it with the test Key ID.
6. Enter a documented test card number from Razorpay's test card page, a future expiry date, and any CVV.
7. Complete the payment and note the payment ID shown on the result screen.
8. Open Dashboard > Transactions > Payments in test mode and confirm the payment ID and status match.
9. Check your webhook log for the payment.captured event and verify the signature against your stored secret.
10. Repeat the flow with a failure test card from the same docs page and confirm your code handles payment.failed.

What the test cards do

Razorpay's test card list is organized by outcome. One number always succeeds, others force a specific decline, and a third group pushes the payment into the 3D Secure challenge so you can test the redirect and the return trip to your site. UPI IDs and netbanking credentials follow the same pattern in test mode. Any expiry date in the future works, and the CVV field accepts any three digits because no real issuer is involved.

Reading a failed test

• Bad request: the order ID, amount, or currency does not match what you created on the server.
• Card declined: expected when you pick a failure test card. This is the branch your code should handle.
• Authentication failed: the 3DS step was abandoned or the return URL did not resolve back to your app.
• Webhook not firing: a signature mismatch or an unreachable endpoint. Check the secret and the response code your handler returns.

Rules that keep testing clean

Never type a real card number into test mode. It will fail, and it teaches you nothing about the live path. Never run a card you do not own, and never use a sandbox account to check whether a number is valid. Card numbers belong to their holders, and storing them outside a PCI DSS compliant flow creates liability for you. Test mode exists to prove your order creation, checkout, capture, and webhook code in that sequence, and that is all it should be used for.

Before you go live

Regenerate live keys, keep them server side, add rate limiting and a CAPTCHA on the payment form, and log request metadata without card data. Run one low value live transaction with your own card, then confirm the settlement report matches your database.