# Paying out shops on your city voucher: from till to bank, with four eyes — MijnEvent [Home](https://mijnevent.nl/en) / [Blog](https://mijnevent.nl/en/blog) / Paying out shops on your city voucher: from till to bank, with four eyes modules stadsbon # Paying out shops on your city voucher: from till to bank, with four eyes A customer pays, the shop deducts the amount — then what? Follow the money: the € 0.05 per redemption, the 'to be paid out' list, payout batches with a SEPA file, and the four-eyes principle. [Jasper Koers](https://mijnevent.nl/en/author/jasper-koers) · 19 August 2026 · 5 min read In short - Every redemption at the till counts towards 'Still to be paid out to shops' in the admin panel straight away — nothing to retype, nothing to keep track of. - MijnEvent charges € 0.05 per redemption. The fee is settled against the shop's payout and passed on by the issuer through the next voucher sale — on balance it costs the issuer nothing. - Payouts run in batches: select the shops, and MijnEvent prepares the self-billing invoices, the summary sheet and a SEPA payment file you import at your own bank. The money never passes through MijnEvent. - The four-eyes principle: whoever creates a payout batch does not submit it to the bank themselves. A second pair of eyes catches mistakes — a wrong amount, an outdated IBAN — before the money is on its way. - It is not a hard requirement: the owner can submit a batch themselves and paying out a single shop manually is always possible. But as a routine it is a clear story towards shops, board and accountant. 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](/en/modules/city-cards) 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](/en/blog/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**: 1. **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. 2. **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. 3. **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. 4. **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](/en/blog/city-voucher-for-your-town). Frequently asked questions ## Frequently asked questions ## Where does the € 0.05 per redemption go and who pays it? The fee is withheld from the shop's payout: the shop receives the redeemed amount minus € 0.05 per redemption, with the breakdown spelled out on its payment specification. The issuing organisation passes the fee on through its next voucher sale — so on balance it costs the issuer nothing. ## Do I have to transfer money to each shop separately? No. You create a payout batch with all shops whose turn it is. MijnEvent puts everything into one SEPA payment file (pain.001) that you import at your own bank — where you approve all payments in one go. ## Is the four-eyes principle mandatory? No. The organisation's owner can submit a batch themselves, and marking a single shop as paid out is always possible — a one-person team stays perfectly workable. But the routine (one person builds the batch, another checks and submits) catches mistakes in time and keeps your books beyond any doubt. ## What if a shop has not entered its payment details yet? Then that shop cannot join the batch. Its outstanding amount simply remains and rolls into a next batch as soon as the payment details are there — nothing evaporates. [ Back to blog ](https://mijnevent.nl/en/blog) MijnEvent ## Read more [ ![](https://regify-mijnevent.s3.eu-central-1.amazonaws.com/blog/covers/deelnemersgegevens-uitvragen-na-de-ticketverkoop.webp) attendee details MijnEvent · 17 August 2026 · 13 min read ## The tickets are sold — and half your attendees are still a blank Dietary needs, company names, weights: the details you only need after the sale rarely arrive on their own. Here is how to collect them without making eighteen phone calls. ](https://mijnevent.nl/en/blog/collecting-attendee-details-after-the-ticket-sale) [ ![](https://regify-mijnevent.s3.eu-central-1.amazonaws.com/blog/covers/van-ideal-naar-wero-wat-verandert-er-voor-je-ticketverkoop.webp) payments MijnEvent · 17 August 2026 · 7 min read ## From October your iDEAL payments run on Wero: what organisers need to know In July the Dutch Payments Association announced the next step in the move from iDEAL to Wero. Your visitors will not notice a thing, and you probably will not either — but there are three things worth checking now. ](https://mijnevent.nl/en/blog/ideal-becomes-wero-what-changes-for-ticket-sales) [ ![](https://regify-mijnevent.s3.eu-central-1.amazonaws.com/blog/covers/controleur-worden-app-installeren-en-testen.webp) steward Jasper Koers · 15 August 2026 · 6 min read ## Scanning at the gate: install the app, prepare and test it together You have been asked to scan tickets. Four steps get you ready: install the app, sign in with the code from your e-mail, download the event for offline use and test with a colleague that the same ticket really does turn red on the second phone. ](https://mijnevent.nl/en/blog/steward-at-the-gate-install-prepare-and-test) MijnEvent ## Ready to get started? Create a free account and sell your first tickets today. [Start free](https://mijnevent.nl/registreer) [Pricing](https://mijnevent.nl/en/pricing)