Test Credit and Debit Card Numbers for Every Payment API (2024)

by Allan MacGregor

When building e-commerce solutions or working with payment processing systems, it’s vital to test the different transaction scenarios to ensure that the payment processing is working as expected. Testing your system to make sure it can handle scenarios where payment transactions fail also helps protect your business and your customers alike.

Payment transactions might fail due to a variety of reasons, and some of the most typical errors include the following:

• Do not honor
• Insufficient funds
• Stolen credit card
• Identity verification error

You might be wondering, "How do I test these scenarios? Should I use a test card number or an actual card number?”

Although credit card companies have a reserved Bank Identification Number or BIN for test credit cards in an attempt to provide a quasi-universal standard of testing card numbers that can be used on any payment, not all payment gateways follow this convention.

It's always recommended to check your gateway processor for details on the numbers and scenarios they support. Needless to say, test card numbers will only work on sandbox accounts, and fail on live payment gateways. Additionally, enabling sandbox mode will vary from payment processor to payment processor, so it’s recommended to consult their official documentation for more information.

This article provides a list of test credit and debit card numbers that will work on most payment processors and elaborates on the specific scenarios that these numbers will simulate.

Testing Credit and Debit Card Numbers

While there’s a wide variety of situations for testing your payment API, typically you’ll want to cover at least the following scenarios:

• Successful transactions.
• Payment errors like do not honor, insufficient funds, and stolen cards.
• Cardholder disputes.
• Testing 3D Secure

The numbers and setup discussed in this article are specific to Rapyd payments, but the numbers should work on most APIs and the steps should also be much the same.
<!--HubSpot Call-to-Action Code --><!--[if lte IE 8]><![endif]--> hbspt.cta.load(5246303, &#39;5fd0724d-a725-4f12-84ac-23227175b99a&#39;, {&quot;useNewLoader&quot;:&quot;true&quot;,&quot;region&quot;:&quot;na1&quot;}); <!-- end HubSpot Call-to-Action Code -->

Numbers for Successful Transactions

A successful transaction is the most typical scenario that you might want to test. Testing a successful translation is useful to confirm that the final stages of your flow are working correctly, like confirmation pages and emails, order reviews, and so on. You can simulate a successful transaction using the following numbers, which will work on any payment processor.

Numbers for Error Transactions

Knowing how your system will handle errors that lead to declined transactions is vital. Transaction errors occur as transactions are being processed, for example, during checkout in an e-commerce store, and typically fall into one of the following categories:

• Do not honor: Also called an invalid service code error, this indicates that the customer's issuing bank will not validate the transaction with the authorization code provided. There are several possible reasons for this error:

  • The customer has a hold on their card.
  • The card has had multiple denied payments in a row, so it’s temporarily locked.
  • The merchant is operating in a different country than the customer.
  • The transactions were flagged by the bank's anti-fraud system.

• Stolen card: This indicates that the card has been reported as stolen. If operating in a retail store, the recommended process is to retain the card, deny any goods or services, and immediately call the card issuer.

• Insufficient funds: The card doesn't have the necessary funds to complete the transaction. This is applicable to credit cards and debit cards.

The numbers for simulating these transaction errors are as follows:

In addition to the above numbers, you can also use a specific transaction amount to simulate the following errors:

• Payment gateway not responding: This error simulates the payment gateway not responding to the request due to an internal error.
• Payment expired: Simulates a scenario where the transaction cannot be processed because the payment has expired.
• Insufficient funds: Simulates an instance of the test credit card not having enough funds to complete the transaction.
• Processor unavailable: Simulates the payment processor not being available and the transaction failing as result of a network error.
• Settlement decline: Simulates the transaction failing due to an instance where the payment could not be processed because the settlement amount was declined.

The following table contains the test numbers along with the transaction amount ranges you must enter to simulate these particular errors.

Numbers for Cardholder Disputes

Cardholder disputes is another category of tests that you should consider running on your e-commerce or payment processing system. These occur when the initial transaction has been processed, and the cardholder is then disputing the transaction.

Normally, the customer will open a dispute through their credit card company and the business will receive notification of the dispute and be offered a chance to refute the claim. Cardholder disputes typically fall under one of the following categories:

• Goods or services not provided: This error indicates that the customer has not received the goods or services they ordered, so they’re disputing the transaction with their credit card company.
• Subscription canceled: For SaaS companies, customers will often dispute subscription payments claiming the subscription had been canceled.
• Counterfeit merchandise: This simulates an instance of a fraudulent transaction where the customer claims the merchandise is counterfeit.

• Credit not processed: A common case for retailers is when customers claim to have a receipt for credit or a voided transaction, but have not yet had their credit processed.

• Cardholder dispute - miscellaneous: Simulates a generic dispute where the customer has a dispute with the credit card company, but no specific reason is attached.

The numbers for simulating these cardholder disputes are as follows.

Testing 3D Secure

Another important aspect of credit card processing that’s worth implementing and testing is 3D Secure, or 3DS. This is a feature that verifies the identity of the cardholder before allowing them to complete a transaction, with the aim of adding another layer of security to your payment processing system.

Different payment processors implement 3DS as different products, for example:

• MasterCard SecureCode
• Verified by Visa
• Discover ProtectBuy

With Rapyd, we can simulate 3DS authentication for the following Rapyd Payment API operations:

• Create payment: Set amount to 1000 or above, while avoiding the amounts listed in the 2000 range for error transactions.
• Create customer: This request will require 3DS for all payment methods.
• Add payment method to customer: This request will require 3DS for all payment methods.

Let's go ahead with the API request to create a payment with a 3DS-enabled verification:

Request URL: POST https://sandboxapi.rapyd.net/v1/payments

{ "amount": 1100, "currency": "USD", "payment_method": { "type": "us_visa_card", "fields": { "number": "4111111111111111", "expiration_month": "12", "expiration_year": "25", "cvv": "789", "name": "John Doe" } }, "capture": true}

Once you receive the response, you can check the status, redirect_url, and next_action fields to validate the response and simulate the 3DS redirection flow. For example:

{ "status": { "error_code": "", "status": "SUCCESS", "message": "", "response_code": "", "operation_id": "42416643-4159-49a8-8c65-4a17e8d4e489" }, "data": { "id": "payment_46bd13214fe6e7ab9f12f70e64d5743c", "amount": 0, "original_amount": 1050, "is_partial": false, "currency_code": "USD", "country_code": "US", "status": "ACT", // ... "payment_method": "card_761c1a5ce9b7af77f5f6cd539fb1fcbb", "payment_method_data": { "id": "card_761c1a5ce9b7af77f5f6cd539fb1fcbb", "type": "us_visa_card", "category": "card", // ... "next_action": "3d_verification" }, // ... "redirect_url": "https://sandboxcheckout.rapyd.net/3ds-payment?token=payment_46bd13214fe6e7ab9f12f70e64d5743c", // ... "next_action": "3d_verification", // ... },}

Looking at the data section of the response, you can see that the next_action field is set to 3d_verification. This means that the payment processor has requested a 3DS authentication:

• status: The status of the payment is ACT (active). The payment is active and awaiting completion of 3DS authentication.
• redirect_url: The URL for 3DS authentication.
• next_action: The value is 3d_verification. 3DS authentication is required to complete the payment.

As part of the testing, you can open the redirect_url in a new tab and complete the 3DS authentication. Once you open the URL in the browser, you should see the following.

From this page, we can simulate the following:

• 3DS failure: By clicking the Cancel button.
• 3DS success: By clicking the Continue button.

Conclusion

In this article, you learned the importance of testing your payment processing system regardless of whether you’re a merchant, a SaaS company, or a retailer; testing will ensure your system can correctly process credit and debit cards and protect you against fraud. You also learned about some of the challenges involved with testing your payment processing system and the existence of test credit and debit card numbers.

While every payment processor has their own set of test credit and debit card numbers, and the testing scenarios they support vary, most will support the scenarios we covered in this article.

This article simulated these transactions and errors using Rapyd Payment API, a payment processing API that makes payment processing from a myriad payment methods, such as credit cards, debit cards, and e-wallets, fast and easy.