Can a lunch card check our own merchant list rather than a category code?

Yes. The authorisation request carries the merchant category and the merchant identifier, and your own service answers it on your own rules before the payment is approved. The funds stay with the issuing platform, so you make a decision rather than hold money.

When is a merchant category code not enough for a meal voucher card?

Where the law requires a contract between the issuer and each accepting merchant, which is the case in Italy, France, Greece, Luxembourg and Romania among others. It is also insufficient where two different ceilings apply to two types of merchant, as in Austria, because the limit cannot be applied until the merchant type is known.

How hard is it to run the same programme in several countries?

Each country is a set of rules rather than a separate build. Ceilings are daily in some markets and monthly in others, some count only days actually worked, and some add geographic conditions on the merchant. Adding a country means writing its rules on a platform that is already live.

Meal vouchers in Europe Acceptance rules that are yours, not the network's

Acceptance rules that are yours, not the network's

Most benefit cards can only say yes or no by merchant category. That is enough in some markets and not enough in others, and the difference decides whether your programme is compliant. We let the acceptance rules live with you, so the card checks your list, your ceiling and your conditions before it approves anything.

The two ways a card can decide

	Category only	Your own rules
What it checks	The merchant category code	Category, merchant identifier, your list, your limits
Who holds the logic	The issuing platform	You, through an API call on every authorisation
Good enough in	Germany, Spain, Poland and similar	Italy, France, Greece, Luxembourg, Romania and similar
Changing a rule	A platform configuration change	Your code, your release, same day

Both are real products and both are supported. The first is simpler and cheaper to run. The second exists because several European markets require a contract between the issuer and each accepting merchant, and a category code cannot express that.

The decision happens inside the authorisation, which is why a meal voucher card behaves differently from an expense card that checks receipts later.

What happens in the moment

The employee taps. Before the payment is approved, the authorisation request arrives carrying the merchant category and the merchant identifier. Your service answers, on your own rules, and the payment is approved or declined. The funds stay on our side throughout, so you are making a decision rather than holding money.

That single call is the whole product. It is why an ordinary payment card, running on an ordinary network with ordinary reach, can carry a benefit whose rules were written for a closed loop scheme.

Why a category code is sometimes not enough

Austria is the shortest example. A meal benefit there is worth 8 euro a working day in a restaurant and 2 euro a working day in a grocery shop. Two separate ceilings, not one allowance, so the daily limit cannot be applied until the type of merchant is known.

The two amounts are not a single ten euro allowance. They are separate ceilings, and a card can only apply them if it can tell a restaurant from a shop before it approves the payment.

Hungary is the other kind of example. Cold food in supermarkets became payable with a benefit card on 1 December 2025 and stopped on 30 April 2026, both by regulation. Nothing about the card changed on either date. A programme whose acceptance scope is a rule it can edit handled that with a configuration change. A programme with the scope built into the product needed two releases in five months.

One platform, seventeen sets of rules

If you run a programme in more than one country, the differences are not cosmetic. The ceiling is daily in France and monthly in Poland. Spain counts only days actually worked. Italy limits how many vouchers may be combined in a single transaction. Luxembourg requires the merchant to be established in Luxembourg, which is a geographic test on top of a category one.

Each of those is a rule, and rules are the thing this product is made of. Adding a country means writing its rules, not rebuilding the programme. The country rules section sets out what applies in each of the seventeen markets we cover.

Not sure which model your market needs? That is the first thing we tell you.

Book 15 minutes

What it costs and how long it takes

Acceptance rules are part of the platform rather than a separate product, so there is no additional licence for them. What varies is the integration: running your own decision service is more work at the start than handing us a category list, and it is the reason to do it only where the market requires it or where the control is worth something to you.

One week from decision to the first card, and two in unusual cases, which for this product usually means an acceptance rule that has to be built rather than configured. Adding a country afterwards is shorter still, because only the rules change.

Where to read further

How a meal voucher card works follows the full authorisation path and the four controls every programme needs. Open loop or closed loop answers the architectural question this page assumes. If you want to know what your own market demands before deciding anything, start with the country rules.