Meal vouchers in Europe How to choose a card issuing platform for a benefit programme
How to choose a card issuing platform for a benefit programme
Feature lists for a card issuing platform look identical until you ask the four questions below, at which point they stop looking identical at all. We build one of these platforms, so read this knowing that, and use it to interrogate us as well as everyone else. Every question here is one we are happy to answer about ourselves.
1. Who makes the acceptance decision?
The single most important question for a benefit card, and the one most often skipped because it sounds technical.
Some platforms decide entirely on their own side: you configure permitted merchant categories and limits, and the platform answers every authorisation. That is simple, cheap and enough in Germany, Spain or Poland. Others let your own service answer the authorisation, so the decision can consult your merchant list and your rules.
You need the second where the law requires a contract between the issuer and each accepting merchant, which is the case in Italy, Greece, Luxembourg and Romania among others. A platform that only offers the first cannot serve those markets, whatever the feature list says. Acceptance rules covers the difference.
Ask: can our own service answer the authorisation, and what data does the request carry?
2. What happens if you fail?
Uncomfortable, and the most informative question on this list. This category has had suppliers wind down, get sold at a fraction of their value and be sanctioned by their regulator, and the benefit companies sitting on them had no say in any of it.
Ask: who holds the employee records, who holds the merchant relationships, what can we export and on what notice, and what happens to the balance if you stop trading. The answers differ far more between suppliers than the feature lists do, and a supplier that has not thought about it will show that immediately.
Switching issuer covers what a migration actually involves, which is worth reading before you need it rather than after.
3. What is inside the platform fee?
A monthly platform fee can mean very different things. The expensive part of running a card platform is not the code, it is the audited environment the code runs in, so the question is whether that environment is included or is a separate project on your side.
Ask: does the fee cover hosting, PCI DSS and security compliance, or are those extra. Ask what is charged per card and what is charged per transaction, because the second one turns a successful programme into an expensive one. Our own answer is on this site with the numbers on it: 500 euro to set up, 1.50 euro per card per month, nothing per transaction.
4. What can you not do?
Every platform has a list. A supplier who cannot produce one has either not thought about it or is not going to tell you, and both are the same problem.
Ask: which licences do you hold and which belong to a partner, which card networks, do you do acquiring, which countries are outside your footprint. Ours is on the site: no electronic money or payment institution licence of our own, no acquiring, Mastercard, and delivery with licensed partners across the EU and EEA.
A question that is usually a waste of time. Asking for a feature comparison matrix. Everyone ticks everything, the differences that matter are not features, and you will spend two weeks producing a document that tells you less than one honest conversation about question two.
What to check without asking anyone
Is the API documentation public? A supplier confident in its platform publishes the endpoints, the authentication, the error cases and often the cost model. A supplier that puts all of it behind a sales call is telling you something.
Does the supplier understand your category? Card issuing is generic. Benefit cards are not, and a platform whose team has never encountered a national voucher register or a mandatory employee contribution will discover them during your implementation rather than before it.
Can they name the constraint in your market? Ask what applies in the country you are launching in. The answer tells you whether they have done this before, and the country rules here let you check the answer.
The order to do this in
Settle question one first, because it decides the architecture and therefore which suppliers are even eligible. Question four second, because it eliminates quickly. Then three, then two, and take two seriously even though it feels like borrowing trouble.
If you already know the answers and want to see whether we fit, the overview is the short version and launching covers what a build looks like.