Bannerbear refunds an unrendered part; Sume cancels only before start

Bannerbear's pricing page (read 2026-10-11) says cancelling an animation refunds the part that had not rendered, so a late cancel returns some credits. Sume does not split a job: a cancel works only before generation starts, and after that it returns 409 job_generation_already_started and the job finishes or fails normally.

If you are moving a render workflow from Bannerbear to Sume, that is the one billing rule you cannot copy over. Design for early cancels.

How Bannerbear charges and refunds

The Bannerbear pricing page (read 2026-10-11) lists Automate at $49 a month with 1,000 API credits, Scale at $149 with 10,000 and Enterprise at $299 with 50,000. Images cost one credit per render, multiplied by format count and scale. Animations cost two credits per second, rounded up. Video tools cost one to four credits depending on complexity. The platform charges credits when the request is created and refunds unused portions for cancelled renders.

The wording I read is "Cancelling an animation refunds the part that had not rendered" and "You are refunded for the portion that had not started rendering, not the whole job". Using the listed rates, a 10-second animation costs 20 credits, which is about $0.98 at Automate's $49 per 1,000 credits ($0.049 a credit). The page does not say how the refunded portion is measured, so I do not give a number for a half-finished cancel.

How Sume handles a cancel

On Sume, paid generation reserves the estimated USD amount when a request is accepted and captures it when the job completes. Failed jobs and failed queue admission release or refund the reservation, and the core workflow page says a cancellation before capture can refund as well.

Generation admission says cancellation succeeds only before generation work starts: POST /v1/jobs/{id}/cancel. After generation starts, cancel returns 409 job_generation_already_started with details.cancelable: false, and the job then completes or fails normally. A cancel on a job already canceled is idempotent and returns the same canceled job.

Side by side

What to change in a port

First, stop relying on a late cancel to recover spend. On Sume the only cheap window is while the job is queued, which is exactly the state a busy workspace creates on purpose; Free holds up to 5 queued jobs and Pro up to 20. Second, cancel from the job status, not from a timer: poll GET /v1/jobs/{id}/status, and send the cancel only when it still reads queued.

Third, treat the 409 as information, not an error to retry. The job is already running and will either complete, which captures the price, or fail, which releases it. Waiting is the correct response.

When this matters

It matters for batch tools where users change their mind, such as a preview that a customer abandons. On Bannerbear a partial refund softens that. On Sume, put a short confirmation step before submit, and use the unbilled checks that some Sume routes offer, since a wrong job that has started cannot be undone.