Apple Pay sur PrestaShop : pourquoi le bouton ne s’affiche pas, et comment le diagnostiquer ?

Le module de paiement est installé, la clé API est bonne, Apple Pay est coché dans le tableau de bord du prestataire. Vous ouvrez le tunnel de commande sur un iPhone, et le bouton n’est pas là.

Pas de message d’erreur. Rien dans les logs PrestaShop, rien dans la console du navigateur, rien côté prestataire de paiement. Le tunnel fonctionne parfaitement, il propose simplement les autres moyens de paiement comme si Apple Pay n’existait pas.

C’est le mode d’échec normal d’Apple Pay sur le web, et il est prévu ainsi. Comprendre pourquoi permet de diagnostiquer en cinq minutes ce qui se traite souvent en plusieurs allers-retours avec un support.

Au programme :

• Le mécanisme exact qui fait disparaître le bouton sans rien signaler
• Les quatre façons de servir le fichier de vérification de travers, dont une propre à PrestaShop
• Ce que le .htaccess généré par PrestaShop fait de votre dossier /.well-known/
• Le piège multiboutique, où Apple Pay marche sur un domaine et pas sur les autres
• La séquence de diagnostic en quatre commandes

Pourquoi rien ne s’affiche, et pourquoi rien ne le dit

Une intégration Apple Pay sur le web n’affiche jamais son bouton d’autorité. Elle demande d’abord au navigateur si le paiement est possible, et ne l’affiche que si la réponse est oui :

if (window.ApplePaySession && ApplePaySession.canMakePayments()) {
    ApplePaySession
        .canMakePaymentsWithActiveCard(merchantIdentifier)
        .then(function (peutPayer) {
            if (peutPayer) {
                afficherBoutonApplePay();
            }
            // sinon : on ne fait rien, et c'est tout le problème
        });
}

Le point capital est le comportement de canMakePaymentsWithActiveCard(). Cette méthode renvoie false, et non une erreur, dans plusieurs situations qui n’ont rien à voir entre elles :

• l’appareil n’a aucune carte active dans le Wallet
• l’identifiant marchand passé en paramètre est invalide
• le domaine sur lequel tourne le code n’est pas un domaine vérifié pour cet identifiant marchand

Un false pour trois causes radicalement différentes, dont une qui est un défaut de configuration serveur et deux qui sont des situations parfaitement normales. Comme le code appelant ne peut pas les distinguer, il fait la seule chose raisonnable : il n’affiche pas le bouton et il se tait.

Autrement dit, un problème de vérification de domaine se présente exactement comme un client qui n’a pas de carte enregistrée. C’est pour ça qu’on peut passer une journée à soupçonner le module, le prestataire ou le thème alors que le sujet est à la racine du serveur web.

Le fichier de vérification, et les quatre façons de le servir de travers

Pour qu’un domaine soit vérifié, Apple télécharge un fichier à une adresse fixe :

https://votre-domaine.fr/.well-known/apple-developer-merchantid-domain-association

Les contraintes sont plus strictes qu’on ne le croit, et chacune produit le même symptôme, à savoir aucun symptôme.

Le fichier doit répondre 200. Pas 301, pas 302. Apple ne suit aucune redirection pour ce téléchargement. C’est la cause la plus fréquente et la plus contre-intuitive, parce que la redirection en question est presque toujours une bonne pratique par ailleurs : la redirection de http vers https, ou celle du domaine sans www vers le domaine avec. Vous testez dans un navigateur, vous voyez le contenu du fichier, tout va bien. Apple, lui, reçoit un 301 et abandonne.

Le contenu doit être exactement celui fourni. Le fichier se télécharge depuis le tableau de bord du prestataire ou depuis le compte développeur Apple. Un copier-coller dans un éditeur qui ajoute un retour à la ligne final, ou un transfert en mode texte plutôt qu’en binaire, suffit à invalider la comparaison.

Le fichier n’a pas d’extension, et il commence par un point dans son chemin. C’est le point suivant, et il mérite sa section.

Chaque domaine doit être enregistré séparément. Vérifier boutique.fr ne vérifie ni www.boutique.fr, ni boutique.be, ni le sous-domaine de préproduction.

Ce que le .htaccess de PrestaShop fait de votre /.well-known/

PrestaShop régénère son .htaccess depuis Tools::generateHtaccess(), et la règle qui décide si un fichier est servi tel quel ou envoyé au dispatcher se termine ainsi :

# Send all other traffic to dispatcher
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ %{ENV:REWRITEBASE}index.php [NC,L]

Regardez la première condition : c’est -s, pas -f. En Apache, -f signifie « le fichier existe » alors que -s signifie « le fichier existe et n’est pas vide ».

La conséquence est vicieuse. Un fichier de vérification tronqué à zéro octet, ce qui arrive avec un transfert FTP interrompu ou un touch malencontreux, ne satisfait aucune des trois conditions. La requête part donc sur index.php, et Apple reçoit une page PrestaShop en guise de fichier de vérification. Le fichier est bien là, ls le montre, et pourtant il n’est jamais servi.

Deuxième point, plus général : PrestaShop protège explicitement un chemin caché, et un seul.

# Protect .git
RewriteRule \.git - [F,L]

Il ne dit rien de /.well-known/. Ce sont donc les règles de durcissement ajoutées ailleurs qui décident, et la règle la plus répandue pour bloquer .env, .git et consorts est une interdiction générale des chemins commençant par un point. Cette règle bloque /.well-known/ avec le reste. C’est exactement pour cette raison que les recettes Let’s Encrypt exigent une exception explicite sur ce dossier, et c’est le même mécanisme qui casse Apple Pay.

Si votre boutique est derrière nginx plutôt qu’Apache, le raisonnement est identique mais le fichier à regarder est le try_files du vhost.

Le piège multiboutique

Celui-là produit le scénario le plus déroutant : Apple Pay fonctionne sur une boutique et pas sur l’autre, avec la même installation, le même module et les mêmes identifiants.

Deux mécanismes se cumulent. D’abord, l’enregistrement Apple est par domaine. Une installation multiboutique avec trois domaines demande trois enregistrements, et rien ne le rappelle au moment de la mise en production de la deuxième boutique.

Ensuite, PrestaShop écrit un bloc de réécriture par domaine déclaré, et en multiboutique la règle qui autorise le service direct des fichiers est conditionnée à l’hôte :

#Domain: boutique.fr
RewriteCond %{HTTP_HOST} ^boutique.fr$
RewriteRule . - [E=REWRITEBASE:/]
...

#Domain: boutique.be
RewriteCond %{HTTP_HOST} ^boutique.be$
RewriteRule . - [E=REWRITEBASE:/]
...

Un domaine qui répond mais qui n’est pas déclaré dans les URL de boutique, typiquement un ancien domaine conservé pour les redirections ou un alias de recette, ne dispose d’aucun bloc. Le comportement de /.well-known/ sur ce domaine n’est alors défini par personne.

La règle de survie est simple : on teste le fichier sur chaque domaine servi, un par un. Jamais sur le domaine principal en supposant que les autres suivent.

La séquence de diagnostic

Quatre commandes, dans cet ordre, avant de contacter qui que ce soit.

D=boutique.fr
F=".well-known/apple-developer-merchantid-domain-association"

# 1. Le fichier répond-il 200, sans redirection ?
curl -s -o /dev/null -w 'code %{http_code}\n' "https://$D/$F"

# 2. Y a-t-il une redirection masquée ? (Apple ne les suit pas)
curl -sIL -o /dev/null -w '%{num_redirects} redirection(s), code final %{http_code}\n' \
  "https://$D/$F"

# 3. Est-ce bien le fichier, ou une page PrestaShop servie à sa place ?
curl -s "https://$D/$F" | head -c 60; echo

# 4. Et sur chacun des autres domaines de l'installation ?
for d in boutique.fr www.boutique.fr boutique.be; do
  printf '%-24s %s\n' "$d" "$(curl -s -o /dev/null -w '%{http_code}' "https://$d/$F")"
done

La lecture est immédiate. Un code autre que 200 en commande 1, ou un nombre de redirections supérieur à zéro en commande 2, et vous avez la réponse. La commande 3 attrape le cas le plus trompeur, celui où tout répond 200 parce que PrestaShop sert sa propre page : si la sortie commence par <!DOCTYPE ou par un espace de noms XML, ce n’est pas le fichier d’Apple.

Ce contrôle mérite d’entrer dans votre checklist de mise en ligne, au même titre que les autres vérifications d’URL. Un changement de domaine, une migration d’hébergement ou un durcissement de configuration le cassent silencieusement, et personne ne s’en aperçoit avant de regarder les statistiques de moyens de paiement.

Deux idées reçues à corriger

« Apple Pay ne marche que sur Safari. » C’était vrai, ça ne l’est plus. Depuis février 2025, Apple Pay est utilisable dans les navigateurs tiers, Chrome et Edge notamment, y compris sur un ordinateur Windows : l’utilisateur confirme le paiement sur son iPhone après avoir scanné un code affiché à l’écran. Refuser d’activer Apple Pay au motif qu’il ne toucherait que les utilisateurs de Safari repose donc sur une information périmée.

« Il faut au moins PrestaShop 1.7. » Cette affirmation confond deux choses. Apple Pay n’a aucune dépendance à la version de PrestaShop, c’est une capacité du module de paiement et du prestataire. Ce qui dépend de la version, c’est la disponibilité d’un module de paiement maintenu, et c’est un tout autre sujet. Si vous êtes sur une version ancienne, votre problème n’est pas Apple Pay, c’est la maintenance de la boutique.

Ce que ça coûte réellement

Apple ne prélève rien sur les paiements web. Apple Pay n’est pas un moyen de paiement au sens comptable, c’est une méthode d’authentification et de transmission de la carte, posée par-dessus le prestataire que vous utilisez déjà.

Les frais sont donc exactement ceux de votre contrat monétique existant, sans ligne supplémentaire. C’est une bonne nouvelle et une contrainte : si vos conditions actuelles ne vous conviennent pas, activer Apple Pay ne les changera pas.

Côté modules, celui de PayPlug est celui qu’on déploie le plus souvent chez nos clients, essentiellement pour deux raisons pratiques : le support est en français et le module PrestaShop est suivi. Stripe et Mollie font le même travail techniquement, et le choix se fait sur les conditions commerciales et sur la qualité du module, pas sur une supériorité technique de l’un ou de l’autre. Tout ce qui est décrit plus haut s’applique identiquement quel que soit le prestataire, parce que la vérification de domaine est une exigence d’Apple, pas du module.

Une dernière chose sur le bouton

Le bouton Apple Pay est fourni par le module, avec le rendu attendu par Apple. La tentation de le reprendre dans le thème pour l’harmoniser avec les autres moyens de paiement est mauvaise pour deux raisons : elle contrevient aux règles de présentation d’Apple, et surtout elle passe souvent par une surcharge de gabarit qui remplace la logique de détection par un affichage inconditionnel.

Le résultat est le symptôme inverse de celui de cet article, et il est pire : le bouton s’affiche pour tout le monde, y compris pour les visiteurs qui ne peuvent pas s’en servir, et le clic ne produit rien. Les libellés et les logos des modules de paiement s’affichent tels qu’ils sont fournis.

Questions fréquentes

Le bouton Apple Pay ne s’affiche pas, par où commencer ?
Par le fichier de vérification de domaine, avant le module et avant le prestataire. Lancez les quatre commandes de la section diagnostic. Dans la majorité des cas, le fichier répond une redirection ou renvoie une page PrestaShop.

Pourquoi n’y a-t-il aucune erreur nulle part ?
Parce que canMakePaymentsWithActiveCard() renvoie false et non une exception. Ce false couvre aussi bien un domaine non vérifié qu’un client sans carte enregistrée, deux situations que le code appelant ne peut pas distinguer. Ne rien afficher est donc le comportement correct.

Mon fichier est bien en place et ça ne marche toujours pas.
Vérifiez qu’il n’est pas vide. La règle générée par PrestaShop teste -s et non -f, donc un fichier de zéro octet est envoyé au dispatcher au lieu d’être servi. Vérifiez ensuite qu’aucune règle de durcissement ne bloque les chemins commençant par un point.

Apple Pay fonctionne sur une boutique et pas sur l’autre.
Chaque domaine doit être enregistré séparément chez Apple, et PrestaShop écrit un bloc de réécriture par domaine déclaré dans les URL de boutique. Testez le fichier sur chaque domaine, y compris les variantes avec et sans www.

Faut-il un certificat SSL particulier ?
Non, un certificat valide et une chaîne complète suffisent. En revanche la redirection de http vers https, qui est une bonne pratique, casse la vérification si elle s’applique à l’URL du fichier, puisque Apple ne suit pas les redirections.

Apple prend-il une commission ?
Non, aucune sur le web. Les frais sont ceux de votre prestataire de paiement actuel, inchangés.

Votre bouton Apple Pay est invisible et le support de votre prestataire vous répond que tout est bon de son côté ? Lancez les quatre commandes ci-dessus, vous aurez la réponse avant la fin du ticket. Si le fichier répond correctement sur tous vos domaines et que le bouton manque toujours, écrivez-nous.