Exemptions à l'authentification forte (SCA) : réduire la friction sans fragiliser sa passerelle de paiement

Depuis l'entrée en vigueur de l'authentification forte, tout commerçant en ligne vit la même tension : sécuriser les transactions sans décourager les acheteurs. Chaque écran d'authentification ajouté au parcours fait chuter la conversion de plusieurs points. C'est précisément là qu'interviennent les exemptions à la SCA : des dérogations légales qui autorisent une passerelle de paiement à présenter certaines transactions sans challenge, en mode frictionless. Bien utilisées, elles permettent de récupérer une part significative du chiffre d'affaires perdu dans la friction, tout en restant parfaitement conforme à la réglementation européenne. Mal comprises, elles exposent le marchand à un risque de fraude accru et à des refus d'autorisation en cascade.

Cet article détaille l'ensemble du dispositif : le cadre SCA/DSP2, chacune des exemptions (TRA, faible montant, MIT, MOTO, bénéficiaires de confiance, corporate), qui les demande, ce qui se passe quand l'émetteur refuse, et comment construire une véritable stratégie d'exemptions avec des acteurs comme Stripe ou Adyen. L'objectif est opérationnel : vous aider à prendre les bonnes décisions de paramétrage.

Le cadre SCA/DSP2 : ce que la loi impose vraiment

La deuxième directive sur les services de paiement (DSP2), transposée en droit français, impose l'authentification forte du client (Strong Customer Authentication, SCA) pour la grande majorité des paiements électroniques initiés par le payeur dans l'Espace économique européen. En France, l'application effective s'est étalée jusqu'au 15 mai 2021 pour le e-commerce par carte, après un plan de migration piloté par la Banque de France et l'Observatoire de la sécurité des moyens de paiement.

Le principe de la SCA est simple : l'authentification doit reposer sur au moins deux facteurs indépendants parmi trois catégories — la connaissance (un mot de passe, un code), la possession (un smartphone, un token) et l'inhérence (une empreinte, le visage). En pratique, la combinaison dominante est aujourd'hui la notification poussée dans l'application bancaire (possession) validée par biométrie (inhérence). Le protocole technique qui porte cette authentification sur le web est le 3-D Secure version 2, dont nous détaillons le fonctionnement dans notre article dédié au 3DS2 et à l'authentification forte.

Mais la DSP2, au-delà de l'obligation, prévoit explicitement une série de dérogations. Elles figurent dans les normes techniques réglementaires (Regulatory Technical Standards, ou RTS) rédigées par l'Autorité bancaire européenne (EBA). Ces RTS encadrent précisément les cas où une transaction peut échapper à l'authentification active. Comprendre cette architecture est essentiel : la SCA n'est pas une obligation absolue, c'est un principe assorti d'exemptions et de cas hors périmètre.

Il faut distinguer trois situations. Premièrement, les transactions dans le périmètre pour lesquelles une exemption peut être demandée. Deuxièmement, les transactions hors périmètre (out of scope) qui ne sont tout simplement pas soumises à la SCA. Troisièmement, les transactions qui doivent impérativement être authentifiées. Nous allons voir que les exemptions relèvent du premier groupe, tandis que MIT et MOTO relèvent plutôt du second.

Qui demande l'exemption : acquéreur ou émetteur ?

C'est le point le plus souvent mal compris, et pourtant déterminant pour votre paramétrage. Dans le flux de paiement par carte, deux établissements interviennent : l'acquéreur (la banque ou le PSP qui encaisse pour le compte du marchand, par l'intermédiaire de votre passerelle de paiement) et l'émetteur (la banque qui a délivré la carte à l'acheteur). Les deux peuvent, selon l'exemption, jouer un rôle.

Certaines exemptions sont demandées côté acquéreur. C'est le cas de l'analyse de risque transactionnel (TRA) : votre passerelle ajoute un indicateur dans le message d'autorisation pour signaler qu'elle estime le risque faible et souhaite sauter l'authentification. D'autres exemptions sont appliquées côté émetteur : la banque de l'acheteur peut décider, de son propre chef et sans que vous ayez rien demandé, de laisser passer un petit montant ou un bénéficiaire que son client a enregistré comme de confiance.

Dans tous les cas, une règle domine : l'émetteur a le dernier mot. Même lorsque votre acquéreur demande une exemption, la banque de l'acheteur peut la refuser si son propre scoring de risque n'est pas d'accord. Elle renvoie alors un signal indiquant qu'une authentification est requise. Ce mécanisme de fallback, que nous détaillons plus loin, est la clef d'une stratégie d'exemptions réussie.

À retenir : demander une exemption n'est jamais une garantie. Vous optimisez une probabilité de passage en frictionless, pas une certitude. La qualité des données transmises et la réputation de votre flux auprès des émetteurs comptent autant que l'exemption elle-même.

L'exemption TRA : la plus puissante et la plus technique

L'analyse de risque transactionnel (Transaction Risk Analysis, TRA) est la pierre angulaire d'une stratégie d'optimisation. Elle permet de demander l'exemption pour des montants bien plus élevés que les autres dérogations, à condition que le prestataire qui la demande affiche un taux de fraude suffisamment bas sur l'ensemble de son portefeuille.

Le principe est le suivant : plus le taux de fraude de l'acquéreur (ou de l'émetteur) est faible, plus le plafond de montant éligible à l'exemption TRA est élevé. Ces seuils sont fixés directement dans les RTS de l'EBA et sont identiques dans toute l'Union. Les voici :

Taux de fraude de référence	Plafond du montant exempté (TRA)
Inférieur à 0,13 % (13 points de base)	Jusqu'à 100 €
Inférieur à 0,06 % (6 points de base)	Jusqu'à 250 €
Inférieur à 0,01 % (1 point de base)	Jusqu'à 500 €

Concrètement, un acquéreur dont le taux de fraude agrégé est inférieur à 1 point de base (soit une transaction frauduleuse pour 10 000) peut demander l'exemption TRA sur des paniers allant jusqu'à 500 €. À l'inverse, au-delà de 0,13 % de fraude, l'exemption TRA n'est plus disponible du tout : l'authentification forte redevient la règle. Ces taux sont calculés par trimestre glissant sur la base du volume de transactions à distance.

Deux subtilités méritent l'attention. D'abord, le taux pris en compte est celui du prestataire, pas celui du marchand isolé. Un gros PSP mutualise le risque sur des milliers de commerçants, ce qui lui permet d'afficher des taux agrégés très bas et donc d'accéder aux plafonds supérieurs. C'est un argument majeur en faveur des grandes passerelles. Ensuite, l'exemption TRA appliquée côté acquéreur ne transfère pas la responsabilité en cas de fraude : le marchand ou son PSP conserve le risque de chargeback. C'est le prix de la fluidité, et cela doit entrer dans votre calcul.

Lorsque c'est l'émetteur qui applique une exemption TRA de son côté (sur la base de son propre taux de fraude), la responsabilité reste alors chez lui. Mais le marchand n'a aucune maîtrise de cette décision ; il ne peut piloter que la demande côté acquéreur, via les règles configurées dans sa passerelle.

L'exemption faible montant (low-value) et son compteur

C'est l'exemption la plus intuitive. Toute transaction par carte à distance d'un montant inférieur à 30 € peut être exemptée d'authentification forte. Elle est particulièrement pertinente pour les petits paniers récurrents : presse en ligne, micro-transactions, applications mobiles, restauration livrée, stationnement.

Mais cette facilité est encadrée par un double compteur tenu par l'émetteur, destiné à éviter qu'un fraudeur n'enchaîne les petits montants :

• Pas plus de 5 transactions faible montant consécutives sans authentification forte sur la même carte ;
• Pas plus de 100 € cumulés en transactions faible montant non authentifiées.

Dès que l'un de ces deux plafonds est atteint, l'émetteur doit déclencher une authentification forte, qui réinitialise le compteur. Le point crucial pour le marchand : ce compteur est côté banque, vous n'y avez pas accès. Vous pouvez donc demander une exemption faible montant parfaitement valide sur le plan du montant (par exemple 12 €) et vous la voir refuser parce que le client a déjà épuisé son quota chez d'autres commerçants. Là encore, le fallback vers le challenge est indispensable.

À noter : l'exemption faible montant appliquée par l'émetteur ne transfère pas non plus la responsabilité au marchand ; comme elle est décidée côté banque, le liability shift ne joue tout simplement pas dans ce schéma. Les montants paraissent faibles, mais sur de gros volumes de micro-paiements, l'optimisation de cette exemption a un impact réel sur la conversion, sujet que nous approfondissons dans notre guide pour optimiser le taux de conversion au checkout.

Les transactions initiées par le marchand (MIT) et les abonnements

Les paiements initiés par le marchand (Merchant-Initiated Transactions, MIT) constituent un cas à part. Ce ne sont pas, à proprement parler, des exemptions : ce sont des transactions hors périmètre de la SCA, parce que le client n'est pas présent au moment où le débit est déclenché. La logique de la DSP2 est que l'authentification forte protège l'acheteur au moment où il agit ; si c'est le marchand qui initie seul le prélèvement, en vertu d'un accord préalable, la SCA ne s'applique pas à ce débit précis.

Les MIT recouvrent de nombreux cas : abonnements et prélèvements récurrents, débits différés, paiements fractionnés, régularisations, facturation à l'usage. C'est le socle de tout modèle par abonnement. Le mécanisme est le suivant :

• Le premier paiement, initié par le client, est dans le périmètre SCA. Il doit être authentifié, le plus souvent avec un challenge, car c'est à cet instant que l'on scelle le mandat et que l'on enregistre la carte.
• Lors de cette première authentification, la passerelle récupère une référence de transaction (et le cas échéant un cryptogramme réseau) qui servira de preuve de consentement.
• Les prélèvements suivants sont présentés comme des MIT, rattachés à cette référence initiale, et passent sans authentification.

Le danger ici est opérationnel : si votre passerelle ne signale pas correctement la nature MIT de la transaction, ou ne transmet pas la référence de l'authentification initiale, l'émetteur peut légitimement décliner le prélèvement en exigeant une SCA impossible à réaliser (le client n'est pas là). C'est une cause fréquente d'échecs sur les abonnements. Les plateformes spécialisées dans le modèle récurrent, comme Stripe Billing ou Adyen, gèrent nativement ce chaînage, mais il faut vérifier que l'intégration est correctement paramétrée. On parle parfois d'exemption « paiement récurrent de montant fixe » pour le cas particulier des abonnements à montant constant, mais dans les faits la plupart des PSP traitent l'ensemble des récurrents en MIT hors périmètre.

Le MOTO : les paiements à distance sans présence en ligne

Le MOTO (Mail Order / Telephone Order) désigne les paiements saisis par le commerçant sur instruction de l'acheteur, par téléphone, par courrier ou par bon de commande. L'exemple type : une réservation prise par téléphone, un abonnement souscrit auprès d'un conseiller, une commande B2B passée oralement.

Ces transactions sont hors périmètre de la SCA, pour une raison technique simple : il n'existe pas de canal électronique permettant de déclencher une authentification forte du client. La carte n'est pas présentée dans un navigateur, il n'y a pas de session 3DS possible. La contrepartie est double. D'une part, l'absence d'authentification signifie aucun transfert de responsabilité : en cas de fraude ou de contestation, c'est le marchand qui porte le risque. D'autre part, les transactions MOTO relèvent souvent d'un contrat d'acquisition spécifique et d'un code de saisie dédié ; elles doivent être correctement catégorisées dans votre passerelle, faute de quoi elles seront traitées comme des transactions e-commerce et bloquées par l'exigence SCA.

Le MOTO reste indispensable dans de nombreux secteurs (hôtellerie, call centers, services, B2B), mais il doit être utilisé avec discernement : c'est le canal le plus exposé à la fraude, et il doit être surveillé de près dans votre dispositif de prévention des chargebacks.

Les bénéficiaires de confiance (trusted beneficiaries / whitelisting)

L'exemption de bénéficiaire de confiance repose sur une démarche de l'acheteur lui-même. Lors d'une authentification 3DS2, l'émetteur peut proposer au client d'ajouter le marchand à sa liste de bénéficiaires de confiance (trusted beneficiaries). Une fois le marchand ainsi « whitelisté » dans l'application bancaire de l'acheteur, les paiements ultérieurs vers ce même marchand peuvent passer sans challenge.

C'est une exemption extrêmement intéressante pour la fidélisation : un client régulier qui vous a enregistré comme marchand de confiance vivra un parcours quasi sans friction sur toutes ses commandes suivantes. Son fonctionnement présente plusieurs caractéristiques :

• L'inscription à la liste se fait côté émetteur, dans l'interface bancaire du client, au moment d'une authentification. Le marchand ne peut pas y inscrire ses clients d'autorité.
• Une fois le marchand enregistré, c'est l'émetteur qui applique l'exemption sur les transactions suivantes, ce qui conserve le transfert de responsabilité : un avantage notable par rapport à la TRA.
• Le marchand peut toutefois signaler, via sa passerelle, qu'il souhaite bénéficier de cette exemption pour un client donné, ce qui invite l'émetteur à la vérifier.

Le déploiement effectif du whitelisting a longtemps été inégal selon les banques, mais il progresse. Pour un commerçant avec une clientèle récurrente (abonnements, achats réguliers, places de marché fidélisantes), encourager ses clients à activer le statut de confiance lors du premier paiement authentifié est un levier de fluidité durable.

Les paiements corporate : cartes logées et virtuelles

La DSP2 prévoit un régime spécifique pour certains paiements professionnels, qualifiés de paiements corporate sécurisés. Il s'agit de transactions effectuées au moyen de dispositifs et de procédures dédiés, mis à disposition de clients qui ne sont pas des consommateurs : cartes logées, cartes virtuelles à usage unique, comptes centralisés de voyages d'affaires, systèmes de paiement interentreprises.

Les cas typiques sont les cartes logées utilisées par les agences de voyages pour régler les prestataires, les cartes virtuelles générées pour une dépense précise, ou encore les comptes de paiement centralisés des grandes entreprises. Ces instruments s'appuient sur des protocoles de sécurité propres (processus d'approbation internes, limites, traçabilité) jugés équivalents par le régulateur, ce qui justifie l'exemption de SCA.

Pour le marchand, l'enjeu est de bien identifier et flaguer ces transactions corporate dans sa passerelle de paiement, car elles exigent un paramétrage spécifique et un contrat d'acquisition adapté. Mal catégorisées, elles tomberont sous le coup de l'exigence SCA standard, impossible à satisfaire pour une carte virtuelle logée. Ce régime concerne surtout les secteurs du voyage, de la distribution B2B et des plateformes de dépenses d'entreprise.

Tableau récapitulatif des exemptions et de leurs conditions

Le tableau ci-dessous synthétise les principales dérogations, qui les demande, et l'impact sur le transfert de responsabilité. Il constitue une grille de lecture utile pour configurer votre moteur de règles.

Dispositif	Condition / plafond	Qui l'initie	Liability shift
TRA (faible risque)	100 € / 250 € / 500 € selon le taux de fraude (<0,13 % / <0,06 % / <0,01 %)	Acquéreur ou émetteur	Non si acquéreur ; oui si émetteur
Faible montant	< 30 € ; max 5 opérations ou 100 € cumulés par carte	Émetteur	Non
MIT / récurrents	Hors périmètre ; 1er paiement authentifié, suivants chaînés	Marchand (signalé par la passerelle)	Selon le 1er paiement
MOTO	Paiement par téléphone ou courrier, hors périmètre	Marchand / acquéreur	Non
Bénéficiaire de confiance	Marchand whitelisté par l'acheteur dans son app bancaire	Émetteur (signalé par l'acquéreur)	Oui
Corporate sécurisé	Cartes logées / virtuelles, procédures B2B dédiées	Acquéreur	Variable selon contrat

Le fallback vers le challenge : le filet de sécurité indispensable

Toute stratégie d'exemption repose sur un mécanisme de repli. Lorsque votre acquéreur demande une exemption et que l'émetteur n'est pas d'accord, ce dernier répond par un refus doux (soft decline), signalé par un code dédié (le plus souvent le code 1A dans l'écosystème). Ce code ne signifie pas « transaction refusée » mais « authentification nécessaire ».

Une passerelle de paiement correctement conçue intercepte ce soft decline et rejoue automatiquement la transaction en déclenchant un challenge 3DS2. L'acheteur s'authentifie (biométrie, notification, OTP), puis le paiement repart et aboutit. Du point de vue du client, la friction n'est ajoutée que lorsqu'elle est strictement nécessaire : c'est exactement l'objectif de la DSP2.

Le danger est de traiter le code 1A comme un refus définitif. Sans logique de fallback, chaque exemption refusée se traduit par une vente perdue, alors que l'acheteur était parfaitement solvable et de bonne foi. La capacité à retenter avec challenge, de façon transparente, est donc un critère de choix majeur d'une passerelle. Toutes les grandes plateformes la gèrent, mais le paramétrage par défaut n'est pas toujours optimal ; il faut le vérifier.

En pratique : une bonne séquence consiste à tenter d'abord l'exemption (frictionless), puis à ne déclencher le challenge qu'en cas de soft decline. On parle de stratégie « exemption first, challenge on decline ». Elle maximise le taux de frictionless tout en garantissant que les ventes à risque modéré ne sont pas perdues.

Impact sur le taux d'autorisation et la conversion

Les exemptions agissent sur deux indicateurs économiques distincts, qu'il ne faut pas confondre. D'un côté, le taux de conversion au checkout : chaque challenge évité supprime un point de friction où l'acheteur peut abandonner. Sur les transactions challengées, le taux d'abandon mesuré se situe souvent entre 3 et 8 % avec les applications bancaires modernes, mais peut grimper nettement plus haut quand l'authentification échoue techniquement (OTP non reçu, appli non installée, temps d'attente).

De l'autre côté, le taux d'autorisation : la part des transactions acceptées par l'émetteur. Une exemption bien demandée augmente les chances d'acceptation en frictionless, mais une exemption mal calibrée ou envoyée sur un flux à mauvaise réputation peut au contraire déclencher des refus. Le pilotage fin du couple exemption/challenge est au cœur du monitoring du taux d'autorisation, qui doit faire l'objet d'un suivi régulier.

Il faut aussi intégrer le risque. Chaque exemption demandée côté acquéreur (TRA notamment) retire le filet du transfert de responsabilité : en cas de fraude, le chargeback est pour vous. Sur des volumes importants, l'économie de friction peut largement compenser ce surcoût de fraude — ou l'inverse, si vos paniers moyens sont élevés et votre clientèle exposée. C'est un arbitrage à chiffrer, pas une règle universelle. Ces questions s'inscrivent dans une démarche plus large de sécurité du paiement en ligne.

Arbitrer entre friction et risque : la grille de décision

La bonne stratégie dépend de votre profil : panier moyen, fréquence d'achat, exposition à la fraude, marge. Le tableau suivant propose une grille d'arbitrage selon le type de transaction.

Profil de transaction	Approche recommandée	Pourquoi
Petit panier (< 30 €), volume élevé	Exemption faible montant, puis TRA en fallback	Friction très coûteuse en proportion ; risque unitaire faible
Panier moyen (30–250 €), client nouveau	TRA si éligible, challenge sur soft decline	Équilibre friction/risque ; fallback obligatoire
Panier élevé (> 500 €) ou atypique	Challenge 3DS2 d'emblée	TRA indisponible ; liability shift indispensable
Client récurrent fidèle	Bénéficiaire de confiance + MIT	Frictionless durable avec transfert de responsabilité
Abonnement / prélèvement	SCA au 1er paiement, MIT ensuite	Hors périmètre après authentification initiale
B2B / voyages d'affaires	Flag corporate / cartes virtuelles	Régime dédié hors SCA standard

La logique générale : réserver le challenge aux transactions où il apporte vraiment de la valeur (montants élevés, signaux de risque, premiers paiements), et laisser passer en frictionless tout ce qui peut l'être sans danger. Cette hiérarchisation doit être traduite en règles concrètes dans le moteur de votre passerelle.

Piloter sa stratégie d'exemptions via sa passerelle (Stripe, Adyen…)

Les grandes passerelles proposent aujourd'hui des moteurs qui décident, transaction par transaction, de la meilleure exemption à demander. Chez Stripe, le dispositif 3D Secure couplé au moteur d'analyse (Radar) choisit automatiquement, pour chaque paiement, s'il faut tenter une exemption ou déclencher un challenge, en optimisant le taux d'autorisation. Chez Adyen, la brique de gestion du risque (RevenueProtect) joue le même rôle, avec une logique de dynamic 3DS et de gestion automatique des soft declines.

Ces moteurs reposent sur deux ingrédients. Le premier est la richesse des données transmises : plus vous fournissez d'informations contextuelles (adresse de facturation et de livraison, e-mail, téléphone, historique du client, device), plus le scoring de risque est précis et plus l'émetteur est enclin à accorder une exemption ou un frictionless. Le second est la réputation du flux : un marchand au taux de fraude faible et au comportement stable obtient de meilleurs taux de frictionless.

Pour piloter efficacement votre stratégie, quelques principes :

• Activez la tokenisation réseau (Apple Pay, Google Pay, network tokens Visa et Mastercard) : ces paiements bénéficient de taux de frictionless nettement supérieurs et fiabilisent les MIT.
• Enrichissez chaque requête d'autorisation avec toutes les données disponibles ; ne laissez jamais les champs optionnels vides.
• Vérifiez le paramétrage du fallback : la bascule automatique vers le challenge sur soft decline doit être active.
• Segmentez vos règles par type de transaction, selon la grille d'arbitrage ci-dessus, plutôt que d'appliquer une politique unique.
• Mesurez en continu : taux de frictionless, taux d'autorisation, taux de challenge, taux de fraude et taux de chargeback doivent être suivis ensemble, car optimiser l'un au détriment des autres est contre-productif.

Enfin, souvenez-vous que les seuils TRA sont calculés sur le portefeuille du prestataire. Choisir une passerelle à faible taux de fraude agrégé, c'est mécaniquement accéder à des plafonds d'exemption plus élevés. C'est l'un des avantages structurels des grandes plateformes, qu'il faut mettre en balance avec leurs frais et leur flexibilité contractuelle.

Questions fréquentes

Quelle est la différence entre une exemption SCA et un paiement hors périmètre (out of scope) ?

Une exemption concerne une transaction qui entre dans le périmètre de la DSP2 (deux acteurs européens, paiement par carte initié par l'acheteur) mais pour laquelle on demande à sauter l'authentification forte : faible montant, TRA, bénéficiaire de confiance, etc. Un paiement hors périmètre n'est tout simplement pas soumis à la SCA : transaction MOTO, paiement initié par le marchand (MIT), ou transaction où l'émetteur ou l'acquéreur est situé hors de l'Espace économique européen (règle one-leg-out). La distinction est importante car une exemption peut être refusée par l'émetteur, alors qu'un paiement hors périmètre n'a pas à l'être.

Qui demande l'exemption : l'acquéreur ou l'émetteur ?

Les deux peuvent initier une exemption, selon le type. L'acquéreur (via votre passerelle de paiement) demande les exemptions TRA, bénéficiaire de confiance et les flags corporate dans le message d'autorisation. L'émetteur, lui, peut appliquer unilatéralement une exemption faible montant ou bénéficiaire de confiance s'il juge le risque acceptable, même si l'acquéreur n'a rien demandé. Dans tous les cas, c'est l'émetteur qui tranche en dernier ressort.

Que se passe-t-il si l'émetteur refuse l'exemption demandée ?

L'émetteur renvoie un code indiquant qu'une authentification est nécessaire (soft decline, souvent le code 1A). Une passerelle de paiement bien conçue bascule alors automatiquement vers un challenge 3DS2 : l'acheteur est invité à s'authentifier (biométrie, notification push, OTP) puis le paiement est rejoué. Sans ce fallback, la transaction est simplement déclinée et vous perdez la vente. C'est pourquoi la capacité à retenter avec challenge est un critère essentiel de choix d'une passerelle.

L'exemption TRA entraîne-t-elle le transfert de responsabilité (liability shift) ?

Non. Quand vous demandez une exemption TRA via l'acquéreur, c'est vous (ou votre PSP) qui assumez la responsabilité en cas de fraude : il n'y a pas de liability shift. Le transfert de responsabilité ne s'applique qu'aux transactions authentifiées par 3DS2 ou aux exemptions appliquées par l'émetteur. C'est le cœur de l'arbitrage : économiser de la friction avec une exemption TRA, c'est accepter de porter le risque de chargeback fraude sur ces transactions.

Les abonnements et prélèvements récurrents sont-ils soumis à la SCA ?

Seul le premier paiement, initié par le client, nécessite une authentification forte (souvent avec un challenge pour sceller le mandat). Les prélèvements suivants sont des MIT (merchant-initiated transactions) : ils sont hors périmètre SCA car le client n'est pas présent au moment du débit. Il faut toutefois les signaler correctement à votre passerelle de paiement, en liant chaque prélèvement à l'authentification initiale via une référence de transaction, sans quoi l'émetteur peut les décliner.

Combien d'exemptions faible montant un client peut-il enchaîner ?

L'émetteur tient un compteur par carte : il doit déclencher une authentification forte dès que le client a cumulé 5 transactions faible montant consécutives sans SCA, ou dès que le montant cumulé de ces transactions dépasse 100 €. Le marchand n'a pas la visibilité sur ce compteur, qui est côté banque. C'est pourquoi une exemption faible montant demandée peut être refusée alors même que la transaction fait moins de 30 € : le seuil du compteur est atteint.