Zahlungen und Statusen
Eine Rechnung beschreibt eine Bestellung. Eine Zahlung ist ein konkreter Versuch, diese zu begleichen. Ein Zahlungsversuch und die Verfügbarkeit seines Links sind getrennte Zustände.
Auf dieser Seite
Der Zahlungsdatensatz#
Die Rechnung speichert die Bestellbedingungen; die Zahlung identifiziert ihren Gateway-Vorgang. Der erste Start reserviert eine dauerhafte Bindung und einen Server-Idempotency-Key. Nach Beginn der Übermittlung kann eine andere Methode keine zweite Belastung auf derselben Rechnung erzeugen.
GET /api/payment-links und GET /api/v1/payments geben link.payment an den Eigentümer zurück. Der Status des Links aktiv/pausiert/storniert/abgelaufen ist getrennt vom Zahlungszustand. Ein Kunde kann seinen Vorgang nur über das zufällige Checkout-Token lesen.
| Daten | Zweck |
|---|---|
| Kennung und Bestellung | Den Versuch mit einem Kauf verknüpfen |
| Grundbetrag und Währung | Die Berechnungsgrundlage |
| Zahlungsmethode | Anwendbare Gebühr und Steuer |
| MwSt-Pflichtiger | Wer die Steuer trägt |
| Gebühr, MwSt und Summen | Gespeicherte Berechnung |
| Status und Zeit | Aktueller Transaktionszustand |
| Gateway-Ereignisreferenz | Server-Bestätigungsquelle |
Live-Vorgangszustände#
Die Demo verwendet getrennte Testdatensätze. Das Ändern eines Demo-Zustands bestätigt keine echte Zahlung und ändert keine Finanzdatensätze.
| Status | Bedeutung |
|---|---|
| ausstehend | Vorgang erstellt; wartet auf Aktion oder ein Ergebnis |
| requires_action | Ein Bankcode oder eine Kundenbestätigung ist erforderlich |
| processing | Der Anbieter bestätigt das Ergebnis noch |
| erfolgreich | Der Server hat die genaue Zahlung verifiziert |
| fehlgeschlagen | Versuch ohne bestätigte Zahlung beendet |
| expired | Anweisungen abgelaufen; Abstimmung bleibt verfügbar |
| review_required | Zusätzliche Prüfung ist erforderlich; nicht erneut bezahlen |
| partially_paid | Nur ein Teil des Betrags erhalten; keine weitere Zahlung erzeugen |
| partially_refunded | Ein Teil der Zahlung wurde erstattet |
| refunded | Erstattung bestätigt |
| disputed | Der Vorgang wird angefochten |
Die Quelle der Wahrheit#
Ein signierter Webhook löst eine authentifizierte Abfrage des genauen Gateway-Vorgangs aus. IDs, Bestellung, Währung, Methode, Grund- und Endbetrag, Live-Modus und monotone Version werden validiert. Ein eingehender Ereignisname allein ist kein Beweis für Geld.
Zustand, Beleg und Händlerereignis werden atomar committet. Ältere Antworten können eine neuere Version nicht überschreiben; Duplikate erfüllen nicht zweimal, und ausstehend kann eine bestätigte Zahlung nicht ersetzen. Diese Datensätze erzeugen automatisch kein abhebbares Guthaben oder keine Auszahlung.
Wenn das Ergebnis unbekannt ist#
- 1
Die ursprüngliche Rechnung und Vorgangskennung aufbewahren.
- 2
GET /api/checkout/{token}/status lesen; dies erzeugt keine Belastung.
- 3
POST /api/checkout/{token}/reconcile verwenden, wenn eine explizite Abstimmung erforderlich ist.
- 4
Methode, Betrag oder Idempotency-Key nach einem ungewissen Ergebnis nicht ändern.
Mehrere Geschäfte und ein USD-Basispreis#
Wählen Sie Alle Geschäfte für aggregierte Analysen und Betrieb, oder wählen Sie ein Geschäft für dessen eigene Aufzeichnungen. Jedes Geschäft hat eine separate storeId, einen Namen, einen MwSt-Standardwert, Rechnungen, API-Schlüssel, Webhook-Endpunkte, Ereignisverlauf und Website-Anwendung. Benachrichtigungen und Support-Tickets gehören zum Konto. Ein Konto kann bis zu 100 Geschäfte erstellen. Vorhandene Datensätze verbleiben im ersten Geschäft.
Neue Workspace-Rechnungen verwenden pricingMode="universal" und einen USD-Basispreis. Any umfasst Karte, Alipay, SBP und Krypto; ein Händler kann eine Teilmenge auswählen. Karten und Alipay berechnen USD. SBP berechnet RUB unter Verwendung des USD/RUB-Referenzkurses der Bank von Russland. Krypto berechnet USDT gemäß der expliziten Rechnungsregel 1 USD = 1 USDT. Dies ist eine Rechnungsumrechnungsregel, kein Markt-USDT-Kurs. Das Gateway liefert den Kurs der ausgewählten Münze, den genauen Überweisungsbetrag und Anweisungen vor der Überweisung.
Der Referenzkurs und beide Beträge werden bei der Erstellung eingefroren. Rechnungen mit RUB-Umrechnung verfallen innerhalb von 24 Stunden. Wenn der Referenzkurs nicht abgerufen werden kann, schlägt die Erstellung mit FX_UNAVAILABLE fehl; es wird kein erfundener oder veralteter Ersatzkurs verwendet. Der Basisbetrag Minor und Angebote verwenden die USD-Buchungswährung. quotes[method].settlement enthält das native Belastungsangebot. Der öffentliche Checkout legt die ausgewählte Belastungswährung in currency, den ursprünglichen Preis in baseAmountMinor/baseCurrency und den Referenzkurs in fx offen. Sobald eine Zahlung ausgelöst wurde, kann ihre Methode nicht geändert werden; eine Rechnung hat einen Gateway-Vorgang.
Erstellen Sie einen API-Schlüssel im vorgesehenen Geschäft und senden Sie Authorization: Bearer <key> von Ihrem Server. Seine Geschäftsbindung ist unveränderlich; X-Kevmi-Store kann ihm keinen Zugriff auf ein anderes Geschäft gewähren. Browser-Sitzungen wählen X-Kevmi-Store: <storeId>; wenn es weggelassen wird, wird das erste Geschäft ausgewählt. Der Wert all wird nur von GET /api/account/dashboard und GET /api/payment-links akzeptiert. Mutationen erfordern ein ausgewähltes Geschäft, Origin und X-CSRF-Token. Konto-IDs und Geschäfts-IDs sind unterschiedliche Kennungen.
Aus Kompatibilitätsgründen behalten API-Anfragen ohne pricingMode="universal" native Preise und die ursprünglichen Währungsbeschränkungen bei. Bestehende Rechnungen werden nie neu berechnet. Bestätigte Zahlungseingänge in Analysen spiegeln verifizierte Zahlungen abzüglich gespeicherter Rechnungsausgaben wider; sie sind kein abhebbarer Saldo. Legacy-Rechnungswährungen bleiben getrennt, und Auszahlungen werden mit dem Support vereinbart. Führen Sie eine Bestellung erst aus, nachdem Sie payment.fulfillmentReady=true und payment.status="succeeded" über die Server-API, den Ereignisverlauf oder einen signierten Webhook geprüft haben.