STRIPE_SECRET_KEY=sk_test_... : cette seule variable d’environnement change tout dans une suite de tests qui touche au paiement. Avec une clé de test, chaque appel à l’API Stripe passe par un réseau parallèle, sans jamais toucher un compte bancaire réel, sans jamais facturer personne.
Sur une extension de don ou de vente en ligne, le tunnel de paiement est souvent la portion de code la plus fragile à faire évoluer : un changement dans la gestion des montants, un ajout de champ dans le formulaire de commande, et c’est toute la conversion qui peut casser silencieusement. Écrire une suite PHPUnit qui couvre ce parcours, du choix du montant à la confirmation, permet de refactoriser sans crainte. Ce billet ne traite pas des webhooks Stripe, qui répondent à une logique de test différente et méritent leur propre article.
Pourquoi ne jamais appeler la vraie API pendant les tests
Un test qui dépend d’un service distant hérite de tous ses défauts : latence, quotas, indisponibilités ponctuelles, et surtout un risque de créer de vraies transactions si la clé de production se glisse par erreur dans la configuration de test. Une suite qui appelle Stripe à chaque exécution devient lente et instable, deux qualificatifs incompatibles avec une intégration continue fiable.
La bonne pratique consiste à isoler la couche réseau derrière une interface que l’on peut remplacer en test. Concrètement, on encapsule les appels au SDK stripe/stripe-php dans une classe dédiée, par exemple Dons_Stripe_Client, injectée dans le contrôleur du formulaire de don plutôt qu’instanciée en dur.
Configurer les clés de test et l’environnement sandbox
Stripe fournit un jeu de clés préfixées pk_test_ et sk_test_, distinctes des clés live, utilisables sans limite et sans impact financier. Sur un projet WordPress, ces clés se stockent dans wp-config.php ou dans un fichier .env chargé par l’extension, jamais versionné.
- Créer un compte Stripe en mode test dans le tableau de bord
- Récupérer les clés de test depuis la section Développeurs
- Définir
STRIPE_SECRET_KEYdans l’environnement de CI, différent de celui de production
Simuler les réponses de l’API avec un double de test
Plutôt que d’appeler réellement Stripe, même en mode test, on peut aller plus loin pour la vitesse d’exécution : remplacer le client par un double qui retourne des réponses préfabriquées. Cela garde les tests rapides et déterministes, sans dépendre du réseau.
class Fake_Stripe_Client implements Stripe_Client_Interface {
public $last_amount;
public function create_payment_intent( $amount, $currency ) {
$this->last_amount = $amount;
return (object) array(
'id' => 'pi_test_123',
'status' => 'succeeded',
'amount' => $amount,
);
}
}Ce double respecte la même interface que le vrai client. Le contrôleur du formulaire de don ne sait pas qu’il parle à un faux service : c’est exactement le principe de l’injection de dépendances appliqué aux tests.
Écrire le test PHPUnit du tunnel de paiement
Le test vérifie que le montant saisi par le donateur est correctement transmis, que le statut de la commande passe à « payé » et qu’un enregistrement est créé en base.
class Test_Tunnel_Don extends WP_UnitTestCase {
public function test_don_de_50_euros_cree_une_commande_payee() {
$client = new Fake_Stripe_Client();
$controleur = new Dons_Controleur( $client );
$commande_id = $controleur->traiter_don( 5000, 'eur' );
$this->assertSame( 5000, $client->last_amount );
$this->assertEquals( 'paye', get_post_meta( $commande_id, 'statut', true ) );
}
}Notez que les montants Stripe s’expriment toujours dans la plus petite unité monétaire, soit des centimes pour l’euro. C’est une source d’erreur classique si le test compare directement des euros à des centimes.
Couvrir les cas d’échec du paiement
Un tunnel de paiement robuste doit aussi gérer les refus. On étend le double de test pour simuler une carte refusée et vérifier que le message affiché à l’utilisateur reste clair.
- Ajouter une méthode
create_payment_intent_refused()au double de test - Vérifier que la commande reste au statut « en attente », jamais « payé »
- Vérifier qu’un message d’erreur lisible est renvoyé au formulaire
Sur nos projets associatifs, la règle est simple : un test de paiement qui ne couvre pas au moins un cas d’échec ne couvre pas grand-chose.
En résumé
Tester un tunnel Stripe sans dépenser un centime demande deux ingrédients : des clés de test dédiées pour l’environnement sandbox, et un double de test pour garder la suite rapide et déterministe au quotidien. Les webhooks, qui valident la confirmation asynchrone du paiement, relèvent d’une stratégie de test distincte, souvent basée sur le rejeu d’événements capturés depuis le tableau de bord Stripe.
