Why redemption is two steps

Until August 2026, redeeming was a flag the holder set. They pressed a button on their voucher page, the row said Redeemed, an event was sealed — and nothing else happened. The brand’s system never learned anything. The customer never got the discounted price.

The voucher carried a claim about a price and there was no counter to present it at.

The rule

The voucher burns at the moment the brand says it gave the value — in the same transaction.

This is the rule the voucher marketplace already ran on: a listing moves nothing; the payment confirmation IS the hand-over. It exists because splitting the two makes “the money moved but the voucher did not” a state that really happens, and no amount of sealing repairs that afterwards.

So:

holder   reserve   → the voucher is locked. nothing is spent.
brand    confirm   → it burns, the event seals, the referrer is paid.
either   release   → the payment failed. it comes back, unspent.

Why the holder cannot confirm

Two reasons, and the second is the load-bearing one.

It was never true. A holder pressing a button has not received a discount; they have announced an intention. Recording that as “used” makes the word mean nothing.

A referrer is paid on redemption. If the holder can confirm, then the person holding a referred voucher can pay their own referrer with one click, and every number built on redemption — including the ratings on /discover — inherits that doubt. The claim “the platform cannot cook these numbers” is only worth making if the numbers cannot be cooked by anyone.

What this costs a brand that integrates nothing

Nothing. There is a screen we host where someone types the code in, and it lands in exactly the same place as an API call. That screen existing is what made it possible to close the holder’s path at all.