# Tester un paiement Stripe en mode sandbox dans une suite PHPUnit WordPress

> Simuler les réponses de l'API Stripe en mode test pour valider un tunnel de paiement sans dépenser un centime, ni dépendre d'une connexion réseau fiable.

- Auteur : WordPress Développement
- Publié le : 2020-07-04
- Mis à jour le : 2020-07-04
- Catégorie : Tests
- URL : https://www.wpmoderne.fr/tests/tester-paiement-stripe-sandbox-phpunit/

## L’essentiel

- Clés de test dédiées, jamais les clés live
- Double de test pour le client Stripe
- Aucun webhook dans ce périmètre

`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_KEY` dans l'environnement de CI, différent de celui de production

> L'essentiel à retenir : Clés de test dédiées, jamais les clés live ; Double de test pour le client Stripe ; Aucun webhook dans ce périmètre

## 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.

1. Ajouter une méthode `create_payment_intent_refused()` au double de test
2. Vérifier que la commande reste au statut « en attente », jamais « payé »
3. 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.