PAYMENT-SIGNATURE aus und wiederholt die Anfrage dann mit derselben Anfrage.
Der Unterschied besteht darin, dass Bestellzahlungen Plattform-APIs sind und ein Kontotoken benötigen; die direkte Nutzung der AI-API von x402.acedata.cloud kann nur X402 verwenden und benötigt kein API-Token.
Bestellung vorbereiten
Rufe die Ace Data Cloud-Konsole auf, wähle die zu bezahlende Bestellung aus und notiere die Bestell-ID. Wenn du noch keine Bestellung hast, kannst du auf der Paket-Seite eine noch zu bezahlende Bestellung erstellen. Der Bestellpreis richtet sich nach der Anzeige auf der Seite; dasamount in der X402-402-Antwort ist die endgültige Grundlage für die Signatur.
Kontotoken erstellen
Anfragen zur Bestellzahlung benötigen ein Kontotoken. Öffne die Plattform-Token-Seite und erstelle ein Token im Formatplatform-v1-....
Verwende für nachfolgende Anfragen:
402 auslösen
Sende zunächst eine Anfrage ohnePAYMENT-SIGNATURE:
accepts:
x402Version ist 2, network verwendet die CAIP-2-Kennung, und das Betragsfeld ist amount.
Programmausgabe beim Erstellen einer Bestellung über 10 Credits und beim Auslösen von 402:
Die folgenden Transaktionsaufzeichnungen sind historische, praktisch getestete Beispiele unter der alten Richtlinie; Beträge und Transaktions-Hashes bleiben unverändert. Neue X402-Bestellungen erhalten keinen Zahlungsartenrabatt mehr; verwende für Signatur und Zahlung bitte das amount aus der aktuellen 402-Antwort.
- Nach erfolgreicher Erstellung der Bestellung lautet der Status
Pending; zu diesem Zeitpunkt gibt es noch keine On-Chain-Zahlung. - Die erste
pay/-Anfrage enthält keinePAYMENT-SIGNATURE, daher wird HTTP 402 zurückgegeben. acceptsenthält gleichzeitig Baseexactund Solanaexact; in dieser Anleitung wird anschließend Base ausgewählt.- Der Preis bei der Bestellungserstellung beträgt
1.26; bei Zahlung während der alten X402-Zahlungsrabattrichtlinie betrugen der tatsächlich signierte und abgerechnete Betrag1.2USDC, entsprechend1200000Atomic USDC.
resource hier ein vom Server zurückgegebenes und an der Signatur beteiligtes Feld ist; der Client darf das darin enthaltene Protokoll, den Pfad oder die Bestell-ID nicht selbst umschreiben.
Signieren und erneut versuchen
Für Bestellzahlungen können die Low-Level-Signaturfunktionen von@acedatacloud/x402-client oder acedatacloud-x402 wiederverwendet werden. Nachfolgend ein TypeScript-Beispiel:
exact:
status 200bedeutet, dass die Plattform-Bestellzahlungsschnittstelle diesePAYMENT-SIGNATUREakzeptiert hat.has_x_payment_response Truebedeutet, dass der Response-Header einen Base64-kodiertenPAYMENT-RESPONSE-Beleg enthält.settle_header.success=Trueundnetwork=basebedeuten, dass der Facilitator das Base-Settlement abgeschlossen hat.- Der endgültige Bestellstatus ist
Finished,pay_wayistX402, undpay_identhält den On-Chain-Transaktionshash. - Das
Transfer-Ereignis auf BaseScan zeigt, dass die Zahlungsadresse1200000atomic USDC, also1.2USDC, an die Plattform-Empfangsadresse überwiesen hat.
Erfolgreiche Antwort und Beleg
Nach erfolgreicher Bestellzahlung enthält der Response-Body die Bestellinformationen. Die Plattform übermittelt außerdem im Response-HeaderPAYMENT-RESPONSE eine Base64-kodierte Settlement-Response, deren dekodierte häufige Felder Folgendes umfassen:
Wenn du einen Abgleich benötigst, wird empfohlen, gleichzeitig die Bestell-ID, die Zahlungs-Wallet-Adresse,
transaction und den endgültigen Bestellstatus zu speichern.
Hinweise
- Für die Bestellzahlung ist ein Plattformkonto-Token erforderlich; sie kann nicht allein mit einer X402-Wallet-Signatur abgeschlossen werden.
amountverwendet USDC atomic units,1200000bedeutet1.2USDC.- Setze Empfangs- oder Asset-Adressen nicht selbst zusammen; maßgeblich ist
acceptsin der 402-Response. - Wenn dieselbe
PAYMENT-SIGNATUREwiederholt übermittelt wird, führt der Facilitator anhand der Nonce einen Replay-Schutz durch.
Antwort bei fehlgeschlagener Zahlung
Das erste HTTP 402 ohnePAYMENT-SIGNATURE ist eine normale Zahlungs-Challenge und bedeutet nicht, dass die Zahlung fehlgeschlagen ist. Bei einem Fehler der signierten Verifizierung oder des Settlements bleibt das standardmäßige String-error als kompatibler Fallback erhalten, und unter extensions.acedatacloud.paymentError wird eine stabile Fehlerstruktur zurückgegeben:
code lokalisieren; bei unbekanntem Code sollte auf einen allgemeinen Zahlungsfehler zurückgefallen werden. charged ist ein dreistufiges Feld: Nur wenn vor dem Settlement eindeutig abgelehnt wird, wird false zurückgegeben; ein fehlendes Feld bedeutet, dass der Belastungsstatus unbekannt ist, und darf nicht als „nicht belastet“ interpretiert werden. Nachdem die aktuelle Bestellung in Failed übergeht, kann sie nicht mit derselben Bestellung erneut versucht werden; erstelle nach Behebung des Wallet-Problems eine neue Bestellung.
Protokolliere oder übermittle nicht die vollständige PAYMENT-SIGNATURE, Wallet-Signaturen, autorisierte Payloads, ursprüngliche Facilitator-Diagnosen oder RPC-Responses. Für die Untersuchung durch den Kundendienst werden nur die Bestell-ID und der öffentliche Fehler-code benötigt.
