commission_rate: the field the vendor could edit.
FIELD CHANGE · COMMISSION RATE · MULTIVENDOR MARKETPLACE · PAYOUTS
General notes
- 01The platform's cut lived on a field the vendor's own settings screen could write to. Nothing needed hacking.
- 02Vendors optimise their cut, not yours. The field was an invitation, and I had written it.
- 03Economic policy is not user data. Rev B: an admin-owned table with caps. The vendor screen lost the write path.
I wrote that field.
Schedule of permissionsOne field, two revisions
| Rev | Field | Owner | Writable by |
|---|---|---|---|
| A | commission_rate | Platform policy | Vendor settings screen |
| B | commission_rate | Admin table, capped | Admin only |
As posted
The field was called commission_rate. Sensible name. One problem: the vendor's own settings screen could write to it.
Nothing needed hacking. Anyone who opened their store settings could see the number that decided how much of each sale they kept, sitting in an editable field. I had written that field.
The lesson does not need a villain. Vendors optimise their cut, not yours, and a writable field is an invitation whether or not anyone accepts it. We found it in a pre-launch audit, before it cost anyone anything.
The fix was barely technical. Economic policy is not user data. The rate moved to a table only admins own, with caps, and the vendor screen lost the write path. Rev A had the number where the vendor could reach it. Rev B has it where only the platform can.
It is the same finding as the delivery distance on sheet 003, through a different door. There, the party who benefited from a number supplied it. Here, the party who benefited from a number could edit it. Whoever benefits from a number must never be the one who sets it.
Sheet 012. Field change, recorded.