Conçu pour des acheteurs qui ne sont pas humains.
Chaque lien de paiement CryptoPayIn et chaque boutique fait aussi office de paiement lisible par machine. Un agent IA découvre ce que vous vendez, crée une facture et paie on-chain en trois appels HTTP — sans navigateur, sans clé API, sans intervention humaine. Livraison incluse, en JSON.
Trois appels. C’est toute l’intégration.
Prenez n'importe quel lien — disons https://cryptopaylink.co/pay/PL-XXXXXXX.
Ajoutez .json et le flux machine démarre. Tout ce qui suit fonctionne déjà aujourd'hui, sur chaque lien.
Ce qui est vendu, le prix, les actifs acceptés, et les champs exacts attendus par l'appel de facturation — auto-descriptif, de sorte qu'un agent n'a besoin d'aucune connaissance préalable du vendeur.
{
"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 seul corps JSON — l'actif, plus tout ce que le lien exige (montant pour un tarif libre, variante,
champs acheteur, adresse de livraison pour les produits physiques). Envoyez un en-tête Idempotency-Key et les nouvelles tentatives ne peuvent jamais créer de double facture.
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" } }Le montant est exact et le taux est verrouillé — l'agent envoie précisément
pay.amount sur pay.network depuis n'importe quel portefeuille qu'il contrôle. Pas de SDK, pas de schéma de signature, pas de facilitateur.
Interrogez toutes les quelques secondes. Les confirmations avancent, et dès que le paiement est finalisé, la réponse contient la livraison — contenu, lien, ou clé de licence réservée exactement à ce paiement.
Les boutiques parlent le même protocole. GET /s/SH-x.json liste le catalogue
complet d'une boutique (produits, variantes, stock en temps réel) ; un seul POST /s/SH-x/order transforme un panier en facture
payable — le reçu se trouve à /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" } }Une ingénierie sobre, par choix
Les factures des agents passent par exactement la même validation, le même verrouillage de taux et la même dérivation d'adresse que la page hébergée — un seul chemin de code, aucune implémentation parallèle susceptible de diverger ou d'être exploitée.
Les points de terminaison agents consomment les mêmes quotas de limitation de débit et les mêmes plafonds de factures en attente que la page. Activer les agents n'ajoute aucune capacité supplémentaire pour l'épuisement d'adresses ou le spam.
Ni cookies, ni sessions, ni surface CSRF sur le domaine de paiement. L'identifiant de paiement est le seul pouvoir d'accès, exactement comme l'URL de reçu destinée aux humains.
L'en-tête Idempotency-Key rend la création de facture sûre en cas de nouvel envoi ; la même clé avec un corps différent est refusée avec un code 409.
Le paiement par agent est configurable par compte et activé par défaut. Le désactiver renvoie 403 sur les points de terminaison machine, tandis que chaque page humaine continue de fonctionner.
Les pages humaines envoient Link: …/pay/PL-x.json; rel="alternate", et ce contrat est résumé dans llms.txt à l'intention des moteurs de réponse.
Tout ce qu'un lien de paiement peut vendre
Contenu texte, URL privées, clés de licence à usage unique — livrés dans le JSON du reçu, réservés par paiement, sans risque de conflit sous limite de stock.
Prix fixes dans l'une des 30 devises fiduciaires, ou montants libres (pourboires, factures, recharges) avec un min/max défini par le vendeur — l'agent transmet "amount".
Variantes de produits avec stock par variante, plus des champs obligatoires personnalisés (noms d'utilisateur, notes de commande) déclarés dans le document de découverte.
L'appel de facturation accepte une adresse de livraison structurée, validée selon le pays de destination — les agents peuvent commander des objets livrés dans des cartons.
GET /s/SH-x.json expose le catalogue complet d'une boutique avec le stock en temps réel ; un seul POST …/order valide le panier, réserve le stock et renvoie la facture.
Vendre aux agents, c'est le côté acheteur. Si vous construisez le côté vendeur — créer des liens, consulter les soldes, effectuer des retraits — c'est l'API REST marchand, tout aussi scriptable.
Vos questions sur les agents, en clair
Un agent a-t-il besoin d'une clé API ou d'un compte ?
Non. La découverte, la création de facture et le reçu sont des points de terminaison publics propres à un lien de paiement — exactement comme la page de paiement destinée aux humains. L'identifiant de paiement renvoyé à la création est le seul identifiant dont l'agent a besoin pour consulter son propre reçu. Les clés API marchand existent pour les vendeurs, pas pour les acheteurs.
Comment l'agent paie-t-il concrètement ?
La réponse de facturation contient une adresse de dépôt, un montant exact et une URI de type BIP-21. N'importe quel portefeuille contrôlé par l'agent — un portefeuille BTC, un signataire EVM, une paire de clés Solana, un portefeuille Monero — envoie ce montant sur le réseau indiqué. Il n'y a aucun schéma de signature propriétaire à intégrer.
S'agit-il de x402 ?
C'est agnostique vis-à-vis du protocole. Toute pile technique capable d'effectuer des appels HTTPS et de diffuser une transaction crypto peut payer — sans facilitateur, sans SDK de portefeuille particulier. Si votre framework parle x402 ou AP2, encapsulez l'appel de facturation dans votre outil de paiement ; le contrat JSON s'aligne proprement sur un flux de type 402, et la négociation x402 native est au programme.
Quels liens et boutiques sont payables par un agent ?
Chaque lien de paiement actif et chaque boutique active, par défaut — prix fixes, montants libres, variantes de produits, champs acheteur, produits physiques avec livraison, et catalogues de boutique complets avec stock en temps réel. Les vendeurs peuvent désactiver le paiement par agent par compte dans les Paramètres ; les points de terminaison répondent alors 403 tandis que les pages destinées aux humains continuent de fonctionner.
Que reçoit l'agent après avoir payé ?
Le point de terminaison du reçu renvoie la livraison en JSON dès que le paiement est finalisé : le contenu, le lien privé, ou une clé de licence réservée à ce paiement. Pour les commandes physiques, il confirme que le vendeur a bien reçu l'adresse de livraison.
Un agent malveillant peut-il abuser des points de terminaison ?
Les appels des agents partagent exactement les mêmes quotas de limitation de débit, plafonds de facturation et règles d'idempotence que la page de paiement hébergée — ils n'ajoutent aucune capacité d'attaque supplémentaire. Il n'y a ni cookies ni sessions sur le domaine de paiement, donc aucun état qu'un appel intersite pourrait exploiter.
Votre prochain client pourrait être un script.
Votre compte est à portée d'un clic — sans KYC, sans attente. Une commission fixe de 1 % par transaction. Aucun abonnement, aucun frais de mise en place.