DEV Community: AI Video

Billing AI video by the rendered second (without double-charging when webhooks race)

AI Video — Thu, 29 Oct 2026 11:15:26 +0000

At TalkPix you upload a portrait, type a script or upload your own audio, and get back a lip-synced talking video. Users pay with credits, and the price depends on how long the video is.

That sounds simple until you notice that you don't know how long the video is until it exists. A typed script has an estimated length. An uploaded recording can run for minutes. The provider renders asynchronously and tells you it's done through a webhook, which may arrive late, twice, or never.

This is the billing flow we ended up with, and the bugs that shaped it.

Rule 1: nothing renders before it's paid for

The first version had a free short preview. It cost real inference money and, when we measured it, didn't convert. Now there is exactly one rule in the generate endpoint: if the wallet can't cover the estimate, return 402 and don't call the provider.

// app/api/generate (simplified)
const estimate = estimateCredits({ seconds: estimatedSeconds, resolution });
const reserved = await reserveCredits({ userId, amount: estimate, jobId });
if (!reserved.ok) {
  return Response.json({ error: "insufficient_credits" }, { status: 402 });
}
await startPrediction({ jobId, webhook: `${BASE_URL}/api/webhooks/provider` });

Reserving before the provider call matters. If you charge after, a user can start ten renders with credits for one.

Rule 2: balances only change inside Postgres functions

Every balance change is a security definer function that locks the wallet row. Application code never does update credit_wallets set balance = balance - x.

create or replace function reserve_credits(p_user uuid, p_amount int, p_job uuid)
returns int language plpgsql security definer as $$
declare bal int;
begin
  select balance into bal from credit_wallets where user_id = p_user for update;
  if bal < p_amount then
    raise exception 'insufficient_credits';
  end if;
  update credit_wallets set balance = balance - p_amount where user_id = p_user
    returning balance into bal;
  insert into credit_transactions (user_id, amount, type, related_job_id)
    values (p_user, -p_amount, 'generation_reserve', p_job);
  return bal;
end $$;

for update serializes two renders started by the same user at the same moment. The transaction row gives you an audit trail for every support question that starts with "where did my credits go?"

Rule 3: bill the video you actually delivered

When the render finishes, the finalizer:

copies the MP4 into our own storage (provider URLs expire),
measures the real duration of the file,
computes the true price, compares it with what was reserved,
refunds the difference, or debits the extra.

const actual = priceFor(measuredSeconds, resolution);
const delta = actual - job.reservedCredits;
if (delta < 0) await refundCredits({ jobId, amount: -delta, reason: "duration_reconcile" });
if (delta > 0) await reconcileGenerationDebit({ jobId, amount: delta, reason: "duration_reconcile" });

The interesting case is delta > 0. Reservations block overdrafts, which is what you want before a render. But for a long uploaded recording, the reservation was based on an estimate, the render has already been delivered, and the wallet may no longer cover the difference. Refusing to record that would make a delivered video impossible to bill.

So exactly one function is allowed to take a balance below zero: the reconcile for a completed, wallet-funded job. Everything else still blocks. A negative balance stops new renders until it's topped up.

-- only a completed job may create debt
select id into done_job from generation_jobs
 where id = p_job and user_id = p_user and status = 'completed';
if done_job is null then
  raise exception 'A completed job is required.';
end if;

Rule 4: the webhook and the poller will both finish the job

The provider's webhook is the fast path. But webhooks get lost, so the result page also polls, and a background sweep asks about anything stuck. That means three different code paths can finalize the same job, sometimes at the same moment. Every one of them has to be safe to run twice.

Three things make that true:

One function finalizes. Webhook, poll and sweep all call the same finalizeJob(). There is no second implementation to drift.

Claim the transition atomically. The status change is a conditional update, and only the caller that actually changed the row continues:

const { data: claimed } = await db
  .from("generation_jobs")
  .update({ status: "completed", video_url, duration_seconds })
  .eq("id", jobId)
  .in("status", ["queued", "processing"]) // only from an unfinished state
  .select("id");

if (!claimed?.length) return; // another finalizer already won; do not bill again

Make each money function idempotent on its own. Even if two callers get past the claim (say, a retry after a timeout), the database refuses to apply the same adjustment twice:

-- inside reconcile_generation_debit, after locking the wallet row
if exists (
  select 1 from credit_transactions
   where related_job_id = p_job
     and metadata ->> 'reason' = 'duration_reconcile'
) then
  return current_balance; -- already applied; retries are free
end if;

Refunds work the same way: refund_credits flips a credits_refunded flag on the job in the same transaction, and does nothing if it's already set.

Rule 5: a completed job never becomes a failed one

The failure mode to design against: the reconcile call times out after the video was delivered, the error bubbles up through a generic catch, and the job gets marked failed and refunded. The user would get the video and their credits back.

So once a job is complete, a billing error is logged loudly for retry, and the job stays complete. Because the reconcile function is idempotent, retrying it later is safe.

What the user sees

All of this exists so the product can make simple promises:

you see the credit price before anything renders,
a render that fails returns its credits automatically,
you're billed for the video you received, at 720p or 1080p,
credits are one-time packs that never expire.

The same flow now backs everything on the platform: talking and singing photos, product video ads, and the AI video templates.

Checklist if you're building this

Reserve before you call the provider; return 402 if you can't.
Change balances only inside row-locking database functions, and log every change as a transaction.
Measure the delivered file, then settle the difference.
Allow debt in exactly one place: a completed, paid job.
Assume webhook, poll and sweep all finalize the same job. One finalizer, an atomic claim, idempotent money functions.
Never let a billing error undo a successful delivery.

If you want to see the result from the user's side, the talking photo studio shows the credit estimate before you render, and pricing lists the packs.

Questions about any of this are welcome in the comments.

I built an app that replaces the whole person in a video. Here's what was hard.

AI Video — Thu, 29 Oct 2026 11:06:26 +0000

Most "face swap" results you've seen paste one face onto the same head. The hair, the body and the clothes stay, and it ends up looking like makeup.

I wanted the opposite: keep the performance from a clip (gestures, timing, camera) and rebuild the person completely, from one photo or from a sentence describing a character that doesn't exist. That became ActLike AI, an iPhone and Android app.

AI-generated example: same gestures and kitchen, a completely different person from one photo.

This post is about the parts that turned out to be harder than the "AI" itself.

The pipeline, roughly

Upload a short clip of one person (capped at 20 seconds) and either a photo or a text description.
Grab a reference frame from the start of the clip.
Build the character image. An image model takes the reference frame plus the photo (or the description) and produces the new person in the clip's exact pose, framing and light.
Replace the person in the video. A video model takes the clip and that character image and renders the clip with the new person, keeping the original motion.
Store the result and hand the phone a short-lived signed URL.

Steps 3 and 4 are where the quality comes from, but almost every bug I shipped lived somewhere else.

Hard part 1: the person looked pasted on

The first results were technically correct and visually wrong. A photo taken in soft studio light, dropped into a rainy street at night, looked like a sticker.

The fix was to stop feeding the user's photo straight into the video step. Instead, step 3 re-creates the new person inside the first frame of the clip: same pose, same head position, same lighting and shadows, with the face, hair and clothing from the photo. The video model then animates that image. In the app this is the "Scene Match" toggle.

Same photo, Scene Match off vs on: with it, the rain and neon reach her hair and clothes.

Two lessons from tuning it:

Lock the prompt. Free-form prompts drifted: the background changed, the camera "zoomed", clothing got restyled. A fixed prompt that lists what must not change (background, camera, framing, depth of field) made results consistent.
Big features transfer, small ones don't. Age, hair, beard and clothing come through reliably. Eye colour, teeth and scars often don't, because the video model follows the performer's own eyes and mouth. I now say this in the app instead of pretending otherwise.

Hard part 2: renders take minutes, and users close apps

A render takes a few minutes. People don't stare at a loading screen for that long; they switch apps, lock the phone, or swipe the app away. My first version kept the job alive only while the screen that started it existed, so a killed app meant a lost video that the user had already paid for.

What fixed it:

The server owns the job. Each render is a job document with a status (queued → processing → completed/failed). The app only reads it.
The device keeps a small ledger of every job it started. Not just the latest one. On launch, on returning to the foreground and on a notification tap, the app walks that list, asks the server for each job's status, and files any finished video in History.
A notification tap carries the job id. Even if the device lost track of a job, the tap is enough to fetch the result and open it.
Timeouts never delete work. A render that runs long is shown as "still preparing, it'll appear in History", and the ledger picks it up later.

The general rule I took away: any long-running job on mobile needs a recovery path that doesn't depend on a screen being alive.

Hard part 3: money and failures

The app uses one-time credit packs, no subscription: 1 credit per second at 480p, 2 per second at 720p, plus 1 if the character image has to be generated (Scene Match or a described character; they share that one credit).

The rule that saved me the most support email: the server is the only place that decides the price, and a failed render refunds its credits automatically. The client shows an estimate, but the charge, the refund and the reason all live in a server-side ledger. When I briefly let my website calculate costs differently from the server, it was wrong by one credit in exactly the combination I hadn't tested. Same formula, one source of truth.

Hard part 4: making examples honest

For the website I wanted every guide to show a real result, not a mock-up. So every example is made with the app's own pipeline and settings, the performers and photos are AI-generated people (no real faces), and each video is labelled with its settings and credit cost.

AI-generated example: a typed description turned a young maker into an old sea captain.

One unexpected design rule came out of this: the new person has to differ from the performer (gender or age plus hair and clothing). When I used a character too similar to the performer, viewers read it as makeup on the same face, which undersold what the model actually does.

What I'd tell someone building something similar

Treat generation as a server job with a status, never as a request the phone waits on.
Lock your prompts and list what must stay the same, not just what should change.
Put pricing and refunds on the server, and test every combination of options.
Be explicit about limits (one person per clip, the face must be visible, shaky footage glitches more). Users forgive limits; they don't forgive surprises.

If you want to see the results with their exact settings and costs, they're here: before-and-after examples. The app is on the App Store and Google Play.

Happy to answer questions about any of this in the comments.