{
  "x402Version": 2,
  "service": {
    "name": "kino402",
    "description": "Pay-per-call video generation and speech over x402. The unpaid 402 is the quote.",
    "url": "https://kino402.com",
    "tags": [
      "x402",
      "video",
      "generation"
    ],
    "contact": "support@kino402.com"
  },
  "resources": [
    {
      "url": "https://kino402.com/v1/generate",
      "method": "POST",
      "description": "Text-to-video, sold per call across 10 models (seedance-2.0, seedance-2.0-mini, seedance-2.5, seedance-1.5-pro, kling-2.5-turbo-pro, hailuo-02-standard, veo-3.1, veo-3.1-fast, veo-3.1-lite, minimax-h3). Parametric: $0.058 to $17.334 — the unpaid 402 quotes the exact price for the body sent, and that is the amount that settles.",
      "mimeType": "application/json",
      "accepts": [
        {
          "scheme": "exact",
          "network": "eip155:8453",
          "amount": "58000",
          "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
          "payTo": "0x2A266c87F7b0D1F8A471D2d5234F5CF4FB62b206"
        },
        {
          "scheme": "exact",
          "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
          "amount": "58000",
          "asset": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
          "payTo": "FZFwXPrnGUKZ9YzgfgXbmbaDzAS8dNEjcrBXkXoKbX9A"
        }
      ],
      "billing_terms": {
        "billable_unit": {
          "unit": "one call",
          "price": {
            "currency": "USD",
            "min": "0.058",
            "max": "17.334",
            "min_atomic": "58000",
            "max_atomic": "17334000",
            "quote": "the unpaid 402 answering the body sent"
          },
          "metered": false,
          "settles_at": "upstream acceptance of the render",
          "note": "One call. A single signed authorization buys exactly one call at the amount that call's own 402 quoted, and the whole quoted amount settles or nothing does — there is no partial, metered or per-second billing and no charge is ever split across a retry. kino402 prices are parametric, so the band published here is the floor and the ceiling this resource can quote; the unpaid 402 answering the body you actually sent is the authority on the number, and it is the number that settles."
        },
        "hold": {
          "held": false,
          "note": "None. Verification is a read at the facilitator (verifyPayment in worker/kino.js), so nothing is reserved, escrowed or held: the signed authorization moves no funds until it is submitted at settle, which runs in ctx.waitUntil after the response has already been sent. An authorization that never reaches settle is simply never submitted, and no balance of yours was ever encumbered while it was outstanding."
        },
        "idempotency": {
          "key": "sha256(signed authorization: network + payer + nonce on EVM, network + transaction on Solana)",
          "headers": [
            "PAYMENT-SIGNATURE",
            "X-PAYMENT"
          ],
          "idempotency_key_header": null,
          "replay": {
            "status": 402,
            "error": "payment_already_used"
          },
          "note": "There is no idempotency-key header. The key is the signed authorization itself, read out of the payment header — PAYMENT-SIGNATURE for x402 v2, X-PAYMENT for x402 v1, and PAYMENT-SIGNATURE is the one read when a request carries both: on Base the SHA-256 of the network, the payer address and the EIP-3009 nonce, on Solana of the network and the serialized transaction's decoded bytes (claimKeyOf in worker/kino.js). Re-encoding the same authorization — whitespace, key order, the other protocol version, a respelled base64 transaction — is therefore the same key, and a payment missing its network's authorization field is refused 402 `malformed_payment_header` before anything is claimed. The key is claimed single-use by claimPaymentOnce after the payment verifies and before any work is ordered. A second request carrying the same authorization, concurrently or an hour later, is answered 402 with invalidReason `payment_already_used` and the live terms re-offered: it submits no render, compiles no prompt, synthesises no audio and settles nothing. Sign a fresh authorization, with a fresh nonce, to buy another call."
        },
        "post_payment_error": {
          "settles": false,
          "before_settlement": "authorization released — the same header can be presented again",
          "after_settlement": "settled at upstream acceptance: one automatic resubmission, then status `failed` with `refund_due` true",
          "note": "No exit before settlement charges anything, and none of them keeps the single-use claim — an exit before the claim never took it, an exit after it hands it back — so the very same header can be presented again: a body that does not price, a payment the facilitator refuses, a facilitator that cannot be reached at all (503), an image URL that does not fetch as an image, an upstream queue that will not take the job, a brief that will not compile, a synthesis that returns no audio, a job row that cannot be written. After that point the answer depends on how the route delivers. The synchronous routes settle behind a response that already carries the product, so there is no window in which you have paid and have nothing. The asynchronous routes settle when the upstream ACCEPTS the render rather than when the file lands, so a render that fails afterwards has already been paid for: it is resubmitted once automatically on the same job row, and a second failure sets status `failed` with `refund_due` true."
        },
        "refund": {
          "path": "none",
          "dispute": "none",
          "automatic": false,
          "flagged_as": "`refund_due` on GET /v1/jobs/{id}",
          "contact": "support@kino402.com",
          "note": "No automatic refund and no self-service one. There is no refund endpoint, no credit, no dispute endpoint and no reversal of a settled payment anywhere in this service. The mechanism is non-charge rather than refund: an authorization for work that was never accepted is never submitted, so no funds move at all. The single case where money moved and no product exists — an asynchronous render that failed twice — is reported as `refund_due` on the free GET /v1/jobs/{id} and refunded by hand against that job id, by mail to support@kino402.com. Anything else is that same address and a conversation, not a guaranteed remedy."
        },
        "acceptance_observer": {
          "observer": "the buyer",
          "observed_from": "{job_id, status_url} in the 200, then GET /v1/jobs/{id} until status is `completed` or `failed`",
          "third_party_attestation": "none",
          "note": "The buyer, from the 200 this service returns. No third party attests, no oracle is consulted and nothing has to be signed back: on the asynchronous routes the 200 carries {job_id, status_url} and the free, unauthenticated GET /v1/jobs/{id} is where you watch the render reach `completed` with its video_url or `failed` with its reason, and on the synchronous routes the 200 body IS the product — the compiled prompt as JSON, or the mp3. kino402 keeps its own settlement ledger, but that is an operator's record for reconciliation and it is not offered to the buyer as evidence."
        },
        "silence_window": {
          "window": "none",
          "seconds": null,
          "accepted_by_silence": false,
          "note": "None. Nothing on this service becomes accepted by the passage of time: settlement is queued at delivery on the synchronous routes and at upstream acceptance on the asynchronous ones, and no timer anywhere converts a buyer's silence into acceptance, closes a complaint or finalises a charge that would otherwise be open. A job that failed after payment keeps reporting `refund_due` on every poll — that flag has no expiry, and not polling does not spend it."
        }
      }
    },
    {
      "url": "https://kino402.com/v1/audio/tts",
      "method": "POST",
      "description": "ElevenLabs TTS: text-to-speech, priced per character of the text sent — $0.001 to $1.20 per call. Synchronous; the mp3 is the response body.",
      "mimeType": "audio/mpeg",
      "accepts": [
        {
          "scheme": "exact",
          "network": "eip155:8453",
          "amount": "1000",
          "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
          "payTo": "0x2A266c87F7b0D1F8A471D2d5234F5CF4FB62b206"
        },
        {
          "scheme": "exact",
          "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
          "amount": "1000",
          "asset": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
          "payTo": "FZFwXPrnGUKZ9YzgfgXbmbaDzAS8dNEjcrBXkXoKbX9A"
        }
      ],
      "billing_terms": {
        "billable_unit": {
          "unit": "one call",
          "price": {
            "currency": "USD",
            "min": "0.001",
            "max": "1.20",
            "min_atomic": "1000",
            "max_atomic": "1200000",
            "quote": "the unpaid 402 answering the body sent"
          },
          "metered": false,
          "settles_at": "delivery of the response body",
          "note": "One call. A single signed authorization buys exactly one call at the amount that call's own 402 quoted, and the whole quoted amount settles or nothing does — there is no partial, metered or per-second billing and no charge is ever split across a retry. kino402 prices are parametric, so the band published here is the floor and the ceiling this resource can quote; the unpaid 402 answering the body you actually sent is the authority on the number, and it is the number that settles."
        },
        "hold": {
          "held": false,
          "note": "None. Verification is a read at the facilitator (verifyPayment in worker/kino.js), so nothing is reserved, escrowed or held: the signed authorization moves no funds until it is submitted at settle, which runs in ctx.waitUntil after the response has already been sent. An authorization that never reaches settle is simply never submitted, and no balance of yours was ever encumbered while it was outstanding."
        },
        "idempotency": {
          "key": "sha256(signed authorization: network + payer + nonce on EVM, network + transaction on Solana)",
          "headers": [
            "PAYMENT-SIGNATURE",
            "X-PAYMENT"
          ],
          "idempotency_key_header": null,
          "replay": {
            "status": 402,
            "error": "payment_already_used"
          },
          "note": "There is no idempotency-key header. The key is the signed authorization itself, read out of the payment header — PAYMENT-SIGNATURE for x402 v2, X-PAYMENT for x402 v1, and PAYMENT-SIGNATURE is the one read when a request carries both: on Base the SHA-256 of the network, the payer address and the EIP-3009 nonce, on Solana of the network and the serialized transaction's decoded bytes (claimKeyOf in worker/kino.js). Re-encoding the same authorization — whitespace, key order, the other protocol version, a respelled base64 transaction — is therefore the same key, and a payment missing its network's authorization field is refused 402 `malformed_payment_header` before anything is claimed. The key is claimed single-use by claimPaymentOnce after the payment verifies and before any work is ordered. A second request carrying the same authorization, concurrently or an hour later, is answered 402 with invalidReason `payment_already_used` and the live terms re-offered: it submits no render, compiles no prompt, synthesises no audio and settles nothing. Sign a fresh authorization, with a fresh nonce, to buy another call."
        },
        "post_payment_error": {
          "settles": false,
          "before_settlement": "authorization released — the same header can be presented again",
          "after_settlement": "none — settlement is queued only once the product is in the response",
          "note": "No exit before settlement charges anything, and none of them keeps the single-use claim — an exit before the claim never took it, an exit after it hands it back — so the very same header can be presented again: a body that does not price, a payment the facilitator refuses, a facilitator that cannot be reached at all (503), an image URL that does not fetch as an image, an upstream queue that will not take the job, a brief that will not compile, a synthesis that returns no audio, a job row that cannot be written. After that point the answer depends on how the route delivers. The synchronous routes settle behind a response that already carries the product, so there is no window in which you have paid and have nothing. The asynchronous routes settle when the upstream ACCEPTS the render rather than when the file lands, so a render that fails afterwards has already been paid for: it is resubmitted once automatically on the same job row, and a second failure sets status `failed` with `refund_due` true."
        },
        "refund": {
          "path": "none",
          "dispute": "none",
          "automatic": false,
          "flagged_as": "none",
          "contact": "support@kino402.com",
          "note": "No automatic refund and no self-service one. There is no refund endpoint, no credit, no dispute endpoint and no reversal of a settled payment anywhere in this service. The mechanism is non-charge rather than refund: an authorization for work that was never accepted is never submitted, so no funds move at all. The single case where money moved and no product exists — an asynchronous render that failed twice — is reported as `refund_due` on the free GET /v1/jobs/{id} and refunded by hand against that job id, by mail to support@kino402.com. Anything else is that same address and a conversation, not a guaranteed remedy."
        },
        "acceptance_observer": {
          "observer": "the buyer",
          "observed_from": "the 200 response body, which is the product",
          "third_party_attestation": "none",
          "note": "The buyer, from the 200 this service returns. No third party attests, no oracle is consulted and nothing has to be signed back: on the asynchronous routes the 200 carries {job_id, status_url} and the free, unauthenticated GET /v1/jobs/{id} is where you watch the render reach `completed` with its video_url or `failed` with its reason, and on the synchronous routes the 200 body IS the product — the compiled prompt as JSON, or the mp3. kino402 keeps its own settlement ledger, but that is an operator's record for reconciliation and it is not offered to the buyer as evidence."
        },
        "silence_window": {
          "window": "none",
          "seconds": null,
          "accepted_by_silence": false,
          "note": "None. Nothing on this service becomes accepted by the passage of time: settlement is queued at delivery on the synchronous routes and at upstream acceptance on the asynchronous ones, and no timer anywhere converts a buyer's silence into acceptance, closes a complaint or finalises a charge that would otherwise be open. A job that failed after payment keeps reporting `refund_due` on every poll — that flag has no expiry, and not polling does not spend it."
        }
      }
    },
    {
      "url": "https://kino402.com/v1/forms/ugc-product-video",
      "method": "POST",
      "description": "UGC product video, compiled and rendered from a structured brief. Parametric: $0.32 to $17.394 — the unpaid 402 quotes the exact price for the brief sent.",
      "mimeType": "application/json",
      "accepts": [
        {
          "scheme": "exact",
          "network": "eip155:8453",
          "amount": "320000",
          "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
          "payTo": "0x2A266c87F7b0D1F8A471D2d5234F5CF4FB62b206"
        },
        {
          "scheme": "exact",
          "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
          "amount": "320000",
          "asset": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
          "payTo": "FZFwXPrnGUKZ9YzgfgXbmbaDzAS8dNEjcrBXkXoKbX9A"
        }
      ],
      "billing_terms": {
        "billable_unit": {
          "unit": "one call",
          "price": {
            "currency": "USD",
            "min": "0.32",
            "max": "17.394",
            "min_atomic": "320000",
            "max_atomic": "17394000",
            "quote": "the unpaid 402 answering the body sent"
          },
          "metered": false,
          "settles_at": "upstream acceptance of the render",
          "note": "One call. A single signed authorization buys exactly one call at the amount that call's own 402 quoted, and the whole quoted amount settles or nothing does — there is no partial, metered or per-second billing and no charge is ever split across a retry. kino402 prices are parametric, so the band published here is the floor and the ceiling this resource can quote; the unpaid 402 answering the body you actually sent is the authority on the number, and it is the number that settles."
        },
        "hold": {
          "held": false,
          "note": "None. Verification is a read at the facilitator (verifyPayment in worker/kino.js), so nothing is reserved, escrowed or held: the signed authorization moves no funds until it is submitted at settle, which runs in ctx.waitUntil after the response has already been sent. An authorization that never reaches settle is simply never submitted, and no balance of yours was ever encumbered while it was outstanding."
        },
        "idempotency": {
          "key": "sha256(signed authorization: network + payer + nonce on EVM, network + transaction on Solana)",
          "headers": [
            "PAYMENT-SIGNATURE",
            "X-PAYMENT"
          ],
          "idempotency_key_header": null,
          "replay": {
            "status": 402,
            "error": "payment_already_used"
          },
          "note": "There is no idempotency-key header. The key is the signed authorization itself, read out of the payment header — PAYMENT-SIGNATURE for x402 v2, X-PAYMENT for x402 v1, and PAYMENT-SIGNATURE is the one read when a request carries both: on Base the SHA-256 of the network, the payer address and the EIP-3009 nonce, on Solana of the network and the serialized transaction's decoded bytes (claimKeyOf in worker/kino.js). Re-encoding the same authorization — whitespace, key order, the other protocol version, a respelled base64 transaction — is therefore the same key, and a payment missing its network's authorization field is refused 402 `malformed_payment_header` before anything is claimed. The key is claimed single-use by claimPaymentOnce after the payment verifies and before any work is ordered. A second request carrying the same authorization, concurrently or an hour later, is answered 402 with invalidReason `payment_already_used` and the live terms re-offered: it submits no render, compiles no prompt, synthesises no audio and settles nothing. Sign a fresh authorization, with a fresh nonce, to buy another call."
        },
        "post_payment_error": {
          "settles": false,
          "before_settlement": "authorization released — the same header can be presented again",
          "after_settlement": "settled at upstream acceptance: one automatic resubmission, then status `failed` with `refund_due` true",
          "note": "No exit before settlement charges anything, and none of them keeps the single-use claim — an exit before the claim never took it, an exit after it hands it back — so the very same header can be presented again: a body that does not price, a payment the facilitator refuses, a facilitator that cannot be reached at all (503), an image URL that does not fetch as an image, an upstream queue that will not take the job, a brief that will not compile, a synthesis that returns no audio, a job row that cannot be written. After that point the answer depends on how the route delivers. The synchronous routes settle behind a response that already carries the product, so there is no window in which you have paid and have nothing. The asynchronous routes settle when the upstream ACCEPTS the render rather than when the file lands, so a render that fails afterwards has already been paid for: it is resubmitted once automatically on the same job row, and a second failure sets status `failed` with `refund_due` true."
        },
        "refund": {
          "path": "none",
          "dispute": "none",
          "automatic": false,
          "flagged_as": "`refund_due` on GET /v1/jobs/{id}",
          "contact": "support@kino402.com",
          "note": "No automatic refund and no self-service one. There is no refund endpoint, no credit, no dispute endpoint and no reversal of a settled payment anywhere in this service. The mechanism is non-charge rather than refund: an authorization for work that was never accepted is never submitted, so no funds move at all. The single case where money moved and no product exists — an asynchronous render that failed twice — is reported as `refund_due` on the free GET /v1/jobs/{id} and refunded by hand against that job id, by mail to support@kino402.com. Anything else is that same address and a conversation, not a guaranteed remedy."
        },
        "acceptance_observer": {
          "observer": "the buyer",
          "observed_from": "{job_id, status_url} in the 200, then GET /v1/jobs/{id} until status is `completed` or `failed`",
          "third_party_attestation": "none",
          "note": "The buyer, from the 200 this service returns. No third party attests, no oracle is consulted and nothing has to be signed back: on the asynchronous routes the 200 carries {job_id, status_url} and the free, unauthenticated GET /v1/jobs/{id} is where you watch the render reach `completed` with its video_url or `failed` with its reason, and on the synchronous routes the 200 body IS the product — the compiled prompt as JSON, or the mp3. kino402 keeps its own settlement ledger, but that is an operator's record for reconciliation and it is not offered to the buyer as evidence."
        },
        "silence_window": {
          "window": "none",
          "seconds": null,
          "accepted_by_silence": false,
          "note": "None. Nothing on this service becomes accepted by the passage of time: settlement is queued at delivery on the synchronous routes and at upstream acceptance on the asynchronous ones, and no timer anywhere converts a buyer's silence into acceptance, closes a complaint or finalises a charge that would otherwise be open. A job that failed after payment keeps reporting `refund_due` on every poll — that flag has no expiry, and not polling does not spend it."
        }
      }
    },
    {
      "url": "https://kino402.com/v1/forms/product-hero-loop",
      "method": "POST",
      "description": "Product hero loop, compiled and rendered from a structured brief. Parametric: $0.19 to $0.449 — the unpaid 402 quotes the exact price for the brief sent.",
      "mimeType": "application/json",
      "accepts": [
        {
          "scheme": "exact",
          "network": "eip155:8453",
          "amount": "190000",
          "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
          "payTo": "0x2A266c87F7b0D1F8A471D2d5234F5CF4FB62b206"
        },
        {
          "scheme": "exact",
          "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
          "amount": "190000",
          "asset": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
          "payTo": "FZFwXPrnGUKZ9YzgfgXbmbaDzAS8dNEjcrBXkXoKbX9A"
        }
      ],
      "billing_terms": {
        "billable_unit": {
          "unit": "one call",
          "price": {
            "currency": "USD",
            "min": "0.19",
            "max": "0.449",
            "min_atomic": "190000",
            "max_atomic": "449000",
            "quote": "the unpaid 402 answering the body sent"
          },
          "metered": false,
          "settles_at": "upstream acceptance of the render",
          "note": "One call. A single signed authorization buys exactly one call at the amount that call's own 402 quoted, and the whole quoted amount settles or nothing does — there is no partial, metered or per-second billing and no charge is ever split across a retry. kino402 prices are parametric, so the band published here is the floor and the ceiling this resource can quote; the unpaid 402 answering the body you actually sent is the authority on the number, and it is the number that settles."
        },
        "hold": {
          "held": false,
          "note": "None. Verification is a read at the facilitator (verifyPayment in worker/kino.js), so nothing is reserved, escrowed or held: the signed authorization moves no funds until it is submitted at settle, which runs in ctx.waitUntil after the response has already been sent. An authorization that never reaches settle is simply never submitted, and no balance of yours was ever encumbered while it was outstanding."
        },
        "idempotency": {
          "key": "sha256(signed authorization: network + payer + nonce on EVM, network + transaction on Solana)",
          "headers": [
            "PAYMENT-SIGNATURE",
            "X-PAYMENT"
          ],
          "idempotency_key_header": null,
          "replay": {
            "status": 402,
            "error": "payment_already_used"
          },
          "note": "There is no idempotency-key header. The key is the signed authorization itself, read out of the payment header — PAYMENT-SIGNATURE for x402 v2, X-PAYMENT for x402 v1, and PAYMENT-SIGNATURE is the one read when a request carries both: on Base the SHA-256 of the network, the payer address and the EIP-3009 nonce, on Solana of the network and the serialized transaction's decoded bytes (claimKeyOf in worker/kino.js). Re-encoding the same authorization — whitespace, key order, the other protocol version, a respelled base64 transaction — is therefore the same key, and a payment missing its network's authorization field is refused 402 `malformed_payment_header` before anything is claimed. The key is claimed single-use by claimPaymentOnce after the payment verifies and before any work is ordered. A second request carrying the same authorization, concurrently or an hour later, is answered 402 with invalidReason `payment_already_used` and the live terms re-offered: it submits no render, compiles no prompt, synthesises no audio and settles nothing. Sign a fresh authorization, with a fresh nonce, to buy another call."
        },
        "post_payment_error": {
          "settles": false,
          "before_settlement": "authorization released — the same header can be presented again",
          "after_settlement": "settled at upstream acceptance: one automatic resubmission, then status `failed` with `refund_due` true",
          "note": "No exit before settlement charges anything, and none of them keeps the single-use claim — an exit before the claim never took it, an exit after it hands it back — so the very same header can be presented again: a body that does not price, a payment the facilitator refuses, a facilitator that cannot be reached at all (503), an image URL that does not fetch as an image, an upstream queue that will not take the job, a brief that will not compile, a synthesis that returns no audio, a job row that cannot be written. After that point the answer depends on how the route delivers. The synchronous routes settle behind a response that already carries the product, so there is no window in which you have paid and have nothing. The asynchronous routes settle when the upstream ACCEPTS the render rather than when the file lands, so a render that fails afterwards has already been paid for: it is resubmitted once automatically on the same job row, and a second failure sets status `failed` with `refund_due` true."
        },
        "refund": {
          "path": "none",
          "dispute": "none",
          "automatic": false,
          "flagged_as": "`refund_due` on GET /v1/jobs/{id}",
          "contact": "support@kino402.com",
          "note": "No automatic refund and no self-service one. There is no refund endpoint, no credit, no dispute endpoint and no reversal of a settled payment anywhere in this service. The mechanism is non-charge rather than refund: an authorization for work that was never accepted is never submitted, so no funds move at all. The single case where money moved and no product exists — an asynchronous render that failed twice — is reported as `refund_due` on the free GET /v1/jobs/{id} and refunded by hand against that job id, by mail to support@kino402.com. Anything else is that same address and a conversation, not a guaranteed remedy."
        },
        "acceptance_observer": {
          "observer": "the buyer",
          "observed_from": "{job_id, status_url} in the 200, then GET /v1/jobs/{id} until status is `completed` or `failed`",
          "third_party_attestation": "none",
          "note": "The buyer, from the 200 this service returns. No third party attests, no oracle is consulted and nothing has to be signed back: on the asynchronous routes the 200 carries {job_id, status_url} and the free, unauthenticated GET /v1/jobs/{id} is where you watch the render reach `completed` with its video_url or `failed` with its reason, and on the synchronous routes the 200 body IS the product — the compiled prompt as JSON, or the mp3. kino402 keeps its own settlement ledger, but that is an operator's record for reconciliation and it is not offered to the buyer as evidence."
        },
        "silence_window": {
          "window": "none",
          "seconds": null,
          "accepted_by_silence": false,
          "note": "None. Nothing on this service becomes accepted by the passage of time: settlement is queued at delivery on the synchronous routes and at upstream acceptance on the asynchronous ones, and no timer anywhere converts a buyer's silence into acceptance, closes a complaint or finalises a charge that would otherwise be open. A job that failed after payment keeps reporting `refund_due` on every poll — that flag has no expiry, and not polling does not spend it."
        }
      }
    },
    {
      "url": "https://kino402.com/v1/forms/launch-teaser",
      "method": "POST",
      "description": "Launch teaser, compiled and rendered from a structured brief. Parametric: $0.32 to $0.838 — the unpaid 402 quotes the exact price for the brief sent.",
      "mimeType": "application/json",
      "accepts": [
        {
          "scheme": "exact",
          "network": "eip155:8453",
          "amount": "320000",
          "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
          "payTo": "0x2A266c87F7b0D1F8A471D2d5234F5CF4FB62b206"
        },
        {
          "scheme": "exact",
          "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
          "amount": "320000",
          "asset": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
          "payTo": "FZFwXPrnGUKZ9YzgfgXbmbaDzAS8dNEjcrBXkXoKbX9A"
        }
      ],
      "billing_terms": {
        "billable_unit": {
          "unit": "one call",
          "price": {
            "currency": "USD",
            "min": "0.32",
            "max": "0.838",
            "min_atomic": "320000",
            "max_atomic": "838000",
            "quote": "the unpaid 402 answering the body sent"
          },
          "metered": false,
          "settles_at": "upstream acceptance of the render",
          "note": "One call. A single signed authorization buys exactly one call at the amount that call's own 402 quoted, and the whole quoted amount settles or nothing does — there is no partial, metered or per-second billing and no charge is ever split across a retry. kino402 prices are parametric, so the band published here is the floor and the ceiling this resource can quote; the unpaid 402 answering the body you actually sent is the authority on the number, and it is the number that settles."
        },
        "hold": {
          "held": false,
          "note": "None. Verification is a read at the facilitator (verifyPayment in worker/kino.js), so nothing is reserved, escrowed or held: the signed authorization moves no funds until it is submitted at settle, which runs in ctx.waitUntil after the response has already been sent. An authorization that never reaches settle is simply never submitted, and no balance of yours was ever encumbered while it was outstanding."
        },
        "idempotency": {
          "key": "sha256(signed authorization: network + payer + nonce on EVM, network + transaction on Solana)",
          "headers": [
            "PAYMENT-SIGNATURE",
            "X-PAYMENT"
          ],
          "idempotency_key_header": null,
          "replay": {
            "status": 402,
            "error": "payment_already_used"
          },
          "note": "There is no idempotency-key header. The key is the signed authorization itself, read out of the payment header — PAYMENT-SIGNATURE for x402 v2, X-PAYMENT for x402 v1, and PAYMENT-SIGNATURE is the one read when a request carries both: on Base the SHA-256 of the network, the payer address and the EIP-3009 nonce, on Solana of the network and the serialized transaction's decoded bytes (claimKeyOf in worker/kino.js). Re-encoding the same authorization — whitespace, key order, the other protocol version, a respelled base64 transaction — is therefore the same key, and a payment missing its network's authorization field is refused 402 `malformed_payment_header` before anything is claimed. The key is claimed single-use by claimPaymentOnce after the payment verifies and before any work is ordered. A second request carrying the same authorization, concurrently or an hour later, is answered 402 with invalidReason `payment_already_used` and the live terms re-offered: it submits no render, compiles no prompt, synthesises no audio and settles nothing. Sign a fresh authorization, with a fresh nonce, to buy another call."
        },
        "post_payment_error": {
          "settles": false,
          "before_settlement": "authorization released — the same header can be presented again",
          "after_settlement": "settled at upstream acceptance: one automatic resubmission, then status `failed` with `refund_due` true",
          "note": "No exit before settlement charges anything, and none of them keeps the single-use claim — an exit before the claim never took it, an exit after it hands it back — so the very same header can be presented again: a body that does not price, a payment the facilitator refuses, a facilitator that cannot be reached at all (503), an image URL that does not fetch as an image, an upstream queue that will not take the job, a brief that will not compile, a synthesis that returns no audio, a job row that cannot be written. After that point the answer depends on how the route delivers. The synchronous routes settle behind a response that already carries the product, so there is no window in which you have paid and have nothing. The asynchronous routes settle when the upstream ACCEPTS the render rather than when the file lands, so a render that fails afterwards has already been paid for: it is resubmitted once automatically on the same job row, and a second failure sets status `failed` with `refund_due` true."
        },
        "refund": {
          "path": "none",
          "dispute": "none",
          "automatic": false,
          "flagged_as": "`refund_due` on GET /v1/jobs/{id}",
          "contact": "support@kino402.com",
          "note": "No automatic refund and no self-service one. There is no refund endpoint, no credit, no dispute endpoint and no reversal of a settled payment anywhere in this service. The mechanism is non-charge rather than refund: an authorization for work that was never accepted is never submitted, so no funds move at all. The single case where money moved and no product exists — an asynchronous render that failed twice — is reported as `refund_due` on the free GET /v1/jobs/{id} and refunded by hand against that job id, by mail to support@kino402.com. Anything else is that same address and a conversation, not a guaranteed remedy."
        },
        "acceptance_observer": {
          "observer": "the buyer",
          "observed_from": "{job_id, status_url} in the 200, then GET /v1/jobs/{id} until status is `completed` or `failed`",
          "third_party_attestation": "none",
          "note": "The buyer, from the 200 this service returns. No third party attests, no oracle is consulted and nothing has to be signed back: on the asynchronous routes the 200 carries {job_id, status_url} and the free, unauthenticated GET /v1/jobs/{id} is where you watch the render reach `completed` with its video_url or `failed` with its reason, and on the synchronous routes the 200 body IS the product — the compiled prompt as JSON, or the mp3. kino402 keeps its own settlement ledger, but that is an operator's record for reconciliation and it is not offered to the buyer as evidence."
        },
        "silence_window": {
          "window": "none",
          "seconds": null,
          "accepted_by_silence": false,
          "note": "None. Nothing on this service becomes accepted by the passage of time: settlement is queued at delivery on the synchronous routes and at upstream acceptance on the asynchronous ones, and no timer anywhere converts a buyer's silence into acceptance, closes a complaint or finalises a charge that would otherwise be open. A job that failed after payment keeps reporting `refund_due` on every poll — that flag has no expiry, and not polling does not spend it."
        }
      }
    },
    {
      "url": "https://kino402.com/v1/forms/faceless-explainer",
      "method": "POST",
      "description": "Faceless explainer, compiled and rendered from a structured brief. Parametric: $0.32 to $0.838 — the unpaid 402 quotes the exact price for the brief sent.",
      "mimeType": "application/json",
      "accepts": [
        {
          "scheme": "exact",
          "network": "eip155:8453",
          "amount": "320000",
          "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
          "payTo": "0x2A266c87F7b0D1F8A471D2d5234F5CF4FB62b206"
        },
        {
          "scheme": "exact",
          "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
          "amount": "320000",
          "asset": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
          "payTo": "FZFwXPrnGUKZ9YzgfgXbmbaDzAS8dNEjcrBXkXoKbX9A"
        }
      ],
      "billing_terms": {
        "billable_unit": {
          "unit": "one call",
          "price": {
            "currency": "USD",
            "min": "0.32",
            "max": "0.838",
            "min_atomic": "320000",
            "max_atomic": "838000",
            "quote": "the unpaid 402 answering the body sent"
          },
          "metered": false,
          "settles_at": "upstream acceptance of the render",
          "note": "One call. A single signed authorization buys exactly one call at the amount that call's own 402 quoted, and the whole quoted amount settles or nothing does — there is no partial, metered or per-second billing and no charge is ever split across a retry. kino402 prices are parametric, so the band published here is the floor and the ceiling this resource can quote; the unpaid 402 answering the body you actually sent is the authority on the number, and it is the number that settles."
        },
        "hold": {
          "held": false,
          "note": "None. Verification is a read at the facilitator (verifyPayment in worker/kino.js), so nothing is reserved, escrowed or held: the signed authorization moves no funds until it is submitted at settle, which runs in ctx.waitUntil after the response has already been sent. An authorization that never reaches settle is simply never submitted, and no balance of yours was ever encumbered while it was outstanding."
        },
        "idempotency": {
          "key": "sha256(signed authorization: network + payer + nonce on EVM, network + transaction on Solana)",
          "headers": [
            "PAYMENT-SIGNATURE",
            "X-PAYMENT"
          ],
          "idempotency_key_header": null,
          "replay": {
            "status": 402,
            "error": "payment_already_used"
          },
          "note": "There is no idempotency-key header. The key is the signed authorization itself, read out of the payment header — PAYMENT-SIGNATURE for x402 v2, X-PAYMENT for x402 v1, and PAYMENT-SIGNATURE is the one read when a request carries both: on Base the SHA-256 of the network, the payer address and the EIP-3009 nonce, on Solana of the network and the serialized transaction's decoded bytes (claimKeyOf in worker/kino.js). Re-encoding the same authorization — whitespace, key order, the other protocol version, a respelled base64 transaction — is therefore the same key, and a payment missing its network's authorization field is refused 402 `malformed_payment_header` before anything is claimed. The key is claimed single-use by claimPaymentOnce after the payment verifies and before any work is ordered. A second request carrying the same authorization, concurrently or an hour later, is answered 402 with invalidReason `payment_already_used` and the live terms re-offered: it submits no render, compiles no prompt, synthesises no audio and settles nothing. Sign a fresh authorization, with a fresh nonce, to buy another call."
        },
        "post_payment_error": {
          "settles": false,
          "before_settlement": "authorization released — the same header can be presented again",
          "after_settlement": "settled at upstream acceptance: one automatic resubmission, then status `failed` with `refund_due` true",
          "note": "No exit before settlement charges anything, and none of them keeps the single-use claim — an exit before the claim never took it, an exit after it hands it back — so the very same header can be presented again: a body that does not price, a payment the facilitator refuses, a facilitator that cannot be reached at all (503), an image URL that does not fetch as an image, an upstream queue that will not take the job, a brief that will not compile, a synthesis that returns no audio, a job row that cannot be written. After that point the answer depends on how the route delivers. The synchronous routes settle behind a response that already carries the product, so there is no window in which you have paid and have nothing. The asynchronous routes settle when the upstream ACCEPTS the render rather than when the file lands, so a render that fails afterwards has already been paid for: it is resubmitted once automatically on the same job row, and a second failure sets status `failed` with `refund_due` true."
        },
        "refund": {
          "path": "none",
          "dispute": "none",
          "automatic": false,
          "flagged_as": "`refund_due` on GET /v1/jobs/{id}",
          "contact": "support@kino402.com",
          "note": "No automatic refund and no self-service one. There is no refund endpoint, no credit, no dispute endpoint and no reversal of a settled payment anywhere in this service. The mechanism is non-charge rather than refund: an authorization for work that was never accepted is never submitted, so no funds move at all. The single case where money moved and no product exists — an asynchronous render that failed twice — is reported as `refund_due` on the free GET /v1/jobs/{id} and refunded by hand against that job id, by mail to support@kino402.com. Anything else is that same address and a conversation, not a guaranteed remedy."
        },
        "acceptance_observer": {
          "observer": "the buyer",
          "observed_from": "{job_id, status_url} in the 200, then GET /v1/jobs/{id} until status is `completed` or `failed`",
          "third_party_attestation": "none",
          "note": "The buyer, from the 200 this service returns. No third party attests, no oracle is consulted and nothing has to be signed back: on the asynchronous routes the 200 carries {job_id, status_url} and the free, unauthenticated GET /v1/jobs/{id} is where you watch the render reach `completed` with its video_url or `failed` with its reason, and on the synchronous routes the 200 body IS the product — the compiled prompt as JSON, or the mp3. kino402 keeps its own settlement ledger, but that is an operator's record for reconciliation and it is not offered to the buyer as evidence."
        },
        "silence_window": {
          "window": "none",
          "seconds": null,
          "accepted_by_silence": false,
          "note": "None. Nothing on this service becomes accepted by the passage of time: settlement is queued at delivery on the synchronous routes and at upstream acceptance on the asynchronous ones, and no timer anywhere converts a buyer's silence into acceptance, closes a complaint or finalises a charge that would otherwise be open. A job that failed after payment keeps reporting `refund_due` on every poll — that flag has no expiry, and not polling does not spend it."
        }
      }
    },
    {
      "url": "https://kino402.com/v1/prompts/ugc-product-video",
      "method": "POST",
      "description": "UGC product video prompt: the compiled prompt and its render plan back as JSON, no video. Flat $0.008 per call.",
      "mimeType": "application/json",
      "accepts": [
        {
          "scheme": "exact",
          "network": "eip155:8453",
          "amount": "8000",
          "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
          "payTo": "0x2A266c87F7b0D1F8A471D2d5234F5CF4FB62b206"
        },
        {
          "scheme": "exact",
          "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
          "amount": "8000",
          "asset": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
          "payTo": "FZFwXPrnGUKZ9YzgfgXbmbaDzAS8dNEjcrBXkXoKbX9A"
        }
      ],
      "billing_terms": {
        "billable_unit": {
          "unit": "one call",
          "price": {
            "currency": "USD",
            "min": "0.008",
            "max": "0.008",
            "min_atomic": "8000",
            "max_atomic": "8000",
            "quote": "the unpaid 402 answering the body sent"
          },
          "metered": false,
          "settles_at": "delivery of the response body",
          "note": "One call. A single signed authorization buys exactly one call at the amount that call's own 402 quoted, and the whole quoted amount settles or nothing does — there is no partial, metered or per-second billing and no charge is ever split across a retry. kino402 prices are parametric, so the band published here is the floor and the ceiling this resource can quote; the unpaid 402 answering the body you actually sent is the authority on the number, and it is the number that settles."
        },
        "hold": {
          "held": false,
          "note": "None. Verification is a read at the facilitator (verifyPayment in worker/kino.js), so nothing is reserved, escrowed or held: the signed authorization moves no funds until it is submitted at settle, which runs in ctx.waitUntil after the response has already been sent. An authorization that never reaches settle is simply never submitted, and no balance of yours was ever encumbered while it was outstanding."
        },
        "idempotency": {
          "key": "sha256(signed authorization: network + payer + nonce on EVM, network + transaction on Solana)",
          "headers": [
            "PAYMENT-SIGNATURE",
            "X-PAYMENT"
          ],
          "idempotency_key_header": null,
          "replay": {
            "status": 402,
            "error": "payment_already_used"
          },
          "note": "There is no idempotency-key header. The key is the signed authorization itself, read out of the payment header — PAYMENT-SIGNATURE for x402 v2, X-PAYMENT for x402 v1, and PAYMENT-SIGNATURE is the one read when a request carries both: on Base the SHA-256 of the network, the payer address and the EIP-3009 nonce, on Solana of the network and the serialized transaction's decoded bytes (claimKeyOf in worker/kino.js). Re-encoding the same authorization — whitespace, key order, the other protocol version, a respelled base64 transaction — is therefore the same key, and a payment missing its network's authorization field is refused 402 `malformed_payment_header` before anything is claimed. The key is claimed single-use by claimPaymentOnce after the payment verifies and before any work is ordered. A second request carrying the same authorization, concurrently or an hour later, is answered 402 with invalidReason `payment_already_used` and the live terms re-offered: it submits no render, compiles no prompt, synthesises no audio and settles nothing. Sign a fresh authorization, with a fresh nonce, to buy another call."
        },
        "post_payment_error": {
          "settles": false,
          "before_settlement": "authorization released — the same header can be presented again",
          "after_settlement": "none — settlement is queued only once the product is in the response",
          "note": "No exit before settlement charges anything, and none of them keeps the single-use claim — an exit before the claim never took it, an exit after it hands it back — so the very same header can be presented again: a body that does not price, a payment the facilitator refuses, a facilitator that cannot be reached at all (503), an image URL that does not fetch as an image, an upstream queue that will not take the job, a brief that will not compile, a synthesis that returns no audio, a job row that cannot be written. After that point the answer depends on how the route delivers. The synchronous routes settle behind a response that already carries the product, so there is no window in which you have paid and have nothing. The asynchronous routes settle when the upstream ACCEPTS the render rather than when the file lands, so a render that fails afterwards has already been paid for: it is resubmitted once automatically on the same job row, and a second failure sets status `failed` with `refund_due` true."
        },
        "refund": {
          "path": "none",
          "dispute": "none",
          "automatic": false,
          "flagged_as": "none",
          "contact": "support@kino402.com",
          "note": "No automatic refund and no self-service one. There is no refund endpoint, no credit, no dispute endpoint and no reversal of a settled payment anywhere in this service. The mechanism is non-charge rather than refund: an authorization for work that was never accepted is never submitted, so no funds move at all. The single case where money moved and no product exists — an asynchronous render that failed twice — is reported as `refund_due` on the free GET /v1/jobs/{id} and refunded by hand against that job id, by mail to support@kino402.com. Anything else is that same address and a conversation, not a guaranteed remedy."
        },
        "acceptance_observer": {
          "observer": "the buyer",
          "observed_from": "the 200 response body, which is the product",
          "third_party_attestation": "none",
          "note": "The buyer, from the 200 this service returns. No third party attests, no oracle is consulted and nothing has to be signed back: on the asynchronous routes the 200 carries {job_id, status_url} and the free, unauthenticated GET /v1/jobs/{id} is where you watch the render reach `completed` with its video_url or `failed` with its reason, and on the synchronous routes the 200 body IS the product — the compiled prompt as JSON, or the mp3. kino402 keeps its own settlement ledger, but that is an operator's record for reconciliation and it is not offered to the buyer as evidence."
        },
        "silence_window": {
          "window": "none",
          "seconds": null,
          "accepted_by_silence": false,
          "note": "None. Nothing on this service becomes accepted by the passage of time: settlement is queued at delivery on the synchronous routes and at upstream acceptance on the asynchronous ones, and no timer anywhere converts a buyer's silence into acceptance, closes a complaint or finalises a charge that would otherwise be open. A job that failed after payment keeps reporting `refund_due` on every poll — that flag has no expiry, and not polling does not spend it."
        }
      }
    },
    {
      "url": "https://kino402.com/v1/prompts/product-hero-loop",
      "method": "POST",
      "description": "Product hero loop prompt: the compiled prompt and its render plan back as JSON, no video. Flat $0.006 per call.",
      "mimeType": "application/json",
      "accepts": [
        {
          "scheme": "exact",
          "network": "eip155:8453",
          "amount": "6000",
          "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
          "payTo": "0x2A266c87F7b0D1F8A471D2d5234F5CF4FB62b206"
        },
        {
          "scheme": "exact",
          "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
          "amount": "6000",
          "asset": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
          "payTo": "FZFwXPrnGUKZ9YzgfgXbmbaDzAS8dNEjcrBXkXoKbX9A"
        }
      ],
      "billing_terms": {
        "billable_unit": {
          "unit": "one call",
          "price": {
            "currency": "USD",
            "min": "0.006",
            "max": "0.006",
            "min_atomic": "6000",
            "max_atomic": "6000",
            "quote": "the unpaid 402 answering the body sent"
          },
          "metered": false,
          "settles_at": "delivery of the response body",
          "note": "One call. A single signed authorization buys exactly one call at the amount that call's own 402 quoted, and the whole quoted amount settles or nothing does — there is no partial, metered or per-second billing and no charge is ever split across a retry. kino402 prices are parametric, so the band published here is the floor and the ceiling this resource can quote; the unpaid 402 answering the body you actually sent is the authority on the number, and it is the number that settles."
        },
        "hold": {
          "held": false,
          "note": "None. Verification is a read at the facilitator (verifyPayment in worker/kino.js), so nothing is reserved, escrowed or held: the signed authorization moves no funds until it is submitted at settle, which runs in ctx.waitUntil after the response has already been sent. An authorization that never reaches settle is simply never submitted, and no balance of yours was ever encumbered while it was outstanding."
        },
        "idempotency": {
          "key": "sha256(signed authorization: network + payer + nonce on EVM, network + transaction on Solana)",
          "headers": [
            "PAYMENT-SIGNATURE",
            "X-PAYMENT"
          ],
          "idempotency_key_header": null,
          "replay": {
            "status": 402,
            "error": "payment_already_used"
          },
          "note": "There is no idempotency-key header. The key is the signed authorization itself, read out of the payment header — PAYMENT-SIGNATURE for x402 v2, X-PAYMENT for x402 v1, and PAYMENT-SIGNATURE is the one read when a request carries both: on Base the SHA-256 of the network, the payer address and the EIP-3009 nonce, on Solana of the network and the serialized transaction's decoded bytes (claimKeyOf in worker/kino.js). Re-encoding the same authorization — whitespace, key order, the other protocol version, a respelled base64 transaction — is therefore the same key, and a payment missing its network's authorization field is refused 402 `malformed_payment_header` before anything is claimed. The key is claimed single-use by claimPaymentOnce after the payment verifies and before any work is ordered. A second request carrying the same authorization, concurrently or an hour later, is answered 402 with invalidReason `payment_already_used` and the live terms re-offered: it submits no render, compiles no prompt, synthesises no audio and settles nothing. Sign a fresh authorization, with a fresh nonce, to buy another call."
        },
        "post_payment_error": {
          "settles": false,
          "before_settlement": "authorization released — the same header can be presented again",
          "after_settlement": "none — settlement is queued only once the product is in the response",
          "note": "No exit before settlement charges anything, and none of them keeps the single-use claim — an exit before the claim never took it, an exit after it hands it back — so the very same header can be presented again: a body that does not price, a payment the facilitator refuses, a facilitator that cannot be reached at all (503), an image URL that does not fetch as an image, an upstream queue that will not take the job, a brief that will not compile, a synthesis that returns no audio, a job row that cannot be written. After that point the answer depends on how the route delivers. The synchronous routes settle behind a response that already carries the product, so there is no window in which you have paid and have nothing. The asynchronous routes settle when the upstream ACCEPTS the render rather than when the file lands, so a render that fails afterwards has already been paid for: it is resubmitted once automatically on the same job row, and a second failure sets status `failed` with `refund_due` true."
        },
        "refund": {
          "path": "none",
          "dispute": "none",
          "automatic": false,
          "flagged_as": "none",
          "contact": "support@kino402.com",
          "note": "No automatic refund and no self-service one. There is no refund endpoint, no credit, no dispute endpoint and no reversal of a settled payment anywhere in this service. The mechanism is non-charge rather than refund: an authorization for work that was never accepted is never submitted, so no funds move at all. The single case where money moved and no product exists — an asynchronous render that failed twice — is reported as `refund_due` on the free GET /v1/jobs/{id} and refunded by hand against that job id, by mail to support@kino402.com. Anything else is that same address and a conversation, not a guaranteed remedy."
        },
        "acceptance_observer": {
          "observer": "the buyer",
          "observed_from": "the 200 response body, which is the product",
          "third_party_attestation": "none",
          "note": "The buyer, from the 200 this service returns. No third party attests, no oracle is consulted and nothing has to be signed back: on the asynchronous routes the 200 carries {job_id, status_url} and the free, unauthenticated GET /v1/jobs/{id} is where you watch the render reach `completed` with its video_url or `failed` with its reason, and on the synchronous routes the 200 body IS the product — the compiled prompt as JSON, or the mp3. kino402 keeps its own settlement ledger, but that is an operator's record for reconciliation and it is not offered to the buyer as evidence."
        },
        "silence_window": {
          "window": "none",
          "seconds": null,
          "accepted_by_silence": false,
          "note": "None. Nothing on this service becomes accepted by the passage of time: settlement is queued at delivery on the synchronous routes and at upstream acceptance on the asynchronous ones, and no timer anywhere converts a buyer's silence into acceptance, closes a complaint or finalises a charge that would otherwise be open. A job that failed after payment keeps reporting `refund_due` on every poll — that flag has no expiry, and not polling does not spend it."
        }
      }
    },
    {
      "url": "https://kino402.com/v1/prompts/launch-teaser",
      "method": "POST",
      "description": "Launch teaser prompt: the compiled prompt and its render plan back as JSON, no video. Flat $0.005 per call.",
      "mimeType": "application/json",
      "accepts": [
        {
          "scheme": "exact",
          "network": "eip155:8453",
          "amount": "5000",
          "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
          "payTo": "0x2A266c87F7b0D1F8A471D2d5234F5CF4FB62b206"
        },
        {
          "scheme": "exact",
          "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
          "amount": "5000",
          "asset": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
          "payTo": "FZFwXPrnGUKZ9YzgfgXbmbaDzAS8dNEjcrBXkXoKbX9A"
        }
      ],
      "billing_terms": {
        "billable_unit": {
          "unit": "one call",
          "price": {
            "currency": "USD",
            "min": "0.005",
            "max": "0.005",
            "min_atomic": "5000",
            "max_atomic": "5000",
            "quote": "the unpaid 402 answering the body sent"
          },
          "metered": false,
          "settles_at": "delivery of the response body",
          "note": "One call. A single signed authorization buys exactly one call at the amount that call's own 402 quoted, and the whole quoted amount settles or nothing does — there is no partial, metered or per-second billing and no charge is ever split across a retry. kino402 prices are parametric, so the band published here is the floor and the ceiling this resource can quote; the unpaid 402 answering the body you actually sent is the authority on the number, and it is the number that settles."
        },
        "hold": {
          "held": false,
          "note": "None. Verification is a read at the facilitator (verifyPayment in worker/kino.js), so nothing is reserved, escrowed or held: the signed authorization moves no funds until it is submitted at settle, which runs in ctx.waitUntil after the response has already been sent. An authorization that never reaches settle is simply never submitted, and no balance of yours was ever encumbered while it was outstanding."
        },
        "idempotency": {
          "key": "sha256(signed authorization: network + payer + nonce on EVM, network + transaction on Solana)",
          "headers": [
            "PAYMENT-SIGNATURE",
            "X-PAYMENT"
          ],
          "idempotency_key_header": null,
          "replay": {
            "status": 402,
            "error": "payment_already_used"
          },
          "note": "There is no idempotency-key header. The key is the signed authorization itself, read out of the payment header — PAYMENT-SIGNATURE for x402 v2, X-PAYMENT for x402 v1, and PAYMENT-SIGNATURE is the one read when a request carries both: on Base the SHA-256 of the network, the payer address and the EIP-3009 nonce, on Solana of the network and the serialized transaction's decoded bytes (claimKeyOf in worker/kino.js). Re-encoding the same authorization — whitespace, key order, the other protocol version, a respelled base64 transaction — is therefore the same key, and a payment missing its network's authorization field is refused 402 `malformed_payment_header` before anything is claimed. The key is claimed single-use by claimPaymentOnce after the payment verifies and before any work is ordered. A second request carrying the same authorization, concurrently or an hour later, is answered 402 with invalidReason `payment_already_used` and the live terms re-offered: it submits no render, compiles no prompt, synthesises no audio and settles nothing. Sign a fresh authorization, with a fresh nonce, to buy another call."
        },
        "post_payment_error": {
          "settles": false,
          "before_settlement": "authorization released — the same header can be presented again",
          "after_settlement": "none — settlement is queued only once the product is in the response",
          "note": "No exit before settlement charges anything, and none of them keeps the single-use claim — an exit before the claim never took it, an exit after it hands it back — so the very same header can be presented again: a body that does not price, a payment the facilitator refuses, a facilitator that cannot be reached at all (503), an image URL that does not fetch as an image, an upstream queue that will not take the job, a brief that will not compile, a synthesis that returns no audio, a job row that cannot be written. After that point the answer depends on how the route delivers. The synchronous routes settle behind a response that already carries the product, so there is no window in which you have paid and have nothing. The asynchronous routes settle when the upstream ACCEPTS the render rather than when the file lands, so a render that fails afterwards has already been paid for: it is resubmitted once automatically on the same job row, and a second failure sets status `failed` with `refund_due` true."
        },
        "refund": {
          "path": "none",
          "dispute": "none",
          "automatic": false,
          "flagged_as": "none",
          "contact": "support@kino402.com",
          "note": "No automatic refund and no self-service one. There is no refund endpoint, no credit, no dispute endpoint and no reversal of a settled payment anywhere in this service. The mechanism is non-charge rather than refund: an authorization for work that was never accepted is never submitted, so no funds move at all. The single case where money moved and no product exists — an asynchronous render that failed twice — is reported as `refund_due` on the free GET /v1/jobs/{id} and refunded by hand against that job id, by mail to support@kino402.com. Anything else is that same address and a conversation, not a guaranteed remedy."
        },
        "acceptance_observer": {
          "observer": "the buyer",
          "observed_from": "the 200 response body, which is the product",
          "third_party_attestation": "none",
          "note": "The buyer, from the 200 this service returns. No third party attests, no oracle is consulted and nothing has to be signed back: on the asynchronous routes the 200 carries {job_id, status_url} and the free, unauthenticated GET /v1/jobs/{id} is where you watch the render reach `completed` with its video_url or `failed` with its reason, and on the synchronous routes the 200 body IS the product — the compiled prompt as JSON, or the mp3. kino402 keeps its own settlement ledger, but that is an operator's record for reconciliation and it is not offered to the buyer as evidence."
        },
        "silence_window": {
          "window": "none",
          "seconds": null,
          "accepted_by_silence": false,
          "note": "None. Nothing on this service becomes accepted by the passage of time: settlement is queued at delivery on the synchronous routes and at upstream acceptance on the asynchronous ones, and no timer anywhere converts a buyer's silence into acceptance, closes a complaint or finalises a charge that would otherwise be open. A job that failed after payment keeps reporting `refund_due` on every poll — that flag has no expiry, and not polling does not spend it."
        }
      }
    },
    {
      "url": "https://kino402.com/v1/prompts/faceless-explainer",
      "method": "POST",
      "description": "Faceless explainer prompt: the compiled prompt and its render plan back as JSON, no video. Flat $0.009 per call.",
      "mimeType": "application/json",
      "accepts": [
        {
          "scheme": "exact",
          "network": "eip155:8453",
          "amount": "9000",
          "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
          "payTo": "0x2A266c87F7b0D1F8A471D2d5234F5CF4FB62b206"
        },
        {
          "scheme": "exact",
          "network": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
          "amount": "9000",
          "asset": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
          "payTo": "FZFwXPrnGUKZ9YzgfgXbmbaDzAS8dNEjcrBXkXoKbX9A"
        }
      ],
      "billing_terms": {
        "billable_unit": {
          "unit": "one call",
          "price": {
            "currency": "USD",
            "min": "0.009",
            "max": "0.009",
            "min_atomic": "9000",
            "max_atomic": "9000",
            "quote": "the unpaid 402 answering the body sent"
          },
          "metered": false,
          "settles_at": "delivery of the response body",
          "note": "One call. A single signed authorization buys exactly one call at the amount that call's own 402 quoted, and the whole quoted amount settles or nothing does — there is no partial, metered or per-second billing and no charge is ever split across a retry. kino402 prices are parametric, so the band published here is the floor and the ceiling this resource can quote; the unpaid 402 answering the body you actually sent is the authority on the number, and it is the number that settles."
        },
        "hold": {
          "held": false,
          "note": "None. Verification is a read at the facilitator (verifyPayment in worker/kino.js), so nothing is reserved, escrowed or held: the signed authorization moves no funds until it is submitted at settle, which runs in ctx.waitUntil after the response has already been sent. An authorization that never reaches settle is simply never submitted, and no balance of yours was ever encumbered while it was outstanding."
        },
        "idempotency": {
          "key": "sha256(signed authorization: network + payer + nonce on EVM, network + transaction on Solana)",
          "headers": [
            "PAYMENT-SIGNATURE",
            "X-PAYMENT"
          ],
          "idempotency_key_header": null,
          "replay": {
            "status": 402,
            "error": "payment_already_used"
          },
          "note": "There is no idempotency-key header. The key is the signed authorization itself, read out of the payment header — PAYMENT-SIGNATURE for x402 v2, X-PAYMENT for x402 v1, and PAYMENT-SIGNATURE is the one read when a request carries both: on Base the SHA-256 of the network, the payer address and the EIP-3009 nonce, on Solana of the network and the serialized transaction's decoded bytes (claimKeyOf in worker/kino.js). Re-encoding the same authorization — whitespace, key order, the other protocol version, a respelled base64 transaction — is therefore the same key, and a payment missing its network's authorization field is refused 402 `malformed_payment_header` before anything is claimed. The key is claimed single-use by claimPaymentOnce after the payment verifies and before any work is ordered. A second request carrying the same authorization, concurrently or an hour later, is answered 402 with invalidReason `payment_already_used` and the live terms re-offered: it submits no render, compiles no prompt, synthesises no audio and settles nothing. Sign a fresh authorization, with a fresh nonce, to buy another call."
        },
        "post_payment_error": {
          "settles": false,
          "before_settlement": "authorization released — the same header can be presented again",
          "after_settlement": "none — settlement is queued only once the product is in the response",
          "note": "No exit before settlement charges anything, and none of them keeps the single-use claim — an exit before the claim never took it, an exit after it hands it back — so the very same header can be presented again: a body that does not price, a payment the facilitator refuses, a facilitator that cannot be reached at all (503), an image URL that does not fetch as an image, an upstream queue that will not take the job, a brief that will not compile, a synthesis that returns no audio, a job row that cannot be written. After that point the answer depends on how the route delivers. The synchronous routes settle behind a response that already carries the product, so there is no window in which you have paid and have nothing. The asynchronous routes settle when the upstream ACCEPTS the render rather than when the file lands, so a render that fails afterwards has already been paid for: it is resubmitted once automatically on the same job row, and a second failure sets status `failed` with `refund_due` true."
        },
        "refund": {
          "path": "none",
          "dispute": "none",
          "automatic": false,
          "flagged_as": "none",
          "contact": "support@kino402.com",
          "note": "No automatic refund and no self-service one. There is no refund endpoint, no credit, no dispute endpoint and no reversal of a settled payment anywhere in this service. The mechanism is non-charge rather than refund: an authorization for work that was never accepted is never submitted, so no funds move at all. The single case where money moved and no product exists — an asynchronous render that failed twice — is reported as `refund_due` on the free GET /v1/jobs/{id} and refunded by hand against that job id, by mail to support@kino402.com. Anything else is that same address and a conversation, not a guaranteed remedy."
        },
        "acceptance_observer": {
          "observer": "the buyer",
          "observed_from": "the 200 response body, which is the product",
          "third_party_attestation": "none",
          "note": "The buyer, from the 200 this service returns. No third party attests, no oracle is consulted and nothing has to be signed back: on the asynchronous routes the 200 carries {job_id, status_url} and the free, unauthenticated GET /v1/jobs/{id} is where you watch the render reach `completed` with its video_url or `failed` with its reason, and on the synchronous routes the 200 body IS the product — the compiled prompt as JSON, or the mp3. kino402 keeps its own settlement ledger, but that is an operator's record for reconciliation and it is not offered to the buyer as evidence."
        },
        "silence_window": {
          "window": "none",
          "seconds": null,
          "accepted_by_silence": false,
          "note": "None. Nothing on this service becomes accepted by the passage of time: settlement is queued at delivery on the synchronous routes and at upstream acceptance on the asynchronous ones, and no timer anywhere converts a buyer's silence into acceptance, closes a complaint or finalises a charge that would otherwise be open. A job that failed after payment keeps reporting `refund_due` on every poll — that flag has no expiry, and not polling does not spend it."
        }
      }
    }
  ],
  "free": [
    {
      "url": "https://kino402.com/v1/models",
      "method": "GET",
      "description": "the full rate card: every model id, its parameter ranges, the rate formula and a worked price"
    }
  ],
  "note": "Prices are parametric: each accepts entry carries the FLOOR of that resource's band, and the unpaid 402 the resource answers quotes the exact amount for the body sent — that 402 is the authority on amount, payTo and rails for one call. Base leads every accepts array; a second rail is a second way to pay the same quote, never a second price."
}