The problem with sending somebody a code

A voucher code is bearer value written in plain text. Whoever has the string has the money.

That is fine when it travels from one person to one person. It is not fine in a group chat, in a photograph taken over a shoulder, or in a message forwarded once too often.

What goes wrong with a plain code

The usual story: a code is posted somewhere slightly too public. Somebody who was not the intended recipient redeems it. The intended recipient finds an expired code and a conversation nobody can resolve, because there is no record of who used it.

The code did its job perfectly. The job was simply never a safe one.

A claim on the ledger

Here, a voucher is recorded as a claim on the issuer — a posting, not a flag in a table.

Issuing it is a posting. Redeeming it is a posting. Both exist in the books, which means both can be examined later.

Redeemed once, visibly

Redemption is single-use. A second attempt is refused, not silently ignored, so the person attempting it sees that it has already gone rather than wondering whether the app is working.

And the record shows when it was redeemed and into which account.

That does not undo a code posted in the wrong place — bearer value is bearer value — but it turns somebody took it and we will never know into a traceable fact.

Send it to a person

The practical advice is dull and worth repeating: send a voucher to one person, in a message to that person.

Not a group. Not a photograph. Not a caption. The security of a bearer instrument is entirely a matter of who can see it.

Promotional value is not your money

Worth explaining, because it is the kind of accounting distinction that matters enormously and is invisible from outside.

Credit the platform gives you as a promotion is a marketing liability of the platform. Money you put in is a redeemable claim backed by safeguarded funds.

They are tracked separately. Counting them together would overstate what customers are owed and understate what has to be backed — and a platform that blurs them is a platform whose backing figure cannot be trusted.

What it costs

Issuing is priced in the dashboard before you create vouchers. Redeeming into a balance is free to the holder.

What you can check

These are facts about the running platform, not adjectives. Each one is visible in the product, in the API reference or in the ledger.

• A voucher is recorded on the ledger as a claim, so issuing it and redeeming it are postings rather than a database flag.
• Redemption is single-use: a second attempt is refused rather than silently ignored.
• The redemption record shows when it was redeemed and into which account.
• Promotional value is tracked separately from customer e-money, because a marketing liability is not a redeemable claim and must not be counted as one.

What it costs

Issuing is priced in the dashboard before you create vouchers. Redeeming into a balance is free to the holder.

Is it switched on?

Whether this is available depends on the authorisations in place and on what the administrator of a given deployment has switched on. That changes, and an article does not — so the live answer lives on the feature page, which reads it from the platform itself: Gift cards and vouchers on the features page.

Read next

• Wallets and transfers — Money that arrives the moment it leaves.
• E-money and safeguarding — Every balance is backed, by construction.
• Referrals and growth — Paid for customers, not for clicks.