Relances entre des sous-traitants avec OrchestrationVersion bêta privée

Des paiements peuvent échouer pour diverses raisons, telles que des problèmes réseau, des pannes de processeur ou des refus temporaires (par exemple, fonds insuffisants). La plupart de ces échecs sont récupérables. Grâce à Orchestration, vous pouvez automatiquement réessayer les paiements ayant échoué en utilisant un processeur différent de celui qui a soumis la tentative initiale, ce qui vous aide à récupérer davantage de revenus.

Configurer les relances de paiement dans le Dashboard

Pour configurer les relances de paiement :

1. Accédez à Payments > Orchestration > Règles.
2. Créez de nouvelles règles ou ouvrez des règles existantes. Si vous apportez des modifications à des règles existantes, vous devez les dupliquer, puis modifier le brouillon de vos règles dupliquées.
3. Dans le générateur de règles, ajoutez une Action pour configurer le comportement de relance :
   • Le sous-traitant principal : le sous-traitant à utiliser pour la tentative de paiement initiale.
   • Relancer le sous-traitant : le sous-traitant à utiliser si la tentative initiale échoue.

Cette configuration permet de relancer les paiements échoués, ce qui améliore les chances de réussite du processus.

Comportement des relances entre sous-traitants

En cas d’échec d’un paiement sur le sous-traitant principal, la logique de relance dépend de plusieurs facteurs.

• 3D Secure : si l’authentification 3D Secure (3DS) est tentée lors de la première tentative sur votre sous-traitant principal et que votre client ne parvient pas à s’identifier, ou s’il s’identifie avec succès, mais que la tentative de paiement échoue tout de même, Orchestration ne réessaie pas la transaction sur le sous-traitant de reprise. À la place, nous envoyons un événement webhook payment_failed.
• fonctionnalités non admissibles : si un paiement utilise une fonctionnalité qui n’est pas prise en charge par le processeur de Réessai, comme le paramètre on_behalf_of avec Stripe Connect, Orchestration ne réessaiera pas avec ce processeur après le premier échec.
• Transactions bloquées : si Stripe est votre principal sous-traitant et que nous bloquons une transaction (par exemple, un paiement à haut risque identifié par Radar), Orchestration traite cela comme un refus de paiement et relance le paiement sur le sous-traitant de relances que vous avez choisi.
• Adaptive Acceptance : si vous avez activé Adaptive Acceptance et que Stripe est votre sous-traitant principal, Stripe peut alors lancer une nouvelle tentative pour une transaction refusée avant de déclencher une nouvelle tentative inter-sous-traitants. Si Stripe est votre sous-traitant chargé des nouvelles tentatives, Stripe peut alors lancer deux nouvelles tentatives, l’une en tant que nouvelle tentative inter-sous-traitants et l’autre dans le cadre de Adaptive Acceptance.