Rozo's Agent Merchant API removes that assumption. An EVM EOA can onboard as a merchant with one wallet signature; after access is approved, a second, fresh signature authorizes an Orders-only API key for invoicing and payment-status reads. Funds settle as USDC on Base to the signing address, and the agent can poll the API until settlement reaches payout_completed. This guide walks through the whole loop.
What the agent actually gets
- A merchant account keyed to its wallet: the first valid signature creates it, repeat signatures reopen the same account — never a duplicate.
- Settlement locked server-side to USDC on Base at the signing address. No API call can redirect where the money goes.
- An Orders-only API key: under the current contract it can create invoices and read payment state for its account. It cannot issue Admin credentials, manage account settings, or change settlement.
- A payment link for each invoice, which the agent shares with the customer. For EVM merchants in this alpha, settlement is delivered as USDC on Base.
The five-step loop
- Request a challenge: GET /account-nonce?chain=evm&address=$ADDRESS&intent=merchant_onboard. The server returns the exact message to sign; anonymous nonces are rejected.
- Sign locally and onboard: POST /account-onboard with the address, signature, and nonce. The private key never leaves the agent's runtime.
- Request access and issue a scoped credential: call POST /account-credentials/request with the wallet session and re-submit the same request no more than a few times per day to check its status. Once approved, sign a fresh credential_issue challenge and call POST /account-credentials with scope "orders". The issued credential has Orders scope; Orders-only credentials cannot create Admin keys.
- Create an invoice: POST /payment-api with a stable orderId, an Idempotency-Key, display information, and the USDC amount. Do not send a destination. After a network failure, retry with the same orderId and idempotency key.
- Poll payment status: poll with the Orders key and stable orderId until payout_completed. Treat the returned payment state as authoritative even if webhook or email delivery fails. If the response includes a payout transaction hash, you can additionally verify it on Base.
The full machine-readable contract lives at https://partners.rozo.ai/llms.txt — it is written to be pasted directly into an agent.
Why the permissions are deliberately narrow
Giving an autonomous agent a payment credential is exactly the place to be paranoid. The API is designed so the blast radius of a leaked agent key is small:
- Orders-only keys cannot mint other keys or change settlement, and their reads are scoped to their own account. Listing and revoking wallet-issued credentials require a fresh, purpose-bound wallet signature.
- Credential issuance requires a fresh wallet signature — a stolen session token alone cannot mint a key.
- Every challenge is single-use, purpose-bound, and carries a server-provided expiration time.
- The payout address equals the signing address, enforced server-side. A leaked Orders-only API key cannot change the configured settlement address, but it can create unwanted invoices and expose payment state — revoke it promptly with a fresh wallet proof.
Getting access (alpha)
The credential program is invite-gated while in alpha. After onboarding, the agent calls POST /account-credentials/request and re-submits the same request no more than a few times per day to check its status. Approval is a human decision on Rozo's side, but no email or direct message is required. The credential and invoicing loop currently supports EVM EOAs settling USDC on Base. Solana and Stellar EOAs can onboard and settle USDC on their respective signing-address chains, but they are outside this credential loop.
EVM contract wallets are not supported in this alpha, and wallet-only accounts have no recovery path: if the signer key is lost, Rozo cannot recover the merchant or manually transfer ownership.
Start at https://partners.rozo.ai/agent.