stripe.confirmPayment() : cet appel unique concentre, dans la nouvelle version du composant de don, toute la logique qui était auparavant dispersée dans un widget monolithique construit pour l’architecture V3 d’Elementor. La reconstruction de ce composant de don, pour une association qui gère six pages de collecte différentes (urgence, projet annuel, adhésion, don ponctuel, don mensuel, legs), n’était pas prévue au départ du projet, mais l’éditeur V4 encore en bêta a changé la donne.
Ce billet documente cette reconstruction, volontairement centrée sur l’architecture du composant de paiement. Il ne couvre pas la gestion des dons récurrents complexes (changement de montant, pause temporaire) ni la génération automatique des reçus fiscaux, deux sujets traités par des extensions spécialisées et hors périmètre ici.
Le problème du widget de don hérité de la V3
Le widget de don initial, construit comme un widget Elementor classique en architecture V3, mêlait dans une seule classe PHP la mise en page du formulaire, la validation des montants et l’appel à l’API Stripe Elements. Cette architecture rendait toute duplication coûteuse : chaque nouvelle page de collecte nécessitait de dupliquer le widget entier, puis d’ajuster manuellement le montant par défaut et le libellé de la campagne, avec un risque d’erreur de copier-coller sur les identifiants Stripe utilisés.
La séparation apportée par le composant V4
L’architecture atomique testée dans l’éditeur V4 a permis de découper cette logique en deux parties distinctes : un composant d’interface, purement responsable de l’affichage du formulaire et de ses champs, et un composant logique, responsable de l’appel à l’API Stripe. Le composant d’interface reçoit ses paramètres (montant par défaut, libellé de campagne, identifiant de produit Stripe) via les propriétés configurables du composant, exposées directement dans l’éditeur visuel.
const form = document.querySelector('#don-form-composant');
const stripe = Stripe('PUBLIC_KEY');
const elements = stripe.elements();
const card = elements.create('card');
card.mount('#card-element');
form.addEventListener('submit', async (e) => {
e.preventDefault();
const amount = form.dataset.montant; // fourni par le composant V4
const campagne = form.dataset.campagne; // fourni par le composant V4
const response = await fetch('/wp-json/wpmoderne/v1/dons/intent', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ amount, campagne }),
});
const { clientSecret } = await response.json();
const result = await stripe.confirmCardPayment(clientSecret, {
payment_method: { card },
});
if (result.error) {
document.querySelector('#don-erreur').textContent = result.error.message;
}
});Le point de terminaison qui crée l’intention de paiement
Côté serveur, un point de terminaison REST WordPress crée l’intention de paiement Stripe avec le montant et la campagne transmis, en s’appuyant sur le SDK PHP officiel de Stripe :
register_rest_route( 'wpmoderne/v1', '/dons/intent', [
'methods' => 'POST',
'callback' => function( $request ) {
\Stripe\Stripe::setApiKey( get_option( 'stripe_secret_key' ) );
$intent = \Stripe\PaymentIntent::create( [
'amount' => absint( $request['amount'] ) * 100,
'currency' => 'eur',
'metadata' => [ 'campagne' => sanitize_text_field( $request['campagne'] ) ],
] );
return [ 'clientSecret' => $intent->client_secret ];
},
'permission_callback' => '__return_true',
] );Le résultat sur les six pages de collecte
Une fois ce composant construit et testé, les six pages de collecte de l’association ont été reconstruites en réutilisant le même composant, avec un simple changement des propriétés montant et campagne pour chacune. La page de legs, qui nécessitait un formulaire plus long avec des champs additionnels, a nécessité une variante spécifique du composant d’interface, tout en réutilisant sans modification le composant logique de paiement.
- Un seul composant logique gère l’intégralité des appels Stripe, quelle que soit la page
- Les propriétés configurables évitent toute duplication de code pour les cas standards
- Les métadonnées de campagne transmises à Stripe simplifient le suivi des dons par origine dans le tableau de bord Stripe
Notre conseil pour ce type de composant sensible : ne jamais laisser la clé secrète Stripe transiter côté client, même dans un environnement de test — elle doit rester strictement confinée au point de terminaison serveur.
Pour aller plus loin
Cette reconstruction a aussi permis d’ajouter un suivi plus fin des dons par campagne, simplement grâce aux métadonnées transmises à chaque intention de paiement. La prochaine étape envisagée par l’association consiste à connecter ce suivi à un tableau de bord interne, un chantier qui dépasse le cadre technique traité dans cet article mais qui bénéficiera directement de cette architecture centralisée.
