Ein Käufer bezahlt, schließt den Browser und fragt später nach seinem Kauf. Ein anderer öffnet die Erfolgsseite zweimal. Keine dieser Browseraktionen sollte darüber entscheiden, ob eine Bestellung bezahlt ist. Die Checkout-Oberfläche kommuniziert mit dem Kunden; die Zahlungsbuchhaltung ist eine eigene Aufgabe des Servers. Bei Domainverkäufen ist dieser Unterschied besonders wichtig: Als nächster Schritt könnte ein Vermögenswert übertragen werden, der sich nicht einfach wieder in den Warenkorb legen lässt. MIT EINER BESTELLUNG BEGINNEN Erstellen Sie vor dem Checkout eine interne Bestellung mit stabiler Kennung, Käufer, Artikel, erwartetem Betrag und Währung. Stellen Sie sich einen versiegelten Umschlag vor, der die gewünschte Transaktion beschreibt. Eine Zahlungsnachricht muss zu diesem Umschlag passen. Eine echte Nachricht über eine andere Bestellung bleibt die falsche Nachricht. Eine Dollarzahlung darf eine Eurobestellung nicht erfüllen, nur weil dieselben Ziffern erscheinen. Beispiel: Eine Domain kostet €500. Speichern Sie 50000 Eurocent statt einer formatierten Zeichenfolge mit Währungssymbol. Halten Sie Rabatt und endgültigen Zahlbetrag bei der Bestellung fest. Eine spätere Katalogänderung darf einen bestehenden Checkout nicht unbemerkt verändern. Definieren Sie ausdrücklich, wie der Käufer die alte Bestellung storniert und eine neue anlegt. ECHTHEIT VOR GESCHÄFTSLOGIK Stripe beschreibt die Signaturprüfung anhand des ursprünglichen Anfrageinhalts, des Signatur-Headers und des Endpoint-Secrets. Offizielle Bibliotheken übernehmen diese Prüfung. Das Secret gehört in die Serverkonfiguration. Trennen Sie Test und Produktivbetrieb und geben Sie es niemals an den Frontend-Code weiter. Verfolgen Sie bei der Implementierungsprüfung den Weg der Anfrage vom Netzwerkeingang bis zum Handler. Wo wird ihr Inhalt gelesen? Welche Middleware verarbeitet ihn? Verändert ein Proxy die Anfrage? Das Team sollte die genaue Prüfgrenze zeigen können. Drucken Sie keine Geheimnisse ins Protokoll, um Fehler zu finden. Erfassen Sie eine Anfragekennung, die Umgebung und eine bereinigte Fehlerkategorie. Fehlende Echtheit und ein vorübergehender Datenbankausfall benötigen unterschiedliche Reaktionen und Warnungen. EINGANG IST NICHT ABSCHLUSS Stripe weist auf wiederholte Nachrichten und eine nicht garantierte Zustellreihenfolge hin. Die Anleitung zur Bestellabwicklung berücksichtigt verzögerte Zahlungsergebnisse. Das sind Eigenschaften von Transport und Zahlung, kein Beweis für einen falschen Klick des Kunden. Entwerfen Sie einen dauerhaften Eingang für akzeptierte Nachrichten und einen getrennten Zustandswechsel der Bestellung. Eine eindeutige Ereigniskennung verhindert wiederholte Verarbeitung derselben Zustellung. Zusätzlich braucht der Geschäftsvorgang eine eigene Absicherung: Eine erfüllte Bestellung darf ihre Domain nicht erneut übertragen. Denken Sie an zwei Worker, die gleichzeitig dieselbe Bestellung erreichen. Eine Datenbankbedingung oder Transaktion sollte den Übergang entscheiden, keine Browservariable und kein optimistisches „bereits geprüft“. Verwenden Sie erklärbare Zustände: Zahlung ausstehend, Zahlung bestätigt, Ausführung ausstehend, erfüllt und Prüfung nötig. Eine fehlgeschlagene oder abgelaufene Zahlungsversuch hat seine eigene Historie. Eine ältere Nachricht darf eine neuere erfolgreiche Zahlung nicht überschreiben, nur weil sie später ankommt. VOR DEM START TESTEN Schreiben Sie eine kleine Tabelle mit erwarteten Ergebnissen. Eine ungültige Signatur verändert keine Bestellung. Ein doppeltes gültiges Ereignis löst keine zweite Übertragung aus. Eine echte Zahlung mit unerwartetem Betrag, falscher Währung oder anderer Session geht zur Prüfung. Eine Zahlung bei geschlossenem Browser muss trotzdem im Konto erscheinen. Ein Datenbankabbruch muss genug Informationen für eine sichere Wiederaufnahme hinterlassen. Prüfen Sie verzögerten Erfolg und verzögertes Scheitern getrennt. Testen Sie anschließend den unspektakulären Fall: Die Nachricht wurde akzeptiert, aber der Ausführungsprozess stoppt mitten in seiner Arbeit. Wiederherstellung muss auf gespeichertem Zustand beruhen, nicht auf der Erinnerung eines Mitarbeiters. Übertragen Sie keinen realen Vermögenswert nur für die Demonstration einer grünen Erfolgsseite. UNSICHERHEIT SICHTBAR MACHEN Kunden müssen „Zahlung bestätigt“ von „Übertragung abgeschlossen“ unterscheiden können. Zeigen Sie Bestellnummer und nächsten Schritt, statt Erfolg zu behaupten, während der Server wartet. Für Mitarbeiter empfiehlt sich eine Prüfwarteschlange mit Gründen und einem Abgleich gegen den maßgeblichen Zahlungsdatensatz. Das ist unsere betriebliche Empfehlung, keine Behauptung, dass ein Webhook allein alle Vorfälle verhindert. Ein Domainprojekt beginnt mit einem passenden Namen; zuverlässige Zahlung gehört jedoch zum Markenerlebnis. Entdecken Sie den DomainEvery-Katalog: https://domainevery.com/de/domains und planen Sie Prüfung, Wiederherstellung und Ausführung gemeinsam mit dem Webdesign. QUELLEN Stripe: Webhooks: https://docs.stripe.com/webhooks Stripe: Endpoints und Signaturprüfung: https://docs.stripe.com/events/manage-webhook-endpoints Stripe: hosted Checkout und Bestellabwicklung: https://docs.stripe.com/checkout/fulfillment.md?payment-ui=stripe-hosted