Entrée en vigueur de la SCA
Comment les régulateurs européens appliquent l'authentification forte du client (SCA).
Bien que l’Europe introduise la SCA progressivement et de manière inégale, vous devez préparer vos tunnels de paiement afin d’être prêt pour la SCA dès que possible si sa réglementation vous concerne. Cela permet d’éviter une augmentation des refus de cartes européennes et de se préparer à une mise en application précoce par les banques. Obtenez plus d’informations sur la façon dont l’application varie selon les pays.
S’assurer que votre intégration est prête pour la SCA
Votre intégration est prête pour la SCA lorsque vous traitez tout le volume de vos paiements à l’aide de produits prêts pour la SCA. Votre entreprise doit utiliser un produit prêt pour la SCA, comme une version récente de Stripe Checkout, Billing, l’API Payment Intents ou une solution partenaire prête pour la SCA. En outre, vous devez :
- Testez minutieusement 3D Secure (3DS). Utilisez nos cartes de test réglementaires pour vous assurer que votre intégration peut gérer 3DS.
- Pour les paiements hors session, assurez-vous de configurer et d’authentifier la carte lors de l’enregistrement du moyen de paiement, et utilisez l’API pour signaler les paiements hors session.
- Si votre entreprise utilise les API Subscriptions ou Invoice de Stripe Billing, assurez-vous que votre intégration est capable de gérer les états incomplets.
Comprendre les paiements incomplets et les refus ou échecs de paiement
Les paiements peuvent échouer pour diverses raisons, notamment en cas de paiement incomplet, ou de refus ou échec de paiement. Si vous constatez dans le Dashboard que vos paiements ne dépassent pas l’état incomplet (requires_ dans l’API) :
- Assurez-vous que votre client n’est pas en train de s’authentifier. S’il s’authentifie et qu’il s’agit d’un paiement pendant une session, il peut s’attendre à voir ce message. Il se peut aussi qu’il ait abandonné le tunnel de paiement.
- Vérifiez que vous traitez les actions suivantes telles que l’authentification. L’échec des actions suivantes peut également entraîner l’échec des paiements.
- Pour les paiements hors session, définissez off_session sur la valeur
truelors de la création du paiement.
Les banques peuvent refuser des paiements qui nécessitent une authentification 3DS, mais pour lesquels le système 3DS n’est pas activé. Accédez au Dashboard pour voir quels paiements ont été refusés pour cette raison. Pour les paiements hors session, filtrez les paiements échoués dans le Dashboard. En passant la souris sur le badge d’état, la raison du refus sera mise en évidence (par exemple, en cas d’authentification requise). Vous pouvez visualiser les paiements en cours de session en appliquant le filtre des paiements incomplets et en vérifiant si le paiement est incomplet parce que l’authentification est requise.
Les paiements hors session peuvent échouer même si vous pensez qu’ils ne sont pas concernés par les exigences de la SCA. Pour les paiements hors session, assurez-vous d’authentifier la carte lorsque vous enregistrez ses informations, soit en absence de paiement, soit au cours d’un paiement. Lorsque vous enregistrez des cartes en absence de paiement, utilisez l’API Setup Intents et définissez l’utilisation sur off_. Si vous enregistrez des cartes pendant un paiement, définissez setup_future_usage sur off_. Enfin, notez que les exemptions ne sont pas garanties et que les paiements hors session peuvent toujours nécessiter une authentification par la banque.
Surveiller les litiges
When monitoring disputes, be aware that payments successfully authenticated through 3DS fall under the liability shift rule. If a cardholder disputes a 3D Secure payment as fraudulent, the liability typically shifts from you to the card issuer. If the card issuer applies exemptions, the payment isn’t authenticated through 3D Secure, and liability shift doesn’t apply.
Collecter l’autorisation de réutiliser les cartes
Lorsque vous configurez votre tunnel de paiement pour enregistrer correctement une carte avec l’API Payment Intents ou Setup Intents, Stripe marque tout paiement ultérieur effectué hors session comme une transaction initiée par le marchand (MIT) afin de réduire le besoin d’authentification. Les transactions initiées par le marchand nécessitent un accord (également appelé mandat) entre vous et votre client. Ajoutez à votre site web ou à votre application des conditions sur la manière dont vous prévoyez de traiter les paiements, auxquelles votre client peut adhérer. Vos conditions doivent au minimum comporter les éléments suivants :
- Le consentement du client vous autorisant à déclencher un paiement ou une série de paiements en son nom
- Fréquence prévue des paiements (à savoir, paiement ponctuel ou série de paiements récurrents)
- La façon dont vous déterminez le montant du paiement
Ajoutez dans votre tunnel de paiement du texte précisant les conditions de paiement. Par exemple : J’autorise [nom de votre entreprise] à demander à l’émetteur de ma carte de prélever un paiement sur le compte bancaire de ma carte conformément au contrat qui nous lie.
Utiliser des plugins Stripe compatibles avec la SCA
Si vous recherchez un plugin prêt pour la SCA, consultez la section Partenaires Stripe. Si vous souhaitez procéder à la migration d’un plugin Stripe existant ou d’une bibliothèque de développeurs pour prendre en charge la SCA, consultez le guide de migration vers la SCA pour les plugins et les bibliothèques de développeurs.