Release 26.1.3, "Voucher Portal (MVP)", gives the Studio a new area, "Vouchers", where an organisation runs its voucher programme: its partners, its voucher offers and the codes behind them. Frontends, such as a Community Portal or an app, keep showing the offers as their own content. The Studio decides which code a member gets and how often, the same way on every frontend that redeems through it. This post walks through the highlights, with Pannoniqa AG, the fictional organisation of our documentation. The changelog entry lists every change.
Partners and voucher offers
Pannoniqa's staff get discounts at a thermal bath, a bike shop and a bookshop. Each of these businesses becomes a partner in the Studio, with its contact persons and a redemption address for members' messages. Thermalbad Pannonia, for example, has its own address for vouchers, while Radwerk Graz has none, so messages about it go to the default redemption address in the voucher settings.
Every deal is a voucher offer: "Spa day, 20 % off" at Thermalbad Pannonia, valid from the first to the last day you choose. An offer starts as a draft and gives out codes only once it is active. If the bath closes for a week of maintenance, "Pause" stops the offer at once on every frontend, and "Activate" brings it back. "End" is final, for a deal that is over.
The redemption limit says how often one person may redeem an offer: once, a number of times per calendar month or year, or as often as they like. It counts across all frontends. Pannoniqa allows the spa day four times per calendar year, so a member who redeemed it four times in the Pannoniqa App cannot redeem it a fifth time on another of Pannoniqa's frontends. Vouchers explains the terms, and Create a voucher offer walks you through the form.
A code of their own for every member
Some partners give one code that every member uses. Others want to know which voucher went to whom, and supply a list of unique codes. For those, a voucher offer now takes a voucher pool.
Thermalbad Pannonia sends Pannoniqa a file with the codes for "Sauna evening for two". A voucher manager imports it into the pool "Spring delivery 2026". Before anything is stored, a preview counts the new codes, the duplicates and the invalid lines, each with its line number. From then on, every member who redeems gets a code of their own, and no code is ever given out twice.
The pool's page shows how many codes are available, issued, withdrawn or expired. When the stock reaches the pool's low-stock threshold, and again when it is empty, the benefits alert address gets an email, so there is time to ask the bath for the next delivery. If the bath recalls part of a delivery, the voucher manager withdraws those codes, one by one, by a filter or by a list. Voucher pools has every step.
Codes stay out of sight: the lists of voucher offers and pool codes show only their first three characters, and showing a pool code in full is a click that the Studio records.
The redemption office sees every redemption
Every code a member is given is a redemption, with a reference starting with RD- that the member can quote. Pannoniqa's redemption office finds them all under "Vouchers", "Redemptions": the code, the member, the frontend, and what the member was shown on the page at that moment. The office keeps track with a status, from "Open" to "Done" or "Cancelled", and a note the member never sees.
The member gets their code by email too, in Pannoniqa's branding and in the language they read the page in. Where the page offers it, they can write to the partner once about their redemption, and the Studio sends that message with their code to the partner's redemption address. If the office wants a copy of every redemption, it switches that on in the redemption settings.
Redemptions follow the same privacy rules as the rest of the Studio. When a membership is anonymized, the member's redemptions are anonymized with it, and every redemption is deleted 7 years after its last status change. Redemptions and Handle a redemption describe the office's work.
Redeeming on any frontend
Frontends redeem through the Studio's Service API. They learn whether an offer can give a code right now, but never how many codes are left. For a signed-in member, the Studio checks the membership at the moment they redeem, so a person who has left the organisation gets no code.
A frontend whose own server checks who it redeems for can also redeem for people who are not signed in, such as a member who proves their membership with their member code. That is off for every frontend until you switch it on under Guest access.
The Community Portal is getting ready for this. Portal editors can already link a Benefit to its voucher offer in the Studio, and the Benefit's codes can then be changed in the Studio only. Members on the Portal keep redeeming from the Benefit's own fields until the Portal redeems through the Studio, with a later release.
Try it out
In the Studio, the "Vouchers" group of the sidebar shows for owners and administrators, and for the Studio users you give the permission set "Voucher manager" or "Voucher viewer", or a permission set that holds "Redemptions: manage". Why benefits and vouchers matter so much to a portal is the subject of Benefits people use: why community portals beat another communication channel. The changelog entry for 26.1.3 lists every change. If something does not work the way you expect, let us know.