Skip to content
PPureDevKit

Documentation · Updated 2026-08-31

Payment test cards

How to test Stripe, Razorpay, and PayPal checkout with official sandbox PANs, UPI IDs, decline scenarios, 3D Secure cards, and Luhn validation — without touching live money.

Open test card toolStripe test cardsRazorpay test cardCashfree test cardPayU test card

Getting started

Overview

Payment processors publish test card numbers that only work in sandbox or test mode. PureDevKit collects them in one reference tool with copy buttons, JSON snippets, and per-processor setup steps.

When to use

Use this when integrating checkout, writing QA scripts, or onboarding a teammate who keeps searching “razorpay test card” in Slack.

Steps

  1. 1Open /tools/test-cards/ and pick a processor in the sidebar.
  2. 2Copy the PAN, full fields, or JSON for your API test.
  3. 3Confirm your integration uses test API keys — not live.
  4. 4Run a payment and verify webhooks in staging with dummy-webhooks if needed.

Tips

  • Bookmark /tools/test-cards#stripe-success or #razorpay-upi for deep links.
  • Official processor docs are the source of truth — numbers can change.

Test mode vs live mode

Test mode uses separate API keys and simulated money. Live mode charges real cards. Mixing them is the most common integration mistake.

When to use

Read this before your first charge, before going live, and whenever a “card declined” bug appears only in production.

Steps

  1. 1Stripe: Dashboard toggle → Test mode. Keys start with pk_test_ / sk_test_.
  2. 2Razorpay: Dashboard → API Keys → Test mode. Live keys reject documented test PANs.
  3. 3PayPal: developer.paypal.com sandbox accounts + sandbox client ID.
  4. 4Never paste test PANs into a live checkout — they will fail or trigger fraud rules.

Reference

  • Stripe test ZIP for US billing: 42424
  • Razorpay UPI success: success@razorpay
  • Razorpay UPI failure: failure@razorpay

Expiry, CVV, and ZIP rules

Most processors accept any future expiry date and any CVV in test mode — unless you are deliberately testing incorrect-CVC or expired-card declines.

When to use

When a teammate asks “what expiry should I use?” or when Stripe Radar tests need a specific billing ZIP.

Steps

  1. 1Default: expiry 12/34 (or any future month/year), CVV 123.
  2. 2Amex test cards: use any four-digit CVV.
  3. 3Stripe US-address tests: ZIP 42424 is commonly documented.
  4. 4Razorpay: random CVV and any future expiry for standard success cards.

Tips

  • For incorrect-CVC decline tests, use Stripe card 4000000000000127 — not a random wrong CVV on 4242.

Stripe

Enable Stripe test mode

Stripe separates test and live data completely. Test charges appear in the Dashboard only when Test mode is on.

When to use

Before creating PaymentIntents, Checkout Sessions, or Elements integrations.

Steps

  1. 1Log in to dashboard.stripe.com.
  2. 2Toggle Test mode in the header (not Live).
  3. 3Developers → API keys → copy Publishable and Secret test keys.
  4. 4Point webhooks at a staging URL; use stripe listen for local dev.

Tips

  • Search your codebase for sk_live_ before shipping — many incidents are a wrong env var.

Stripe success cards

These PANs complete a charge when keys and mode are correct. 4242424242424242 is the default Visa developers memorize.

When to use

Happy-path checkout, subscription renewals, and saved-card flows in test mode.

Steps

  1. 1Visa: 4242424242424242
  2. 2Visa debit: 4000056655665556
  3. 3Mastercard: 5555555555554444
  4. 4American Express: 378282246310005 (4-digit CVV)

Reference

  • 4242424242424242 — Visa, succeeds
  • 4000056655665556 — Visa debit
  • 5555555555554444 — Mastercard
  • 378282246310005 — Amex

Stripe decline & error cards

Stripe documents PANs that simulate specific failure codes — generic decline, insufficient funds, wrong CVC, expired card.

When to use

QA error UI, retry logic, and webhook failure handling.

Steps

  1. 1Generic decline: 4000000000000002
  2. 2Insufficient funds: 4000000000009995
  3. 3Incorrect CVC: 4000000000000127
  4. 4Expired card: 4000000000000069

Reference

  • 4000000000000002 — card_declined
  • 4000000000009995 — insufficient_funds
  • 4000000000000127 — incorrect_cvc
  • 4000000000000069 — expired_card

Stripe 3D Secure test cards

Some test PANs require Strong Customer Authentication before the charge succeeds. Use these to test redirect and challenge flows.

When to use

SCA compliance, PaymentIntent status requires_action, and mobile 3DS redirects.

Steps

  1. 13DS2 required: 4000002760003184
  2. 2Always authenticate: 4000002500003155
  3. 3Alternate 3DS2 flow: 4000008400001629
  4. 4Complete the test authentication prompt in Checkout or Elements.

Tips

  • If 3DS never appears, confirm your integration requests 3DS — not all test charges force it automatically.

Stripe PaymentIntent example

A minimal server-side test charge using the official Node SDK pattern. Replace keys and amount as needed.

When to use

Backend integration smoke tests before wiring the frontend.

Steps

  1. 1Create a PaymentIntent with amount and currency in test mode.
  2. 2Confirm with payment_method_data containing the test PAN.
  3. 3Inspect payment_intent.status — succeeded, requires_action, or requires_payment_method.

Reference

  • const stripe = require('stripe')(process.env.STRIPE_TEST_KEY);
  • await stripe.paymentIntents.create({ amount: 2000, currency: 'usd' });
  • Test PAN in Elements or confirmCardPayment on the client.

Razorpay

Enable Razorpay test mode

Razorpay test keys and live keys are different. Test PANs return “card issuer is invalid” if you accidentally use live credentials.

When to use

Indian checkout integrations — cards, UPI, netbanking, wallets.

Steps

  1. 1Dashboard → Settings → API Keys.
  2. 2Generate keys while Test mode is enabled.
  3. 3Use rzp_test_ key id in Checkout and Orders API.
  4. 4Verify Dashboard shows test transactions, not live settlements.

Tips

  • India-focused teams: pair this with our data.gov.in and pincode API guides for address fixtures.

Razorpay test cards

Razorpay lists domestic and international test PANs. 4111111111111111 is the domestic Visa most Indian tutorials reference.

When to use

Card payments on Razorpay Checkout or custom card forms in test mode.

Steps

  1. 1Domestic Visa: 4111111111111111
  2. 2Domestic Mastercard: 5267318187975449
  3. 3International Visa: 4012888888881881
  4. 4International Mastercard: 5555555555554444
  5. 5Use any future expiry and any random CVV.

Reference

  • 4111111111111111 — domestic Visa
  • 5267318187975449 — domestic Mastercard
  • 5104060000000008 — domestic debit
  • 4718609108204366 — domestic Visa credit
  • 4012888888881881 — international Visa

Razorpay UPI test IDs

UPI checkout does not use a card number. Enter a test VPA at the UPI step in Razorpay Checkout.

When to use

Domestic Indian one-time UPI payments in test mode.

Steps

  1. 1Select UPI as the payment method at Checkout.
  2. 2Enter success@razorpay for a successful payment.
  3. 3Enter failure@razorpay to simulate failure.
  4. 4On iOS or mobile web, test UPI Collect; on Android prefer UPI Intent per NPCI guidelines.

Tips

  • In test mode, cancelling a UPI payment may still succeed — test cancellation behavior in live mode.

Reference

  • success@razorpay — payment succeeds
  • failure@razorpay — payment fails

Netbanking & wallets

In test mode, Razorpay does not redirect to real bank logins. You pick a bank or wallet, then a mock page offers success or failure.

When to use

Full Checkout QA covering all Indian payment rails.

Steps

  1. 1Select any listed bank for netbanking.
  2. 2On the mock page, choose Success or Failure.
  3. 3For wallets, pick any wallet and use the same mock result page.
  4. 4Assert order status and webhook payload on your server.

Cashfree (India)

Cashfree test cards

Cashfree sandbox uses fixed card metadata: expiry 03/2028, CVV 123, name Test, OTP 111000. Keys start with TEST_.

When to use

Indian integrations on sandbox.cashfree.com before production.

Steps

  1. 1Dashboard → Switch to Test.
  2. 2Visa debit: 4706131211212123
  3. 3Mastercard credit: 5105105105105100
  4. 4RuPay debit: 6074825972083818
  5. 5OTP: 111000 for every card.

Reference

  • Source: cashfree.com/docs/api-reference/payments/data-to-test-integration
  • UPI success: testsuccess@gocash
  • UPI failure: testfailure@gocash

PayU (India)

PayU test cards

PayU India sandbox cards for merchant-hosted checkout with OTP 123456 and expiry 05/30.

When to use

test.payu.in integrations with Test Key and Salt.

Steps

  1. 1Mastercard: 5123456789012346
  2. 2Visa: 4012001037141112
  3. 3RuPay: 6082015309577308
  4. 4Amex: 370295061673669 (CVV 1234)
  5. 5Endpoint: https://test.payu.in/_payment

Reference

  • Source: docs.payu.in/docs/test-cards-upi-id-and-wallets

Instamojo (India)

Instamojo sandbox

Sign up at test.instamojo.com — no full KYC. Single documented test card plus 2FA.

When to use

Lightweight Indian payment links and marketplace flows.

Steps

  1. 1Base URL: https://test.instamojo.com/
  2. 2Card: 4242424242424242
  3. 3CVV: 111, any future expiry
  4. 42FA code at payment: 1221

More global gateways

Braintree sandbox

PayPal-owned Braintree lists valid PANs per network plus verification-failure and 3DS2 cards.

When to use

Braintree Drop-in, Hosted Fields, or server-side vault testing.

Steps

  1. 1Visa: 4111111111111111
  2. 2Decline verification: 4000111111111115
  3. 33DS2: 4000000000001091 (expiry 01 / year+3)
  4. 4Login: sandbox.braintreegateway.com

Adyen test platform

Adyen test cards work only on checkout-test.adyen.com. Outcomes often driven by holderName or RequestedTestAcquirerResponseCode.

When to use

Enterprise multi-method checkout on Adyen test environment.

Steps

  1. 1Visa success: holderName APPROVED or code 1
  2. 2Visa decline: holderName DECLINED or code 2
  3. 33DS2 card: 4917610000000000
  4. 4Amex: 370000000000002

Square sandbox

Square rejects real cards in sandbox. Tokenize test PANs via Web Payments SDK.

When to use

Square Online, POS API, or CreatePayment with cnon:card-nonce-ok.

Steps

  1. 1Visa: 4111111111111111, CVV 111
  2. 2Mastercard: 5105105105105100
  3. 3API shortcut: source_id cnon:card-nonce-ok

Checkout.com sandbox

Response-code-driven test PANs. Some declines require specific payment amounts.

When to use

Checkout.com Unified Payments API in sandbox.

Steps

  1. 1Approved US Visa: 4000020000000000
  2. 2Approved GB Visa: 4242424242424242
  3. 3Insufficient funds: 4242424242424242 with amount 101
  4. 43DS Visa debit: 4532446037926437

Authorize.net sandbox

Classic sandbox PANs plus amount-based decline simulation.

When to use

AIM, CIM, or Accept.js test integrations.

Steps

  1. 1Success Visa: 4111111111111111
  2. 2Response-code Visa: 4222222222222 (13 digits) with amount = reason code
  3. 3Mastercard: 5424000000000015

PayPal

PayPal sandbox setup

PayPal testing centers on sandbox Business and Personal accounts. Card numbers supplement account-based flows.

When to use

PayPal Checkout, REST payments, and subscription sandboxes.

Steps

  1. 1Create sandbox accounts at developer.paypal.com.
  2. 2Use sandbox client ID and secret in your integration.
  3. 3Log in as sandbox buyer when testing redirect flows.
  4. 4Supplement with test PANs like 4032033263236350 or 4242424242424242 where card fields appear.

Tips

  • Many PayPal flows need a sandbox buyer login — a PAN alone is not always enough.

Reference

Luhn algorithm & PCI basics

Luhn validates a checksum — not whether a card is issued, funded, or allowed on a gateway. PCI rules still apply to how you handle card fields.

When to use

Generating format-test numbers, teaching juniors, or validating user input client-side before tokenization.

Steps

  1. 1Use the Luhn checker at /tools/test-cards#luhn-tools.
  2. 2For deeper checksum work, open the Check digit tool.
  3. 3Never log full PANs in production — even test numbers encourage bad habits.
  4. 4Prefer processor tokenization (Stripe Elements, Razorpay Checkout) over handling raw PANs yourself.

Tips

  • Random Luhn-valid numbers are for format tests only — not authorization.

Troubleshooting checklist

When a test payment fails unexpectedly, walk through this list before assuming the integration is broken.

When to use

“It works in Postman but not Checkout” and similar support threads.

Steps

  1. 1Confirm test/sandbox API keys — not live.
  2. 2Confirm Dashboard test mode toggle matches your keys.
  3. 3Confirm the PAN matches the processor (Stripe card on Stripe, not Razorpay).
  4. 4Check currency and amount limits for the test account.
  5. 5Inspect webhook delivery and order status on the server, not only the client UI.

Reference

  • Wrong key mode → most common root cause
  • Live key + test PAN → issuer invalid / card declined
  • Missing webhook → payment succeeded but order stuck pending

Related tools

Test cards

Stripe, Razorpay, Cashfree, PayU, Braintree, Adyen, and more — sandbox test cards, UPI IDs, OTP rules, and Luhn tools.

Check digits

Luhn, Verhoeff, ISBN, and GSTIN format checks.

Dummy webhooks

Sample GitHub, Stripe, Slack, Razorpay, Shopify, and Twilio payloads.

Money

Format amounts with Intl and a small ISO 4217 catalog.

India fixtures

Format-check PAN, GSTIN, IFSC, and UPI. Sample values included.