How to migrate a meal voucher programme to a new issuer

Why programmes migrate

Three reasons account for most of them, and only one is a decision.

The partner fails or is forced to change. Benefit card providers do not usually hold the licence themselves, so the licensed institution behind the card is a single point of failure. This is not hypothetical in European benefits: providers have had to move issuers when their partner collapsed, and some have done it more than once.

A regulatory deadline forces the format. An issuer with paper volume and no card product does not have a migration problem, it has a product problem. France is the current example: a bill filed in June 2026 ends paper issuance from 1 January 2028.

Economics change. When a regulator caps what an issuer may charge merchants, as Italy did at 5 percent, the cost per transaction stops being a background number.

What actually has to move

In rough order of difficulty, which is the reverse of the order people expect.

What	Difficulty	Why
The merchant list	Hardest	It is the asset, and it is often the least clean data in the business
Employee records and entitlements	Hard	Working patterns, part time, leavers, regional ceilings
Funding and reconciliation	Moderate	Two programmes running at once means two balances to reconcile
Unspent balances	Moderate	Value already funded has to end up on the new card, not be written off
The cards themselves	Easiest	Virtual cards issue in minutes

The merchant list is the real project

In any market where the law ties acceptance to merchants holding a contract with the issuer, that list is the licence to operate. It is also, in most businesses, the data set that has grown for years without a single owner: duplicates, closed businesses, merchants recorded under a trading name in one system and a legal name in another, and identifiers that came from an acquirer rather than from you.

Two questions decide how painful this is.

Do you hold the list, or does your issuer? If the authoritative copy lives inside the incumbent platform, extracting it is a negotiation as much as an export. If it lives in your own system, the migration is far shorter.

What identifies a merchant? A merchant identifier issued by one acquirer does not necessarily match the same shop seen through another. Any list keyed only on identifiers from the outgoing arrangement needs a second key, usually the legal registration number, before it can be moved.

Keep the authorisation decision on your side

The single design choice that makes future migrations cheap is where the accept or decline decision is made.

If your rules live inside the issuing platform, then every platform change is a re-implementation of those rules, tested from scratch, in someone else's configuration language. If the decision is made by your own system, with the platform passing each authorisation for a verdict, the rules do not move at all. Only the transport changes.

That is the practical case for shared authorisation beyond compliance: it turns the issuer into a replaceable component. Your merchant list, your ceilings, your exclusions and your product logic stay where they are maintained. The interface is documented in the shared authorisation documentation.

Running the migration without a gap

Six steps, sequenced so the benefit never stops.

1. Freeze the merchant list and clean it. Deduplicate, drop closed businesses, add a second identifier. Do this before anything technical starts, because everything downstream depends on it.
2. Stand up the new programme in parallel. New cards issued, not yet funded, not yet distributed. The old programme continues untouched.
3. Run one funding cycle on both. Fund the new programme for a small pilot group while the old one carries everyone else. This is where reconciliation differences surface, and they always do.
4. Move employees in waves, not on a date. By site, by country or by employer, so a problem affects a group rather than the workforce. Virtual cards make each wave a same day event.
5. Sweep unspent balances. Decide early whether value transfers or the old card stays live until spent. Both work, but the choice drives employee communication, and the wrong answer produces complaints on the first Monday.
6. Close the old programme only after a full cycle. Not after the last card is issued.

Questions that come up during a switch

What happens to unspent balances when you change meal voucher provider?

The value stays with the employee until it expires, so the old programme has to keep paying until then. The expiry rule sets that date. In France a titre-restaurant is usable during the calendar year printed on it and until the end of the following February, under article R3262-5 of the Code du travail. In Belgium an electronic meal voucher is valid for 12 months from the day it lands on the employee's account. In Italy the old issuer must still pay merchants for at least six months after a voucher expires, under ministerial decree 122/2017. Two setups work: move the remaining value to the new card, or leave the old card live until it is spent or expires.

How long does it take to switch meal voucher provider?

Plan for at least two funding cycles once the merchant list is clean. The first runs both programmes side by side with a pilot group. The second is a full cycle on the new programme before the old one closes. For a monthly benefit that means about two months of overlap, plus whatever expiry tail the country rules above leave on the old cards. The merchant list usually decides the start date, because it has to be clean before anything else begins.

What goes wrong

Treating the deadline as the finish line. If the plan has everyone moved on the final day, there is no room for the group that does not activate. Aim to be finished a cycle early.

Assuming employee data is current. Migration is when a benefits database meets reality: leavers still listed, changed working patterns, people at a site that closed. Reconciling headcount is part of the project, not a precondition someone else handles.

Migrating the rules by hand. Ceilings, excluded categories and market specific conditions rewritten into a new platform from memory rather than from a specification is how a programme quietly stops matching the law it was built for.

Before starting, settle the acceptance model for each market you operate in: see open loop or closed loop. For a new programme rather than a move, see how to launch a meal voucher card programme.