Moving money and granting rights are separate systems that fail in separate ways. Across video, investing and payments, I learned to design the bridge between them explicitly.
Dennismary Chidiebere22 August 20255 min read
Operator Notes
Get the next essay in your inbox.
Field notes from building, deciding and carrying the cost of clarity.
A payment succeeds. The money has moved. And the customer still cannot do the thing they paid for.
Every builder who has shipped something that takes money has met this bug, usually in a support ticket at the worst possible hour. The instinct is to call it a glitch: a webhook that arrived late, a flag that did not flip. It is not a glitch. It is the architecture telling you something true: a transaction and the access it is meant to buy are two different systems, and you wired them as if they were one.
I have built this bridge four times now: across a creator video platform, a robo-advisor, wallet infrastructure and cross-border payments. The lesson was the same every time. Treat payment, entitlement and settlement as one thing and you get a system that is fragile in exactly the places that cost you money and trust. Separate them on purpose, and connect them with a bridge you can see, and it holds.
Three systems wearing one coat
Underneath almost any "pay to unlock" feature there are three concerns that people keep squashing together.
Payment is money changing hands. It has its own truth: a charge is captured, a transfer clears, a refund reverses. Its unit is currency, and its hard problems are reconciliation and not doing anything twice.
Entitlement is the right to do something: watch this video, hold this position, enrol this student. Its unit is permission, and it answers a different question entirely: not did they pay but are they allowed, right now.
Settlement is value coming to rest: a creator's payout, an investor's units, an institution's confirmed receipt. It is slow, it is where compliance lives, and it is where "done" is finally real.
These fail in different ways and on different timelines. A payment can succeed while settlement is still pending. An entitlement can be live after a subscription has lapsed if nobody re-checked it. Collapse them into one flow and a failure in any one of them silently corrupts the other two. Keep them apart and each can fail, and recover, without lying to the others.
Separate ledgers, because one balance lies
The clearest version of this is in the ledger.
On the creator platform I designed, money and rights never shared a balance. A wallet ledger pays for content and subscriptions. A separate virtual-gift ledger drives gifting thresholds between fans and creators. They are different kinds of value with different rules: wallet credit is spent on the platform and settled out to creators through payouts; gifting credits are not cash and are never redeemed as cash. Mixing them in one number would make refunds, audits and payouts fragile, because every operation would have to reason about every kind of value at once.
The robo-advisor taught me the same thing from the other side. There, the first fund ledger (tracking units, net asset value and cash) was deliberately kept simple and operator-auditable, so a small team could reconcile every position by hand before scale justified anything heavier. A ledger you cannot reconcile by hand when it is small is a ledger that will betray you when it is large. Separation is what makes that reconciliation possible: each ledger has one job and one definition of correct.
Idempotent events, because the network will betray you
A bridge between systems is a series of messages, and messages get lost, duplicated and retried. If moving money is not safe to repeat, the network itself becomes an attacker.
Building wallet infrastructure for fintechs, where the platform served tens of thousands of API requests a day across partners, this was the non-negotiable. Any call that creates a customer or moves money carries an idempotency key, and that key is persisted before the provider is ever called. A timeout followed by a retry then cannot create a customer twice or send a payment twice: the second attempt recognises the first and returns the same result.
The same discipline runs the other direction, on the events coming back. On-chain and provider events arrive by webhook, get reconciled against the wallet's own history, and only then get forwarded to the partner. The bridge does not trust a single message to be delivered exactly once. It trusts the ledger as the source of truth and makes every event safe to replay against it. Idempotency is not a nicety here; it is the only thing standing between you and double-charged customers.
Check entitlement at the moment of use
Here is the mistake I see most: granting access at the moment of payment instead of the moment of use.
If you flip a permanent "unlocked" flag when a charge succeeds, you have baked a payment event into an entitlement decision forever. Subscriptions lapse. Refunds happen. A gift threshold is a different right from a purchase. The only honest place to decide whether someone may do a thing is the instant they try to do it.
On the video platform, that principle is literally wired into playback. Content is encrypted once; the business decision about who may watch lives in a rights service, and it is consulted at the one moment that matters: when a player asks for a licence to decrypt. The licence callback asks the platform is this viewer entitled to this post right now, and only a yes releases a key. Paying is not the same as being entitled, and being entitled is not the same as being licensed to play. The figure below lets you pull those three apart and watch them disagree.
The Cinema Vault
A vault of encrypted video, a DRM provider that holds the keys, and a rights desk that answers who may watch, so you can set a viewer as paying, entitled or neither and see when a licence is actually issued.
The Cinema Vault
A vault of encrypted video, a DRM provider that holds the keys, and a rights desk that answers who may watch, so you can set a viewer as paying, entitled or neither and see when a licence is actually issued.
A vault of encrypted video, a DRM provider that holds the keys, and a rights desk that answers who may watch, so you can set a viewer as paying, entitled or neither and see when a licence is actually issued.
Interactive figure: The Cinema Vault. A vault of encrypted video, a DRM provider that holds the keys, and a rights desk that answers who may watch, so you can set a viewer as paying, entitled or neither and see when a licence is actually issued.
The Cinema Vault separates paying from entitled from licensed: the encrypted stream reaches everyone, but only a live entitlement check releases a key.
Fig. 1The Cinema Vault. The Cinema Vault separates paying from entitled from licensed: the encrypted stream reaches everyone, but only a live entitlement check releases a key. Open the full exhibit
Checking at the moment of use costs you something: every playback start now depends on the rights service being fast and available. The cheaper path, checking only in the app, is bypassable. When the content is the product, you pay for the stricter path, and you decide that trade-off on purpose rather than discovering it in an incident.
Put compliance in the flow, not after it
The last piece is where money comes to rest. Settlement is where the rules live, and the rules cannot be an afterthought bolted on once the value has already moved.
In cross-border payments (tuition flows now running US$10–15 million, operated as a registered Money Services Business), the compliance logic sits inside the payment journey, not after it. A payment is cleared before it moves, not retroactively inspected once it has landed. That ordering is the whole point. If settlement can complete and then fail its checks, you have built a system that routinely has to claw value back, which is slow, expensive and corrosive to trust. Cross-border payments are a trust business; clear quotes and clean settlement are the product, not the paperwork.
So: separate ledgers so no balance has to lie. Idempotent events so the network cannot double anything. Entitlement checked at the moment of use so a stale payment never grants a live right. Compliance inside the flow so settlement is real when it says it is. Four rules, one idea.
The money moving is the easy half. The hard half, and the one worth designing explicitly, is everything that has to be true for the money to mean something.
Exhibit 05 · Circo
Readout
Stream
DASH · Android and Chrome DRM
Segments
Waiting
Rights answer
Waiting
Content keys
Held by the DRM provider
Playback
Waiting
A protected film waits in the vault. Choose the offer, the viewer and the device.
What happens, step by step
1
The player asks for the post and gets the DASH description of the stream, the format Chrome or Android plays with Android and Chrome DRM.
2
Segments arrive from the CDN, encrypted once with Common Encryption. Anyone can fetch them; nobody can watch them without a key.
3
To decrypt, the player asks the DRM provider for a Android and Chrome DRM licence.
4
Before issuing anything, the provider calls back to the platform: is this viewer allowed to watch this post?
5
The rights service checks the business rule (the post needs a subscription to the creator) and answers play = true.
6
The provider issues a licence with the content key. The player decrypts and the film plays.