Chuttamalle Dance AI: Stripe Credits for a One-Portrait Generative Vertical Clip

How I shipped an authorized-portrait → vertical generative dance product on Cloudflare Workers — with Stripe credits that refund when Seedance says no.

trychuttamalle.app is a fan-style tool around the Chuttamalle / Devara-song dance edit trend: upload an authorized adult portrait → get a ~15s 9:16 generative dance MP4 (720p path). Unofficial — not affiliated with the film or studio. AI-labeled results; original/AI or licensed audio only; no NSFW.

This write-up focuses on the Stripe credit loop that makes a one-photo dance product feel trustworthy. Prices and model ids change; treat live site / console as source of truth.

What users buy (verified live)

Homepage launch pricing while writing:

• Single $8.88 — one clip path.
• Duo $16.99 — 3 clips messaging on the fan launch copy.
• Preview framing locally before spending credits where the UI offers it.

Failed generations should restore credits — that sentence belongs next to the price, not buried in a ToS PDF. Guest Stripe checkout keeps the “I only want one vertical” path alive.

Why one portrait (not two)

This niche is a generative dance edit from a single clear face/body reference — not a dedicated face-swap booth with left/right seats. UX copy stresses: even light, face toward camera, authorized adult only. That reduces role confusion and support load.

Product is also honest about what it is not: not a mega-template library, not an official studio app. Honesty converts better than feature inflation.

Credit ledger design

Think in three buckets:

1. Stripe Checkout Session (guest OK) → webhook grants site credits.
2. Pre-debit / lock credits when Create is pressed.
3. Upstream spend on TryAllAPI → Seedance (your USD COGS).

Never merge (1) and (3) in one mental spreadsheet. Underpricing usually comes from ignoring retries + refunds + Stripe fees.

portrait → generative dance template
→ if credits low → Stripe
→ lock credits → create task
→ poll MP4 → deliver
→ failed → unlock/refund credits

Stack overview

Layer	Choice	Role
Front / SSR	TanStack Start (Vite)	Landing, upload panel, generation status
Runtime	Cloudflare Workers	Edge deploy, secrets, API routes
DB	Cloudflare D1	Credits, orders, task rows (table prefixes if DBs are shared)
Payments	Stripe Checkout	One-time packs + optional larger packs; guest checkout
Video upstream	TryAllAPI → Seedance	Async create + poll
Analytics	GA	Funnel sanity check

Why a video API aggregator

Operational checklist after register / top-up:

1. Confirm available USD balance in the console (not only the checkout success page).
2. Create a token in pay-as-you-go style billing.
3. Enable the video / Seedance-related channel group on that token. Wrong group → “no available channel” even when the model id looks right.
4. Prefer separate keys per product (chuttamalle-prod vs sandbox).
5. Put the key only in Workers Secrets (for example TRYALLAPI_API_KEY). Never in the frontend bundle or a blog post.

Conceptually the call shape looks like this (field names follow the aggregator’s v3 contents API; always re-check current docs):

POST /api/v3/contents/generations/tasks
Authorization: Bearer <TRYALLAPI_API_KEY>
Content-Type: application/json
Accept-Encoding: identity

GET /api/v3/contents/generations/tasks/{id}

I send Accept-Encoding: identity from the Worker because some gateways behave badly with transparent decompression. Model ids used in production look like Seedance 2.x family strings — treat console ids as source of truth, not this paragraph.

Seedance parameters for a one-portrait dance

A few details that bit me across this family of sites:

• Pass duration as an explicit integer. Some models default to “smart length.” Omitting duration can silently lengthen the clip and the bill.
• resolution and ratio. Cost tracks resolution tier and duration more than portrait vs landscape. Match whatever the create UI offers (often 480p/720p and 9:16 for Shorts).
• generate_audio. When the product ships “finished” downloads, leave audio on; creators who want a trending sound can mute later.
• Status machine. Expect something like queued → running → succeeded / failed. Success URLs are often short-lived signed links — download/rehost on your side before handing the file to the user.
• Decent failure. On supply_unavailable or hard failures: refund credits, show a short human message, log the detailed upstream error server-side, optionally fall back to another Seedance tier.

Rough mental model for upstream cost (illustrative only — use your own usage fields and invoices):

tokens ≈ duration_sec × width × height × fps / 1024
cost   ≈ tokens × price_per_million_tokens

Price the site after you measure a few real runs with retry margin, Stripe fees, and failed-job refunds — not from a spreadsheet fantasy of 0% failure.

One-reference notes: keep the locked dance template stable; push 9:16 for Shorts; rehost signed URLs; safety refusal → refund + short message.

Credits, Stripe, and the “can charge money” line

Demo UIs are easy. The line between toy and product is:

1. User hits Create → check credit balance.
2. If short → Stripe Checkout Session (guest allowed).
3. Webhook (plus a return-URL sync check) grants credits.
4. Pre-debit / lock credits, create upstream task, persist task_id in D1.
5. Poll until done; succeed → show MP4; fail → refund credits.

Two books of account stay separate: USD balance at TryAllAPI (your cost) vs site credits (what you sold). Mixing them in one mental ledger is how you underprice or invent “mysterious” losses.

When several products share one Stripe account, isolate webhooks by endpoint or by metadata (site / product). Callbacks pointed at the wrong apex domain are a classic multi-site footgun.

Secrets stay in Workers: TRYALLAPI_API_KEY, STRIPE_SECRET_KEY, webhook secret, auth secrets. The browser only ever sees publishable Stripe keys if needed.

Deploy notes (Workers + D1)

Typical loop on this template family:

pnpm install
# wire D1 database_id, production env, custom domain in wrangler
pnpm cf:deploy

Before calling a deploy “done”:

• D1 binding is correct; shared DBs use table prefixes, not a new database per micro-idea (free-tier DB counts are limited).
• AUTH_TRUSTED_ORIGINS and Stripe return / webhook URLs match the production HTTPS origin.
• GA id is set for a coarse funnel (land → upload → pay → wait → download).
• One real end-to-end path on production or a staging Worker: upload → pay → render → download.

Production origin: https://trychuttamalle.app (alternate hostname may exist — keep Checkout return URLs aligned).

Product rules that are not optional

Face-based generation is not “just another SaaS CRUD app”:

• Require an explicit 18+ / rights-to-use confirmation on upload.
• Block minors and refuse celebrity / stranger misuse in copy and policy.
• Expect upstream safety refusals; refund and explain.
• Keep privacy policy honest about retention; do not train on user media by default.
• Market as an independent fan-style tool for a trend format — not as an official tie-in unless you actually have that deal.
• Use your own sample renders in marketing.

Those constraints belong in the product, not in a footnote you add after the first dispute email.

What I would reuse on the next one-portrait dance site

1. Put credit refund language next to the price.
2. Preview framing before debit when possible.
3. Guest Single pack (~$8.88) matches impulse verticals.
4. Aggregator keeps the Worker thin.
5. Measure real 720p COGS before locking launch pricing.

Creators: try trychuttamalle.app with a photo you have rights to. Builders: TryAllAPI for create/poll, then wrap Stripe credits with automatic refunds. Price the pack after you measure real 720p COGS — then make failure boring.