Skip to main content
Available in🇮🇳 India
Use these test cards to test card-based recurring payment flows in test mode. The flow has two stages:
  1. Mandate registration (initial payment) – the customer authorises the card mandate.
  2. Subsequent (auto-debit) payments – Razorpay charges the registered token each time you initiate a debit.
Watch Out!
  • You can use these test cards to make payments in test mode only.
  • Test mode features a mock bank page with Success and Failure buttons to replicate the live payment experience.
  • No real money is deducted due to the usage of test API keys. This is a simulated transaction.
  • A subsequent (auto-debit) payment is simulated to reach its terminal state (Success or Failure) about 5 minutes after it is created, with the relevant Razorpay webhook triggered. This is done to let you validate the flow quickly without waiting. This differs from Live Mode, where a PDN (Pre-Debit Notification) is sent first, and the actual debit can happen only after a mandatory 24-hour TAT. Test Mode does not make calls to the Mandate Hubs, so no PDN (Pre-Debit Notification) or AFA (Additional Factor of Authentication) messages are triggered for any of the simulated scenarios below.
  • If you use these test cards for live mode payments, either of the following error messages is displayed: card issuer is invalid or invalid card input.
  1. At the Checkout, select Card as the payment method.
  2. Enter the card number for the scenario you want to test.
  3. Enter any random CVV and any future date as the expiry date.
  4. Consent to tokenisation for the recurring mandate when prompted.
  5. Click Pay. A sample bank/payment page is displayed.
    • Select Success to complete the mandate registration.
    • Select Failure to simulate a failed mandate registration.
  6. For a subsequent payment, first register the mandate with the same card number, then charge the token via the Charge a Token API or the Dashboard. The payment reaches its terminal state about 5 minutes later.
Use the following cards for testing. You can use any random CVV and any future date as the expiry date.

Test Cards for Mandate Registration (Happy Flow)

Use these cards to register a card mandate successfully (initial authorisation transaction).
For backward compatibility, the Visa card 4718 6091 0820 4366 (previously documented for Subscriptions) continues to work for the happy mandate-registration flow.

Test Cards for Subsequent Payments (Happy Flow)

First register the mandate using one of the cards below, then attempt the subsequent (auto-debit) payment using the same card number. The subsequent payment moves to Success about 5 minutes after it is created.

Error Scenarios – Mandate Registration

Use these test cards to simulate error conditions during mandate registration. Once you initiate the payment, on the success/failure screen you must select Failure to get the relevant error.
BIN Not Supported Scenario: Token Rejected Despite Successful Registration for Visa and MastarcardFor the following Visa and Mastercard cards, the mandate registration payment succeeds (select Success on the payment page), but the recurring token is later rejected at the Mandate Hub because the card BIN is not supported. The rejection is communicated via a Razorpay webhook when mandate creation is attempted (card_mandate_bin_not_supported).

Error Scenarios – Subsequent Payments

Use these test cards to simulate error conditions during subsequent (auto-debit) payments. First successfully register the mandate using the same card number, then attempt the subsequent payment. The payment reaches its terminal (failed) state about 5 minutes after it is created, with the relevant Razorpay webhook triggered.
Handy Tips
  • The customer_action_required scenario simulates a debit amount greater than the Additional Factor of Authentication (AFA) limit, where the customer did not approve the AFA request. Know more in the Card Recurring Payments FAQs.
  • The card_mandate_not_active and card_mandate_paused scenarios simulate the customer cancelling or pausing the mandate after the payment is created but before the debit is executed. This is determined when the pre-debit notification (PDN) is verified.