Preview-Before-Pay AI Video: Who Pays for the Preview?

By Yuki Yu

Preview-before-pay moves the customer's payment later; it does not automatically move the provider's generation charge later. If your application generates a custom clip before checkout, budget for previews that never become purchases. Keep the approved video version separate from the customer's right to download it.

The product decision has three parts: what users can inspect, what they receive after payment, and who funds abandoned previews. Resolve those questions before comparing vendors by the phrase “video API.”

Read first: The AI video API pricing guide explains generation meters. This article focuses on a product that offers a preview before the customer pays.

What does preview-before-pay actually promise?

It promises a chance to inspect something before purchasing a defined deliverable. Specify whether that something is the actual generated clip, a derivative of it, or merely a representative sample.

Preview offer	What the user sees	What must be made clear
Existing sample	A previously created example	It is not the user's personalized result
Custom derivative	A limited version of a generated master	Which limitations disappear after payment
Full playback, restricted download	The complete result in a player	What the purchase adds beyond viewing
Draft followed by new generation	An initial take	The paid generation may differ from the preview

A static thumbnail is not evidence of motion quality. A short excerpt cannot prove the whole clip is coherent. Give users enough information to assess the promised result while keeping the preview proportionate to its purpose.

Does a free customer preview mean free API generation?

No. Your retail offer and your provider's billing contract are separate. Confirm the model's actual pricing and charge behavior rather than inferring them from your checkout design.

Token360's billing documentation says model requests follow the selected model's pricing rules, and distinguishes estimates from final recorded charges. It does not establish a general rule that preview generations become free when customers abandon checkout.

Track the provider request independently of the order. A completed preview can have an associated generation charge even when no order exists. Likewise, a customer payment does not prove the provider job completed successfully. These records answer different questions.

How much can abandoned previews add to each sale?

Spread the cost of all previews over the purchases they produce. Looking only at the successful buyer's generation understates the cost of an offer that also serves non-buyers.

We calculated three hypothetical scenarios on November 3, 2026. Each has 1,000 completed custom previews, one paid generation per preview at an assumed $0.60, and an assumed $0.01 of preview processing and delivery per preview. These are illustrative inputs, not Token360 prices, measured conversion rates or provider benchmarks.

Scenario	Completed previews	Purchases	Conversion	Included preview cost	Cost per purchase
A	1,000	200	20%	$610	$3.05
B	1,000	500	50%	$610	$1.22
C	1,000	800	80%	$610	$0.7625

preview_cost = previews * (generation_cost + preview_overhead)
cost_per_purchase = preview_cost / purchases
                  = cost_per_preview / conversion_rate

At 20% conversion, each purchase carries $3.05 of included preview cost, not just $0.60. At zero purchases, cost per purchase is undefined, not zero. The application has spent money without producing a sale.

Copy preview-scenarios.csv from the complete source below. Recalculate with your own generation charges, overhead and purchase cohort.

previews,generation_per_preview,overhead_per_preview,purchases,conversion,total_preview_cost,cost_per_purchase
1000,0.6,0.01,200,0.2,610,3.05
1000,0.6,0.01,500,0.5,610,1.22
1000,0.6,0.01,800,0.8,610,0.7625

The example assumes every submitted generation yields a completed preview and each purchase buys one previewed asset. Real failures, retries and repeated previews can increase spending. Define a consistent cohort and purchase window before measuring conversion; do not divide this week's generation costs by unrelated historic sales.

Should payment unlock the same asset or trigger a new generation?

If the offer promises the exact previewed take, unlock its corresponding master. A new generation creates both a cost and a product-consistency question.

Store an immutable asset version for the reviewed result, then derive the preview from that version. Associate the purchase with the master version, preview version and advertised deliverable. A later prompt edit should create a new version rather than silently replacing what the buyer inspected.

In the hypothetical scenarios, generating one extra $0.60 take for every purchaser would add $0.60 per purchase. Scenario A's included cost would become $3.65. That arithmetic does not establish that the second take will match the first. Upscaling, editing or re-rendering should have an explicit promise and review step when they alter the deliverable.

The seed reproducibility guide explains why a seed alone is not a substitute for preserving an approved asset. Saving the exact master gives you a concrete object to fulfill.

What can a preview restriction protect?

A separate preview derivative can limit the quality or portion you expose. Authorization can limit who retrieves the master. Neither makes already displayed content impossible to capture.

Keep the master out of the public preview response. Hiding a download button while returning an unrestricted master URL leaves the asset accessible through that URL. A visible watermark is a product presentation choice; it is not a replacement for access checks.

As one delivery example, Cloudflare Stream documents requiring signed URLs for private viewing or downloads. That feature controls access to the configured video resource. It does not implement your store's payment decision, and its existence does not establish the same feature on a generation provider.

Let your application determine entitlement before issuing access to the paid asset. Expiring a link can limit future retrieval, but cannot erase a copy a viewer already obtained. Describe the preview honestly rather than promising perfect copy prevention.

How should checkout connect to video fulfillment?

Verify payment on the server, then grant access to the specific purchased asset. Keep generation state, payment state and fulfillment state distinct.

A practical application record links the preview session, asset version, provider request, order and fulfillment result. This lets support distinguish “preview failed,” “payment pending” and “paid download unavailable” without starting another generation by default.

Stripe's fulfillment documentation explains why a redirect alone is insufficient and why fulfillment must handle repeated calls safely. Apply your chosen payment provider's verified completion rules, including delayed payment behavior where relevant. Repeated notifications should reconcile the same order rather than purchase another video generation.

Use a durable fulfillment record and an atomic transition or equivalent concurrency control. If access issuance fails after payment, retry delivery of the existing asset. The duplicate generation guide covers the related cost of confusing a retry with a new creation request.

Which controls make a pilot worth running?

Set the preview allowance, spend ceiling and success criteria before opening the offer widely. Measure completed previews, paid purchases and actual provider charges together.

Record repeated preview requests per user or account, generation attempts per completed preview, purchase conversion within a defined window, and fulfillment failures after payment. Use those measurements to decide whether to change the preview length, limit free attempts or revise the offer.

Do not treat a high conversion percentage as proof of profit. Include acquisition, editing, support and refunds in the broader decision. The video production economics article covers that wider accounting. This article isolates the cost incurred before a buyer commits.

For Token360, verify the chosen model's charge records and limits. For the delivery and payment services, verify access and fulfillment separately. This is an application architecture proposal, not a claim that Token360 ships a preview storefront or payment integration.

Frequently asked questions

Which API is best for preview-before-pay video?

Evaluate generation cost, asset retrieval, preview processing and private delivery separately. A product label alone does not establish a complete storefront workflow.

Can I offer previews for free?

You can choose a free retail offer, but must fund any provider and delivery costs that occur before a sale.

Should checkout generate a clean copy?

If the customer bought the exact previewed take, deliver the saved master. A new generation requires a separate expectation about possible differences.

Does removing the download button protect the master?

No. The resource itself needs appropriate access controls. Do not send an unrestricted master URL to an unauthorized preview client.

Does a successful payment page prove fulfillment?

No. Verify payment through the provider's server-side process and record whether access to the purchased asset was actually granted.

Are the conversion rates in this article real results?

No. The 20%, 50% and 80% cases are declared assumptions used to calculate cost sensitivity. No paid generation or checkout experiment was run.

Read next: The billing reconciliation guide helps link jobs to recorded charges. Visit Token360's resources for platform documentation.

Editorial revision: November 4, 2026. Test dates and dated source snapshots remain as stated in the article.