How category batches turn recorded hours into contributor revenue
Follow a category purchase from approved footage and frozen order selection to exact cent allocation and confirmed payment.
Buying data · 4 min read ·
In this guide
A category total is a selection rule
A laboratory may need a broad collection of gardening activities rather than a relationship with one individual contributor. Category batches make that purchase possible: eligible recordings from several contributors are assembled under one category, while each contributor’s share remains attributable to the footage included.
The number displayed for a category should describe approved, available source duration under the current selection rules. Uploaded files awaiting review do not belong in that total. Neither do paused offers, withdrawn recordings or listings whose contributors have declined category batches. A large number without these definitions gives a buyer little basis for estimating the usable collection.
Direct listings and batch participation serve different choices
A direct listing lets a contributor describe a particular activity and set an hourly license price. A category batch combines eligible recordings at the marketplace’s batch rate. These are separate pricing decisions: a contributor’s direct rate should not silently become the batch rate, and changing a direct price should not retrospectively alter an existing order.
The launch batch model uses €1 per approved hour, with a zero platform commission and payment processing fees absorbed by the platform. Contributors choose whether their recordings participate in category batches. This describes the allocation rule, not a promise that any uploaded recording will sell. Purchase and payout actions depend on the corresponding services being configured and available.
Work through the 300, 500 and 200 hour example
Suppose a buyer licenses 1,000 hours of eligible gardening video for €1,000. Three contributors supply all the footage selected: one contributes 300 hours, another 500 hours, and the third 200 hours. Their shares follow the approved duration included in this particular order.
The contributor pool is €1,000 under the stated zero-commission model. The first contributor receives 300 divided by 1,000 of that pool, or €300. The second receives €500, and the third €200. The amounts sum to the buyer’s €1,000 license payment. A contributor with more footage elsewhere in the catalog earns no additional share from footage absent from this order.
| Contributor | Included footage | Share of selected hours | Allocation |
|---|---|---|---|
| Contributor A | 300 hours | 30% | €300 |
| Contributor B | 500 hours | 50% | €500 |
| Contributor C | 200 hours | 20% | €200 |
| Total | 1,000 hours | 100% | €1,000 |
Allocate integer cents without losing the remainder
Real orders rarely divide as neatly. Use integer milliseconds for included duration and integer cents for money. Calculate each contributor’s exact proportional share, allocate the whole cents first, then distribute any remaining cents according to the largest fractional remainders. A stable contributor-ID order can break ties reproducibly.
For a one-cent pool shared by three equal contributors, only one contributor can receive that cent in that order. A documented tie-break explains which one; rounding everyone independently could allocate zero cents or more money than exists. Check that every allocation is non-negative and that the sum equals the pool exactly. Retain the calculation inputs so the result can be audited.
Freeze what the buyer actually ordered
The order needs an immutable selection of recording IDs, included durations, contributor ownership, annotations and license terms. Otherwise a contributor’s later update or a new upload could change the purchase after the buyer accepted it. Current catalog totals and a previous order total are different views and may legitimately diverge.
Keep the source file available for valid existing orders even if its listing is later withdrawn from future sales. Do not silently replace it with a revised file bearing the same ID. If a buyer requests another batch later, check which recordings that buyer already licensed so the new selection does not unintentionally charge for the same footage again.
Payment confirmation is a separate event from checkout
A browser returning from a payment page does not prove that funds were successfully received. Some payment methods complete asynchronously, and an interrupted browser should not lose a valid order. Stripe’s webhook documentation describes server events for payment changes; a marketplace needs verified provider information before unlocking the purchased delivery or creating earned allocations.
The processing logic must tolerate duplicate and out-of-order events. Recording a provider event ID and making the allocation step repeatable prevents a retried notification from paying the same contribution twice. If the payment integration is unavailable, the interface should communicate that state and leave the order unpaid. A calculated quote alone is not contributor revenue.
Separate an allocation, a transfer and a bank payout
An earned allocation records the contributor’s share of a confirmed order. A transfer moves eligible funds into a connected payment account. A bank payout is another stage, governed by account verification, supported locations, available balances and the provider’s schedule. These stages need distinct statuses so contributors can understand where their money is.
Stripe documents separate charges and transfers as a way for one platform payment to fund multiple connected accounts. Its payout documentation separately covers movement to external accounts. Neither mechanism justifies promising an immediate bank deposit. A contributor may need to complete onboarding before a transfer can proceed, and provider failures need a retryable record rather than an unexplained disappearance.
Keep reversals visible and earnings grounded in events
A refund or dispute can change the amount retained from an order. Record reversals against the original allocations and preserve the history, rather than editing yesterday’s balance without explanation. With separate charges and transfers, platform responsibilities for fees, refunds and chargebacks must be reflected in the operating model.
For a contributor, the most useful earnings view connects each amount to its category, order, included duration and current status. For a buyer, the useful evidence is the frozen delivery and the confirmed license. Both depend on the same underlying discipline: count approved footage, calculate exact shares, and advance financial states only when the relevant real-world event has occurred.