Charged for a failed Seedance or Kling job? Reserve, capture, refund

No: on Sume you are not charged for a Seedance or Kling video that fails or is canceled before it is captured. Sume reserves the estimated cost when it accepts the job, captures that reservation when the clip completes, and releases or refunds it when the job fails or is canceled. The one catch is timing: cancel only works before generation starts.

This matters most for long, high-resolution clips, where the hold is largest. Below is the full lifecycle, the cancel call, and where each state shows up in Usage.

What happens to the money when you submit a video job?

The video generation docs say the workspace USD balance is reserved on submit at provider list price times 1.25, for every model. The generation admission docs describe the same flow for all paid generation: Sume reserves the estimated amount when the request is accepted, successful completion captures the reserved usage, and failed jobs and failed queue admission release or refund the reservation where applicable.

If the balance cannot cover the hold, the submit fails with 402 insufficient_credits before any provider work starts, so no job exists and nothing is held. The usage.cost field on a finished video is the Sume billable amount, not the provider's number.

When can you still cancel a Seedance or Kling job?

Cancellation succeeds only before generation work starts. A job that is still queued behind your plan's concurrency limit can be canceled; once it is processing, cancel returns 409 job_generation_already_started with details.cancelable: false, and the job completes or fails normally. Canceling a job that is already canceled is idempotent, so a retried cancel is safe.

That makes the queue the cheap place to change your mind. If you submitted a batch of Seedance clips and spotted a wrong prompt, cancel the queued ones first and leave the running ones alone.

# cancel a queued job
curl -X POST https://api.sume.com/v1/jobs/job_123/cancel \
  -H "Authorization: Bearer $SUME_API_KEY"

# 409 job_generation_already_started means it is already
# processing: let it finish, it will complete or fail normally.

How do you check that a refund happened?

The Usage docs list the entry kinds: reservations, captures, refunds, top-ups and grants. A row with status refunded means reserved usage was released after failure or cancellation before capture. The summary fields held_usd_micros and refunded_usd_micros separate money still on hold from money given back, and refunded holds are not spend.

Do not sum rows yourself. A refunded row keeps its hold amount for the record, so adding the amounts double counts. Use the totals Usage computes, and match a row to a clip by job id.

What is not refunded or not covered?

A clip that completes but looks wrong is a completed job: it was captured, because the provider did the work. Sume does not judge quality, so there is no refund path for a bad take. Cheaper iteration is the answer, and a 480p draft before a 1080p final is the usual way to spend less on retries.

Also note what a retry costs. If your client times out and you resubmit without an idempotency key, you create a second job and a second hold. Send an Idempotency-Key on every paid submit; a replay returns the original job instead. The same key reused for a different payload returns 409 idempotency_conflict, which protects you from paying for the wrong request.

Finally, jobs stuck in queued are not failures. With a low concurrency limit, a Seedance job can wait behind earlier ones while its hold stays in place; poll with backoff rather than resubmitting. For the states themselves, see Errors and rate limits and the admission page above.