# QA-Checkliste (/de/online/getting-started/checklist)



Arbeiten Sie diese Checkliste in der [Sandbox](./testing) 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.

<ChecklistProgress />

## 1. Zahlungsergebnisse [#1-payment-outcomes]

<ChecklistItem id="OP-PO-1" code="PO-1" title="Erfolgreiche Zahlung">
  Zahlen Sie mit 

  `4242 4242 4242 4242`

  . Die abgerufene Session hat 

  `paymentStatus: successful`

   und die Bestellung wird genau einmal abgewickelt.
</ChecklistItem>

<ChecklistItem id="OP-PO-2" code="PO-2" title="Abgelehnte Karte">
  Zahlen 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.
</ChecklistItem>

<ChecklistItem id="OP-PO-3" code="PO-3" title="3-D Secure">
  Zahlen Sie mit 

  `4012 0018 0000 0016`

   und schließen Sie die Challenge ab. Die Abwicklung der Bestellung wartet auf den abgerufenen Status.
</ChecklistItem>

<ChecklistItem id="OP-PO-4" code="PO-4" title="Verarbeitungsfehler">
  Verwenden Sie eine Testkarte für Verarbeitungsfehler des Test-Gateways. Die Bestellung bleibt unbezahlt, obwohl das Kartenformular die Karte akzeptiert hat.
</ChecklistItem>

<ChecklistItem id="OP-PO-5" code="PO-5" title="Nicht behandelte Status">
  Ihr Code behandelt 

  `unpaid`

  , 

  `failed`

  , 

  `action_needed`

  , 

  `cancelled`

   und unbekannte Werte als nicht bezahlt. Siehe 

  [Zahlungsstatus](/online/integration/api_integration#payment-status)

  .
</ChecklistItem>

## 2. Verifizierung und Abwicklung der Bestellung [#2-verification-and-fulfillment]

<ChecklistItem id="OP-VF-1" code="VF-1" title="Serverseitige Prüfung">
  Die Abwicklung vergleicht Bestellreferenz, Betrag, Währung und 

  `paymentStatus`

   mit der gespeicherten Bestellung, nicht mit der Weiterleitung.
</ChecklistItem>

<ChecklistItem id="OP-VF-2" code="VF-2" title="Erfolgs-URL ohne Zahlung">
  Rufen Sie die Erfolgs-URL direkt auf, ohne zu zahlen. Die Bestellung bleibt unbezahlt.
</ChecklistItem>

<ChecklistItem id="OP-VF-3" code="VF-3" title="Abbruch-Link">
  Folgen Sie dem Abbruch-Link des Checkouts. Die Bestellung bleibt unbezahlt, und Ihr Code leitet nicht allein aus der Navigation einen Status 

  `cancelled`

   ab.
</ChecklistItem>

<ChecklistItem id="OP-VF-4" code="VF-4" title="Wiederholte Rückkehr">
  Laden Sie nach einer erfolgreichen Zahlung die Rückkehrseite zweimal neu. Die Bestellung wird genau einmal abgewickelt.
</ChecklistItem>

## 3. Wiederholungsversuche und Unterbrechungen [#3-retries-and-interruptions]

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.

<ChecklistItem id="OP-RI-1" code="RI-1" title="Verlorene Antwort auf das Erstellen">
  Verwerfen 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.
</ChecklistItem>

<ChecklistItem id="OP-RI-2" code="RI-2" title="Geänderter Body">
  Verwenden 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.
</ChecklistItem>

<ChecklistItem id="OP-RI-3" code="RI-3" title="Kunde kehrt nie zurück">
  Zahlen 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.
</ChecklistItem>

<ChecklistItem id="OP-RI-4" code="RI-4" title="Timeout beim Status">
  Lassen 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.
</ChecklistItem>

<ChecklistItem id="OP-RI-6" code="RI-6" title="Ersetzte Session">
  Erstellen 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.
</ChecklistItem>

<ChecklistItem id="OP-RI-5" code="RI-5" title="Ablauf der Session">
  Warten 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.
</ChecklistItem>

## 4. Checkout-Einstellungen [#4-checkout-settings]

<ChecklistItem id="OP-CS-1" code="CS-1" title="Händler freigegeben">
  Jeder Händler, für den Sie Zahlungen annehmen, steht in der Tabelle 

  **Checkout merchants**

   mit dem Status 

  **Ready**

  .
</ChecklistItem>

<ChecklistItem id="OP-CS-2" code="CS-2" title="Rückkehrziele">
  Standard-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.
</ChecklistItem>

<ChecklistItem id="OP-CS-3" code="CS-3" title="Überschreibungen pro Session">
  Jede 

  `successUrl`

   oder 

  `cancelUrl`

  , die Sie senden, passt zu einem konfigurierten Origin.
</ChecklistItem>

<ChecklistItem id="OP-CS-4" code="CS-4" title="Wallets">
  Apple Pay und Google Pay sind wie vorgesehen aktiviert oder deaktiviert. Für Google Pay im Live-Modus ist eine Google Pay Merchant ID konfiguriert.
</ChecklistItem>

<ChecklistItem id="OP-CS-6" code="CS-6" title="Wallets bei eingebetteten Zahlungen">
  Der 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.
</ChecklistItem>

<ChecklistItem id="OP-CS-5" code="CS-5" title="Branding">
  Farbe und Logo sehen in 

  **Checkout preview**

   sowohl im Desktop- als auch im Mobil-Layout korrekt aus.
</ChecklistItem>

## 5. Sicherheit [#5-security]

<ChecklistItem id="OP-SE-1" code="SE-1" title="Schlüssel auf dem Server">
  Ihr Checkout-Händlerschlüssel oder der Secret key der Organisation liegt nur in der Serverkonfiguration, niemals in Browser-Code, App-Bundles oder der Versionsverwaltung.
</ChecklistItem>

<ChecklistItem id="OP-SE-2" code="SE-2" title="Beträge vom Server">
  Betrag, Währung und Bestell-ID stammen aus Ihrer gespeicherten Bestellung, niemals aus dem Browser.
</ChecklistItem>

<ChecklistItem id="OP-SE-3" code="SE-3" title="Endpoints für eingebettete Zahlungen">
  Wenn 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.
</ChecklistItem>

<ChecklistItem id="OP-SE-4" code="SE-4" title="Content Security Policy">
  Wenn Sie eingebettete Zahlungen verwenden, erlaubt Ihre CSP die Skript- und Frame-Origins von Tapaya, und 3-D-Secure-Challenges funktionieren damit weiterhin.
</ChecklistItem>

## 6. Sandbox-Konfiguration [#6-sandbox-configuration]

<ChecklistItem id="OP-PR-1" code="PR-1" title="Sandbox-API">
  `TAPAYA_CHECKOUT_API_URL`

   zeigt auf 

  `https://api.sandbox.tapaya.com`

  .
</ChecklistItem>

<ChecklistItem id="OP-PR-2" code="PR-2" title="Sandbox-Schlüssel">
  Die Integration verwendet einen Sandbox-Checkout-Händlerschlüssel oder den Secret key der Organisation, geladen aus der Serverkonfiguration.
</ChecklistItem>

<ChecklistItem id="OP-PR-3" code="PR-3" title="Abgleichsjob">
  Der Job, der ungeklärte Sessions abruft, ist in Ihrer Testumgebung eingeplant.
</ChecklistItem>

## 7. Bereitschaft für die Produktion [#7-production-readiness]

<ChecklistItem id="OP-LV-1" code="LV-1" title="Bereitschaft des Händlers">
  Der 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**

  .
</ChecklistItem>

<ChecklistItem id="OP-LV-2" code="LV-2" title="Live-Zugangsdaten">
  Der 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.
</ChecklistItem>

<ChecklistItem id="OP-LV-3" code="LV-3" title="Wallets im Live-Modus">
  Die 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.
</ChecklistItem>

<ChecklistItem id="OP-LV-4" code="LV-4" title="Abgleich im Live-Modus">
  Produktive Rückkehr-URLs, Serververifizierung, Abwicklung der Bestellung und der Abgleichsjob verwenden die Produktionskonfiguration.
</ChecklistItem>

<ChecklistProgress />

<Callout title="Abnahme" type="tip">
  Schließen Sie die Sandbox-Tests und die Prüfungen der Bereitschaft für die Produktion ab. Mit **Reset** starten Sie einen neuen, sauberen Durchlauf, da Häkchen aus früheren Testrunden in diesem Browser gespeichert bleiben.
</Callout>