The commission that must not mint twice

On the creator marketplace a sale works like this. A creator shares a tracking link, a buyer taps it and pays, and the platform writes a commission entry into a ledger, where it sits for thirty days before it is paid out. The entry is minted by a server function that the checkout calls once per cart line after the payment has succeeded. The processor's webhook does not mint anything; it writes an audit row. That ordering has consequences, and most of this note is about them.

Three ways to mint a commission nobody is owed

The first is the direct call. The mint is a function any signed-in client can invoke, so without a check anyone could call it with an invented sale amount and a link code they never earned. Every caller must therefore present a payment intent id, and the function verifies it with the processor before doing anything else: the intent exists, its status is succeeded, its metadata names the caller as the buyer, and the sale amount being claimed is not more than the amount actually charged. The comment above those checks says what they close: direct-call commission minting, a fake sale amount or an unearned tracking code.

The second is collusion. A brand and a creator who are in it together could make a genuine purchase of a cheap product and then call the mint with the tracking link for an expensive one. The payment is real, so the checks above pass. The function has to prove that this payment bought this product, and it does so by looking up the platform's own order records: same payment intent, same buyer, same product. No matching record, no commission. The comment names the attack in one sentence, a colluding pair round-tripping a purchase of product X to mint against a link for product Y, which is the kind of sentence that only gets written by someone who has sat and thought about how they would rob their own platform.

There is a nuance worth stating. The proof reads the platform's records, not the processor's line items. That is sound only because those records are written server-side, when the order is created, under document ids derived from the payment intent and a line index. The client cannot choose those ids and cannot write those documents, so a record that matches is a record the server put there.

The third is the ordinary one: the same mint arriving twice. A retried request, a double tap, two tabs. The first version of the function checked the ledger for an existing entry and then added one. That is the order everybody writes it in, and it has the hole everybody's version has: two calls for the same sale a few milliseconds apart both pass the check and both add an entry. The fix is a deterministic document id and a create rather than a set. Create fails if the document already exists. The second call catches that specific error, logs it, and returns success with a flag saying the commission was already processed. No transaction, no lock: the database's create-or-fail is the lock.

Which id

The obvious key is the payment intent id, and it is wrong. A multi-item cart on the web checkout shares one payment intent across every item, so keying the ledger on the intent would mint the first item and refuse the rest as duplicates. The comment in the code says exactly that. So the key is the transaction id, which is unique per cart line because it is the intent id with the line index appended; the mobile app, which sells one item per order, does not pass one and falls back to the intent. It is a small decision and it is the difference between a cart that pays creators and one that quietly pays only the first of them.

The small things beside it

The commission rate is capped at whatever the brand set on the product, because a creator can write an inflated rate onto their own collaboration record and the platform must never trust that number above the brand's. The team split is clamped to between zero and one hundred, because a tampered link could carry a split over a hundred and make the team leader's share negative. And a sort-order bug was caught in a comment: document names sort line ten before line two, which would have handed the tenth item's commission call the second item's record, so the lines are sorted numerically before anything is aligned. None of these is clever. All of them are the sort of thing that is only found by reading the money path as one piece.

What it costs

The mint is called from the checkout, and the checkout is not allowed to fail because of it: a mint error is caught and the buyer completes their purchase. That is the right trade, buyer over bookkeeping, and it means a creator's entry can be missing until someone notices. The proof of purchase is against the platform's own records rather than the processor's line items, which is a dependency on the order-writing code staying honest. And the race was closed a month after the collusion check landed, in the same pass that hardened the payout path; the summer of 2026 was spent finding these, one at a time.

Why it belongs on this page

This is the same shape as the webhook decision on the payments platform, described in its own note: derive the id from the event itself so a retry collides with its own first attempt instead of being treated as new. Two platforms, two databases, one idea, and the fact that it was recognised as the same idea the second time is the thing this site is trying to show. That happens when one person owns both ledgers.