Testen
Validieren Sie Ihre Integration für Online-Zahlungen in der Sandbox mit Testkarten.
Testen Sie Ihre Checkout-Integration in der Tapaya-Sandbox, bevor Sie Live-Zahlungen annehmen. Zahlungen in der Sandbox verwenden Testkarten, es fließt also kein echtes Geld. Checkout in der Produktionsumgebung nimmt echte Zahlungen von freigegebenen Händlern an.
Server auf die Sandbox-API ausrichten
Setzen Sie TAPAYA_CHECKOUT_API_URL auf https://api.sandbox.tapaya.com und speichern Sie einen Checkout-Händlerschlüssel in TAPAYA_CHECKOUT_API_KEY. Bewahren Sie beides auf Ihrem Server auf.
TAPAYA_CHECKOUT_API_URL=https://api.sandbox.tapaya.com
TAPAYA_CHECKOUT_API_KEY=tapaya_test_...Schließen Sie das Onboarding mit der Funktion für Online-Zahlungen ab und prüfen Sie in den Checkout-Einstellungen, ob der Händler Ready ist. Speichern Sie Rückkehr-URLs, wenn Sie Hosted Checkout verwenden.
Test-Session erstellen
Erstellen Sie eine Session für eine Testbestellung, genau wie im Schnellstart. Speichern Sie die zurückgegebene
id vor der Weiterleitung zusammen mit der Bestellung, damit Sie das Ergebnis auch dann prüfen können, wenn der Browser geschlossen wird.
Mit einer Testkarte zahlen
Öffnen Sie die url der Session und zahlen Sie mit einer der unten aufgeführten Karten, einem beliebigen Ablaufdatum in der Zukunft und dem CVC 123.
Vom Server aus verifizieren
Rufen Sie die Session von Ihrem Server ab und vergleichen Sie Bestellreferenz, Betrag, Währung und
paymentStatus mit der gespeicherten Bestellung. Dass der Browser zu Ihrer Erfolgs-URL zurückkehrt, beweist keine Zahlung.
Testkarten
Verwenden Sie diese Testkarten.
| Szenario | Kartennummer | Erwartetes Ergebnis |
|---|---|---|
| Zahlung erfolgreich | 4242 4242 4242 4242 | paymentStatus: successful. Ihr Server wickelt die Bestellung genau einmal ab. |
| Karte wird abgelehnt | 4916 0184 7581 4056 | paymentStatus: failed, status bleibt open. Der Kunde kann in derselben Session eine andere Karte versuchen. |
| 3-D Secure erforderlich | 4012 0018 0000 0016 | Schließen Sie die Test-Challenge ab. Wickeln Sie die Bestellung erst ab, wenn der Abruf den Erfolg bestätigt. |
Eine Karte für Verarbeitungsfehler kann die Tokenisierung bestehen und erst bei der Belastung fehlschlagen. Prüfen Sie daher immer den abgerufenen Status und nicht die Reaktion des Kartenformulars.
Was die Sandbox abdeckt
- Hosted Checkout: Karten mit den oben genannten Testkarten. Wallet-Buttons hängen von den Einstellungen des Händlers sowie vom Gerät und Browser des Kunden ab. Verlassen Sie sich daher nicht darauf, dass sie in jedem Test erscheinen.
- Eingebettete Zahlungen: Karten und unterstützte Wallets mit Tapaya.js 0.2.0. Testen Sie die Verfügbarkeit der Wallets, Abbrüche, Änderungen des Gesamtbetrags und die Verifizierung auf dem Server. Apple Pay erfordert eine registrierte Shop-Domain. Siehe Embedded Checkout.
- Gültigkeitsdauer der Session: Sessions nehmen 30 Minuten nach ihrer Erstellung neue Zahlungen an. Verwenden Sie für
jeden unabhängigen Test eine neue
merchantOrderId: Eine Bestellung kann nur einmal bezahlt werden, und eine neue Session für eine unbezahlte Bestellung ersetzt die vorherige.
Sobald der grundlegende Ablauf funktioniert, arbeiten Sie die QA-Checkliste durch. Sie deckt Wiederholungsversuche, verlorene Antworten und Kunden ab, die nie zurückkehren.
Fehlt Ihnen etwas auf dieser Seite?Wünschen Sie sich eine Funktion. Wir hängen diese Seite an, damit das Team den Kontext sieht.