Rentals, purchases and tickets to a live event
A viewer who will not take a subscription will often pay for one film or one match. The platform has a complete path for that — a price resolved server-side, a window that expires, and a settlement that cannot double-charge.
Three things can be bought once
A title can be rented, which grants access for a window measured in hours and then stops. A title can be bought outright, which grants access with no expiry. A live event can be ticketed, which grants access for the window the event itself defines. All three are the same code path with different answers from the service that owns the item.
Prices are columns on the item, not constants in the platform. A title carries a rental price and a purchase price in taka, an optional pair in dollars, and a rental window in hours, all editable through the admin write path. A title with no rental price set is refused rather than defaulted to zero — a zero-priced checkout would hand the film out for nothing, which is the kind of default that is discovered by an audience rather than by a test.
An event that has already finished cannot be ticketed. The check happens before the payment session rather than at the entitlement gate, because taking money for access that can never be used is the failure worth preventing rather than detecting.
What happens at checkout
Five steps, and the reason each one is there.
The request names an item, never a price
A checkout says which title or event and what is being bought. It does not say what that costs, so a client that posts its own amount changes nothing.
Anything already owned is refused
The platform checks whether this account can already watch this item and returns a conflict if so. Without that step, a viewer who double-submits pays twice for one rental.
The price and the window are resolved server-side
Billing asks the service that owns the item — the catalogue for a title, the live service for an event — immediately before the payment session is created, over HTTP rather than by reaching into another service's database.
A pending record is written, then the gateway session opens
The pending row is kept even if the gateway call fails, because it is the record that a checkout was attempted and it is what lets a later callback still settle it.
Settlement happens once, under a row lock
The payment notification settles the purchase inside a locked read, so one validated payment settles at most one transaction. A verification playbook reads the deployed source and fails if that lock is missing.
What the path covers
| Capability | Status | Detail |
|---|---|---|
| Rent a title, with an expiry window | Built — commissioned at deployment | Window from the title's own hours column; 48h fallback |
| Buy a title outright | Built — commissioned at deployment | No expiry; refused if no purchase price is set |
| Ticket a live event | Built — commissioned at deployment | Priced and windowed by the event; finished events refused |
| Per-title prices, editable | Shipping | Real columns on the catalogue with an admin write path |
| Double-purchase protection | Built | Existing entitlement returns a conflict before checkout |
| Idempotent settlement | Built and verified | Row-locked; asserted by a verification playbook |
| Entitlement read-back | Built | Per item, and a purchase history per user |
| Refunds and chargebacks | Not built | No refund path exists in billing |
| Gifting, bundles, season passes | Not built | No code anywhere |
Questions
Can a subscriber also buy a pay-per-view event?
Yes. A subscription entitlement and a purchase entitlement are independent grants and playback asks both, so a subscriber buying a match is a normal case rather than an edge one.
What happens when a rental expires?
Access stops because the expiry timestamp has passed. Entitlement is a comparison against that date rather than a flag a job has to clear, so there is no window in which an expired rental keeps working.
Can I refund a purchase?
Not through the platform today — there is no refund path in billing. A refund is issued at the gateway, and reconciling that back into the entitlement is a build.
What exactly is outstanding before I can sell a ticket?
One database migration creating the purchases table. The application code, the pricing resolver, the double-purchase guard and the locked settlement are deployed and verified; the schema for the table they write to is not in the repository, so it is created as part of commissioning.
Selling a match or a premiere?
Event ticketing is the one that usually has a date attached. Tell us the date and we will tell you what has to be commissioned before it.