Testing Credit-Card Numbers In E-Commerce Checkouts (Cheat Sheet)

Testing Credit-Card Numbers In E-Commerce Checkouts (Cheat Sheet)

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 OmniPay1 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 list2 — 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 Link

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.

Card typeCard number(s)
American Express378282246310005 and 371449635398431
American Express Corporate378734493671000
BankCard (Australia)5610591081018250
Diners Club30569309025904 and 38520000023237
Discover6011111111111117 and 6011000990139424
JCB3530111333300000 and 3566002020360505
MasterCard5555555555554444 and 5105105105105100
Visa4111111111111111, 4012888888881881 and 4222222222222

Stripe Link

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.

Card typeCard number
American Express378282246310005 and 371449635398431
Diners Club30569309025904 and 38520000023237
Discover6011111111111117 and 6011000990139424
JCB3530111333300000 and 3566002020360505
MasterCard (debit)5200828282828210
MasterCard (prepaid)5105105105105100
Visa4242424242424242 and 4012888888881881
Visa (debit)4000056655665556

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

Authorize.Net Link

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 Guide4” for further details.

Card typeCard number(s)
American Express370000000000002
Diners Club (Carte Blanche)38000000000006
Visa4007000000027, 4012888818888 and 4111111111111111

SagePay Link

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.”

Card typeCard numberIssueCVV23DS
American Express3742000000000041234N/A
Diners Club36000000000008123N/A
Maestro (UK)5641820000000005 and 675900000000501123Y
Maestro (Germany)670500000000801123Y
Maestro (Ireland)677700000000701123Y
Maestro (Spain)676600000000001123Y
Maestro (international)300000000000000004123Y
MasterCard (credit)5404000000000001123Y
MasterCard (credit)5404000000000043123N
MasterCard (credit)5404000000000084123U
MasterCard (credit)5404000000000068123E
MasterCard (debit)5573470000000001123Y
Visa Corporate4484000000002123N
Visa (debit and Delta)4462000000000003123Y
Visa Electron4917300000000008123Y

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 Transactions5” page.

Braintree Link

The following card numbers will not trigger errors.

Card typeCard number(s)
American Express378282246310005 and 371449635398431
Visa4111111111111111, 4005519200000004, 4009348888881881, 4012000033330026, 4012000077777777, 4012888888881881, 4217651111111119 and 4500600000000061

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

Card typeCard number(s)Verification response
American Express378734493671000Processor declined
Discover6011000990139424Processor declined
Mastercard5105105105105100Processor declined
Visa4000111111111115Processor declined
JCB3566002020360505Failed (3000)

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

Ogone Link

Card typeCard number

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

Pay360 Link

Card typeCard number3DSSuccessful authorization
American Express9905000000005139YY
American Express9905000000000015NY
American Express9905000000010253UY
American Express9905000000005287YN
American Express9905000000000163NN
American Express9905000000010402UN
Mastercard (debit)9900000000005159YY
Mastercard (debit)9900000000000010NY
Mastercard (debit)9900000000010258UY
Mastercard (debit)9900000000005282YN
Mastercard (debit)9900000000000168NN
Mastercard (debit)9900000000010407UN
Mastercard (credit)9901000000005133YY
Mastercard (credit)9901000000000019NY
Mastercard (credit)9901000000010257UY
Mastercard (credit)9901000000005281YY
Mastercard (credit)9901000000000167NY
Mastercard (credit)9901000000010406UY
Visa (debit)9902000000005132YY
Visa (debit)9902000000000018NY
Visa (debit)9902000000010256UY
Visa (debit)9902000000005280YN
Visa (debit)9902000000000166NN
Visa (debit)9902000000010405UN
Visa (credit)9903000000005131YY
Visa (credit)9903000000000017NY
Visa (credit)9903000000010255UY
Visa (credit)9903000000005289YN
Visa (credit)9903000000000165NN
Visa (credit)9903000000010404UN

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

PayPoint Link

Card typeCard number(s)
Mastercard (credit)5555555555554444 and 5105105105105100
Visa4444333322221111 and 4444444444441111

RedSys Link

Card NumberExpirationCVV2CIP code

WePay Link

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

Card typeCard numberCVV2
American Express378282246310005 and 371449635398431Any

WorldPay Link

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

Card typeCard number(s)
American Express34343434343434
Carte Bleue5555555555554444
Diners Club36700102000000 and 36148900647913
Laser630495060000000000 and 630490017740292441
Maestro6759649826438453 and 67999990100000000019
MasterCard5555555555554444 and 5454545454545454
Visa4444333322221111, 4911830000000 and 4917610000000000
Visa (debit)4462030000000000 and 4917610000000000003
Visa Electron (UK only)4917300800000000
Visa (purchasing)4484070000000000

Other Resources Link

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 algorithm10, 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.

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 Link

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 repository14.

Happy testing!

(vf, il, al)

Footnotes Link

  1. 1 http://omnipay.thephpleague.com/
  2. 2 https://github.com/drmonkeyninja/test-payment-cards
  3. 3 https://stripe.com/docs/testing
  4. 4 http://developer.authorize.net/hello_world/testing_guide/
  5. 5 http://www.sagepay.co.uk/support/12/36/test-card-details-for-your-test-transactions
  6. 6 https://developers.braintreepayments.com/reference/general/testing/php
  7. 7 https://payment-services.ingenico.com/int/en/ogone/support/guides/user%20guides/test-account-creation
  8. 8 https://paymentdeveloperdocs.com/test_card_numbers/
  9. 9 https://www.wepay.com/developer/reference/testing
  10. 10 https://en.wikipedia.org/wiki/Luhn_algorithm
  11. 11 http://jquerycreditcardvalidator.com/
  12. 12 https://github.com/braintree/card-validator
  13. 13 https://github.com/stripe/jquery.payment
  14. 14 https://github.com/drmonkeyninja/test-payment-cards

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to topTweet itShare on Facebook

(Visited 2 times, 1 visits today)