Connectez-vous pour souscrire à la cotisation.
'; } $statut = get_user_meta( get_current_user_id(), 'statut_abonnement_stripe', true ); if ( 'actif' === $statut ) { return 'Votre cotisation est active. Merci !
'; } return cotisation_generer_bouton_checkout(); } ``` > L'essentiel à retenir : Webhook Stripe traité par un endpoint REST WordPress dédié ; Statut d'abonnement stocké en post meta plutôt qu'en table personnalisée ; Bloc dynamique affichant le formulaire selon le statut de connexion ## Étape 3 — Créer la session Checkout en mode abonnement Le bouton déclenche un appel REST vers un endpoint WordPress dédié, qui crée une session Stripe Checkout en mode `subscription` plutôt qu'en mode `payment` unique : ``` function cotisation_creer_session_checkout( WP_REST_Request $request ) { $session = \Stripe\Checkout\Session::create( array( 'mode' => 'subscription', 'line_items' => array( array( 'price' => 'price_XXXXXXXX', 'quantity' => 1, ) ), 'client_reference_id' => get_current_user_id(), 'success_url' => home_url( '/merci-adhesion/' ), 'cancel_url' => home_url( '/adhesion/' ), ) ); return rest_ensure_response( array( 'url' => $session->url ) ); } ``` ## Étape 4 — Traiter le webhook invoice.paid Un seul événement webhook suffit à couvrir ce cas d'usage : `invoice.paid`, déclenché à chaque paiement réussi, initial ou renouvelé. L'endpoint REST dédié met à jour le post meta du statut d'abonnement, après vérification de la signature Stripe : ``` function cotisation_webhook_stripe( WP_REST_Request $request ) { $evenement = \Stripe\Webhook::constructEvent( $request->get_body(), $request->get_header( 'stripe-signature' ), COTISATION_WEBHOOK_SECRET ); if ( 'invoice.paid' === $evenement->type ) { $user_id = $evenement->data->object->subscription_details->metadata['user_id'] ?? null; if ( $user_id ) { update_user_meta( $user_id, 'statut_abonnement_stripe', 'actif' ); } } return rest_ensure_response( array( 'reçu' => true ) ); } ``` ## Le choix du post meta plutôt qu'une table dédiée Une table personnalisée aurait pu sembler plus « propre », mais pour une seule donnée par utilisateur (le statut d'abonnement), elle ajoute une migration, une gestion de schéma et des requêtes SQL supplémentaires sans bénéfice réel sur ce volume. Le post meta sur l'utilisateur, via `update_user_meta()`, reste indexé correctement par WordPress et suffit largement tant que le nombre d'adhérents reste dans les milliers, pas les millions. - Statut d'abonnement stocké en `user_meta`, pas en table personnalisée. - Un seul événement webhook traité : `invoice.paid`, suffisant pour ce cas. - Session Checkout en mode `subscription`, jamais en paiement unique reconduit manuellement. > Avant d'ajouter une table SQL personnalisée, il vaut mieux se demander si le post meta ne suffit pas déjà — la réponse est oui bien plus souvent qu'on ne le pense. ## En résumé Un abonnement récurrent associatif se construit correctement avec un bloc dynamique léger, une session Stripe Checkout en mode abonnement, et un seul webhook traité côté WordPress. WooCommerce reste pertinent dès qu'un catalogue de produits variés entre en jeu, mais devient un poids inutile pour ce cas d'usage unique et récurrent.