A customer pays with the city voucher, the shop scans the QR code and deducts the amount — then what? For the issuing organisation the real work starts there: making sure every shop gets its money, correct to the cent. The instruction video above follows that entire path through the admin panel of the City cards & vouchers module; this article walks through the steps.
What happens at the moment of payment
At the till, the shopkeeper scans the voucher's QR code (or the physical pass), sees the available balance and deducts the purchase amount. Double redemption is technically impossible: the balance is debited and recorded in a single move. The voucher holder immediately receives an e-mail about the deduction, the remaining balance stays on the voucher and updates everywhere — including the wallet pass.
For you as issuer, something important happens in the admin panel at that same moment: the redemption appears on the Overview tab and immediately counts towards the tile "Still to be paid out to shops". Nothing to retype, no till receipts to collect, no spreadsheet to maintain. What the till side looks like for the shopkeeper is covered in Redeeming a city voucher as a shop.
The € 0.05 withheld per redemption
MijnEvent charges € 0.05 per redemption. Those five cents are not collected separately but settled against the payout: a shop that deducted € 32.50 receives € 32.45. The payment specification spells out that breakdown — gross redeemed, number of redemptions, platform fee withheld, net paid out. So the shopkeeper sees exactly why the amount differs a fraction from the till receipts.
And the issuer? They pass the accumulated fees on through the next voucher sale — the admin panel shows this as "Outstanding — withheld from your next voucher". On balance the fee costs the issuing organisation nothing: it weighs on the payout to the shop, not on your own cash.
From 'to be paid out' to a payout batch
The Shops tab shows, per shop, what has been redeemed and what is still due — always as "redeemed amount minus the MijnEvent fee". The actual paying out happens on the Payouts tab, and runs in batches:
- Select the shops whose turn it is. A shop without payment details cannot join; its amount simply remains and rolls into a next batch automatically.
- Create the batch. MijnEvent records the payout per shop (with a snapshot of IBAN and account name), prepares a self-billing invoice or payment specification per shop plus a summary sheet, and e-mails every shop that its payout is on its way. Every batch gets its own reference, such as STB-2026-0007.
- Download the SEPA file. One payment file (pain.001) with all transfers in the batch. Because it contains account numbers, MijnEvent asks for a fresh code from your authenticator app right before the download.
- Import the file at your own bank and approve the payments there.
That last step is a deliberate choice: the money never passes through MijnEvent. We prepare the payment instruction, the documents and the bookkeeping — the actual transfer is done by you, at your own bank. Of the file itself MijnEvent only keeps a checksum, so you can prove afterwards that the downloaded file was submitted unchanged.
The four-eyes principle: why, and how strict is it?
Submitting comes with a clever safeguard: whoever created the payout batch cannot mark it as "Submitted to the bank" themselves. Another team member with payout permissions has to do that. This is the four-eyes principle, and it exists for two reasons:
- A second look catches mistakes. A wrong amount, a shop that should not be in there, an outdated IBAN — it gets noticed before the file goes to the bank, not after.
- Nobody handles the money alone. One person assembles, another checks and submits. Combined with the activity log, which records every step, that is a clear story towards shops, board and accountant — your books are beyond any doubt.
Good to know: it is not a hard requirement. The organisation's owner can submit a batch themselves — so a one-person team stays perfectly workable — and marking a single shop as paid out manually, outside the batches, is always possible. In those situations the bank's own authorisation and the activity log carry the checks. But if you work with more people, following the routine is simply the smart move: it costs nothing extra, and it keeps you a step ahead of awkward situations — from a simple typo to uncomfortable questions afterwards.
Reconciled: full circle
Once the bank has processed the payments, you set the batch to "Reconciled". The outstanding amount on the Overview goes down, the paid amounts add to "Paid out", and every shop already has its specification in the mail. If a single transfer fails (a closed account, say), you mark just that line as failed — its redemptions automatically roll into the next batch.
And that closes the circle: from the till in the shop to a reconciled batch at the bank, with every cent accounted for and every step on record. Want to know more about issuing your own voucher? Read Issuing a city voucher for your town.
