Built for buyers that aren’t human.
Every CryptoPayIn payment link and storefront doubles as a machine-readable checkout. An AI agent discovers what you sell, creates an invoice and pays on-chain in three HTTP calls — no browser, no API key, no human in the loop. Delivery included, in JSON.
Three calls. That’s the whole integration.
Take any link — say https://cryptopaylink.co/pay/PL-XXXXXXX.
Append .json and the machine flow starts. Everything below is live today, on every link.
What is sold, the price, accepted assets, and the exact fields the invoice call expects — self-describing, so an agent needs no prior knowledge of the seller.
{
"protocol": "cpi-agent-checkout/1",
"link": {
"id": "PL-XXXXXXX", "state": "ok",
"title": "Pro license — 1 seat",
"pricing": { "currency": "USD", "type": "fixed", "amount": "12.00" },
"delivery": { "type": "keys", "description": "A unique key reserved for you…" }
},
"payment_assets": [ { "asset": "BTC", "network": "mainnet", "min_usd": "5.00" }, … ],
"checkout": { "create_invoice": { "method": "POST", "url": "…/invoice" }, … }
}One JSON body — the asset, plus whatever the link requires (amount for open pricing, variant,
buyer fields, shipping for physical goods). Send an Idempotency-Key header and retries can never double-invoice.
curl -X POST https://cryptopaylink.co/pay/PL-XXXXXXX/invoice \
-H "Content-Type: application/json" \
-H "Idempotency-Key: agent-run-42" \
-d '{ "asset": "BTC", "fields": { "Discord username": "buyer#0001" } }'
{ "ok": true, "invoice": {
"payment": "P-XXXXXXXXXX",
"pay": { "asset": "BTC", "network": "mainnet",
"address": "bc1q…", "amount": "0.0001867",
"uri": "bitcoin:bc1q…?amount=0.0001867" },
"expires_at": "2026-07-20T11:00:25Z",
"receipt": "…/receipt?p=P-XXXXXXXXXX" } }The amount is exact and the rate is locked — the agent sends precisely
pay.amount on pay.network from any wallet it controls. No SDK, no signature scheme, no facilitator.
Poll every few seconds. Confirmations advance, and the moment the payment completes the response contains the delivery — content, link, or a license key reserved for exactly this payment.
Shops speak the same protocol. GET /s/SH-x.json lists a storefront’s
whole catalogue (products, variants, live stock); one POST /s/SH-x/order turns a cart into a payable
invoice — the receipt lives at /s/SH-x/o/ORD-…/receipt.
{ "ok": true, "receipt": {
"payment": "P-XXXXXXXXXX", "status": "completed",
"paid_at": "2026-07-20T10:30:58Z",
"delivery": { "type": "keys", "key": "LICENSE-XXXX-YYYY",
"note": "Delivered once, tied to this payment — store it now." },
"next": "done" } }Boring engineering, on purpose
Agent invoices run through the exact validation, rate-locking and address derivation as the hosted page — one code path, no shadow implementation to drift or exploit.
Agent endpoints consume the same rate-limit buckets and pending-invoice caps as the page. Turning agents on adds zero extra capacity for address-exhaustion or spam.
No cookies, no sessions, no CSRF surface on the payment domain. The payment id is the only capability, exactly like the human receipt URL.
The Idempotency-Key header makes invoice creation replay-safe; the same key with a different body is refused with 409.
Agent checkout is per-account and on by default. Off means 403 on the machine endpoints while every human page keeps working.
Human pages send Link: …/pay/PL-x.json; rel="alternate", and this contract is summarised in llms.txt for answer engines.
Everything a payment link can sell
Text content, private URLs, one-time license keys — delivered in the receipt JSON, reserved per payment, race-safe under stock limits.
Fixed prices in any of 30 fiat currencies, or open amounts (tips, invoices, top-ups) with seller-defined min/max — the agent passes "amount".
Product variants with per-variant stock, plus custom required fields (usernames, order notes) declared in the discovery document.
The invoice call accepts a structured shipping address, validated per destination country — agents can order things that arrive in boxes.
GET /s/SH-x.json exposes a shop’s full catalogue with live stock; one POST …/order validates the cart, reserves stock and returns the invoice.
Selling to agents is the buyer side. If you are building the seller side — creating links, reading balances, withdrawing — that is the merchant REST API, and it is just as scriptable.
Agent questions, answered plainly
Does an agent need an API key or an account?
No. Discovery, invoice creation and the receipt are public endpoints scoped to one payment link — exactly like the human checkout page. The payment id returned at creation is the only credential the agent needs to poll its own receipt. Merchant API keys exist for sellers, not buyers.
How does the agent actually pay?
The invoice response contains a deposit address, an exact amount and a BIP-21-style URI. Any wallet the agent controls — a BTC wallet, an EVM signer, a Solana keypair, a Monero wallet — sends that amount on the stated network. There is no proprietary signing scheme to integrate.
Is this x402?
It is protocol-agnostic. Any stack that can make HTTPS calls and broadcast a crypto transaction can pay — no facilitator, no special wallet SDK. If your framework speaks x402 or AP2, wrap the invoice call in your payment tool; the JSON contract maps cleanly onto a 402-style flow, and native x402 negotiation is on the roadmap.
Which links and shops are agent-payable?
Every active payment link and every active storefront, by default — fixed prices, open amounts, product variants, buyer fields, physical goods with shipping, and full shop catalogues with live stock. Sellers can switch agent checkout off per account in Settings; the endpoints then answer 403 while the human pages keep working.
What does the agent receive after paying?
The receipt endpoint returns the delivery in JSON the moment the payment completes: the content, the private link, or a license key reserved for that payment. Physical orders confirm that the seller received the shipping address.
Can a malicious agent abuse the endpoints?
Agent calls share the exact same rate-limit buckets, invoice caps and idempotency rules as the hosted checkout page — they add zero extra attack capacity. There are no cookies or sessions on the payment domain, so there is no state a cross-site call could ride.
Your next customer might be a script.
Your account is one click away — no KYC, no waiting. One flat 1% fee per transaction. No subscriptions, no setup costs.