By Maryna Poplavska, Head of Project Managers · 26 October 2026
A coin economy for pay-per-minute video calls is a prepaid wallet joined to a billing clock: the caller loads coins, the platform debits them as the call runs, and the other side is credited in the same transaction, though not out of those coins. The wallet is the easy half. The hard half: a live conversation ends in at least four ways — either person hangs up, the balance hits zero, a tab closes, a network drops — and billing has to produce one defensible number for each.
The design comes from the specification I wrote as PM for a 1:1 video platform Trembit built for a client we do not name. It is what was specified, not a reading of the shipped code, and where the specification is ambiguous this says so. The same trade-offs come up in any product that meters a live conversation — tutoring, expert advice, interpretation.
Key takeaways
- Three low-balance warnings, with a collision rule. A toast at 50% or less of the balance held at call start, a banner with a top-up CTA at 3 remaining, a 30-second countdown. When two land together the rule shows the closest-to-zero one — except on a true collision, where both sit at the same value and, on our reading, it cannot pick.
- Prepaid, per minute, debited at the start of each minute, rounded up. A 0:30 call costs one coin, and the caller pays for a minute they may not finish.
- Debit and credit are atomic, but they are not a transfer — both move in one transaction or not at all, yet they are separate units on separate ledgers, and the platform funds the credit itself.
- The server settles at the first authoritative end-or-grace-expiry event — one rule, applied once, instead of reconciling three timestamps after the fact.
How do you warn someone their coins are running out without firing three warnings at once?
The specification sets three in-call low-balance warnings, each firing independently and at most once: a toast at 50% or less of the balance held at call start; a banner with a top-up CTA at 3 remaining — the spec says minutes, this piece reads coins; a 30-second countdown overlay.
No single trigger serves both ends of the range. Proportional means nothing on a small balance, where 50% can be one minute; absolute means nothing on a large one. The countdown is not information; it is the last call to action.
The consequence is collision — and finding it exposes an ambiguity worth more than the answer. Remaining has two scales: coins in the wallet, or billable time including the minute running. The spec says “remaining balance” for the toast and “3 minutes of billable time remaining” for the banner, never saying these are the same scale. On the wallet reading the two collide on a call that starts with six or seven coins; read the banner on billable time and it is a call that starts with four or five. On the wallet reading the collision lands at three coins. Both readings are ours, from the spec’s wording. The rest of this piece uses the wallet reading. The countdown is not a boundary event at all. The rule is that when two coincide, only the closest-to-zero warning is shown — but a collision fires both at the same remaining value, so on our reading the rule does not pick. Ours: keep the one carrying the top-up action, the banner.
The rule does not stop crowding: warnings thirty seconds apart are not a collision (ours), so nothing suppresses them for coinciding. Whether that makes two interruptions inside the only minute a one-coin call has depends on a second rule: a threshold already passed, or unreachable, at call start is not fired — which may be the toast’s position on a balance that small, so whether it fires is in doubt. The small-balance caller is the one the ladder serves worst, and that is the case to settle before video chat app development starts, not in QA.
When is a minute billable, and who pays for a partial one?
Billing is prepaid and per minute: a coin is debited at the start of each minute, rounded up. A 0:30 call costs one coin.
Decide what starts minute one — acceptance, both joined, or first media — since the first coin moves then. Debit on acceptance and a connection that never establishes is still paid for; wait for media and the first seconds are free. Neither is wrong; the choice has to be written down.
Charging at the start of a minute rather than the end is a solvency decision, not a pricing one. Debit first and the worst case is a caller paying for a minute they barely used. Debit at the end and the worst case is a call that has happened and cannot be funded — the one position a prepaid system exists to avoid. At zero balance the call auto-disconnects with a top-up prompt, so “out of coins” is a state, never a debt.
Rounding a part-minute up is one telephony billing convention — a voice vendor bills “4 minutes and 19 seconds” as five — and it makes the unit honest in both directions: a coin buys a minute, or any part of one — predictable for the caller, explainable by support. The cost, on a call that bills from the first second: someone who hangs up at 0:05 pays what someone who talks for 0:59 pays. A short free window at the start softens that edge, and belongs in the same decision as the unit.
Why do the debit and the credit have to move in the same transaction?
The caller’s balance is debited and the other side’s earnings ledger credited atomically — all or nothing, and every movement is a ledger row.
Note what that is not. It is not a transfer: the two sides are different units on separate ledgers, and the earning side is credited by the platform out of its own funds. The caller’s coins pay the platform; what the earner accrues is what the platform owes them, converted to cash only at payout. Treat it as money crossing the table and you model one balance where there are two, then reconcile a transfer that never happened.
Atomicity is not a performance concern here; it is the definition of the product. If the halves separate you get a caller charged for a minute nobody was credited, or a credit never collected — neither recoverable without manual work. You write one of these every sixty seconds of every live call, and the cost is a coupled write across two balances on every minute boundary.
Anything else that can spend that balance mid-call — here, an in-call gift — competes for the same rows. Two rules settle it: a spend that would overdraw is rejected outright, never partially applied, and one that takes the balance to zero triggers the zero-balance flow at the next minute boundary, not mid-transaction. Settling it at the boundary (ours) keeps the teardown in one place, not whichever code path spent the last coin.
What happens when both sides hang up at the same moment?
The server settles billing at the first authoritative end-or-grace-expiry event.
Simultaneous ends are not an edge case — they happen whenever both reach for the button. Add a network drop and you have two or three end events arriving out of order, each with its own idea of when the call stopped. Reconciling them means choosing which clock to trust, then choosing again for every new way a call can end.
First-authoritative-event-wins refuses the question: that event settles the ledger and everything after is a no-op (ours). A later event with a better timestamp is discarded. Deterministic beats precise: a number settled once against one record is reproducible by support; one assembled from three competing timestamps is not. Say which event is authoritative — the media layer’s disconnect, or your session server’s — because “first” means nothing until it is fixed.
Does a page refresh end a pay-per-minute video call?
Not if it takes less than ten seconds.
A refresh rejoins the same room inside a 10-second grace window. Rejoin, and billing continues uninterrupted, the chat panel restoring its history. Miss it — a true tab close or network loss, detected server-side when the heartbeat stops — and the server releases the room, disconnects both parties, and no further minute is debited. The minute already running was paid at its start and stays paid. The specification states this for a hang-up: billing stops at the current, already-debited minute, and that minute is not refunded — a spent minute is delivered, and only unspent purchased coins are refundable. Two sentences point the other way, both about a dropped connection rather than a hang-up: billing there “stops at elapsed minutes”, and “at the last fully elapsed minute”. We read those as no further debiting rather than a reversal, since neither is a rule about refunding and the refund rule is explicit (ours). A closed tab sometimes tells your server; a dead network never does, so absence has to be inferred (ours). WebSocket ping and pong frames are the usual instrument (ours) — RFC 6455 notes that “a Ping frame may serve either as a keepalive or as a means to verify that the remote endpoint is still responsive” (RFC 6455 §5.5.2). The grace window is the gap between “we have stopped hearing from this client” and “this client is gone”.
A longer window covers more mobile blips, at the price of holding the other party. A shorter one frees the room sooner but turns an ordinary reload into a lost call. Ten seconds covers a reload (ours): the caller pays for the gap when it works and for the minute the drop fell in when it does not.
Who can end the call, and is there a penalty for it?
Either party can end the call. No further coin is debited after it ends — and the minute already running stays paid — and when the earning side ends it, no cooldown penalty applies to them. Either side can place the call, so the person charged is not always the one who dialled: the balance check follows the payer.
The specification gives no reason. Ours: the platform gives up revenue it could keep, and should, when one side is a stranger. Any penalty for leaving — a cooldown, a ranking hit, fewer proposals — is a reason to stay in a call you want to leave: a safety problem before it is a retention feature. The cost: nothing distinguishes “it was over” from “it was unpleasant”; that signal must come from report-and-block.
There is also no hard cap on call length: the balance is the only ceiling. That pushes the weight onto the warning ladder: the only thing between a caller and zero is whether they were told it was coming.
Where should the paywall sit — at the search, or at the call?
At the call. Search is free: a caller with zero coins can search and receive call proposals, and payment is required only at call initiation, where they get a top-up prompt instead of a connection.
Free search costs real capacity — queue, presence, the attention of whoever answers a proposal that never becomes a call. Ours: still the right place for the gate, because at call initiation a specific person is waiting and the value of a coin is concrete. The middle option the specification did not take: free search, proposals only to callers holding at least one minute.
Where do refunds stop, and what covers the gap?
Refunds exist but are deliberately narrow, and that is load-bearing: it decides what the rest of the design carries.
A refund reaches a purchase, never a call. A purchase of coins refunds in full while untouched, bonus coins included; spend one coin from it and the whole purchase stops being refundable, inside a window the server sets. A delivered minute never is. So fairness inside a call rests on what acts before the money moves: prepaid debit, atomic settlement, first-authoritative-event, the warning ladder. Because the running minute stays paid, the unit bounds the exposure: one event costs a caller at most a single minute.
Write down which pre-emptive control does a refund’s work where refunds do not reach. Related: buy or build the real-time video layer.
FAQ
Should a partial minute be charged or discarded? The specification rounds up: a 0:30 call costs one coin. Ours: a minute or any part of one is a unit a caller can predict and support can explain. Very short calls are the worst value.
What happens when a caller runs out of coins mid-call? The call auto-disconnects at the minute boundary (ours; the spec says only “when the balance reaches zero”) and a top-up prompt replaces it. There is no hard cap on length either: the balance is the only ceiling.
Decide these before you build them
Bring your call flow to a free 30-minute call with engineers who build real-time video, and leave with the billing decisions it forces and which are expensive to reverse. No deck, no pitch. Tell us what you are building.
