Wan 3.0's billing hinges on a fingerprint, because a careless retry buys a second render

An idempotency key is a promise about the wire. The fingerprint is the promise about the ledger, and the Wan 3.0 account uses both: the key names the operation, a hash over model, scene and validated parameters is compared against it, a repeat that matches returns the existing task, and the same key arriving with different input is rejected outright ^[12]. That rejection is the half worth copying. Without it a key becomes a container for whichever payload landed last ^[12], which is the route by which a double-click or a post-accept timeout ends up as a paid render nobody ordered ^{[1] [14]}.

Ordering does the rest of the work. The reservation is taken at task creation, before the provider adapter is called ^[11], so the provider has not yet agreed to anything when the credit moves. Billing honesty then lives in the failure paths rather than the happy one, and the record keeps five states, including canceled, while the flow names only two money endings: result history or automatic refund ^{[10] [11]}.

Cancel is where that gets thin. In the provider interface only the name, the webhook flag and generate are required; query, webhook verification and cancel are all optional ^{[8] [2]}. A provider whose adapter omits cancel cannot be told to stop, so a task wedged in processing holds its reservation until something outside the adapter decides the task has failed, and the published flow describes the refund as automatic without saying what triggers it ^[11].

The scene union declares seven modes ^[4], and the input contracts described in the post cover four of them: text, image, ordered frame pairs and references ^[3]. Edit, extend and upscale are declared and unspecified ^[1]. Since each model declares which scenes and fields it supports ^[5], that is a gap in a capability table rather than a redesign, but it is the gap that determines whether the server can still refuse a bad combination locally, and the argument for local refusal is cost: an upstream error is slower and sometimes dearer than a validation failure ^[6].

The audit row is the strongest part of the design. Selected model, provider, normalized input, pricing snapshot, cost, timestamps and terminal result all sit on the same operation ^[13], which is what makes a charge answerable months later. The stated hard requirement is that the displayed estimate and the recorded charge use the same basis ^[15], and the published text stops mid-sentence there ^[15]. The unanswered question is when the snapshot is captured, because that is what decides who absorbs a price change that lands between the estimate and the provider call.