Refus de paiement

Les paiements peuvent échouer pour diverses raisons, y compris, dans certains cas, pour prévenir les transactions frauduleuses. Stripe s’efforce de réduire les taux de refus sur tous les moyens de paiement pris en charge. Nous travaillons avec les émetteurs et les réseaux pour améliorer les taux d’acceptation, généralement sans affecter votre intégration.

Trois raisons peuvent expliquer un échec de paiement :

• Refus de l’émetteur
• Paiements bloqués
• Appels d’API non valides

Chaque type d’échec de paiement doit être traité différemment. Pour chaque échec, vous pouvez utiliser le Dashboard ou l’API pour examiner les détails d’un paiement. Lors de l’utilisation de l’API, regardez l’objet Charge résultat. Cet attribut couvre le type d’échec de paiement et fournit des informations sur sa cause.

Stripe gère les refus de moyen de paiement autre que la carte de la même manière que les refus de carte. Stripe vous envoie un code de réponse qui inclut des informations sur le refus, par exemple, s’il est dû à des fonds insuffisants, à une carte perdue ou volée ou à une autre raison.

Paiement refusé par l’émetteur

Lorsque l’émetteur de carte ou le prestataire de services de paiement de votre client reçoit des paiement, ses systèmes et modèles automatisés décident de l’autoriser ou non. Ces outils analysent des signaux tels que les habitudes de dépenses, le solde du compte et les données de carte (date d’expiration, informations d’adresse et CVC).

Si l’émetteur ou le prestataire de services de paiement de la carte refuse un paiement, Stripe partage avec vous les informations de refus de paiement que nous recevons par le biais de Stripe decline codes. Ces informations sont disponibles dans le Dashboard et sur l’API . Lorsque les émetteurs fournissent des explications spécifiques, comme un numéro de carte incorrect ou des fonds insuffisants, ces explications retournent à Stripe sous la forme de network decline codes.

Paiements bloqués

Stripe Radar bloque les paiements à haut risque, notamment ceux qui enfreignent vos règles personnalisées ou présentent des indices de risque élevés. Ce produit de prévention de la fraude automatisé évalue chaque paiement, sans que vous ayez à intervenir.

Un paiement refusé par Radar

Lorsque Stripe bloque un paiement, il n’obtient pas l’autorisation de l’émetteur de la carte. Cette précaution permet d’éviter d’éventuels paiements frauduleux qui pourraient donner lieu à des litiges.

Pour certains types de cartes, les clients peuvent voir l’autorisation de l’émetteur de la carte pour le montant du paiement sur leur relevé de compte. Cependant, Stripe n’a pas débité ce montant ni retiré de fonds. L’émetteur de la carte retire généralement cette autorisation du relevé du client en quelques jours.

Si une règle que vous avez configurée bloque un paiement que vous reconnaissez comme légitime, vous pouvez lever le blocage en localisant le paiement dans le Dashboard et en cliquant sur Ajouter à la liste blanche. Cette action ne permet pas de relancer le paiement. Au lieu de cela, il remplace toutes vos autres règles pour empêcher les tentatives de paiement ultérieures qui correspondent à l’attribut de liste.

Si vous utilisez l’API, le paramètre outcome d’un paiement bloqué indique le type et la raison de l’échec de paiement ainsi que son niveau de risque.

...
outcome: {
  network_decline_code: null,
  network_advice_code: null,
  network_status: "not_sent_to_network",
  reason: "highest_risk_level",
  advice_code: "do_not_try_again",
  risk_level: "highest",
  seller_message: "Stripe blocked this charge as too risky.",
  type: "blocked"
},
...

For users with IC+ pricing, Adaptive Acceptance blocks certain payments to help you avoid unnecessary network costs. For example, Adaptive Acceptance helps you avoid excessive retry penalties. Adaptive Acceptance can also help you avoid network costs by blocking payments that have low likelihood of authorization.

...
outcome: {
  network_decline_code: null,
  network_advice_code: null,
  network_status: "not_sent_to_network",
  reason: "low_probability_of_authorization",
  advice_code: "do_not_try_again",
  risk_level: "normal",
  seller_message: "Stripe blocked this payment as it is unlikely to be authorized.",
  type: "blocked"
},
...

Appels à l’API non valides

Dans l’API, vous pouvez voir un appel à l’API non valide comme suit :

curl https://api.stripe.com/v1/charges \
  -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:" \
  -d amount=2000 \
  -d currency=usd \
  -d source=tok_invalid \
  --data-urlencode description="Charge for jenny.rosen@example.com"

L’appel à l’API non valide génère une réponse d’erreur qui pourrait ressembler à ceci

{
  "error": {
    "code": "invalid_number",
    "doc_url": "https://docs.stripe.com/error-codes#invalid-number",
    "message": "Your card number is incorrect.",
    "param": "card[number]",
    "type": "card_error"
  }
}

Le résultat d’un paiement refusé comprend le type d’échec de paiement et le motif, en fonction du code de refus de l’émetteur de la carte. Le motif peut contenir des informations autres que le code de réponse de l’émetteur, par exemple, si une évaluation de règle Radar a bloqué les frais.

...
outcome: {
  network_decline_code: "54",
  network_advice_code: "01",
  network_status: "declined_by_network",
  reason: "expired_card",
  advice_code: "do_not_try_again",
  risk_level: "normal",
  seller_message: "The bank returned the decline code `expired_card`.",
  type: "issuer_declined"
},
...

Lors du développement de votre intégration Stripe, effectuez des tests en continu pour déterminer les éventuels problèmes susceptibles de générer des appels non valides à l’API. Les appels à l’API non valides n’entraînent généralement pas l’affichage d’un paiement dans votre Dashboard. Le paiement peut toutefois y être affiché dans certains cas.

...
outcome: {
  network_decline_code: null,
  network_advice_code: null,
  network_status: "not_sent_to_network",
  type: "invalid"
},
...