« Atelier Kessler », enseigne d’électroménager haut de gamme, constatait un taux d’abandon de panier élevé sur ses articles au-delà de 400 euros. Le paiement en plusieurs fois, courant dans la distribution physique du secteur, manquait totalement à son tunnel WooCommerce. Ce tutoriel construit l’intégration d’un prestataire tiers spécialisé dans le paiement fractionné, sans revenir sur l’architecture générale d’une passerelle de paiement personnalisée classique, déjà traitée ailleurs.
La particularité de ce type d’intégration : contrairement à une carte bancaire classique où la boutique reçoit le montant total immédiatement, le prestataire de paiement fractionné avance généralement la totalité à la boutique et prend à sa charge le risque de défaut de paiement des échéances suivantes, moyennant une commission. Le rôle de WooCommerce se limite à initier la demande et à réagir aux rappels de statut envoyés par le prestataire.
Étape 1 : enregistrer la passerelle
Comme toute méthode de paiement WooCommerce, l’intégration commence par une classe qui étend WC_Payment_Gateway, déclarée via le filtre woocommerce_payment_gateways. Cette passerelle n’affiche ses conditions qu’à partir d’un montant minimum de panier, configuré dans ses réglages, en dessous duquel le paiement fractionné n’a pas de sens commercial pour le prestataire retenu.
class AK_Gateway_Paiement_Fractionne extends WC_Payment_Gateway {
public function __construct() {
$this->id = 'ak_fractionne';
$this->method_title = 'Paiement en 3 fois';
$this->has_fields = false;
$this->init_form_fields();
$this->init_settings();
$this->montant_minimum = $this->get_option( 'montant_minimum', 100 );
}
public function is_available() {
if ( WC()->cart && WC()->cart->get_total( 'edit' ) < $this->montant_minimum ) {
return false;
}
return parent::is_available();
}
}Étape 2 : rediriger vers le prestataire
La méthode process_payment() ne finalise jamais la commande directement : elle crée la commande WooCommerce au statut en attente, prépare la charge utile attendue par l’API du prestataire (montant, découpage des échéances, identifiants de commande), puis redirige le client vers l’interface de paiement hébergée du prestataire.
public function process_payment( $order_id ) {
$order = wc_get_order( $order_id );
$order->update_status( 'on-hold', 'En attente de validation du paiement fractionné.' );
$url_redirection = ak_creer_session_paiement_fractionne( $order );
return array(
'result' => 'success',
'redirect' => $url_redirection,
);
}
Étape 3 : traiter le rappel serveur à serveur
Le prestataire notifie l’issue du paiement via un rappel HTTP (webhook) vers un point d’entrée dédié, indépendant de la redirection navigateur du client, qui peut échouer ou être fermée avant complétion. C’est ce rappel serveur à serveur, et lui seul, qui doit faire foi pour changer le statut réel de la commande.
add_action( 'woocommerce_api_ak_rappel_fractionne', 'ak_traiter_rappel_prestataire' );
function ak_traiter_rappel_prestataire() {
$signature_valide = ak_verifier_signature_rappel( $_POST );
if ( ! $signature_valide ) {
status_header( 400 );
exit;
}
$order = wc_get_order( sanitize_text_field( $_POST['reference_commande'] ) );
if ( 'accepte' === $_POST['statut'] ) {
$order->payment_complete( sanitize_text_field( $_POST['id_transaction'] ) );
} else {
$order->update_status( 'failed', 'Paiement fractionné refusé par le prestataire.' );
}
status_header( 200 );
}Étape 4 : gérer les remboursements partiels
Un remboursement partiel après un paiement fractionné doit être transmis au prestataire, qui recalcule les échéances restantes du client plutôt que la boutique elle-même. La méthode process_refund() de la passerelle appelle donc l’API du prestataire avant de confirmer le remboursement côté WooCommerce, jamais l’inverse.
- Ne jamais marquer une commande payée avant réception du rappel serveur à serveur
- Toujours vérifier la signature du rappel avant tout traitement
- Déléguer le recalcul des échéances au prestataire lors d’un remboursement partiel
Un test à ne pas sauter
Simuler une fermeture de navigateur juste après le paiement, avant la redirection de retour, permet de vérifier que la commande passe bien au bon statut grâce au seul rappel serveur à serveur, sans dépendre du retour du client sur le site. C’est un scénario que les tests manuels superficiels oublient presque systématiquement.
Une passerelle de paiement qui fait confiance à la redirection du navigateur pour valider une commande finira, tôt ou tard, par valider une commande jamais réellement payée.
En résumé
Intégrer un paiement fractionné tiers sur WooCommerce ressemble à toute intégration de passerelle externe, avec une nuance importante : le rappel serveur à serveur devient la seule source de vérité fiable, la redirection visible par le client n’étant qu’un affichage, jamais une confirmation. Chez Atelier Kessler, cette mise en place a permis de proposer trois échéances sur les paniers dépassant 400 euros, sans reprendre le développement d’une passerelle complète depuis zéro.
