# Une association et Stripe : la 3D Secure qui doublait le temps perçu

> Plusieurs secondes de redirections 3D Secure s'ajoutaient au parcours de don d'une association, sans qu'aucun blocage réel n'existe côté serveur. Diagnostic et correctif par affichage progressif.

- Auteur : WordPress Développement
- Publié le : 2022-07-25
- Mis à jour le : 2022-07-25
- Catégorie : Performance
- URL : https://www.wpmoderne.fr/performance/association-stripe-3d-secure-temps-percu/

## L’essentiel

- Le blocage n'est pas technique mais perceptif, l'écran reste figé
- Un affichage progressif change radicalement l'expérience sans toucher au flux 3D Secure
- Chaque étape de la redirection doit rester visible pour le donateur

« Le paiement est-il en train de planter ? » Cette question, posée en interne après plusieurs signalements de donateurs abandonnant leur parcours de don juste après avoir saisi leurs coordonnées bancaires, résume bien le problème observé sur cette plateforme de collecte pour une association. Le parcours de don, techniquement fonctionnel de bout en bout, semblait figer l'écran pendant près de cinq secondes au moment précis où la banque du donateur déclenche une vérification 3D Secure.

## Diagnostic : une chaîne de redirections invisible pour l'utilisateur

L'authentification 3D Secure, imposée par la directive européenne DSP2 sur la majorité des paiements par carte, fonctionne par une série de redirections : le navigateur du donateur est envoyé vers une page hébergée par la banque émettrice, qui affiche un défi d'authentification (code reçu par SMS, application bancaire), avant de rediriger à nouveau vers le site marchand une fois la vérification validée. Sur ce parcours, l'intégration Stripe utilisée gérait cette chaîne de redirections dans un conteneur invisible (une iframe cachée) le temps que la première étape de la banque se charge, ce qui laissait l'écran visible du donateur strictement identique pendant plusieurs secondes, sans aucun indice visuel de ce qui se passait.

Techniquement, rien ne bloquait : chaque redirection s'exécutait normalement, dans les délais attendus pour ce type d'échange entre le site marchand, Stripe, et la banque émettrice. Le problème n'était pas un ralentissement réel, mais un silence perceptif : le donateur voyait un écran figé et en concluait, à raison, que quelque chose n'allait pas.

> L'essentiel à retenir : Le blocage n'est pas technique mais perceptif, l'écran reste figé ; Un affichage progressif change radicalement l'expérience sans toucher au flux 3D Secure ; Chaque étape de la redirection doit rester visible pour le donateur

## Mesure du temps perçu comme figé

Un chronométrage manuel, reproduit sur une dizaine de parcours de test avec différentes banques, a mesuré un temps moyen de 4,8 secondes entre le clic sur le bouton de paiement et l'apparition visible du premier écran d'authentification de la banque, temps pendant lequel l'interface du site ne montrait strictement aucun changement, pas même une simple animation de chargement.

## Correctif : un affichage progressif de chaque étape

La correction n'a pas touché au flux 3D Secure lui-même, techniquement conforme et non modifiable côté site marchand puisqu'il obéit à une norme bancaire. Elle a consisté à rendre visibles, une par une, les étapes réellement en cours grâce aux événements exposés par le SDK Stripe.js, plutôt que de masquer entièrement le processus derrière un écran statique :

```
const { error, paymentIntent } = await stripe.confirmCardPayment(
    clientSecret,
    { payment_method: idMoyenPaiement }
);

// Affichage progressif basé sur le statut retourné
stripe.registerAppInfo({ name: 'don-association' });

afficherEtape( 'Connexion sécurisée à votre banque…' );

stripe.confirmCardPayment( clientSecret, {
    payment_method: idMoyenPaiement
} ).then( ( result ) => {
    if ( result.paymentIntent && result.paymentIntent.status === 'requires_action' ) {
        afficherEtape( 'Vérification en cours par votre banque…' );
    }
});
```

Concrètement, dès le déclenchement du paiement, un message « Connexion sécurisée à votre banque… » apparaît immédiatement, remplacé par « Vérification en cours par votre banque… » dès que Stripe signale le passage en authentification renforcée, puis par un message de confirmation une fois le don validé. Aucune de ces étapes n'ajoute de délai réel : elles se contentent de rendre visible ce qui se passait déjà, silencieusement, en arrière-plan.

## Résultat

Le temps réel du parcours de don n'a pas changé d'une seconde : la contrainte réglementaire de la 3D Secure reste incompressible. Ce qui a changé, c'est le taux d'abandon mesuré sur cette étape précise, qui a diminué de façon nette après la mise en place de cet affichage progressif, les donateurs ne quittant plus le parcours en pensant qu'il s'était interrompu.

- Ne jamais laisser un écran totalement statique pendant une étape bancaire obligatoire, même de quelques secondes.
- S'appuyer sur les événements exposés par le SDK de paiement plutôt que d'inventer un minuteur arbitraire déconnecté du déroulement réel.
- Tester le parcours avec plusieurs banques différentes, les délais réels de la première étape variant sensiblement d'un émetteur à l'autre.

> Un parcours de paiement qui respecte toutes les règles de sécurité peut encore échouer si le donateur croit, à tort, qu'il est cassé. La perception compte autant que la conformité.

## En résumé

Le ralentissement perçu sur ce parcours de don n'était pas un problème de performance au sens strict, mais un défaut d'affichage pendant une étape bancaire obligatoire et incompressible. En rendant visibles, étape par étape, les événements déjà exposés par le SDK Stripe, le temps réel du parcours n'a pas bougé, mais le sentiment de blocage a disparu, avec un effet mesurable sur le taux d'abandon.