Tapaya
Online-ZahlungenCheckout-SicherheitCheckout-Sicherheit

Checkout-Sicherheit

Die serverseitigen Regeln, die eine Checkout-Integration sicher halten, vom Umgang mit Schlüsseln bis zur Verifizierung einer Zahlung vor der Abwicklung der Bestellung.

Tapaya hostet die Kartenfelder, die Tokenisierung, die Kartenauthentifizierung und die Belastung, sodass Ihre Systeme nie mit unverarbeiteten Kartendaten in Berührung kommen. Bei Ihnen bleibt der Server, der Zahlungen erstellt und entscheidet, wann eine Bestellung bezahlt ist. Diese Regeln gelten sowohl für den Hosted Checkout als auch für eingebettete Zahlungen.

Wie Tapaya mit Karteninhaberdaten und personenbezogenen Daten umgeht, lesen Sie unter Datenschutz und Privatsphäre.

Schlüssel auf dem Server aufbewahren

  • Speichern Sie Ihren Checkout-Händlerschlüssel oder den Secret key der Organisation ausschließlich in der serverseitigen Konfiguration. Keiner von beiden gehört in Browser-Code, in Bundles mobiler Apps oder in die Versionsverwaltung. Nur der publishable key und das client secret einer Zahlung gelangen in den Browser.
  • Rufen Sie die Checkout-API des Händlers aus Ihrer Serverumgebung auf. Führen Sie diese Anfragen nicht im Browser des Kunden aus.
  • Ein Checkout-Händlerschlüssel gilt nur für seinen eigenen Händler. Geben Sie dem eigenen Backend eines Händlers diesen Schlüssel, niemals den Secret key Ihrer Organisation.
  • Der Secret key der Organisation hat organisationsweite Berechtigungen. Senden Sie ihn im Plattformmodus bei jeder Anfrage zusammen mit X-Tapaya-Merchant-Token; die API prüft, ob der Händler zur Organisation des Schlüssels gehört. Siehe Checkout-Authentifizierung.
  • Händlerschlüssel werden nur einmal angezeigt und nur als Hash gespeichert. Widerrufen Sie einen Schlüssel, bei dem Sie eine Offenlegung vermuten, nachdem Sie seinen Ersatz erstellt haben.

Die Bestellung auf dem Server verwalten

  • Berechnen Sie den Gesamtbetrag der Bestellung auf Ihrem Server und speichern Sie die Bestellung, bevor Sie eine Session oder einen Zahlungsversuch erstellen.
  • Lesen Sie Beträge, Währung und Bestell-IDs aus Ihrem gespeicherten Snapshot der Bestellung. Akzeptieren Sie keine vom Browser gesendeten Ersatzwerte.
  • Binden Sie bei eingebetteten Zahlungen Ihre Endpoints prepare und submit an einen authentifizierten Checkout oder an ein signiertes HTTP-only-Cookie und validieren Sie den Origin ändernder Anfragen.

Vor der Abwicklung verifizieren

Eine Browser-Weiterleitung, ein Aufruf Ihrer Erfolgs-URL, Query-Parameter, Rückkehr-Cookies und Browser-Nachrichten sind Navigationsdaten. Keines davon beweist eine Zahlung.

  • Rufen Sie die Session von Ihrem Server ab und vergleichen Sie Bestellreferenz, Betrag, Währung und Zahlungsstatus mit der gespeicherten Bestellung.
  • Wickeln Sie die Bestellung nur ab, wenn diese Prüfung paymentStatus: successful bestätigt. Eine HTTP-200-Antwort allein beweist keine Zahlung.
  • Halten Sie die Abwicklung atomar fest, damit wiederholte Rückkehrbesuche oder Statusprüfungen dieselbe Bestellung nicht zweimal abwickeln können.
  • Wenn die Session noch unpaid ist oder der Abruf fehlschlägt, behalten Sie die Session-ID und prüfen Sie erneut mit einer begrenzten Anzahl von Wiederholungen. Erstellen Sie keine weitere Session, nur weil das erste Ergebnis unbekannt ist: Eine neue Session für die Bestellung ersetzt die alte. Webhooks gibt es noch nicht, gleichen Sie daher per Polling ab.

Sicher wiederholen

  • Speichern Sie vor dem Erstellen einer Session einen eindeutigen idempotency key (Idempotenzschlüssel) mit der Bestellung. Wenn eine Anfrage in ein Timeout läuft oder ihre Antwort verloren geht, wiederholen Sie sie mit demselben Schlüssel und unverändertem Body.
  • Erzeugen Sie bei einem unsicheren Ergebnis keinen neuen Schlüssel. Die Regeln für die Wiederholung finden Sie unter Idempotenz und Fehler.

Origins für Weiterleitungen einschränken

  • Fügen Sie unter Allowed websites in den Checkout-Einstellungen nur die Origins Ihrer eigenen Shops hinzu.
  • Verwenden Sie für bereitgestellte Shops HTTPS. Überschreibungen von successUrl und cancelUrl pro Session müssen trotzdem zu einem konfigurierten Origin passen.

Ein Sicherheitsproblem melden

Wenn Sie eine Schwachstelle oder einen Sicherheitsvorfall vermuten, wenden Sie sich an das Sicherheitsteam, wie unter Kontakte beschrieben.

Fehlt Ihnen etwas auf dieser Seite?Wünschen Sie sich eine Funktion. Wir hängen diese Seite an, damit das Team den Kontext sieht.