A new service is attempting to solve one of the foundational problems for autonomous software agents: how do you schedule recurring work on someone else's infrastructure without a human standing by to enter a credit card number? 402cron, which launched recently, offers scheduled HTTP delivery for machine clients, paid entirely through on-chain payments with no account creation, no email address, and no human intervention required.
The payment protocol is the product
The name is a reference to HTTP status code 402, "Payment Required," and the service takes that concept literally. 402cron accepts payment in USDC on Base using the x402 protocol, a machine-readable payment standard that lets software pay for services the way humans swipe a card. An agent sends USDC, receives delivery credits, and gets a management token tied to the wallet that paid. The token is shown once. Credits never expire.
This design removes the entire account provisioning flow that normally sits between a piece of software and the infrastructure it needs. There is no signup form, no API key to rotate, no subscription to cancel. The agent pays, gets a token, and starts scheduling tasks. The payment itself is the authentication.
Destination verification prevents abuse
Before a task can be scheduled, the target URL must be proven to belong to the requester. 402cron requires HTTPS and posts a challenge to the registered URL, which the caller must echo back. The permission scope covers the specific path and everything beneath it, not the entire domain. This is a deliberate constraint: it prevents a caller from registering a path and then routing unexpected traffic to unrelated endpoints on the same server.
The verification step is lightweight but meaningful. It establishes that whoever is scheduling the task controls the destination, which matters when the service is sending signed HTTP requests on a recurring basis. Without this step, the system could be weaponized to send traffic to arbitrary servers at someone else's expense.
At-least-once delivery with idempotency baked in
The delivery model is at-least-once. Every request carries an HMAC signature, a timestamp, and a delivery ID that remains stable across retries. If an acknowledgement is lost, the same delivery ID arrives again. The service explicitly instructs callers to treat repeated delivery IDs as already handled, which pushes idempotency responsibility to the recipient in a way that matches how most modern API consumers already work.
Recipients have a two-second window to return 202 and move the actual work to a background process. This timeout covers acceptance only, not completion. The distinction matters: a slow database query or a long-running computation doesn't consume the delivery window. The agent just needs to acknowledge that it received the request and will handle it.
Retry logic is specific and documented
The retry policy draws clear lines between different failure modes. Timeouts and unreachable hosts are retried up to three times per execution, then the task pauses itself. Server responses in the 4xx or 5xx range are treated as definitive answers, not transient faults, and are never retried. However, 20 consecutive refusals or 10 consecutive server errors trigger an automatic pause.
This policy reflects a practical understanding of how scheduled HTTP delivery actually fails. A timeout usually means something is wrong with the network or the target is temporarily down. A 404 means the endpoint doesn't exist. A 500 means the server understood the request and chose to fail. Treating these differently avoids wasting credits on retries that won't help while still catching genuine transient issues.
The task status always indicates which condition caused a pause, and resuming requires a single API call. The pause is not a failure state. It's a circuit breaker.
Pricing favors high-frequency use
You pay per delivery attempt, not per outcome. A successful delivery, a server error, a timeout, and an unreachable host each cost one credit. 402cron's own failures cost nothing, and skipped executions, when the previous delivery is still running, also cost nothing. A single failing cycle burns at most three credits.
The pricing tiers scale from a trial pack of 20 attempts for $0.02 up to 50,000 attempts for $25. You purchase a quantity of credits, not a time-bound subscription. A month's worth of credits that sits unused while an agent sleeps is a month you paid for but didn't consume. This model rewards consistent usage and penalizes idle subscriptions, which aligns the cost structure with how machine clients actually behave.
Why this matters for autonomous agents
The real significance of 402cron isn't the cron functionality. Standard cron jobs and cloud scheduler services have existed for decades. What's new is the payment model and the absence of human involvement. An autonomous agent can discover the service, pay for it, configure a scheduled task, and begin receiving signed HTTP requests without any human touching a keyboard.
This is infrastructure designed for a world where software is a customer. The A2A agent card at /.well-known/agent-card.json and the machine-readable pricing at /api/pricing aren't features. They're the product interface. The landing page with its prose explanation is for humans evaluating the service. The JSON endpoints are for agents that already know what they need.
For developers building agents that need to poll an API, trigger a webhook, or maintain a heartbeat on a schedule, 402cron removes the dependency on human-managed infrastructure. That's a small but necessary step toward making autonomous agents genuinely autonomous.