What a Bullmark voucher is

A Bullmark voucher is one row, held by one person, that says: this holder may buy this product of yours at this price, until this date.

Three properties follow from that, and they are the ones worth knowing before you write any code.

It is per-holder, not a coupon code you print

Each voucher is a distinct record with its own redeem code and its own serial number. Two customers never hold “the same” voucher. When one changes hands, the old row closes and a new one opens in the new holder’s name, linked to the old one — so “who holds voucher #37 right now” has exactly one answer, for the whole life of that number.

This is why there is no “how many uses left” field. A voucher is used once, by the person holding it.

It is single-use, and it burns when YOU say so

Redemption is two steps:

the holder reserves it — the voucher is locked, and nothing is spent;
you confirm you gave them the price — and that is when it burns.

A holder cannot do step 2. That is deliberate: if they could, “redeemed” would mean “somebody clicked a button”, and every number built on it — including what we pay referrers — would inherit that doubt.

It is sealed

Issuance, every change of hands, and the redemption are events on an append-only chain, hash-linked and anchored. You can verify that chain yourself without taking our word for anything.

What you are agreeing to

When you accept a voucher, you are agreeing to give that holder priceUsd instead of retailPriceUsd. Two fields decide the shape of that:

`benefitMonths`

How many months the discounted price runs for.

`productKey`

Your own key for the product (plan.pro, addon.seats, whatever your system calls it), carried on the listing so we can hand it back to you.

Match on this, never on productName. The display name is something a marketer can change between the moment a voucher is issued and the moment it is presented.