A marketplace state you can inspect.
Every important transition has a defined actor, prerequisite, payment truth, failure state, and audit record.
1. Verify the individual robot
The seller proves identity and control of the specific robot. Manufacturer availability is source context, not ownership evidence.
2. Publish exactly ten spots
Prices, placement duration, public-use context, safe areas, and seller-decision time are fixed before publication.
3. Reserve atomically
The server locks one spot in one short database transaction. A partial unique index is the final double-sale barrier.
4. Pay the seller
Stripe Checkout runs on the connected seller account. BrandMyHumanoid sets no application fee on the spot purchase.
5. Approve or reject artwork
The seller reviews the brand and sanitized artwork. Authentication, ownership, and expected payment state are checked again.
6. Refund before reopening
A rejected spot stays locked until Stripe confirms the full refund. Pending or failed is never shown as refunded.
7. Apply and prove
Approved artwork is applied safely and a moderated proof derivative becomes public. Originals remain private.
No success-by-redirect.
A Stripe success URL is only navigation. The order becomes paid only after signature-verified webhook evidence or direct reconciliation matches object ID, seller account, amount, currency, environment, and expected prior state.
Checkout expiry also comes from Stripe. A local clock alone cannot free scarce inventory.
Physical visibility without reach theatre.
- No guaranteed impressions or clicks.
- No endorsement by the seller or manufacturer.
- No promise of press coverage, sales, or ROI.
- No claim that the robot runs continuously.
- No placement over sensors, joints, controls, or required markings.
Have a real humanoid and a real public context?
Build the ten-spot draft before connecting payments.