Stripe Checkout sans WooCommerce : encaisser un paiement unique

\Stripe\Checkout\Session::create() prend moins de dix paramètres pour afficher une page de paiement hébergée, sécurisée et déjà traduite en français. Pas besoin d’installer WooCommerce, ses tables supplémentaires et ses trente réglages pour encaisser un paiement ponctuel : un don, un acompte, une inscription à un événement.

Cette approche convient dès que le site ne vend pas de catalogue de produits. Elle demande une extension légère, une clé API Stripe et un point d’entrée pour créer la session. Le reste — formulaire de carte bancaire, 3D Secure, gestion des erreurs de paiement — reste entièrement du côté de Stripe.

Pourquoi éviter WooCommerce pour un besoin ponctuel

WooCommerce ajoute une dizaine de tables, un système de commandes complet, des statuts, des emails transactionnels et un panier. Pour un formulaire de don ou un acompte unique, cette mécanique est disproportionnée : elle alourdit la base de données, multiplie les points de configuration et complique la maintenance d’un site qui n’a pas vocation à devenir une boutique.

Une extension maison de quelques centaines de lignes, appuyée sur l’API Stripe Checkout, couvre le besoin sans dépendance lourde. Le paiement lui-même est délégué à une page hébergée par Stripe, ce qui simplifie aussi la conformité PCI-DSS : aucune donnée de carte ne transite par le serveur WordPress.

Installer le SDK et générer la clé secrète

Le SDK officiel s’installe via Composer :

composer require stripe/stripe-php

La clé secrète (sk_live_... ou sk_test_...) ne doit jamais figurer dans un champ de réglage classique stocké en base sans précaution. Elle est chargée depuis une constante définie dans wp-config.php :

define( 'ASSO_STRIPE_SECRET_KEY', 'sk_test_xxx' );

Créer la session Checkout côté serveur

La création de la session se fait dans un callback lié à rest_api_init, qui expose un point d’entrée personnalisé :

add_action( 'rest_api_init', function () {
    register_rest_route( 'asso/v1', '/don', array(
        'methods'             => 'POST',
        'callback'            => 'asso_creer_session_stripe',
        'permission_callback' => '__return_true',
    ) );
} );

function asso_creer_session_stripe( WP_REST_Request $request ) {
    \Stripe\Stripe::setApiKey( ASSO_STRIPE_SECRET_KEY );

    $montant = absint( $request->get_param( 'montant' ) ) * 100;

    $session = \Stripe\Checkout\Session::create( array(
        'mode'                => 'payment',
        'payment_method_types' => array( 'card' ),
        'line_items'          => array( array(
            'price_data' => array(
                'currency'     => 'eur',
                'product_data' => array( 'name' => 'Don libre' ),
                'unit_amount'  => $montant,
            ),
            'quantity' => 1,
        ) ),
        'success_url' => home_url( '/merci?session_id={CHECKOUT_SESSION_ID}' ),
        'cancel_url'  => home_url( '/don-annule' ),
    ) );

    // On garde une trace côté WordPress avant même le paiement effectif.
    $don_id = wp_insert_post( array(
        'post_type'   => 'don',
        'post_status' => 'pending',
        'meta_input'  => array( '_stripe_session_id' => $session->id ),
    ) );

    return array( 'url' => $session->url );
}

Le champ à retenir ici, c’est mode: 'payment', qui distingue un paiement unique d’un abonnement (mode: 'subscription'). Confondre les deux est l’erreur la plus fréquente sur ce type d’intégration.

Gérer la page de retour et confirmer le paiement

La page de succès ne doit jamais marquer le don comme payé sur la seule foi du paramètre session_id dans l’URL : un visiteur pourrait forger cette URL manuellement. La confirmation se fait en interrogeant l’API Stripe :

1. Récupérer session_id depuis la requête GET.
2. Appeler \Stripe\Checkout\Session::retrieve( $session_id ).
3. Vérifier que $session->payment_status === 'paid'.
4. Mettre à jour le statut du CPT don correspondant en publish.
5. Déclencher l’envoi de l’email de remerciement via wp_mail() ou un service transactionnel.

Pour une fiabilité complète face à un visiteur qui ferme l’onglet avant le retour sur le site, un webhook Stripe (checkout.session.completed) reste la méthode la plus sûre — un sujet suffisamment dense pour mériter son propre article.

Sécuriser l’environnement de production

Quelques points de vigilance avant la mise en ligne :

• Utiliser les clés sk_test_ en environnement de recette, jamais la clé live en local.
• Restreindre le point d’entrée REST avec une vérification de nonce si le formulaire est affiché à un utilisateur connecté.
• Journaliser les erreurs de l’API Stripe (\Stripe\Exception\ApiErrorException) sans jamais afficher le message brut à l’utilisateur final.
• Prévoir un statut failed pour les dons qui n’aboutissent pas, afin de ne pas fausser les statistiques de collecte.

Le réflexe à prendre : toute donnée qui détermine si un paiement a réussi doit venir de Stripe, jamais du navigateur du visiteur.

Ce qu’il faut retenir

Une intégration Stripe Checkout autonome tient dans un seul fichier d’extension : un point d’entrée REST pour créer la session, un CPT léger pour le suivi, une page de retour qui vérifie le statut auprès de l’API. Cette sobriété a un coût : pas de facturation récurrente, pas de gestion de remboursement intégrée à l’admin WordPress, pas de rapport de vente. Pour un besoin ponctuel — don, acompte, inscription payante — c’est un compromis largement gagnant face à l’installation complète de WooCommerce.