Meal vouchers in Europe Integration: how you connect, and what protects it
Integration: how you connect, and what protects it
The card platform is an API, and the integration is smaller than most people expect because the hard parts are already built. This page is for whoever on your side has to say yes to the technical design: the three ways to talk to us, how requests are authenticated, and what the platform carries so that you do not have to.
Three channels, chosen by who is calling
| Channel | Who uses it | How it is authenticated |
|---|---|---|
| Mobile | Your app, on behalf of one user | Session token issued for that user |
| Server to server | Your backend | x509 certificates |
| Administration | Your operations team | Panel access for the institution |
Requests and responses carrying sensitive data are additionally encrypted with JSON Web Encryption, using RSA-OAEP-256 and A256GCM. That is a requirement rather than an option on those endpoints, and it is the same mechanism whichever channel you use.
What you actually build
For a benefit programme the sequence is short. Register the user, run identity verification, create the balance, issue the card. After that you are loading value and reading transactions.
The part that varies is the acceptance decision. If your market allows a category code to carry the rule, the platform applies it and you build nothing. If your market wants a contract with each accepting merchant, you expose one endpoint that answers an authorisation request, and that endpoint is where your merchant list and your ceilings live. Acceptance rules covers when each applies.
Cards can be virtual or physical, and virtual first is usually the faster route to a working pilot. Balances come in several shapes, including balances you hold as the partner rather than per user, which matters if you fund the programme centrally.
Send us the architecture you have in mind and we will tell you what it touches.
Book 15 minutesWhat the platform carries so you do not
Hosting, PCI DSS and security compliance, hardware, software and the devops behind it are all inside the monthly per card price. That is worth stating plainly, because it is the largest hidden cost in building this yourself. A card platform is not mostly code, it is mostly the audited environment the code runs in.
Card issuing is delivered with licensed partners across the EU and EEA, so the licence, the scheme membership and the BIN sponsorship sit with them rather than with you. Funds stay on the platform side throughout, which is why an acceptance decision on your side is a decision rather than a movement of money.
What we do not do
We issue cards and process transactions on Mastercard. We do not hold our own electronic money or payment institution licence, we do not do acquiring, and we are not on every network. If any of those is a requirement, the earlier you know the better.
Read the documentation before you talk to us
The API documentation is public and it is not a brochure. It has the endpoints, the authentication, the error cases and the platform cost model, and it is a fair test of whether this is the kind of supplier you want. Start at the card issuing and core banking overview.
If you would rather see the shape of a programme first, launching covers who delivers what and in what order, and how a meal voucher card works follows one payment from tap to decision.