QA-Checkliste

Arbeiten Sie diese Checkliste in der Sandbox durch und schließen Sie anschließend die Prüfungen für die Produktionsumgebung ab, bevor Sie Live-Zahlungen annehmen. Sie deckt Zahlungsergebnisse, Verifizierung, Wiederholungsversuche, Konfiguration und Sicherheit ab. Haken Sie jede Prüfung ab, sobald Sie sie verifiziert haben.

1. Zahlungsergebnisse

Erfolgreiche ZahlungPO-1Zahlen Sie mit 4242 4242 4242 4242. Die abgerufene Session hat paymentStatus: successful und die Bestellung wird genau einmal abgewickelt. Abgelehnte KartePO-2Zahlen Sie mit 4916 0184 7581 4056. Die Bestellung bleibt unbezahlt, und ein erneuter Versuch mit der Karte für erfolgreiche Zahlungen funktioniert, solange die Session offen ist. 3-D SecurePO-3Zahlen Sie mit 4012 0018 0000 0016 und schließen Sie die Challenge ab. Die Abwicklung der Bestellung wartet auf den abgerufenen Status. VerarbeitungsfehlerPO-4Verwenden Sie eine Testkarte für Verarbeitungsfehler des Test-Gateways. Die Bestellung bleibt unbezahlt, obwohl das Kartenformular die Karte akzeptiert hat. Nicht behandelte StatusPO-5Ihr Code behandelt unpaid, failed, action_needed, cancelled und unbekannte Werte als nicht bezahlt. Siehe Zahlungsstatus.

2. Verifizierung und Abwicklung der Bestellung

Serverseitige PrüfungVF-1Die Abwicklung vergleicht Bestellreferenz, Betrag, Währung und paymentStatus mit der gespeicherten Bestellung, nicht mit der Weiterleitung. Erfolgs-URL ohne ZahlungVF-2Rufen Sie die Erfolgs-URL direkt auf, ohne zu zahlen. Die Bestellung bleibt unbezahlt. Abbruch-LinkVF-3Folgen Sie dem Abbruch-Link des Checkouts. Die Bestellung bleibt unbezahlt, und Ihr Code leitet nicht allein aus der Navigation einen Status cancelled ab. Wiederholte RückkehrVF-4Laden Sie nach einer erfolgreichen Zahlung die Rückkehrseite zweimal neu. Die Bestellung wird genau einmal abgewickelt.

3. Wiederholungsversuche und Unterbrechungen

Verwenden Sie für jeden unabhängigen Fall eine neue Testbestellung und Session. Verwenden Sie bei Tests von Wiederholungsversuchen die ursprüngliche Bestellung, den ursprünglichen Request-Body und den ursprünglichen idempotency key (Idempotenzschlüssel) erneut.

Verlorene Antwort auf das ErstellenRI-1Verwerfen Sie in Ihrer Testumgebung die Antwort auf das Erstellen und wiederholen Sie die Anfrage mit demselben Idempotency-Key und Body. Die ursprüngliche Session wird erneut zurückgegeben und keine zweite erstellt. Geänderter BodyRI-2Verwenden Sie einen Schlüssel erneut mit einem anderen Body. Die API gibt HTTP 409 zurück und Ihr Code behandelt dies nicht als neue Session. Kunde kehrt nie zurückRI-3Zahlen Sie und schließen Sie dann den Tab, bevor die Rückkehr erfolgt. Ihr Abgleichsjob ruft die gespeicherte Session ab und verbucht die Zahlung genau einmal. Timeout beim StatusRI-4Lassen Sie den Abruf in ein Timeout laufen. Ihre App behält die Session-ID, lässt das Ergebnis ungeklärt und erstellt keine Ersatz-Session. Ersetzte SessionRI-6Erstellen Sie eine zweite Session für dieselbe unbezahlte Bestellung. Die erste URL meldet expired und kann keine Zahlung mehr annehmen. Nachdem die Bestellung bezahlt ist, gibt das Erstellen einer weiteren Session HTTP 409 zurück. Ablauf der SessionRI-5Warten Sie, bis expiresAt (30 Minuten) überschritten ist, und öffnen Sie die URL erneut. Es kann keine neue Zahlung gestartet werden und die Bestellung bleibt unbezahlt.

4. Checkout-Einstellungen

Händler freigegebenCS-1Jeder Händler, für den Sie Zahlungen annehmen, steht in der Tabelle Checkout merchants mit dem Status Ready. RückkehrzieleCS-2Standard-URLs für Erfolg und Abbruch sind für die verwendeten Zugangsdaten festgelegt (Organisationsstandards für den Secret key, die Einstellungen des Händlers für einen Händlerschlüssel), verwenden HTTPS, und ihre genauen Origins stehen unter Allowed websites dieser Zugangsdaten. Überschreibungen pro SessionCS-3Jede successUrl oder cancelUrl, die Sie senden, passt zu einem konfigurierten Origin. WalletsCS-4Apple Pay und Google Pay sind wie vorgesehen aktiviert oder deaktiviert. Für Google Pay im Live-Modus ist eine Google Pay Merchant ID konfiguriert. Wallets bei eingebetteten ZahlungenCS-6Der Wallet-Gesamtbetrag stimmt mit der Bestellung auf dem Server überein. Änderungen an Versand oder Rabatten aktualisieren ihn. Ein Abbruch in der Wallet lässt den Checkout verfügbar, und ausstehende Zahlungen verhindern eine weitere Belastung. BrandingCS-5Farbe und Logo sehen in Checkout preview sowohl im Desktop- als auch im Mobil-Layout korrekt aus.

5. Sicherheit

Schlüssel auf dem ServerSE-1Ihr Checkout-Händlerschlüssel oder der Secret key der Organisation liegt nur in der Serverkonfiguration, niemals in Browser-Code, App-Bundles oder der Versionsverwaltung. Beträge vom ServerSE-2Betrag, Währung und Bestell-ID stammen aus Ihrer gespeicherten Bestellung, niemals aus dem Browser. Endpoints für eingebettete ZahlungenSE-3Wenn Sie eingebettete Zahlungen verwenden, sind prepare und submit an einen authentifizierten Checkout oder ein signiertes HTTP-only-Cookie gebunden, und die Origins ändernder Anfragen werden validiert. Content Security PolicySE-4Wenn Sie eingebettete Zahlungen verwenden, erlaubt Ihre CSP die Skript- und Frame-Origins von Tapaya, und 3-D-Secure-Challenges funktionieren damit weiterhin.

6. Sandbox-Konfiguration

Sandbox-APIPR-1TAPAYA_CHECKOUT_API_URL zeigt auf https://api.sandbox.tapaya.com. Sandbox-SchlüsselPR-2Die Integration verwendet einen Sandbox-Checkout-Händlerschlüssel oder den Secret key der Organisation, geladen aus der Serverkonfiguration. AbgleichsjobPR-3Der Job, der ungeklärte Sessions abruft, ist in Ihrer Testumgebung eingeplant.

7. Bereitschaft für die Produktion

Bereitschaft des HändlersLV-1Der Live-Händler hat das Onboarding mit Online-Zahlungen abgeschlossen, die Freigabe des Zahlungsabwicklers erhalten und verfügt über ein konfiguriertes Payment-Gateway. Der Händler ist in den Checkout-Einstellungen Ready. Live-ZugangsdatenLV-2Der Server verwendet Produktionszugangsdaten und https://api.tapaya.com. SDK-Integrationen setzen TAPAYA_ENVIRONMENT=production. Sandbox-Schlüssel und Testkarten werden nicht für Live-Zahlungen verwendet. Wallets im Live-ModusLV-3Die Shop-Domains für Apple Pay sind aktiv. Für Google Pay im Live-Modus ist eine Merchant ID konfiguriert. Unterstützte Wallets schließen eine Zahlung ab und funktionieren nach einem Abbruch weiter. Abgleich im Live-ModusLV-4Produktive Rückkehr-URLs, Serververifizierung, Abwicklung der Bestellung und der Abgleichsjob verwenden die Produktionskonfiguration. Fehlt Ihnen etwas auf dieser Seite?Wünschen Sie sich eine Funktion. Wir hängen diese Seite an, damit das Team den Kontext sieht.