As a developer, I work a lot with e-commerce websites and, as a result, with a lot of payment gateways. I’m fortunate that I get to work on many different projects for different clients, each with its own unique challenges. I have, therefore, found myself working with a lot of different payment gateways over the years, from the more familiar ones like PayPal and Stripe to some lesser known ones.

While I love the variety of my work, I generally find working with payment gateways to be frustrating. I’m sure I’m not alone in this opinion! For many payment gateways, the documentation is poorly written, lengthy and, at times, difficult to find.

Thankfully, libraries such as OmniPay have helped me a lot and bring some consistency to working with the different services. However, while these libraries remove some of the need to check documentation, testing often still requires me to dig it up.

Testing is a crucial part of the development process, from initially setting up a payment system to the continual testing of a checkout process. For each stage, we need to work with test payment cards to run our code through the hoops and ensure the interface works well. I doubt any of us are paid well enough to happily reach for our wallet and put through a genuine payment with our own credit card! So, we look for the test payment card details relevant to the gateway we’re working with.

Even if we’ve already found the appropriate documentation at the beginning of development, what about a month or two later when we need to retest something? How about a year later, when everything has moved around on the official website of the payment gateway? Documentation easily gets misplaced, and we find ourselves hunting around for it. Even once we have our hands on it, locating the test details can be a challenge. Some gateways seem to love providing multiple PDF files, all mysteriously titled, with the test card details buried deep within one of them.

I have been increasingly finding myself in this situation. Moreover, developers aren’t the only ones who need these details in the course of a project. There are project managers, QA testers and the clients themselves. I was getting fed up with searching for card numbers. So, earlier this year, I decided to do something about it.

Back in April, I set up a new repository on GitHub and started compiling a list of all of the payment gateways I’ve used over the years and the test card numbers available for each of them. The idea was simply to create a single accessible resource of card numbers and other relevant details required to put test payments through.

I chose to host the list — or cheat sheet, if you will — on GitHub so that it could easily be maintained and updated. By making it a repository, others can quickly fork and contribute to it themselves, adding other payment gateways to the ones already represented. I released the cheat sheet under a Creative Commons Attribution-ShareAlike license to encourage people to share and adapt the list.

So, here are the test card numbers for some of the major payment gateways and a few lesser known ones.

PayPal

One of the largest online payment companies, PayPal is a popular choice with clients for its recognizable brand (even if it is less popular with those who have to implement it). The following test cards are available in PayPal sandbox mode and can be used with any card expiry date set in the future.

Stripe

Stripe is a much younger (and, may I say, trendier?) payment company than PayPal. It has quickly proven to be popular with developers, thanks to its simplicity of implementation and solid documentation, which is always a plus.

All of the following card numbers will produce successful transactions in test mode using any future expiry date.

Full details of Stripe’s test cards can be found on the “Testing” page of its documentation.

Authorize.Net

Like PayPal, Authorize.Net has been around for a while. The following test credit-card numbers will only work in the sandbox. If the card’s CVV2 code is required, use any three-digit combination, except for American Express, which requires a four-digit combination. See the “Testing Guide” for further details.

SagePay

SagePay is a popular British payment gateway. A lot of card numbers are available for testing that result in various 3DSecure statuses. All of SagePay’s test cards use the address “88” and postcode “412.”

The 3DSecure (3DS) responses are:

• Y
  Enrolled and will progress to the password page to complete verification
• N
  Not enrolled and will return a 3DSecureStatus=NOTAVAILABLE to your system
• U
  Unable to verify enrolment and will return a 3DSecureStatus=NOTAVAILABLE to your system
• E
  Error occurred during 3D Secure verification, and a 3DSecureStatus=ERROR will be returned to your system

Full details can be found on the “Test Card Details for Your Test Transactions” page.

Braintree

The following card numbers will not trigger errors.

To trigger an unsuccessful credit-card verification, use one of the following cards:

Further details about using Braintree’s test payment numbers can be found on its “Testing” page.

Ogone

Details about using test cards in Ogone can be found in “Create and Configure Your Ogone Test Account.”

Pay360

The test card details above can be found on Pay360’s “Test Cards” page.

PayPoint

RedSys

WePay

Full details of WePay’s test cards can be found on the “Testing” page of its documentation.

WorldPay

WorldPay test cards do not have a verification code or issue number.

Other Resources

If you’re building a website that will take payment details to be passed to the relevant payment gateway, doing some local validation before attempting to process the payment can be useful. This will improve the user experience and speed things up a little. Credit-card numbers can be checked using the Luhn algorithm, and many libraries out there will help you do this. The following JavaScript plugins all provide a simple way to integrate this validation and avoid issues with PCI compliance, because the card details don’t have to be sent to your server to be tested.

• jQuery Credit Card Validator, Pawel Decowski
  jQuery plugin for detecting card types and validating card numbers
• Credit Card Validator, Braintree
  Card number validation from the Braintree payment gateway.
• jQuery.payment, Stripe
  Can be used to validate inputs and to format numbers

Most payment gateways use test card numbers that can be checked using the Luhn algorithm; so, you shouldn’t have any issue validating during testing.

Final Words

Hopefully, the test card numbers presented here will be of use to you. If a payment gateway that you use is missing, feel free to contribute it to the original cheat sheet repository.

Happy testing!

(vf, il, al)