Meal vouchers in Europe Switching issuer on a programme that is already live
Switching issuer on a programme that is already live
Nobody plans this. It happens because a provider is winding down, has been sold, or has stopped being able to support what you need next, and it has happened to serious benefit companies more than once. Switching issuer is a solved problem, and the difficult part is not the one people expect.
The hard part is the balance, not the cards
Cards can be reissued. Employees can be onboarded again. What cannot be waved away is that people are holding value they were given, some of it earned months ago, and on the day of the switch it has to still be there and still be spendable.
That is why migration is planned backwards from the balance. Everything else in the sequence exists to protect it.
What carries over and what does not
| Item | Carries over |
|---|---|
| Balances | Yes, and this is the piece that sets the timetable |
| Card numbers | No. New cards, new numbers, new plastic if physical |
| Employee records | Yes, if your side holds them rather than the outgoing issuer |
| Merchant list and acceptance rules | Yes, and they usually improve on the way across |
| Transaction history | Export it before you leave. Assume you will not get it later |
The item that catches people is the third one. If the outgoing issuer holds your employee records and your merchant relationships, you are not switching a supplier, you are rebuilding a programme. Finding that out early changes the plan.
The order of operations
- Establish what you actually holdRecords, merchant contracts, transaction history. Export anything you would need if the relationship ended badly, and do it while it is still cordial.
- Build in parallelThe new programme goes live in sandbox while the old one keeps running. Nothing is switched off to make room.
- Move the balancePlanned to a date, communicated to employees before it happens, with the old instrument kept usable until the new one is confirmed working.
- Reissue and onboardNew cards out ahead of the date. The onboarding has to work first time because everyone does it in the same week.
- Close the old programmeOnly after the new one has carried a full cycle, including a month end and a load.
If your provider has given you a date, the useful first call is now rather than later.
Book 15 minutesWhy this keeps happening
The category has had a difficult few years on the supply side. Providers have failed, been sold at a fraction of their value, or been sanctioned by their regulator, and the benefit companies sitting on them had no say in any of it. Two of the better known German benefit platforms have already been through a forced issuer migration once.
The lesson most of them draw afterwards is the same: the questions to ask a prospective issuer are about what happens if it goes wrong, and who holds what. Worth asking us too.
What it costs and how long
A migration is priced like a launch, 500 EUR to set the programme up and 1.50 EUR per card per month, with no transaction fees. Our side of the timetable is the same as a launch, about a week. The difference is that most of the elapsed time is yours rather than ours: the export from your current provider, the communication to employees and the onboarding window.
Where it goes wrong is when the outgoing provider sets a deadline that leaves no room for a parallel run. If you are in that position, say so on the first call rather than the third.
The longer version
Migrating to a new issuer covers the sequence in full, including the cases where the timetable is not yours. Acceptance rules explains the part that usually improves on the way across, and launching covers what a build looks like when there is nothing to migrate.