Skip to main content
WURK accepts x402 v2 payments in native USDC on Solana and Base. Start without PAYMENT-SIGNATURE; a payable response has HTTP 402, PAYMENT-REQUIRED and nonempty accepts. Use your x402 client to sign the complete returned requirements, then send the saved payment once. Creation/payment rejects X-API-Key, SIGN-IN-WITH-X, Authorization and X-WURK-Auth with 400 X402_PAYMENT_AUTH_FORBIDDEN. The verified paying wallet determines ownership. Account authentication belongs on its documented read and account operations.

​
Check the quote

Before signing, verify the intended task and spending limit against the exact resource, network, USDC asset, payTo, atomic amount, expiry and all extra metadata. Do not reconstruct the amount from a catalog price or reward budget. Different checkouts can have identical amounts; a normal wallet transfer does not replace the x402 proof. Privately save the original request, full challenge and signed payment before submitting. Save the response and any PAYMENT-RESPONSE receipt afterward. A payment response can precede work activation.

​
Checkout families

This contract applies to Advanced with reward_token:"USDC", all Contests, store purchases and direct hires.
  1. Save the complete JSON body and a unique idempotencyKey: 8–128 letters, digits or ._:-.
  2. Generate 32 cryptographically random bytes and encode them as unpadded base64url. Save this private token before the initial request and send it as X-Checkout-Token. An initial request without the header can return a server-generated token; save it immediately.
  3. Inspect the 402’s payment requirements and checkout. The checkout includes id, token, payment deadlines and a statusCheck descriptor. An unpaid checkout has no canonical funded job yet.
  4. Sign the full returned requirement, including extra.wurkGuestToken. Preserve the Solana memo. On Base, use the exact advertised extra.wurkGuestNonce for the EIP-3009 signature.
  5. Repeat the original endpoint, HTTP method and body/key, retaining X-Checkout-Token and adding PAYMENT-SIGNATURE. The quote’s resource.url can include a checkout identifier; it binds the signature and is not an instruction to replace the saved creation body.
  6. Follow checkout.statusCheck with the saved token and no payment header. After verified payment reservation the response includes the linked job or purchase; follow its funding and work state.
The verified payment reuses or creates the payer’s WURK account. It does not issue an API key or browser session. The checkout token authorizes only that checkout; it cannot read account history or send account support messages.
A Base signer must preserve extra.wurkGuestNonce. The stock @x402/evm 2.28.0 signer generates its own nonce and needs an adapter for these checkouts. Follow the maintained payment-client example.

​
Payment-and-secret families

Basic, Advanced WURK and Preselection WURK/USDC accept a complete request without payment, followed by a retry with the original input and signed proof. They do not acquire the checkout idempotency contract above. Save jobId, secret, statusUrl and the receipt from the result. For social quick routes, the actual challenge commonly identifies a canonical GET /api/x402/jobs/{jobId}/pay resource, or /api/x402/base/jobs/{jobId}/pay. Pay that returned resource, or retry the same public URL with unchanged input. Some utility routes use a different payment resource. Do not apply one retry-URL rule to every family. Social SDK/CLI 0.7.1 payments resume reads only the local journal; it does not query remote payment or fulfillment status or recover missing job/raid IDs. For an unresolved social payment, preserve the original references and follow social recovery before taking further action. Do not create a replacement payment. A PENDING_JOB_NOT_FOUND response is not evidence that a previous payment failed. If payment was submitted, reconcile the saved job/payment before requesting a replacement. If nothing was signed or submitted, obtain a fresh challenge for the intended operation.

​
Status and recovery

USDC reward and store/hire quotes last thirty minutes; SOL/WURK Contest conversion quotes last two minutes. Settlement must start with more than sixty seconds remaining. Use payment.initiateBefore, not merely expiresAt. After a timeout, 202 or uncertain error, read status before any payment retry. Retry a saved signed payment only with its original complete payload while the checkout is still awaiting payment. Once payment is reserved, a different payment is rejected. Do not rerun signing as automatic recovery. Advanced USDC and Contest share an idempotency namespace; store and hire share another. Changing family, network or intent under an existing key conflicts. Keep a separate key and token for each new purchase. If a token or response is lost, use the supported account authentication or fresh payer-wallet SIWX on that operation’s status/recovery route. A public transaction or idempotency key alone cannot reveal a secret. See the maintained recovery guide.