Project · VAMED Vitality World
Vouchers guests print themselves
Bought online, printed at home, redeemed at the till. That needed a product type of its own in Magento, a PDF carrying a barcode, and a point of sale that knows the code.
A voucher is a strange product
It is bought like goods but never shipped. It is not used up when it reaches the buyer, only when somebody presents it at the till, and that is often not the same person. A year can pass between the two.
VAMED Vitality World wanted guests to buy a voucher online, print it themselves straight away or pass it on, and have it work at the till in the building.
What was built for it
A product type of its own
In Magento the voucher is a product like any other: price, cart, order. It simply ends in a document rather than a shipment.
A PDF with a barcode
The purchase produces a print-ready PDF carrying a barcode. The barcode is what makes the voucher unique, not the paper it sits on.
Connected to the till
The point of sale has to know the code and be able to redeem it. That is what turns a good-looking PDF into a means of payment rather than a printout.
Print it or pass it on
The buyer prints the voucher immediately or sends it to someone else. No waiting for post, and the person redeeming it need not be the buyer.
There Was Nothing to Copy
Print-at-home vouchers were not a pattern anyone knew at the time. There was no module to buy and no shop to look at to see how it was done. This was Magento 1, and it was the era before REST: an interface was not something you called, it was something you built.
The idea the whole thing rests on is a decision about where the value sits. Not in the document, but in the code. The PDF is only the carrier. Once that is settled, the questions that looked unanswerable resolve themselves: the guest can print it as often as they like, pass it on, or forward it by email. None of that multiplies the value, because what counts is not the sheet of paper but what the till knows about it.
After that, the work was the kind you have to think through in advance. A voucher may sit in a drawer for a year. Whatever produced it has to still recognise it a year later. It must be redeemable exactly once, and that decision is taken at a till inside the building, not in the shop. That is the kind of requirement a system either designs for at the start or retrofits painfully later.
What can be evidenced
The system was in service for more than five years. Exactly when it was built is not recorded in my own files, and how VAMED solves it today I do not know. I hold no figures on vouchers sold.
Why it is here: it was a shop, and an odd one. What it sold is never shipped, and that changes almost everything behind it: the product type, what the order produces, and where and when the thing is redeemed. A shop is not the same thing as sending parcels, and that is work I still do.
Related services
Do you sell something that is not a parcel?
Vouchers, access, appointments, licences: anything sold and not shipped needs logic of its own. Tell me what you sell and what should happen after the sale.