check_ajax_referer( 'mon-action', 'security' ) — cette ligne, ou son absence, figure parmi les premières choses à chercher dans le code d’une passerelle de paiement livrée par un prestataire externe. Valider le travail d’un tiers sur une passerelle demande une liste de contrôle précise, car les erreurs les plus coûteuses ne sautent pas aux yeux lors d’un simple test d’achat réussi.
Voici les cinq points qui reviennent le plus souvent dans une revue de ce type de code, dans l’ordre où il est utile de les vérifier.
1. Le montant est-il revalidé côté serveur ?
Le piège le plus classique consiste à faire confiance à un montant transmis par le navigateur, par exemple dans un champ caché ou un paramètre de requête, sans le recalculer à partir de l’objet WC_Order côté serveur avant de l’envoyer au prestataire de paiement. Une passerelle correctement écrite recalcule systématiquement $order->get_total() juste avant de construire la requête de paiement, et ignore toute valeur de montant qui pourrait provenir d’ailleurs.
$montant_a_facturer = $order->get_total();
// Ne jamais utiliser une valeur transmise par le client à ce stade.2. Les journaux contiennent-ils des données sensibles ?
Un appel à wc_get_logger()->debug() placé sans précaution peut consigner l’intégralité de la charge utile échangée avec le prestataire, y compris des fragments de numéro de carte ou des jetons d’authentification, si la passerelle n’utilise pas correctement la tokenisation proposée par son prestataire. Il faut relire chaque appel de journalisation et vérifier explicitement quelles clés du tableau sont effectivement écrites.
3. Les webhooks sont-ils authentifiés indépendamment des nonces ?
Un nonce WordPress protège une action déclenchée depuis une session authentifiée du site, mais un webhook entrant provient d’un serveur tiers sans session WordPress associée : un nonce n’a donc aucun sens à cet endroit. La vérification attendue ici passe par la signature fournie par le prestataire — une somme de contrôle HMAC calculée avec une clé secrète partagée — comparée avec hash_equals() plutôt qu’un simple opérateur d’égalité, pour éviter une comparaison vulnérable aux attaques temporelles.
if ( ! hash_equals( $signature_attendue, $signature_recue ) ) {
wp_die( 'Signature invalide', '', [ 'response' => 401 ] );
}4. Le statut de commande change-t-il uniquement sur confirmation du prestataire ?
Certaines implémentations marquent une commande comme payée dès le retour du navigateur vers la page de confirmation, sans attendre la notification serveur à serveur du prestataire. Un client qui ferme son navigateur avant la redirection finale, ou dont la redirection échoue pour une raison réseau, se retrouve alors avec une commande jamais marquée payée malgré un paiement réellement effectué — ou l’inverse, plus grave, une commande marquée payée sans confirmation réelle du prestataire.
5. Les erreurs de configuration échouent-elles de façon visible ?
Une clé d’API mal renseignée ou un mode bac à sable resté actif par erreur doivent produire un message d’erreur explicite dans l’administration, pas un échec silencieux découvert uniquement lorsqu’un client se plaint de ne pas pouvoir payer. La méthode process_payment() de la classe WC_Payment_Gateway doit systématiquement encapsuler ses appels externes dans une gestion d’exception qui journalise clairement la cause.
Liste de contrôle récapitulative
- Le montant transmis au prestataire est recalculé côté serveur, jamais reçu tel quel du client.
- Aucune donnée de carte ou jeton n’apparaît en clair dans les journaux applicatifs.
- Les webhooks sont authentifiés par signature comparée avec
hash_equals(), indépendamment de tout nonce. - Le statut de commande ne change qu’après confirmation explicite du prestataire, jamais sur simple retour navigateur.
- Toute erreur de configuration produit un message exploitable en administration.
En résumé
Une passerelle de paiement qui fonctionne lors d’un test d’achat ponctuel n’a pas nécessairement été construite correctement sur ces cinq points, qui ne se révèlent que dans des cas limites : montant manipulé, webhook rejoué, connexion coupée en cours de redirection. Les vérifier systématiquement avant mise en ligne coûte quelques heures de revue et évite des incidents bien plus longs à corriger une fois le prestataire parti.
