Gestion des erreurs
Capturer et répondre aux refus de paiement, aux données non valides, aux problèmes de réseau, etc.
Stripe présente plusieurs types d’erreurs. Elles peuvent refléter des événements extérieurs, tels que des paiements refusés et des interruptions de réseau, ou des problèmes de code, comme des appels à l’API non-valides.
Pour gérer les erreurs, utilisez toutes ou certaines des techniques présentées dans le tableau ci-dessous. Quelle que soit la technique utilisée, vous pouvez faire un suivi avec nos réponses recommandées pour chaque type d’erreur.
Technique | Objectif | Si nécessaire |
---|---|---|
Capturer les exceptions | Rectifier les problèmes en cas d’interruption d’un appel à l’API | Toujours |
Suivre les webhooks | Réagir aux notifications de Stripe | Parfois |
Obtenir des informations enregistrées sur les échecs | Analyser les problèmes antérieurs et soutenir d’autres techniques | Parfois |
Capturer les exceptions
Si un problème immédiat empêche la poursuite d’un appel à l’API, la bibliothèque Ruby de Stripe génère une exception. Nous vous conseillons vivement de capturer et de traiter ces exceptions.
Pour capturer une exception, utilisez le mot-clé rescue
de Ruby. Catch Stripe::StripeError
ou ses sous-classes pour gérer uniquement les exceptions propres à Stripe. Chaque sous-classe représente un type d’exception différent. Lorsque vous capturez une exception, vous pouvez utiliser sa classe pour choisir une réponse.
Une fois que vous avez configuré la manière de gérer les exceptions, effectuez des tests sur divers types de données, y compris des cartes de test, afin de simuler différents résultats de paiement.
Suivre les webhooks
En cas de problème, Stripe vous avertit à l’aide de webhooks, y compris pour les problèmes qui ne surviennent pas immédiatement après un appel à l’API. Par exemple :
- Vous perdez un litige.
- Un paiement récurrent échoue après plusieurs mois sans souci.
- Votre application frontale confirme un paiement, mais se met hors ligne avant de détecter l’échec du paiement. (L’application dorsale continue de recevoir une notification de webhook, même si ce n’est pas celle qui a effectué l’appel à l’API.)
Vous n’avez pas besoin de gérer tous les types d’événements webhook. En fait, certaines intégrations n’en gèrent aucun.
Dans votre gestionnaire de webhooks, commencez par suivre les étapes de base de l’outil de création de webhook : prenez un objet Event et servez-vous du type d’événement pour découvrir ce qui s’est passé. Ensuite, si le type d’événement indique une erreur, suivez ces étapes supplémentaires :
- Accédez à event.data.object pour récupérer l’objet affecté.
- Utilisez les informations stockées dans l’objet concerné pour obtenir des explications, y compris dans le cas d’un objet Error.
- Référez-vous au type de l’objet pour déterminer la marche à suivre.
Pour tester la façon dont votre intégration répond aux événements webhook, vous pouvez déclencher des événements webhook localement. Lorsque les étapes de configuration sont terminées sur ce lien, déclenchez un échec de paiement pour voir le message d’erreur généré.
stripe trigger payment_intent.payment_failed
A payment error occurred: Your card was declined.
Obtenir des informations enregistrées sur les échecs
De nombreux objets stockent des informations sur les échecs. Cela signifie que s’il y a déjà eu un problème, vous êtes en mesure de récupérer l’objet et de l’examiner afin d’en savoir plus. Les informations stockées se présentent généralement sous la forme d’un objet Error, et vous pouvez vous reporter à sa classe pour déterminer la marche à suivre.
Par exemple :
- Récupérez un Payment Intent spécifique.
- Vérifiez s’il y a eu une erreur de paiement en déterminant si last_payment_error est vide.
- Si c’est le cas, consignez l’erreur en incluant son type et l’objet concerné.
Voici des objets courants qui enregistrent des informations sur les échecs.
Objet | Attribut | Valeurs |
---|---|---|
Payment Intent | last_ | Un objet Error |
Setup Intent | last_ | Un objet Error |
Facture | last_ | Un objet Error |
Tentative de configuration | setup_ | Un objet Error |
Virement | failure_ | Un code d’échec de virement |
Remboursement | failure_ | Un code d’échec de remboursement |
Pour tester un code qui utilise des informations enregistrées sur les échecs, vous devez fréquemment simuler des transactions qui ont échoué. Vous pouvez le faire à l’aide de cartes de test ou de numéros de comptes bancaires de test. Par exemple :
- Simuler un paiement refusé, pour avoir créé des paiements, des PaymentIntents, des SetupIntents, etc. qui ont échoué.
- Simuler un échec de virement.
- Simuler l’échec d’un remboursement.
Types d’erreurs et réponses
Dans la bibliothèque Ruby de Stripe, les objets d’erreur appartiennent à stripe.
et à ses sous-classes. Reportez-vous à la documentation concernant chaque classe pour obtenir des conseils quant aux réponses à apporter.
Nom | Classe | Description |
---|---|---|
Erreur de paiement | Une erreur est survenue lors d’un paiement. Voici les cas possibles : | |
Erreur de requête invalide | Vous avez effectué un appel à l’API contenant des paramètres incorrects, dont l’état est incompatible ou d’une manière non valide. | |
Erreur de connexion | Un problème réseau entre votre serveur et Stripe est survenu. | |
Erreur d’API | Un problème est survenu au niveau de Stripe (cas rare). | |
Erreur d’authentification | Stripe ne parvient pas à vous authentifier avec les informations que vous avez fournies. | |
Erreur d’idempotence | You used an idempotency key for something unexpected, like replaying a request but passing different parameters. | |
Erreur d’autorisation | La clé API utilisée pour cette requête ne dispose pas des autorisations nécessaires. | |
Erreurs de limite de débit | Vous avez effectué trop d’appels à l’API en un temps réduit. | |
Erreur de vérification de signature | You’re using webhook signature verification and couldn’t verify that a webhook event is authentic. |
Erreurs de paiement
Les erreurs de paiement, parfois appelées « erreurs de carte » pour des raisons historiques, regroupe un grand nombre de problèmes courants. Elles sont réparties en trois catégories :
To distinguish these categories or get more information about how to respond, consult the error code, decline code, and charge outcome.
(To find the charge outcome from an error object, first get the Payment Intent that’s involved and the latest Charge it created. See the example below for a demonstration.)
Users on API version 2022-08-01 or older:
(To find the charge outcome from an error object, first get the Payment Intent that’s involved and the latest Charge it created. See the example below for a demonstration.)
Grâce aux cartes de test, vous pouvez déclencher certains types d’erreur de paiement courants. Consultez ces listes pour connaître les démarches à suivre :
Le code de test ci-dessous montre quelques possibilités.
Paiement bloqué pour suspicion de fraude
Type |
|
Codes |
|
Codes |
|
Problème | Radar, le système de prévention des fraudes implémenté par Stripe, a bloqué le paiement |
Solutions | Cette erreur peut se produire alors que votre intégration fonctionne correctement. Capturez-la et invitez le client à utiliser un autre moyen de paiement. Pour bloquer moins de paiements légitimes, suivez ce qui suit :
Les clients de Radar for Fraud Teams disposent des options supplémentaires suivantes :
You can test your integration’s settings with test cards that simulate fraud. If you have custom Radar rules, follow the testing advice in the Radar documentation. |
Paiement refusé par l’émetteur
Type |
|
Codes |
|
Problème | L’émetteur de la carte a refusé le paiement. |
Solutions | This error can occur when your integration is working correctly. It reflects an action by the issuer, and that action may be legitimate. Use the decline code to determine what next steps are appropriate. See the documentation on decline codes for appropriate responses to each code. Vous pouvez également effectuer les actions ci-après :
Test how your integration handles declines with test cards that simulate successful and declined payments. |
Autres erreurs de paiement
Type |
|
Problème | Une autre erreur de paiement s’est produite. |
Solutions | This error can occur when your integration is working correctly. Use the error code to determine what next steps are appropriate. See the documentation on error codes for appropriate responses to each code. |
Erreurs de requêtes invalides
Type |
|
Problème | Vous avez effectué un appel à l’API contenant des paramètres incorrects, dont l’état est incompatible ou d’une manière non valide. |
Solutions | Dans la plupart des cas, le problème vient de la requête elle-même : soit ses paramètres ne sont pas valides, soit l’état actuel de votre intégration ne permet pas son exécution.
|
Erreurs de connexion
Type |
|
Problème | Une erreur réseau entre votre serveur et Stripe s’est produite. |
Solutions | Traitez le résultat de l’appel à l’API comme indéterminé. Autrement dit, ne partez pas du principe qu’il a abouti ou échoué. Pour savoir si cela a abouti, vous pouvez effectuer les actions suivantes :
Pour faciliter la correction des erreurs liées à la connexion, vous pouvez effectuer les actions suivantes :
Cette erreur peut en cacher d’autres. Il peut arriver que d’autres erreurs apparaissent après en avoir résolu une. |
Erreurs d’API
Type |
|
Problème | Un problème est survenu au niveau de Stripe (cas rare). |
Solutions | Traitez le résultat de l’appel à l’API comme indéterminé. Autrement dit, ne partez pas du principe qu’il a abouti ou échoué. Appuyez-vous sur les webhooks pour obtenir des informations sur le résultat. Lorsque cela est possible, Stripe déclenche des webhooks pour tous les nouveaux objets créés pendant la résolution du problème. To set your integration up for maximum robustness in unusual situations, see this advanced discussion of server errors. |
Erreurs d’authentification
Type |
|
Problème | Stripe ne parvient pas à vous authentifier avec les informations que vous avez fournies. |
Solutions |
|
Erreurs d’idempotence
Type |
|
Problème | You used an idempotency key for something unexpected, like replaying a request but passing different parameters. |
Solutions |
|
Erreurs d’autorisation
Type |
|
Problème | La clé API utilisée pour cette requête ne dispose pas des autorisations nécessaires. |
Solutions |
|
Erreurs de limite de débit
Type |
|
Problème | Vous avez effectué trop d’appels à l’API dans un temps réduit. |
Solutions |
|
Erreurs de vérification de signature
Type |
|
Problème | You’re using webhook signature verification and couldn’t verify that a webhook event is authentic. |
Solutions | Cette erreur peut se produire alors que votre intégration fonctionne correctement. Si vous utilisez la vérification de signature de webhook et qu’un tiers tente de vous envoyer un faux webhook ou un webhook malveillant, alors la vérification échoue et une erreur survient. Capturez-la et renvoyez un code d’état If you receive this error when you shouldn’t—for instance, with webhooks that you know originate with Stripe—then see the documentation on checking webhook signatures for further advice. In particular, make sure you’re using the correct endpoint secret. This is different from your API key. |