Pensato per acquirenti che non sono umani.
Ogni link di pagamento CryptoPayIn e ogni vetrina è anche un checkout leggibile dalle macchine. Un agente IA scopre cosa vendi, crea una fattura e paga on-chain in tre chiamate HTTP — niente browser, niente chiave API, nessun intervento umano. Consegna inclusa, in JSON.
Tre chiamate. Ecco tutta l’integrazione.
Prendi un link qualsiasi — ad esempio https://cryptopaylink.co/pay/PL-XXXXXXX.
Aggiungi .json e il flusso automatico si avvia. Tutto quanto segue è già attivo oggi, su ogni link.
Cosa viene venduto, il prezzo, gli asset accettati e i campi esatti richiesti dalla chiamata di fatturazione — autodescrittivo, così l’agente non ha bisogno di alcuna conoscenza pregressa del venditore.
{
"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" }, … }
}Un unico corpo JSON — l’asset, più tutto ciò che il link richiede (importo per prezzi aperti, variante,
campi per l’acquirente, spedizione per beni fisici). Invia un header Idempotency-Key e i tentativi ripetuti non potranno mai generare una doppia fattura.
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" } }L’importo è esatto e il tasso è bloccato — l’agente invia esattamente
pay.amount su pay.network da qualsiasi wallet che controlla. Nessun SDK, nessuno schema di firma, nessun facilitator.
Effettua un polling ogni pochi secondi. Le conferme avanzano e, nel momento in cui il pagamento si completa, la risposta contiene la consegna — contenuto, link o una chiave di licenza riservata esattamente a questo pagamento.
Anche i negozi parlano lo stesso protocollo. GET /s/SH-x.json elenca l’intero
catalogo di una vetrina (prodotti, varianti, scorte in tempo reale); un unico POST /s/SH-x/order trasforma un carrello in una
fattura pagabile — la ricevuta si trova su /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" } }Un’ingegneria noiosa, per scelta
Le fatture degli agenti seguono esattamente la stessa validazione, lo stesso blocco del tasso e la stessa derivazione degli indirizzi della pagina ospitata — un solo percorso di codice, nessuna implementazione ombra che possa deviare o essere sfruttata.
Gli endpoint per gli agenti consumano gli stessi bucket di rate-limit e gli stessi limiti sulle fatture in sospeso della pagina. Attivare gli agenti non aggiunge alcuna capacità extra per l’esaurimento degli indirizzi o lo spam.
Nessun cookie, nessuna sessione, nessuna superficie CSRF sul dominio di pagamento. L’id di pagamento è l’unica capacità, esattamente come l’URL di ricevuta per gli utenti umani.
L’header Idempotency-Key rende la creazione della fattura sicura contro i replay; la stessa chiave con un corpo diverso viene rifiutata con 409.
Il checkout per agenti è configurabile per account ed è attivo per impostazione predefinita. Disattivarlo significa 403 sugli endpoint automatici, mentre ogni pagina per gli utenti umani continua a funzionare.
Le pagine per gli utenti umani inviano Link: …/pay/PL-x.json; rel="alternate", e questo contratto è riassunto in llms.txt per i motori di risposta.
Tutto ciò che un link di pagamento può vendere
Contenuti testuali, URL privati, chiavi di licenza monouso — consegnati nel JSON della ricevuta, riservati per ogni pagamento, al sicuro da race condition nei limiti di scorta.
Prezzi fissi in una qualsiasi delle 30 valute fiat, oppure importi aperti (mance, fatture, ricariche) con min/max definiti dal venditore — l’agente passa "amount".
Varianti di prodotto con scorte per variante, più campi obbligatori personalizzati (nomi utente, note d’ordine) dichiarati nel documento di scoperta.
La chiamata di fatturazione accetta un indirizzo di spedizione strutturato, convalidato in base al paese di destinazione — gli agenti possono ordinare oggetti che arrivano in scatole.
GET /s/SH-x.json espone il catalogo completo di un negozio con scorte in tempo reale; un unico POST …/order convalida il carrello, riserva le scorte e restituisce la fattura.
Vendere agli agenti riguarda il lato acquirente. Se invece stai costruendo il lato venditore — creare link, leggere i saldi, effettuare prelievi — quella è la API REST per esercenti, ed è altrettanto scriptabile.
Le domande sugli agenti, con risposte chiare
L’agente ha bisogno di una chiave API o di un account?
No. La scoperta, la creazione della fattura e la ricevuta sono endpoint pubblici legati a un singolo link di pagamento — esattamente come la pagina di checkout per gli utenti umani. L’id di pagamento restituito alla creazione è l’unica credenziale di cui l’agente ha bisogno per consultare la propria ricevuta. Le chiavi API per esercenti esistono per i venditori, non per gli acquirenti.
Come paga effettivamente l’agente?
La risposta della fattura contiene un indirizzo di deposito, un importo esatto e un URI in stile BIP-21. Qualsiasi wallet controllato dall’agente — un wallet BTC, un signer EVM, una keypair Solana, un wallet Monero — invia quell’importo sulla rete indicata. Non c’è nessuno schema di firma proprietario da integrare.
Si tratta di x402?
È agnostico rispetto al protocollo. Qualsiasi stack in grado di effettuare chiamate HTTPS e trasmettere una transazione crypto può pagare — senza facilitator, senza SDK di wallet particolari. Se il tuo framework parla x402 o AP2, incapsula la chiamata alla fattura nel tuo strumento di pagamento; il contratto JSON si adatta perfettamente a un flusso in stile 402, e la negoziazione nativa x402 è nella roadmap.
Quali link e negozi sono pagabili dagli agenti?
Ogni link di pagamento attivo e ogni vetrina attiva, per impostazione predefinita — prezzi fissi, importi aperti, varianti di prodotto, campi per l’acquirente, beni fisici con spedizione e cataloghi di negozio completi con scorte in tempo reale. I venditori possono disattivare il checkout per agenti per singolo account nelle Impostazioni; gli endpoint rispondono quindi 403, mentre le pagine per gli utenti umani continuano a funzionare.
Cosa riceve l’agente dopo il pagamento?
L’endpoint della ricevuta restituisce la consegna in JSON nel momento in cui il pagamento si completa: il contenuto, il link privato o una chiave di licenza riservata a quel pagamento. Gli ordini fisici confermano che il venditore ha ricevuto l’indirizzo di spedizione.
Un agente malintenzionato può abusare degli endpoint?
Le chiamate degli agenti condividono esattamente gli stessi bucket di rate-limit, i limiti sulle fatture e le regole di idempotenza della pagina di checkout ospitata — non aggiungono alcuna capacità di attacco extra. Non ci sono cookie né sessioni sul dominio di pagamento, quindi non esiste alcuno stato che una chiamata cross-site possa sfruttare.
Il tuo prossimo cliente potrebbe essere uno script.
Il tuo account è a un clic di distanza — nessun KYC, nessuna attesa. Una commissione fissa dell’1% a transazione. Nessun abbonamento, nessun costo di attivazione.