Germany is the market that breaks the assumption most checkout code is built on: that “payment” means “card”. It does not here, and a German checkout that ships with a card field and nothing else will convert badly for reasons that never show up in your test suite.
| Currency | EUR (Euro) |
|---|---|
| Card networks in common use | Visa, Mastercard and girocard |
| National card scheme | girocard — operated by Die Deutsche Kreditwirtschaft (domestic debit) |
| Other payment methods a checkout has to handle | SEPA Direct Debit (Lastschrift), Purchase on invoice (Kauf auf Rechnung), PayPal and Klarna |
| Payments regulator | BaFin |
| Strong customer authentication | Required — PSD2 / EBA RTS on SCA |
Why the card field is not the whole job
German consumers pay for things online in ways that have no card in them at all. Direct debit under the SEPA scheme — Lastschrift — lets a merchant pull funds from a bank account given a mandate, and it is deeply established. So is buying on invoice, Kauf auf Rechnung, where the goods ship first and the customer pays within a couple of weeks. That model exists in almost no other large market at the same scale, and it puts a payment method in your checkout whose entire flow happens after fulfilment.
The consequence for testing is structural rather than cosmetic. A card payment either authorises or it does not, at checkout, synchronously. An invoice payment has no authorisation step, a settlement window measured in weeks, a dunning path when it is not paid, and a risk decision that has to happen before the goods leave the warehouse. If your order state machine was designed around “authorised → captured → settled”, invoice payment does not fit in it, and you will find that out in production rather than in QA.
Direct debit sits somewhere between the two. It clears, but it can be returned — the payer can reverse a SEPA Direct Debit for eight weeks without giving a reason, and up to thirteen months for an unauthorised one. A merchant that treats a cleared direct debit as final revenue is carrying a liability it has not modelled.
girocard, and why it is not a card number problem
girocard is the domestic debit scheme, operated by the German banking industry association girocard1. It is overwhelmingly a point-of-sale scheme: the card in a German wallet is usually a girocard, and it is usually co-badged with an international debit product so it works abroad.
That co-badging is the part that catches developers out. When such a card is used online, the transaction runs on the co-badged network, not on girocard — so the PAN your form receives looks like an ordinary Visa or Mastercard number, because it is one. There is no “girocard number format” to validate against, and any guide offering you a girocard prefix range to detect is describing something your checkout will never see.
What this means practically: you cannot test girocard by generating a number. Testing it means testing terminal integrations, and that is a different discipline from testing a web form. If your product is online-only, the correct amount of girocard-specific code is zero, and the correct amount of girocard-specific worry is also zero.
What actually needs testing
The card path itself is unremarkable. Germany runs on the same Visa and Mastercard rails as everywhere else, so the number rules in the card length reference apply unchanged, and a Luhn-valid test number exercises the field normally. Generate one from the Visa generator or the Mastercard generator and the field behaves the way it would for any European market.
The parts worth deliberate test coverage are the ones Germany adds:
- SCA. Germany is in the EEA, so PSD2 applies and most remote card payments carry a 3-D Secure challenge. Test the challenge path, the frictionless path, and the abandoned-challenge path — the 3-D Secure testing guide covers the states your code has to survive.
- IBAN input. If you accept direct debit, you accept IBANs, and a German IBAN is 22 characters with a checksum of its own. The IBAN generator produces structurally valid ones for exercising that field.
- Address format. House number after street name, five-digit postal codes with meaningful leading zeros. A postcode field that stores an integer loses Dresden.
- Refunds and returns. German consumer law gives a fourteen-day withdrawal right on most distance sales, which means refunds are a normal path, not an exception path. Test them as such.
The mistake worth avoiding
The pattern we see most often is a checkout built and tested entirely against card payments, with the German-specific methods bolted on afterwards as separate buttons that bypass most of the order pipeline. It works in the demo and it fails quietly later: refunds go down a path nobody tested, reconciliation reports do not balance, and the state machine has two shapes depending on which button the customer pressed.
If you are building for this market, model the non-card methods first and make the card path one case among several. It is more work up front, and it is the only version of this that survives contact with the accounting team.
Germany is not unusual in having its own shape — every large market does. Brazil attaches an instalment count to the authorisation itself, and India forbids merchants from storing card numbers at all. The specifics differ; the lesson that a card field is the smallest part of a localised checkout does not.
The regulatory and scheme details on this page were last checked against provider documentation on . Providers do change what they publish — the official link beside each claim is authoritative.