How the Luhn algorithm works
The Luhn algorithm (created by Hans Peter Luhn at IBM, 1954) is a simple checksum that detects single-digit transcription errors or transpositions of adjacent digits. It's not cryptographic security: it's basic format validation. The calculation: starting from the last digit, double every second digit (if the result is greater than 9, sum the digits of the result). Add all values. If the total is divisible by 10, the number is 'Luhn-valid'.
For example, for 4532015112830366: we start from the last (6=6), the second-to-last is doubled (6×2=12, we sum 1+2=3), the next stays the same (3=3), the next is doubled (0×2=0)... Sum all processed. The result must end in 0. Any number generated this way passes any processor's validation. But passing Luhn doesn't mean it's a real card with funds: it's just the first filter of many.
The algorithm covers the first line of defense: user typos. If they type 4532015112830366 instead of 4532015112830466, Luhn detects it before sending the transaction to the processor. This saves unnecessary requests. Processors like Stripe execute Luhn in frontend before calling the backend. But remember: passing Luhn only confirms mathematical structure, not real banking validity or available balance for charging.
Official testing cards: Stripe, PayPal, and Adyen
Each processor publishes official cards for testing. Stripe documents numbers like 4242 4242 4242 4242 (Visa success), 4000 0000 0000 0002 (declined), 4000 0027 6000 3184 (3D Secure required). Each simulates a different scenario: success, failure due to funds, CVC failure, additional authentication. Using the official ones in sandbox guarantees predictable documented behavior for automated testing of your integration.
PayPal and Adyen have their own sets. The catch is that in production these cards don't work: they're hardcoded in sandbox. If by mistake you push code pointing to production using 4242..., the charge fails with invalid card. This is anti-fraud defense: nobody can 'predict' test cards to actually charge. Testing ones only live in clearly marked sandbox environments.
For exhaustive QA you need to cover all scenarios: success, declined, expired, incorrect CVC, 3DS required, fraud detection, partial capture, refund failure. Stripe documents 30+ numbers each with specific behavior. Your automated test suite should run the complete flow with each and validate that your UI shows the correct message. This prevents regressions when you update SDK or change checkout flow validations.
PCI DSS and why the data generated here is safe
PCI DSS (Payment Card Industry Data Security Standard) regulates how to handle real card data. Storing real numbers without certification is a severe violation with monthly fines in thousands of dollars. The data generated with Luhn here are not real cards: they pass mathematical validation but don't correspond to existing bank accounts. They're not issued, have no holder, have no funds. Storing them generates no PCI obligations.
However, never use these numbers in production or send them to real processors. Although they pass Luhn, processors immediately reject because they don't find issuer (BIN check). If by mistake your production system tries to charge with one of these, you can generate rejected transaction logs, anti-fraud alerts, and temporary blocks of your merchant account. Keep environments clearly separated: dev/staging use these, prod never.
The correct use: populate testing forms where you need to validate visual format, autocomplete, length validations, type detection (Visa vs Amex). Your frontend validator should accept these numbers as formally valid. Your backend in sandbox processes them with simulated processor response. In automated E2E tests, they fill fields without touching real APIs. For real integration with processor sandbox, use the official documented ones.
Common payment testing mistakes
The most expensive mistake is only testing the happy path. The team tests 'successful purchase' and goes to production. But 30% of real transactions fail: declined, insufficient funds, CVC, expired, 3DS timeout. If your UI doesn't handle each error with a clear message, users abandon the cart. List the 10 most frequent processor errors and test each error UI flow before going to production.
Another mistake is not testing 3D Secure. Europe requires SCA (Strong Customer Authentication) under PSD2: most transactions require an additional authentication step. If your integration doesn't handle the bank redirect and return, purchases silently fail. Cards like 4000 0027 6000 3184 (Stripe) simulate 3DS challenge. Validate that your flow supports modal opening, response wait, and timeout or user cancellation handling.
The third mistake is testing only with home country cards. If your app sells internationally, foreign cards have different behaviors: conversion fees, stricter fraud rules, declines by issuing country. Stripe offers cards labeled by country (UK, France, Brazil). Test each priority market. An integration that works perfectly with US cards may fail 50% with Argentine cards due to anti-fraud rules of the real processor.