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.
Analyser les données d’erreur
Lorsque Stripe renvoie une erreur à votre requête à l’API, vous recevez des informations sur l’erreur qui vous aident à comprendre comment appliquer les suggestions de traitement de ce guide. Ces informations vous permettent également de fournir des informations importantes au service d’assistance de Stripe, le cas échéant.
Propriété | Description |
---|---|
code | Le code d’erreur. |
doc_ | Lien vers la documentation Stripe concernant le code d’erreur en question. |
message | Une description du motif de l’erreur. |
param | Paramètre de la requête responsable de l’erreur. |
request_ | Un lien vers le Dashboard Stripe où vous pouvez consulter les journaux détaillés de la requête initiale et de l’erreur. |
ID de demande | Un identifiant unique pour la requête d’origine ayant généré l’erreur. L’en-tête de réponse à l’erreur inclut cette valeur (chaîne commençant par req ), mais vous pouvez spécifier une impression dans votre requête, comme indiqué dans les exemples de code de ce guide. |
type | Référence à la catégorie d’erreur à laquelle l’erreur appartient. |
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 |
---|---|---|
Utiliser les valeurs d’erreur | 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 |
Utiliser des valeurs d’erreur
Les appels à l’API dans la bibliothèque Go de Stripe retournent une valeur de résultat et une valeur d’erreur. Utilisez des attributions multiples pour capturer ces deux valeurs. Si la valeur d’erreur n’est pas nil
, cela signifie qu’un problème immédiat a empêché la poursuite de l’appel à l’API.
Si la valeur de l’erreur est associée à Stripe, vous pouvez la convertir en objet stripe.
qui contient des champs qui décrivent le problème. Utilisez le champ Type pour déterminer la marche à suivre. Dans certains cas, vous pouvez convertir la propriété Err
en un type d’erreur plus précis avec des informations complémentaires.
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 :
- Récupérez l’objet concerné en désérialisant les données de
event.
.Data. Raw - 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 Go de Stripe, chaque objet Error possède un attribut Type
. Reportez-vous à la documentation concernant chaque classe pour obtenir des conseils quant aux réponses à apporter.
Nom | Type | Description |
---|---|---|
Erreur de paiement | Une erreur est survenue lors d’un paiement. Voici les cas possibles : | |
Erreur de requête invalide | L’appel à l’API que vous avez effectué n’est pas valide. Cela peut être dû à l’une des raisons suivantes : | |
Erreur d’API | Un problème est survenu au niveau de Stripe (cas rare). | |
Erreur d’idempotence | Vous avez utilisé une clé d’idempotence pour effectuer une action inattendue (par exemple, relancer une requête en transmettant des paramètres différents). |
Erreurs de carte
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 :
Pour pouvoir distinguer ces catégories ou en savoir davantage sur la façon d’y répondre, consultez les sections relatives aux codes d’erreur, aux codes de refus de paiement et aux résultats du paiement.
(Pour rechercher un résultat de paiement à partir d’un objet Error, récupérez d’abord le PaymentIntent correspondant ainsi que le dernier paiement que ce dernier a créé. L’exemple ci-après illustre cette étape.)
Utilisateurs de la version de l’API 2022-08-01 ou d’une version antérieure :
(Pour rechercher un résultat de paiement à partir d’un objet Error, récupérez d’abord le PaymentIntent correspondant ainsi que le dernier paiement que ce dernier a créé. L’exemple ci-après illustre cette étape.)
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 :
- Simulation de paiements bloqués en raison d’un risque de fraude
- Simulation de refus de paiements et d’autres erreurs liées aux cartes
Le code de test ci-dessous montre quelques possibilités.
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 :
Vous pouvez tester les paramètres de votre intégration à l’aide de cartes de test qui permettent de simuler des fraudes. Si vous avez défini des règles Radar personnalisées, suivez les conseils en matière de test décrits dans la documentation Radar. |
Refusé par l’émetteur
Type |
|
Codes |
|
Problème | L’émetteur de la carte a refusé le paiement. |
Solutions | Cette erreur peut se produire alors que votre intégration fonctionne normalement. Elle reflète une action effectuée par l’émetteur, qui peut être légitime. Utilisez le code de refus pour déterminer la marche à suivre. Consultez la documentation sur les codes de refus de paiement pour connaître les réponses adaptées à chaque code. Vous pouvez également effectuer les actions ci-après :
Analysez la façon dont votre intégration gère les refus de paiement à l’aide de cartes de test qui permettent de simuler des paiements réussis et refusés. |
Autres erreurs de paiement
Type |
|
Problème | Une autre erreur de paiement s’est produite. |
Solutions | Cette erreur peut se produire alors que votre intégration fonctionne correctement. Utilisez le code d’erreur pour déterminer la marche à suivre. Consultez la documentation sur les codes d’erreur pour connaître les réponses adaptées à chaque code. |
Erreurs de requêtes invalides
Les erreurs de requêtes non valides couvrent de nombreuses situations. La plus courante survient lorsque la requête à l’API contient des paramètres non valides ou si l’état actuel de votre intégration ne permet pas son exécution. Utilisez le code d’erreur (stripeErr.
) et consultez la documentation sur les codes d’erreur afin de trouver une solution. Certains codes d’erreur nécessitent une réponse spéciale :
rate_
etlimit lock_
reflètent erreurs de limite de débittimeout secret_
désigne une erreur d’authentificationkey_ required - D’autres codes d’erreur reflètent des paramètres ou un état non valides
Erreurs de limite de débit
Type |
|
Codes | stripeErr. |
Problème | Vous avez effectué trop d’appels à l’API dans un temps réduit. |
Solutions |
|
Erreurs d’authentification
Type |
|
Codes | stripeErr. |
Problème | Stripe ne parvient pas à vous authentifier avec les informations que vous avez fournies. |
Solutions |
|
Paramètres ou état non valides
Type |
|
Codes | stripeErr. |
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 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. Pour définir votre intégration de sorte qu’elle puisse gérer des situations inhabituelles, consultez cette section plus avancée sur les erreurs de serveur. |
Erreurs d’idempotence
Type |
|
Problème | Vous avez utilisé une clé d’idempotence pour effectuer une action inattendue (par exemple, relancer une requête en transmettant des paramètres différents). |
Solutions |
|