The hidden complexity behind every payment card

Most companies in the money movement space know what it takes to offer a card to their customers. They understand the benefits: deeper engagement, more transactions, a stickier product. And many have already done the groundwork: the business case is clear, the appetite is there.

But the road from "we want to offer a card" to "cards are live and working" requires considerable investment in time and money. There are vendors to evaluate, certifications to pass, compliance requirements to meet, and technical dependencies that only reveal themselves halfway through a project.

We've been through this process many times. We help fintechs, banks and money movement companies navigate the full card program journey. From the early strategic decisions all the way through to launch and beyond. That means paying attention to every part of the stack, including the pieces that don't always get the attention they deserve. PAN provisioning is one of them.

Why it matters more than most people think

Every card needs a unique PAN, the 16-digit number on a payment card. That process is scheme-governed and regulated, you can't build it yourself. Get it wrong and your cards either don't work or work insecurely. Get it delayed and you block testing, certification, and launch. It's also the foundation for tokenization, so if you ever want to offer your cards in Apple Pay or Google Pay, this has to be solid first.

How it actually works

There are three stages. Your sponsor bank allocates a BIN range, that's the pool of numbers you're allowed to issue from. Your issuer-processor then generates individual PANs, bundles them with expiry and CVV data, and packages everything for delivery. Then it goes out, physically to a card bureau, or instantly via API for virtual cards.

Virtual cards are fast. Physical cards take 5–10 business days and come with more operational complexity around replacements and reissuance.

Where things get complicated

Launching is the easy part. The harder challenge is managing PANs over time. Cards expire and need replacing before customers notice. PANs get compromised and need cancelling fast. Account changes have to sync without disrupting live cards. Unissued numbers in your BIN range create compliance risk. And as you grow, your PCI DSS audit scope grows with you.

The tokenization trap

Most programs treat digital wallet provisioning as a later problem. It isn't. Apple Pay and Google Pay use tokens, not PANs directly, and getting certified to provision those requires a separate track with the scheme's Token Service Provider. Leave it too late and you're rebuilding work you've already done.

Before you go live, make sure you can tick these off:

• BIN range confirmed before development starts
• Certified HSM in use for all cryptographic operations
• Full PAN lifecycle managed in one system
• Tokenization planned in parallel, not bolted on after
• Reissuance process tested before a single card ships

Get these right and the rest of your card program has a solid foundation to build on. And we get them right, together with you.

‍