Stripe Checkout multilingue : accorder langue de page et langue de paiement

Un client navigue en italien sur une boutique WooCommerce multilingue, ajoute un produit au panier, clique sur payer, et se retrouve face à un formulaire de carte bancaire intégralement en anglais. Rien n’est cassé au sens strict : Stripe Checkout fonctionne, le paiement passe, mais l’expérience se rompt brutalement à l’étape la plus sensible du parcours d’achat, celle où la confiance du client compte le plus.

Ce décalage vient d’un malentendu fréquent sur la façon dont Stripe détermine la langue de son interface de paiement : par défaut, Stripe Checkout ne lit pas la langue active du site WordPress. Il applique sa propre logique, basée sur la langue du navigateur du client ou sur un paramètre explicite transmis lors de la création de la session de paiement.

Comment Stripe Checkout choisit sa langue sans intervention

Sans réglage additionnel, Stripe applique cet ordre de priorité pour choisir la langue de son interface :

• Le paramètre locale transmis explicitement lors de la création de la session Checkout, s’il est présent
• À défaut, la langue déclarée du navigateur du client (en-tête Accept-Language)
• À défaut encore, l’anglais par défaut

Sur une boutique multilingue, si l’extension de passerelle de paiement WooCommerce ne transmet pas ce paramètre locale, le client italien de l’exemple, avec un navigateur configuré en anglais pour des raisons professionnelles, se retrouve avec une interface de paiement en anglais malgré une navigation entièrement en italien sur le site.

Correctif : transmettre la langue Polylang ou WPML comme paramètre locale de Stripe

La correction consiste à intercepter la création de la session Stripe Checkout côté WooCommerce et à y injecter explicitement la langue active du site, convertie au format attendu par Stripe :

<?php
add_filter( 'wc_stripe_checkout_session_args', function( $args ) {
    $langue = function_exists( 'pll_current_language' )
        ? pll_current_language( 'locale' )   // ex. "it_IT"
        : get_locale();

    // Stripe attend un code court, pas toujours identique au format WordPress
    $correspondance = [
        'it_IT' => 'it',
        'de_DE' => 'de',
        'es_ES' => 'es',
        'fr_FR' => 'fr',
    ];

    $args['locale'] = $correspondance[ $langue ] ?? 'auto';

    return $args;
} );

La valeur auto en repli laisse Stripe revenir à sa détection par défaut si la langue active du site ne fait pas partie des langues explicitement gérées par Stripe Checkout, plutôt que de forcer une langue non supportée qui produirait une erreur silencieuse.

Les neuf langues gérées nativement, et ce qui se passe au-delà

Stripe Checkout gère nativement une liste précise de langues pour son interface (anglais, français, allemand, espagnol, italien, néerlandais, japonais, portugais du Brésil et chinois simplifié, entre autres selon les mises à jour de la plateforme). Une boutique proposant une langue hors de cette liste, l’arabe par exemple, verra Stripe basculer automatiquement sur l’anglais pour son interface de paiement, quelle que soit la configuration transmise, faute d’une traduction native disponible côté Stripe.

Ce point mérite d’être anticipé et assumé dans la communication au client plutôt que découvert en production : le tunnel de paiement d’un site en arabe restera en anglais, ce qui n’est pas un bug mais une limite documentée de l’outil de paiement.

Vérifier le rendu sans dépendre du navigateur du testeur

Pour tester ce réglage de façon fiable, il ne suffit pas de changer la langue du site : il faut aussi neutraliser la langue du navigateur de test, sans quoi une détection automatique par Stripe peut masquer un problème de transmission du paramètre locale. Le test le plus rigoureux consiste à ouvrir une session de navigation privée avec les outils de développement configurés pour usurper un en-tête Accept-Language différent de la langue du site testé.

En résumé

Stripe Checkout ne suit pas automatiquement la langue active d’un site WooCommerce multilingue : il faut lui transmettre explicitement ce réglage via le paramètre locale à chaque création de session. Sans cette synchronisation, l’expérience du client bascule silencieusement dans une langue potentiellement différente au moment le plus critique du parcours d’achat, celui du paiement.