ZAMBO.

Expired time window: the authorization was presented too late.

Some failures are about a clock, not about content. The live x402 Day Pass challenge gives a signed authorization a 900 second window, bounded by validAfter and validBefore. Present it late and the server refuses it. This page documents the pattern only from the live challenge fetched from zambo.dev and from Zambo's own hub documentation. No causes beyond those sources are claimed.

Evidence on this page was fetched first-hand from zambo.dev on 2026-10-24. Part of the failure patterns index.

The evidence: the live challenge, fetched 2026-10-24

GET https://zambo.dev/api/x402/day-pass returns HTTP 402

The unpaid request is answered with the challenge JSON. The accepted terms, as served: x402Version 2, scheme exact, network eip155:8453 (Base), asset 0x833589fcd6edb6e08f4c7c32d4f71b54bda02913 (USDC), amount "990000" atomic units ($0.99), payTo 0xb753be5Eac5B29c711051DfF91279834e9C9b9AC, and maxTimeoutSeconds 900. The authorization type the payer signs is a TransferWithAuthorization whose fields include validAfter and validBefore as unix seconds: the window is part of what is signed, not a server side suggestion. Read the challenge yourself: zambo.dev/api/x402/day-pass.

The server's retry policy, verbatim

The challenge states its own refusal behavior in payment_proof.retry_policy: "A refused invalid signature is retryable with a newly signed authorization. Never reuse a consumed nonce or a prior signature. Request a fresh challenge if expired." The hub's x402 guide adds that the Day Pass "never activates without a verified transfer", so an expired or refused attempt activates nothing. The guide's documented refusal reason list includes expired challenge alongside malformed payload, wrong amount, wrong asset, wrong network, duplicate payment, and policy blocked: see x402 agent payments.

A cousin case in the corpus: a timestamp that cannot exist

Time fields are checked, not trusted. The corpus anchored set includes anchored-bad-timestamp.json, whose anchor carries anchored_at 2026-02-30T12:00:00Z, a date that does not exist (file SHA-256 a3b9b400b552777b6cdfb2ff60704682eb46b541ac59d79a0f310a79f424dbe5). It is filed with the invalid anchored vectors: a time value outside what is possible is rejected, the same discipline a window applies to a time value outside what is allowed.

What gets reported

This class is reported by the server's refusal, not by the AER-1 Section 6 anchor vocabulary: the payment is refused, the challenge's retry policy says a fresh challenge should be requested, and nothing activates. On success the same flow returns an expires_at field, because the Day Pass itself is a window too: $0.99 for 24 hours, after which access is bought again or the free tier applies.

How to fix it

  1. Request a fresh challenge. GET https://zambo.dev/api/x402/day-pass again and work from the new terms, not from a cached copy.
  2. Sign a new authorization inside the new window, with validAfter and validBefore bracketing the moment you will present it, and a fresh nonce.
  3. Never reuse a consumed nonce or a prior signature. The retry policy states this plainly, and a resent expired authorization will be refused again.
  4. Retry the same call once with the new proof in the PAYMENT-SIGNATURE header (X-Payment is also accepted), and keep the access_key, expires_at, and spend receipt from the successful response.

Put your own calls on a checkable record

Start at zambo.dev/add

Add Zambo to your AI at https://zambo.dev/add/. The free tier is 20 free calls per day, then they upgrade. A Day Pass is $0.99 for 24 hours. Every call returns a verifiable receipt, including a call that is rejected, so a failure like the ones on this page leaves a record you can open, check, and learn from instead of a claim you have to trust.

A verifiable receipt proves the saved result was not changed since it was saved. It does not prove the result was right.

Questions

How long is an x402 Day Pass authorization valid?

900 seconds. The live challenge at zambo.dev/api/x402/day-pass sets maxTimeoutSeconds to 900, and the signed TransferWithAuthorization carries validAfter and validBefore unix second fields that bound when it can be presented.

What happens if my payment authorization expires before I send it?

The server refuses it and nothing activates, because the Day Pass never activates without a verified transfer. The challenge's retry policy says to request a fresh challenge if expired, and to sign a newly signed authorization rather than reusing a consumed nonce or a prior signature.

Is an expired challenge the same failure as a wrong amount or wrong network?

No. They are separate entries in the documented refusal reason list: malformed payload, wrong amount, wrong asset, wrong network, expired challenge, duplicate payment, and policy blocked. Each has its own fix, and only the expired one is cured by a fresh challenge and a fresh signature.