Why Kuvert never holds the money

A gift card is a strange product to build a platform around. Somebody pays in November, somebody else eats in March, and for the four months in between the money has to be somewhere. The first real decision on Kuvert was where that somewhere is.

The easy answer is a platform account. Every sale lands with the platform, the platform keeps a ledger of what each business is owed, and it pays out on a schedule. It is how a lot of gift card services work, and it is the answer I said no to on the first day.

Holding money is a business of its own#

A platform that collects customers' money and owes it to somebody else later is holding funds. Rules for electronic money are written for exactly that situation, and they come with capital requirements, safeguarding and supervision. That is a fine business for a company built to do it. It is a strange thing for a two-company partnership in Vejle to take on by accident, because it seemed simpler to route the payments through one account.

It is also a trust problem that no amount of copy fixes. A restaurant owner selling a gift card should not have to wonder whether the platform will still exist on the day the card is spent.

Direct charges#

So Kuvert uses Stripe Connect with direct charges. Each business has its own Stripe account, connected to Kuvert. When a guest buys a card, the payment is created on the business's account: the money lands in their balance, on their payout schedule, under their name on the guest's bank statement. Kuvert takes an application fee on the charge and nothing else.

There is no float. If Kuvert went dark tomorrow, every krone that has been paid is already with the business that sold the card.

It also settled the payment methods. Danes buy gift cards with MobilePay, and a gift card shop without it loses a large share of its buyers at the last step. MobilePay, cards, Apple Pay and Google Pay all run through the same Checkout on the business's account, so none of them needed a second integration.

A refund is not a chargeback#

The model gets interesting when money goes backwards, because there are two ways it can happen and they must never be treated as one.

A refund is the business choosing to give money back. The card is voided, the money returns, done.

A dispute is the buyer's bank taking the money back. The bank does it on the day the dispute is filed, the case can run for weeks, and the fee is not refunded even if the business wins. Treating that as a refund would be wrong in both directions: void the card and the business has lost a sale it might win back; leave it active and the card can be spent while its money is gone.

So a dispute freezes the order's cards and seats instead. Frozen is the only reversible state either of them has. When the dispute closes, a win thaws them and a loss drains them like a full refund. The thaw is scoped to frozen cards on purpose, so winning a dispute can never bring back a card the business voided by hand in the meantime.

One detail took a while to see. When a dispute is lost, Stripe takes the whole charge from the business and leaves the platform's fee where it is. Without a correction, the business pays us commission on a sale its customer's bank reversed. So a lost dispute also refunds Kuvert's fee. It is a small amount on each case and exactly the kind of thing a business notices on a statement and never forgets.

The failure mode here is silent, which is the worst kind. If the two dispute events are not subscribed on the Stripe endpoint, none of this runs and nothing reports it. That line is in the deployment runbook, where the next person will read it before they need it.

The law is not the fee#

The last piece is cashing out. Under the Danish payment act, § 96, the holder of an electronic gift card can ask for the remaining balance back for the card's validity plus a year. Kuvert lets a business charge a small, capped fee for doing that while the card is valid, and after it has expired the rules allow no fee at all. Both halves live in one function, so the dashboard, the API and the receipts cannot disagree about what a business may charge.

It would have been easy to write "legal requirement" next to every limit in the product and let the words do the work. I kept the two apart instead: what the law says, cited where it applies, and what Kuvert chooses on top of it, named as our own rule.

What it cost#

Direct charges are more work than a platform account. Every business needs its own Stripe onboarding before it can sell anything, refunds and disputes have to be handled on accounts we do not own, and reporting has to be assembled across all of them.

It is still the right trade. The money a guest pays for a dinner in March belongs to the restaurant from the second the card is bought, and the platform in between should never be the reason it is late.