Für Käufer gebaut, die keine Menschen sind.
Jeder CryptoPayIn-Payment-Link und jede Storefront fungiert zugleich als maschinenlesbarer Checkout. Ein KI-Agent erkennt, was Sie verkaufen, erstellt eine Rechnung und zahlt on-chain in drei HTTP-Aufrufen — kein Browser, kein API-Schlüssel, kein Mensch im Ablauf. Auslieferung inklusive, in JSON.
Drei Aufrufe. Das ist die gesamte Integration.
Nehmen Sie einen beliebigen Link — etwa https://cryptopaylink.co/pay/PL-XXXXXXX.
Hängen Sie .json an, und der maschinelle Ablauf beginnt. Alles Folgende ist schon heute live, auf jedem Link.
Was verkauft wird, der Preis, akzeptierte Assets und genau die Felder, die der Rechnungsaufruf erwartet — selbstbeschreibend, sodass ein Agent kein Vorwissen über den Verkäufer benötigt.
{
"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" }, … }
}Ein einziger JSON-Body — das Asset sowie alles, was der Link zusätzlich verlangt (Betrag bei offener Preisgestaltung, Variante,
Käuferfelder, Versand bei physischen Waren). Senden Sie einen Idempotency-Key-Header mit, damit Wiederholungsversuche niemals zu einer doppelten Rechnungsstellung führen können.
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" } }Der Betrag ist exakt und der Kurs fixiert — der Agent sendet genau
pay.amount auf pay.network von einem beliebigen Wallet, das er kontrolliert. Kein SDK, kein Signaturschema, kein Facilitator.
Fragen Sie alle paar Sekunden ab. Die Bestätigungen steigen, und sobald die Zahlung abgeschlossen ist, enthält die Antwort die Auslieferung — Inhalt, Link oder einen exakt für diese Zahlung reservierten Lizenzschlüssel.
Shops sprechen dasselbe Protokoll. GET /s/SH-x.json listet den gesamten
Katalog einer Storefront (Produkte, Varianten, Live-Lagerbestand) auf; ein einziger POST /s/SH-x/order verwandelt einen Warenkorb in eine zahlbare
Rechnung — der Beleg liegt unter /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" } }Bewusst unspektakuläres Engineering
Agenten-Rechnungen durchlaufen exakt dieselbe Validierung, Kursfixierung und Adressableitung wie die gehostete Seite — ein einziger Codepfad, keine Schatten-Implementierung, die auseinanderdriften oder ausgenutzt werden könnte.
Agenten-Endpunkte nutzen dieselben Rate-Limit-Buckets und Obergrenzen für offene Rechnungen wie die Seite. Das Aktivieren von Agenten schafft keinerlei zusätzliche Kapazität für Address-Exhaustion oder Spam.
Keine Cookies, keine Sessions, keine CSRF-Angriffsfläche auf der Payment-Domain. Die Payment-ID ist die einzige Berechtigung — genau wie bei der Beleg-URL für Menschen.
Der Idempotency-Key-Header macht die Rechnungserstellung wiederholungssicher; derselbe Schlüssel mit einem anderen Body wird mit 409 abgelehnt.
Der Agent-Checkout ist pro Konto einstellbar und standardmäßig aktiv. Deaktiviert bedeutet 403 auf den maschinellen Endpunkten, während jede Seite für Menschen weiterhin funktioniert.
Seiten für Menschen senden Link: …/pay/PL-x.json; rel="alternate", und dieser Vertrag wird in llms.txt für Answer Engines zusammengefasst.
Alles, was ein Payment-Link verkaufen kann
Textinhalte, private URLs, einmalige Lizenzschlüssel — ausgeliefert im Beleg-JSON, pro Zahlung reserviert, race-sicher bei begrenztem Lagerbestand.
Festpreise in einer von 30 Fiat-Währungen oder offene Beträge (Trinkgelder, Rechnungen, Aufladungen) mit vom Verkäufer festgelegtem Min./Max. — der Agent übergibt "amount".
Produktvarianten mit Lagerbestand je Variante sowie benutzerdefinierte Pflichtfelder (Benutzernamen, Bestellhinweise), die im Discovery-Dokument deklariert sind.
Der Rechnungsaufruf akzeptiert eine strukturierte Versandadresse, validiert je nach Zielland — Agenten können auch Dinge bestellen, die in Paketen ankommen.
GET /s/SH-x.json stellt den vollständigen Katalog eines Shops mit Live-Lagerbestand bereit; ein einziger POST …/order validiert den Warenkorb, reserviert den Lagerbestand und liefert die Rechnung zurück.
Der Verkauf an Agenten ist die Käuferseite. Wenn Sie die Verkäuferseite aufbauen — Links erstellen, Guthaben abfragen, auszahlen —, ist das die Händler-REST-API, und die ist genauso skriptfähig.
Fragen rund um Agenten, klar beantwortet
Benötigt ein Agent einen API-Schlüssel oder ein Konto?
Nein. Discovery, Rechnungserstellung und Beleg sind öffentliche Endpunkte, die auf einen einzelnen Payment-Link beschränkt sind — genau wie die Checkout-Seite für Menschen. Die bei der Erstellung zurückgegebene Payment-ID ist die einzige Anmeldeinformation, die der Agent benötigt, um seinen eigenen Beleg abzufragen. Händler-API-Schlüssel sind für Verkäufer gedacht, nicht für Käufer.
Wie bezahlt der Agent tatsächlich?
Die Antwort auf die Rechnungsanfrage enthält eine Einzahlungsadresse, einen genauen Betrag und eine URI im BIP-21-Stil. Jedes Wallet, das der Agent kontrolliert — ein BTC-Wallet, ein EVM-Signer, ein Solana-Keypair, ein Monero-Wallet — sendet diesen Betrag im angegebenen Netzwerk. Es ist kein proprietäres Signaturschema zu integrieren.
Ist das x402?
Es ist protokollagnostisch. Jeder Stack, der HTTPS-Aufrufe ausführen und eine Krypto-Transaktion broadcasten kann, kann zahlen — ohne Facilitator, ohne spezielles Wallet-SDK. Spricht Ihr Framework x402 oder AP2, betten Sie den Rechnungsaufruf einfach in Ihr Payment-Tool ein; der JSON-Vertrag lässt sich sauber auf einen 402-artigen Ablauf abbilden, und eine native x402-Verhandlung ist für die Roadmap vorgesehen.
Welche Links und Shops können von Agenten bezahlt werden?
Standardmäßig jeder aktive Payment-Link und jede aktive Storefront — Festpreise, offene Beträge, Produktvarianten, Käuferfelder, physische Waren mit Versand sowie vollständige Shop-Kataloge mit Live-Lagerbestand. Verkäufer können den Agent-Checkout pro Konto in den Einstellungen deaktivieren; die Endpunkte antworten dann mit 403, während die Seiten für Menschen weiterhin funktionieren.
Was erhält der Agent nach der Zahlung?
Der Beleg-Endpunkt liefert die Auslieferung in JSON, sobald die Zahlung abgeschlossen ist: den Inhalt, den privaten Link oder einen für diese Zahlung reservierten Lizenzschlüssel. Bei physischen Bestellungen wird bestätigt, dass der Verkäufer die Versandadresse erhalten hat.
Kann ein böswilliger Agent die Endpunkte missbrauchen?
Agent-Aufrufe teilen sich genau dieselben Rate-Limit-Buckets, Rechnungsobergrenzen und Idempotenzregeln wie die gehostete Checkout-Seite — sie schaffen keinerlei zusätzliche Angriffsfläche. Auf der Payment-Domain gibt es weder Cookies noch Sessions, sodass kein Zustand existiert, auf dem ein Cross-Site-Aufruf aufsetzen könnte.
Ihr nächster Kunde könnte ein Skript sein.
Ihr Konto ist nur einen Klick entfernt — kein KYC, kein Warten. Eine pauschale 1% Gebühr pro Transaktion. Keine Abonnements, keine Einrichtungskosten.