Credits und Aufladungen

Fünf Zahlungswege, verifizierte Aufladungen und sichere Wiederholungen.

Zuletzt aktualisiert: 30.09.2026

Mit einem Draft beginnen

Fordere einen Auflade-Draft mit einem write-Token an. Lies vor der Zahlung Mindestbetrag, Asset-Kurse, Verfügbarkeit, Bonus und Caps aus pricing. Der Beispielbetrag beträgt mindestens 10.000 Credits und unterschreitet nie den konfigurierten Mindestbetrag dieser Instanz. Credits sind USD-verankert; Asset-Beträge werden berechnet und sind nicht fest. Ein Draft ist eine Zahlungsanweisung, keine Gutschrift.

curl -X POST 'https://ftso.app/api/x402/topup' \
  -H 'authorization: Bearer fbx_WRITE_TOKEN' \
  -H 'content-type: application/json' \
  -H 'Idempotency-Key: topup_20260930_001' \
  -d '{"credits":10000,"asset":"FBEST"}'
# asset: FBEST | WFLR | FXRP | FLR | XRP

FBEST, WFLR und FXRP

Der Draft liefert PaymentRouter-Adresse, Asset, amountRaw, deadline, signedBy, typedData und signature. FXRP hat sechs Dezimalstellen; behandle es nicht als Token mit 18 Dezimalstellen. Prüfe erwarteten Router und Treasury gegen die öffentliche Konfiguration, lies settlementSigner() und verifiziere die EIP-712-Signatur kryptografisch. Ein Vergleich von signedBy allein prüft keine Signatur. Prüfe buyer, asset, amount, Chain, Deadline, feeBps=0 und mode=0 vor der Freigabe und dem Aufruf von pay().

// draft is response.topup; router and token are viem contract instances.
// Verify the complete authorization before approval or payment.
const m = draft.typedData.message;
await token.write.approve([draft.routerAddress, BigInt(draft.amountRaw)]);
const txHash = await router.write.pay([
  { ...m, amount: BigInt(m.amount), deadline: BigInt(m.deadline), nonce: m.nonce },
  draft.signature,
]);
curl -X POST 'https://ftso.app/api/x402/topup/HANDLE/confirm' \
  -H 'authorization: Bearer fbx_WRITE_TOKEN' \
  -H 'content-type: application/json' \
  -d '{"txHash":"0xPAY_TRANSACTION_HASH"}'

Die Bestätigung prüft die Zahlung vor der Gutschrift. Ein Transaktionshash allein beweist keine bezahlte Aufladung. Der Router überträgt den autorisierten Betrag; eine doppelte Bestätigung kann keine zweite Gutschrift erzeugen.

Natives FLR

Sende amountWei aus dem Draft an payTo auf Chain 14 und übernimm den exakten 32-Byte-Handle dataHex. Eine Token-Freigabe ist nicht nötig. Bestätige danach den Transaktionshash. Credits hängen vom eingegangenen Betrag ab, werden abgerundet und durch konfigurierte Caps begrenzt.

await wallet.sendTransaction({
  to: draft.payTo,
  value: BigInt(draft.amountWei),
  data: draft.dataHex,
  chainId: 14,
});

Natives XRP

Nutze die zurückgegebene XRPL-Adresse und destinationTag zusammen mit amountDrops. Der Destination Tag ordnet die Zahlung der richtigen Aufladung zu. Frage den Status mit einem read-Token ab; der Worker schreibt eine verifizierte eingegangene Zahlung asynchron gut. Es gibt keine garantierte Abschlusszeit. Eine optionale FDC-Attestation folgt der Gutschrift und ist keine Voraussetzung dafür. verifiedByFdc kann false bleiben.

curl 'https://ftso.app/api/x402/topup/HANDLE' \
  -H 'authorization: Bearer fbx_READ_TOKEN'

Ablauf und Überzahlungen

Beachte die Draft-Deadline. Verspätete proportionale FLR-/XRP-Zahlungen verwenden den niedrigeren eingefrorenen oder aktuellen Kurs; ohne aktuellen Preis wartet der Worker. Caps je Aufladung begrenzen Gutschriften bei Überzahlungen; das Erreichen einer Bestandsgrenze pausiert neue Drafts. Sende nie ohne Router-Order, dataHex oder destinationTag: Die Anwendung kann eine solche Zahlung nicht zuverlässig zuordnen.

Idempotency-Key

Abo-Käufe mit Bearer-Token benötigen einen Idempotency-Key aus 8–128 Buchstaben, Ziffern, Unterstrichen oder Bindestrichen. Der Header wird auch beim Erstellen von Watches, Auflade-Drafts und Empfängern sowie bei Kanal-PUT unterstützt. Verwende nach einem Timeout denselben Schlüssel und Body. Endgültige Antworten bleiben 24 Stunden gespeichert; ein geänderter Body liefert 409 idempotency_key_reused. Eine aktive Reservierung liefert 409 idempotency_in_progress mit Retry-After. Wiederholbare Fehler geben den Schlüssel frei; abgelaufene Drafts liefern 410 draft_expired. Replays zählen gegen Rate-Limits. Zurückgegebene Secrets können über einen Replay derselben Wallet 24 Stunden lang wiederherstellbar sein.

Verdiente Credits

Verdiente Credits werden getrennt von gekauften Credits geführt. Die bestehende FBEST-Konvertierung verwendet einen Antrag, Admin-Freigabe und Wallet-Claim am ConversionVault; automatische Auszahlung ist nicht implementiert. Den Nutzerablauf beschreibt Credits.

Aufladegrenzen und Credit-Einstellungen

Aktuelle Kurse, Verfügbarkeit und Konfiguration stehen unter /api/x402/pricing. Dieser Abschnitt liest die Konfiguration dieser App-Instanz; er fragt weder Treasury noch einen entfernten Server ab.

  • Mindestbetrag in Credits: 10000
  • USD je 1.000 Credits: 1
  • FBEST: Höchstbetrag je Aufladung: Keine konfigurierte Grenze; Grenze für Treasury-Bestände: Keine konfigurierte Grenze.
  • WFLR: Höchstbetrag je Aufladung: Keine konfigurierte Grenze; Grenze für Treasury-Bestände: Keine konfigurierte Grenze.
  • FXRP: Höchstbetrag je Aufladung: 1000; Grenze für Treasury-Bestände: 5000.
  • FLR: Höchstbetrag je Aufladung: Keine konfigurierte Grenze; Grenze für Treasury-Bestände: Keine konfigurierte Grenze.
  • XRP: Höchstbetrag je Aufladung: 1000; Grenze für Treasury-Bestände: 5000.