Skip to main content
Erstellen oder aktualisieren Sie eine Zahlungssitzung für eine Pending-Bestellung. Die Zahlungsaktion greift auf den Zahlungskanal zu und kann den Bestellstatus ändern; vor dem Aufruf müssen Bestell-ID, Betrag und Zahlungsmethode bestätigt werden.

​
Schnittstellenübersicht

​
Grenzen der anonymen Zahlung

Anonymer Zugriff dient für Szenarien, in denen der Login-Status nach dem Öffnen eines kopierten Zahlungslinks verloren geht; ein langfristiges Account-Token ist weder erforderlich noch sollte es mitgeführt werden. Anonyme Aufrufe:
  • erlauben nur serverseitig konfigurierte gehostete Weiterleitungszahlungsmethoden;
  • verwenden fest die Desktop-Zahlungsseite;
  • können keine Bestellungen mit einem Preis von null einlösen;
  • unterliegen einer Ratenbegrenzung pro IP und einzelner Bestellung;
  • geben eine minimale Bestellprojektion zurück, die weder Konto, Application noch interne metadata enthält.
Authentifizierte Aufrufer müssen der Bestelleigentümer oder ein Superadministrator sein. Methoden wie X402 und Belohnungseinlösung, die einen Benutzerkontext benötigen, können nicht anonym aufgerufen werden.

​
Anfragebeispiele

Zahlungsmethoden, die Authentifizierung erfordern:
pay_way verwendet tatsächliche Werte, die vom Bestellmodell unterstützt werden, beispielsweise WechatPay, AliPay, Stripe, Card, Airwallex, X402, PayPal, AppleIAP, Reward, BankTransfer. Nicht jeder Wert ist für anonyme Anfragen oder jede Website verfügbar.

​
Antwortbeschreibung

Eine erfolgreiche Antwort ist das aktualisierte Bestellobjekt, das normalerweise über pay_url den Einstieg für den nächsten Schritt bereitstellt; verschiedene Zahlungsmethoden können außerdem in kontrollierten Feldern Informationen zurückgeben, die der Client für die Fortsetzung der Zahlung benötigt. Anonyme Antworten verwenden eine minimale Feld-Whitelist, authentifizierte Eigentümer erhalten vollständige Details. Verlassen Sie sich nicht auf alte Feldnamen wie payment_url, qr_code_url oder payment_method; der aktuelle Order-Vertrag verwendet pay_url und pay_way.

​
iOS-In-App-Kauf

Der eingeloggte Bestelleigentümer kann pay_way: "AppleIAP" übergeben. Diese Anfrage aktualisiert die ausstehende Bestellung anhand von metadata.apple_price des ausgewählten Pakets und entfernt Rabatte; sie führt keine Belastung aus, vergibt keine Credits und gibt keinen Zahlungslink zurück. Alte ausstehende Bestellungen sollten zuerst diesen Schritt abschließen, bevor die native Apple-Zahlung gestartet wird. Es wird nur ein Usage-Paket unterstützt, das über ein konfiguriertes Apple-Produkt und einen Preis verfügt; nicht unterstützte Pakete oder Sammelbestellungen geben 400 zurück. Nach der nativen Apple-Zahlung wird über /api/v1/orders/{id}/apple-verify/ die transaction_id übermittelt, um die serverseitige Verifizierung und die Credit-Vergabe abzuschließen. Die Anzahl der Credits stammt aus dem Paket; der Betrag verwendet den unabhängigen USD-Voreinstellungspreis von Apple, ohne Mitgliederrabatte oder Website-Aufschläge, und der Belastungsbetrag in lokaler Währung für andere Regionen richtet sich nach der Apple-Bestätigungsseite.

​
Fehler und Wiederholung

  • Die Bestellung ist nicht Pending: Gibt 400 zurück; erstellen Sie die Zahlungssitzung nicht erneut.
  • pay_way wurde nicht angegeben: Bestellungen mit einem Betrag ungleich null geben 400 zurück.
  • Ein anonymer Aufruf verwendet eine nicht erlaubte Methode oder eine Bestellung mit einem Preis von null: Gibt 403 zurück; nach dem Login sollte der Eigentümer es erneut versuchen.
  • Authentifiziert, aber nicht der Bestelleigentümer: Gibt 403 zurück.
  • Zahlungskanal fehlgeschlagen: Nicht blind erneut übermitteln; fragen Sie zuerst die Bestelldetails ab und versuchen Sie es erst erneut, nachdem Sie bestätigt haben, dass sie weiterhin Pending ist.

​
Verwandte Schnittstellen