Der Unter-Abwickler versucht die Zahlung erneut mit OrchestrationPrivate Vorschau

Zahlungen können aus verschiedenen Gründen fehlschlagen, z. B. bei Netzwerkproblemen, Abwicklerausfällen oder vorübergehenden Ablehnungen (z. B. wegen unzureichender Geldmittel). Viele dieser Fehler können behoben werden. Mit Orchestration können Sie fehlgeschlagene Zahlungen automatisch mit einem anderen Abwickler als dem, der den ursprünglichen Versuch getätigt hat, wiederholen und so mehr Umsatz erzielen.

Einrichten von Zahlungswiederholungen im Dashboard

So konfigurieren Sie Wiederholungsversuche für Zahlungen:

1. Navigieren Sie zu Zahlungen > Orchestration >Regeln.
2. Erstellen Sie neue Regeln oder öffnen Sie vorhandene Regeln. Wenn Sie Änderungen an vorhandenen Regeln vornehmen, müssen Sie sie duplizieren. Bearbeiten Sie dann den Entwurf Ihrer duplizierten Regeln.
3. Fügen Sie im Regel-Generator eine Action hinzu, um das Wiederholungsverhalten zu konfigurieren:
   • Hauptverarbeiter: Der Verarbeiter, der für den ersten Zahlungsversuch verwendet werden soll.
   • Verarbeiter des erneuten Versuchs: Der Verarbeiter, der verwendet werden soll, wenn der erste Versuch fehlschlägt.

Diese Einrichtung ermöglicht Wiederholungen fehlgeschlagener Zahlungen und erhöht somit die Wahrscheinlichkeit einer erfolgreichen Abwicklung.

Wiederholungsverhalten des Unter-Abwicklers

Wenn eine Zahlung über den Haupt-Abwickler fehlschlägt, hängt die Wiederholungslogik von mehreren Faktoren ab.

• 3D Secure: Wenn die 3D Secure (3DS)-Authentifizierung zum ersten Mal bei Ihrem Hauptverarbeiter versucht wird und sich Ihre Kundin oder Ihr Kunde nicht erfolgreich authentifiziert oder sich erfolgreich authentifiziert, der Zahlungsversuch aber immer noch fehlschlägt, versucht Orchestration die Transaktion nicht erneut auf dem Verarbeiter für erneute Versuche. Wir senden stattdessen das Webhook-Ereignis payment_failed.
• Nicht berechtigte Funktionen: Wenn bei einer Zahlung eine Funktion verwendet wird, die vom Abwickler des erneuten Versuchs nicht unterstützt wird, etwa der Parameter on_behalf_of von Stripe Connect, startet Orchestration nach dem ersten Fehlschlag mit diesem Abwickler keinen neuen Versuch mehr.
• Blockierte Transaktionen: Wenn Stripe Ihr Hauptverarbeiter ist und wir eine Transaktion blockieren (z. B. eine von Radar identifizierte Zahlung mit hohem Risiko), behandelt Orchestration dies als abgelehnte Zahlung und versucht die Zahlung mit dem von Ihnen ausgewählten Verarbeiter für einen erneuten Versuch.
• Adaptive Acceptance: Wenn Sie Adaptive Acceptance aktiviert haben und Stripe Ihr Hauptverarbeiter ist, startet Stripe möglicherweise einen zusätzlichen Wiederholungsversuch für eine abgelehnte Transaktion, bevor der erneute Versuch durch einen Unterverarbeiter ausgelöst wird. Wenn Stripe Ihr Verarbeiter ist, kann Stripe letztendlich zwei Wiederholungen durchführen, eine als erneuter Versuch durch den Unterverarbeiter und eine im Rahmen von Adaptive Acceptance.