Meal vouchers in Europe / How to launch a meal voucher card programme

How to launch a meal voucher card programme

Launching a meal voucher card programme is mostly a sequence of country decisions, not a technology project. You confirm whether the market keeps a register of issuers, establish whether the law requires a contract with each accepting merchant, settle the licence model, then design the acceptance rules and decide who approves each transaction. The card itself is the last part, and the easiest.

Last reviewed: 28 August 2026. Written for benefit platforms, welfare operators and voucher issuers building or replacing a card programme.

Step 1: Check whether the market keeps a register of issuers

In most European markets, issuing meal vouchers is not open to anyone. Italy publishes a register of authorised companies under legislative decree 36/2023, France accredits issuers through the Commission Nationale des Titres-Restaurant, Belgium recognises them through the FOD Economie, and Romania authorises them through the Ministry of Finance.

Being on the register is a precondition, not paperwork you complete before launch. Where no register exists, as in Poland, the benefit runs on a tax or social contribution exemption instead, and the constraint moves from licensing to how you evidence that the card was only used for food.

Step 2: Establish whether the law requires an affiliated merchant list

This is the question that decides your architecture, and it is worth answering before anything else is designed.

European meal vouchers sit outside interchange regulation because of a specific exemption covering instruments valid in a single member state, provided at the request of an employer or public body, regulated by a national authority for a social or tax purpose, and usable at suppliers holding a commercial agreement with the issuer. That final condition is why affiliated merchant networks exist at all.

How strictly it binds varies. In Italy, decree 122/2017 requires an agreement between the issuing company and each affiliated merchant, so restricting acceptance by merchant category code alone does not meet the rules. In France, enforcement runs through merchant accreditation held by the CNTR, and the acceptance network is shared across issuers.

Step 3: Settle the licence model

Three routes exist. You hold your own electronic money or payment institution licence. You run the programme under a licensed partner. Or you place it with an institution that already holds the licence and the scheme membership.

The choice drives timelines more than anything else on this list. It also drives who holds customer funds, which in turn determines how much working capital the programme needs.

Step 4: Choose the scheme and the currency

The card scheme decides where the card is technically accepted, and the currency decides whether your employees carry a conversion on every purchase.

Currency deserves more attention than it usually gets. A euro denominated card issued to an employee in a non euro market works, but every transaction converts, and the employee sees it. If the benefit is meant to feel like the value the employer promised, the programme currency should match the market.

Step 5: Design the acceptance rules

At minimum a meal voucher programme needs four controls:

• Category scope. Which merchant categories are permitted. Typically restaurants, fast food and caterers, often extended to bakeries, grocery, dairy and speciality food.
• A daily ceiling. France caps spending at 25 EUR per day, Belgium at 10 EUR per working day.
• Hard exclusions. Alcohol, tobacco, fuel, cash withdrawal and gambling, on every scope, without exception.
• Expiry. Meal voucher value is usually time limited, and unused value has to behave the way local rules say it should.

Some markets add rules that do not map onto a category code at all, such as a limit on how many vouchers may be combined in a single transaction. Italy sets that ceiling at eight.

Step 6: Decide who approves each transaction

This is the step most programmes underestimate, and it follows directly from step 2.

If your rules can be expressed entirely as merchant categories and limits, the issuing platform can enforce them on its own. If they cannot, because the law requires an affiliated merchant list, or because your commercial terms differ merchant by merchant, then the approval decision has to sit with the party that holds that list. That party is you.

The arrangement that supports this is shared authorisation: the issuing platform passes each authorisation request to your system with the merchant category code and the merchant identifier attached, your system applies your own rules and answers approve or decline, and the funds stay held on the platform side. You get merchant level control without having to hold the balance yourself, and without rebuilding a ledger.

The interface detail is documented in the shared authorisation documentation.

Step 7: Plan funding and collateral

Two separate pots, and they are routinely confused.

The programme balance holds the money that employees will spend. Cards carry value only once the employer funds it, which is what prevents anyone spending money that is not there.

The collateral is a separate amount held against settlement risk with the card scheme, sized on transaction volume and growing with it. It is not refundable while the programme runs. For a meal voucher issuer this is usually less painful than it sounds, because the business model already runs on employer prepayments, but it belongs in the plan rather than in a surprise.

Step 8: Plan the roll-out

Issue virtual cards first. They reach employees in minutes, land in a mobile wallet, and remove delivery from the critical path. Physical cards can follow for the employees who want them, without holding up the start date.

For a migration rather than a launch, run both programmes in parallel over one funding cycle. The failure mode in migrations is not the card, it is the merchant list and the employee data arriving in a different shape than expected.

What usually goes wrong

Three failures account for most of the trouble. Designing the acceptance model before answering the affiliated merchant question, which means rebuilding it. Choosing a currency that does not match the market, which turns into a support problem the moment employees notice conversions. And treating the merchant list as reference data rather than as part of the authorisation path, which only surfaces when a transaction is approved that should not have been.

For the country rules behind these decisions, see Italy, France and the calendar of upcoming changes. Verestro builds the card infrastructure underneath programmes like these, with licensed partners; the wider product range is on verestro.com.