Meal vouchers in Europe / How a meal voucher card works

How a meal voucher card works

A meal voucher card works like any other payment card until the moment of authorisation. At that moment the programme checks three things: is this merchant allowed, is the amount inside the daily ceiling, and does the card hold enough value. If any answer is no, the payment is declined at the till rather than corrected afterwards. Everything else about the product follows from that one design decision.

Last reviewed: 28 August 2026. Written for anyone specifying, buying or migrating a meal voucher programme.

The four parties

Every card based scheme has the same cast, whatever the country calls them.

• The employer funds the benefit and decides how much each employee gets.
• The employee holds the card and spends it on food.
• The merchant accepts it and gets paid.
• The issuer sits in the middle, holds the money until it is spent, and enforces the rules.

Where schemes differ is who the issuer has a contract with. In some markets the issuer contracts every accepting merchant directly. In others it relies on a shared national accreditation and never signs a merchant at all. That single difference drives most of the product design, and it is the subject of open loop or closed loop.

What happens during a payment

An employee taps the card in a bakery. Within a second or two, the following happens.

1. The merchant's terminal sends an authorisation request to its acquirer, and from there to the card network.
2. The network routes it to the issuer of the card, carrying the amount, the merchant category code, an identifier for that specific merchant, and the country.
3. The programme applies its rules to those fields.
4. An approve or decline goes back the same way, and the terminal prints or refuses.

Two fields in step two do the heavy lifting, and they are not the same thing.

Merchant category code

The category code says what kind of business this is: 5812 for a restaurant, 5411 for a supermarket, 5462 for a bakery. It is assigned when the merchant is onboarded by its acquirer. It is a coarse instrument, but it is universal, and for a scheme whose rule is simply "food only" it is enough.

Merchant identifier

The identifier points at one specific merchant rather than a type of merchant. Where the law says an employee may only pay at merchants that have a contract with the issuer, this is the field that matters, because a category code cannot tell a contracted bakery from an uncontracted one.

The four controls every programme needs

Whatever the market, a meal voucher programme has to enforce at least these:

Austria shows why the first control carries the others. An Essensgutschein is worth 8 EUR a working day in a restaurant and 2 EUR a working day in a grocery shop. These are two ceilings rather than one allowance, so the daily limit cannot be applied until the merchant type is known. The acceptance scope does not merely restrict spending there, it selects which ceiling exists.

Some markets add rules that do not fit any of these boxes. Italy limits how many vouchers may be combined in one transaction, to eight. Spain counts only days actually worked, so weekends, holidays and leave do not accrue entitlement. Rules like these have to live somewhere in the programme logic, and they are the usual reason a generic prepaid platform turns out not to fit.

Who decides whether the payment goes through

There are two arrangements, and the choice is not cosmetic.

The issuing platform decides. The programme's rules are loaded onto the platform as categories and limits, and it answers every authorisation on its own. This is simple, fast and adequate whenever the rules can be written as "these categories, this ceiling".

The programme owner decides. Each authorisation request is passed to the operator's own system, which applies its own logic and answers approve or decline. This is the arrangement you need when the rule depends on a list of named merchants, when commercial terms differ merchant by merchant, or when the operator already runs the merchant database and is not going to duplicate it.

Where the money sits

The employer funds the programme, and value reaches cards only after that money settles. That ordering is what makes it impossible for an employee to spend a benefit the employer has not paid for, and it is also why funding cycles matter more in this product than in ordinary expense cards.

Separately, a card programme carries collateral against settlement risk with the card network, usually sized on a few days of transaction volume and growing with it. For a meal voucher operator this is rarely a shock, because the business already runs on employer prepayments, but it belongs in the financial model rather than in a late surprise.

Virtual and physical cards

A virtual card can be issued in minutes and added to a mobile wallet immediately. A physical card has to be produced and posted. Most programmes now issue virtual first and treat plastic as optional, which takes card production off the critical path and lets a programme start on the date the employer wanted rather than the date the post arrives.

For migrations this matters more than for launches. When paper is being retired to a deadline, as in France from February 2027, the constraint is how fast employees can be activated, not how fast cards can be printed.

Next: whether your market allows an open loop card, or the country rules for Italy, Germany, Austria and Spain. If your market is not listed, it may be one of the countries with no scheme at all.