Paiement en plusieurs fois et Pay Later avec CAWL sur WooCommerce

Le problème que rencontrent les marchands CAWL

Vous encaissez déjà avec CAWL, la solution de paiement adossée à la plateforme Worldline. Votre client vous demande de payer en trois fois. Vous cherchez l’option dans les réglages de l’extension WooCommerce, et il n’y a rien.

Actuellement, l’extension officielle CAWL pour WooCommerce gère le paiement par carte classique. Pas le paiement fractionné, pas le paiement différé.

Restent deux mauvaises options. Renoncer, et laisser partir les paniers élevés. Ou ajouter un second prestataire de type Alma ou Klarna, avec un contrat de plus, une commission de plus, un rapprochement comptable de plus, et un tunnel de commande qui affiche deux logos de financement concurrents.

Il en existe une troisième, et c’est l’objet de cet article : l’API CAWL sait déjà faire tout ce qu’il faut. Ce n’est simplement pas exposé dans l’extension.

Ce que l’API permet réellement

La plateforme sous-jacente met à disposition quatre briques qui suffisent à construire un paiement fractionné complet :

• Hosted Checkout : une session de paiement hébergée pour l’encaissement initial, avec l’authentification forte gérée par la banque
• Card-On-File : le paiement initial est marqué comme réutilisable pour des paiements ultérieurs
• SubsequentPayment : rejouer un paiement à partir de l’identifiant du paiement initial, en type installment ou recurring
• Pré-autorisation et capture différée : la base technique du Pay Later

L’authentification des appels utilise le schéma de signature de la plateforme :

Authorization: GCS v1HMAC:{apiKeyId}:{base64(hmac-sha256(secret, stringToSign))}

Le stringToSign concatène la méthode HTTP, le type de contenu, la date, le chemin de la ressource. Une erreur d’un seul caractère, un en-tête dans le mauvais ordre, et vous obtenez un 401 sans plus d’explication. C’est le premier obstacle, et le plus bête.

L’architecture : un CIT puis des MIT

C’est le point central, et celui qui inquiète à juste titre tout marchand : où sont stockées les cartes ?

Nulle part sur votre site, et c’est précisément l’intérêt du montage.

1. CIT, Customer Initiated Transaction. Le client paie la première échéance dans le tunnel hébergé de la banque, avec authentification forte. Le paiement est marqué comme réutilisable.
2. MIT, Merchant Initiated Transaction. Les échéances suivantes rejouent ce paiement initial en référençant son identifiant. Le client n’est pas présent, il n’y a pas de nouvelle authentification, et vous n’avez jamais manipulé un numéro de carte.

C’est le mécanisme prévu par les règles d’authentification forte pour exactement ce cas d’usage. Votre site ne stocke qu’un identifiant de transaction, pas une donnée bancaire.

Découper l’échéancier sans perdre un centime

Un total de 1000 € en 3 fois donne 333,33 €, trois fois, et il manque un centime. Multipliez par le nombre de commandes et votre comptabilité ne tombe plus juste.

Travaillez en centimes, entiers, et posez le reliquat sur la première échéance :

function split_amount( int $total_cents, int $count ): array {
    $base    = intdiv( $total_cents, $count );
    $amounts = array_fill( 0, $count, $base );
    // Le reliquat part sur la première échéance, celle qui est réellement encaissée.
    $amounts[0] += $total_cents - ( $base * $count );
    return $amounts;
}

Le reliquat sur la première et non sur la dernière : c’est la seule qui est encaissée avec le client présent, donc la seule dont le montant est visible et accepté au moment de l’achat.

Prélever les échéances avec Action Scheduler

N’utilisez pas WP-Cron pour des prélèvements bancaires. Sur un site à faible trafic, une tâche peut se déclencher avec plusieurs heures de retard, voire pas du tout.

Action Scheduler, déjà présent avec WooCommerce, offre une file persistante en base, avec journal d’exécution :

as_schedule_single_action(
    strtotime( $date . ' 09:00:00' ),
    'mon_prelevement_echeance',
    array( 'order_id' => $order->get_id(), 'k' => $k, 'attempt' => 0 ),
    'mon-plugin'
);

Prévoyez la relance dès le départ. Une carte expirée ou un solde insuffisant, ça arrive sur toutes les boutiques. Deux tentatives espacées de deux jours couvrent la grande majorité des cas, après quoi il faut basculer sur un traitement humain plutôt que d’insister.

Le piège des webhooks : l’idempotence

C’est de loin l’erreur la plus coûteuse, parce qu’elle ne se voit pas en recette et se paie en production.

Un même événement de paiement peut vous parvenir deux fois : par la notification de la banque et par le retour du navigateur du client. Ou deux fois par la même voie, si la banque considère que votre première réponse a échoué et rejoue l’appel.

Si votre code se contente de réagir à l’événement, vous confirmez deux fois la commande, vous planifiez deux échéanciers, et dans le pire des cas vous prélevez deux fois.

La parade tient en trois lignes, à condition d’y penser :

if ( $order->get_meta( '_echeance_' . $k . '_payee' ) ) {
    return; // Déjà traité, on ne fait rien.
}
$order->update_meta_data( '_echeance_' . $k . '_payee', $amount_cents );
$order->save();

Vérifiez aussi la signature des notifications. La plateforme signe le corps brut de la requête en HMAC-SHA256 avec un secret dédié. Un point d’entrée REST ouvert sans vérification de signature, c’est une porte pour marquer n’importe quelle commande comme payée.

Dernier détail, qui surprend : la paire de clés de webhook signe toutes les adresses de notification du compte. Selon la configuration, vous ne pourrez pas forcément déclarer une seconde adresse à côté de celle de l’extension officielle. Il faut alors observer les notifications qui lui sont destinées et traiter les vôtres au passage.

Le Pay Later

Le paiement différé repose sur un mécanisme différent : une pré-autorisation à la commande, puis une capture au bout de X jours.

Le point de vigilance est la durée de validité de l’autorisation. Elle dépend du réseau et de la banque émettrice, et se compte souvent en une poignée de jours plutôt qu’en un mois. Proposer un « payez dans 30 jours » sans avoir vérifié ce que votre contrat autorise, c’est prendre le risque de captures refusées en série.

Proposez des délais que vous avez validés, pas ceux qui font joli sur la page produit.

Le checkout en blocs

WooCommerce a fait du checkout en blocs le mode par défaut. Une passerelle de paiement écrite uniquement pour l’ancien tunnel n’y apparaîtra tout simplement pas.

Il faut enregistrer chaque moyen de paiement auprès du registre des blocs, avec son pendant JavaScript :

add_action( 'woocommerce_blocks_payment_method_type_registration', function ( $registry ) {
    $registry->register( new Mon_Blocks_Support( 'mon_paiement_nfois' ) );
} );

Si vous n’êtes pas encore passé aux blocs, mon service de migration vers le checkout en blocs traite ce sujet en amont.

L’affichage sur la fiche produit, là où tout se joue

Une erreur fréquente consiste à ne montrer le paiement en plusieurs fois qu’à l’étape de paiement. À ce moment-là, le client a déjà décidé.

Le paiement fractionné agit avant l’ajout au panier. « 1290 € » et « ou 3 fois 430 € » ne déclenchent pas la même décision, et c’est sur la fiche produit que la comparaison a lieu.

Sur un produit variable, pensez à recalculer le montant côté navigateur à chaque changement de variation, sans quoi vous affichez la mensualité de la mauvaise déclinaison.

Un point réglementaire à surveiller

Le paiement fractionné à court terme et sans frais a longtemps échappé au régime du crédit à la consommation en France. Le cadre européen évolue, et une partie de ces offres entre progressivement dans le champ du crédit, avec les obligations d’information et de vérification qui vont avec.

Je ne suis pas juriste et cet article n’est pas un avis juridique. Avant de mettre en ligne une offre de paiement fractionné, faites valider votre dispositif et vos mentions par votre conseil et par votre établissement bancaire. C’est le genre de sujet où le coût d’une vérification est sans commune mesure avec celui d’une régularisation.

En résumé

Construire le paiement en plusieurs fois sur CAWL est faisable, et probablement plus simple que d’ajouter un prestataire supplémentaire à votre tunnel. La difficulté n’est pas dans l’appel à l’API, elle est dans tout ce qui l’entoure : l’échéancier au centime, la file de prélèvements, les relances, l’idempotence, la signature des notifications, et l’affichage au bon endroit du parcours.

Aucun de ces points n’est insurmontable. Chacun d’eux, oublié, se traduit par une commande fausse ou un client prélevé deux fois.

Vous encaissez avec CAWL et vous voulez proposer le paiement en plusieurs fois ou le Pay Later sur votre boutique WooCommerce ? Parlons-en.