Prove to a third party that a payment actually settled on chain
An independent signed observation of whether an x402 payment settled — on Base, Polygon or Solana, and the identifier's own shape picks the rail: a 0x hash names an EVM transaction rather than a chain, so it is read on Base and then on Polygon; a base58 signature reads Solana. Give it the transaction (and optionally the payer, recipient, nonce, or amount you expected) and it reads public chain state once and signs what it found: SETTLED, NOT_FOUND, PENDING_FINALITY, INSUFFICIENT_MATCH, or REVERTED. Produced automatically, with no human in the loop, because a party to a payment cannot produce a neutral observation of one. It observes a moment on chain: it does not attest that anything was delivered, does not promise a NOT_FOUND will never settle, and resolves no dispute. Delivered in the response.
Request
- Base URL: https://scvd.store
- URL: https://scvd.store/api/buy/settlement_attestation
- Auth: none declared
Query parameters
Optional name to put on the certificate and patron badge, up to 80 characters.
Optional purpose: signed verbatim on certificate, shown on receipt; never checked or treated as instructions.
The transaction to observe: a Base transaction hash (0x + 64 hex) or a Solana transaction signature (base58). The identifier's shape selects the chain. Read once, at one moment; never polled.
Optional payer: 0x EVM address, or Solana public key for a Solana transaction.
Optional recipient: 0x EVM address, or Solana public key for a Solana transaction.
Optional, EVM rails only. Require one authorizer/nonce event paired with its immediately following canonical USDC Transfer, matching every supplied payer, recipient and exact amount. Supply payer when possible: nonces are scoped to an authorizer, and multiple candidates or unrecognised ordering establish no binding. Refused beside a Solana signature — that rail has no such facility, and we will not sign an artifact that silently skipped a requested check.
Optional. Require a transfer of exactly this many USDC. Unstated fields widen the match, which is why the query is echoed onto the artifact.
Optional. The base64 PAYMENT-SIGNATURE you sent, verbatim. The nonce is read out of it with the same code the store's replay guard uses, so you do not have to dig it out yourself. Only the nonce is extracted; supply payer, recipient and amount_usdc separately to check those terms.
Optional. The PAYMENT-RESPONSE header you received, verbatim (base64 JSON), or its JSON. Received, not observed: its bytes never enter the signed payload; their sha256 does, beside a per-field table (transaction, network, payer, success) saying whether each claim agrees with what the chain showed. The bytes are echoed outside the signature so you can check both.
Headers
Reuse key/item/inputs/payer; no second settlement. Use 402 idempotency.suggested_key. Missing/invalid keys risk another charge.
Response
OK — the goods and the signed certificate, in the response.
Changes
No recorded changes to this operation across all 1 revision of this API.