Paiements récurrents et abonnements, niveau 2. 6 chapitres et un QCM final.

Chapitre 1. Architecture billing : plans, essais, prorata.

Un système d'abonnement mature sépare deux moteurs. Le billing engine décide quoi facturer, quand et combien (catalogue, cycles, essais, prorata, avoirs, taxes), tandis que le payment engine encaisse (identifiants stockés, autorisations, retries). Confondre les deux produit des architectures fragiles, où une simple remise commerciale casse la chaîne d'encaissement.

{
  "subscriptionId": "sub_9f27",
  "status": "active",
  "plan": { "id": "pro-monthly", "amount": 2900, "currency": "EUR", "interval": "month" },
  "trialEnd": "2026-06-15",
  "currentPeriod": { "start": "2026-07-01", "end": "2026-07-31" },
  "paymentMethod": { "type": "networkToken", "expiry": "2028-11" },
  "mandate": { "citAuthenticatedAt": "2026-06-01", "initialSchemeTxId": "MCC4XR..." },
  "pendingProration": { "amount": 1450, "reason": "upgrade-pro-to-max" }
}

Chapitre 2. CIT, MIT et conformité SCA du récurrent.

Le cadre des stored credentials de Visa et Mastercard distingue deux figures. Dans la CIT (Customer Initiated Transaction), le client est présent et agit ; dans la MIT (Merchant Initiated Transaction), le marchand déclenche seul, selon un accord préalable. Toute la conformité SCA du récurrent repose sur ce couple, avec SCA obligatoire sur la CIT initiale, puis MIT hors périmètre SCA, à condition que la chaîne soit correctement construite.

{
  "amount": 2900,
  "currency": "EUR",
  "storedCredential": {
    "initiator": "merchant",
    "usage": "subsequent",
    "reason": "recurring",
    "initialSchemeTransactionId": "MCC4XR9T20260601"
  },
  "credentialOnFile": true,
  "cvvPresent": false
}

Et côté prélèvement SEPA ?

• Le SDD (SEPA Direct Debit) repose sur un mandat signé (papier ou électronique) portant une référence unique (RUM) : c'est l'équivalent fonctionnel de la CIT initiale.
• La pré-notification du débiteur avant chaque prélèvement est obligatoire (montant et date), sauf accord sur un autre délai.
• Les échecs se matérialisent en R-transactions (reject, return, refund) : un remboursement peut être demandé par le payeur jusqu'à 8 semaines sans motif, 13 mois si mandat invalide.
• Le SDD est imbattable en coût pour le récurrent domestique, mais son délai de retour d'information et son droit à remboursement imposent une gestion du risque spécifique.

Chapitre 3. Involuntary churn : anatomie des échecs de prélèvement.

Le churn volontaire est une décision du client. Le churn involontaire (involuntary churn) est un accident de paiement. La carte a expiré, le solde est insuffisant, l'émetteur a refusé. Le client voulait rester abonné, et il part quand même. Cette perte de revenu est la plus frustrante d'un business d'abonnement, et la plus corrigeable.

Chapitre 4. Dunning avancé : retries, séquences, communication.

Le dunning orchestre la récupération d'un paiement échoué. Côté machine, des retries intelligents ; côté humain, une séquence de communications et une fenêtre de grâce. Les deux moitiés se renforcent. Le meilleur retry du monde ne récupère rien si la carte est fermée. Le meilleur email ne sert à rien si le lien de mise à jour demande dix étapes.

{
  "dunning": {
    "graceDays": 14,
    "retries": [
      { "at": "+1d", "window": "09:00-11:00 local", "if": "retryable" },
      { "at": "payday-next", "if": "code == 51" },
      { "at": "+8d", "mutations": ["useNetworkToken", "force3dsOnSoftDecline"] },
      { "at": "+14d", "final": true }
    ],
    "hardStops": ["category1", "chargeback", "mandateRevoked"],
    "notifications": ["email:J1", "push:J4", "email:J8", "email:J14"]
  }
}

• Timing sur les dates de paie : pour les codes 51, retenter autour du 28-1er (ou de la quinzaine selon le pays) surperforme largement les intervalles fixes.
• Heure locale et jour de semaine : les taux d'approbation varient selon l'heure ; les modèles ML des PSP spécialisés exploitent ces motifs par émetteur.
• Mutations de tentative : re-présenter autrement (basculer sur le network token, forcer le 3DS sur soft decline, ajuster le rail) plutôt que répéter à l'identique.
• Fenêtre de grâce : maintenir le service quelques jours augmente fortement la récupération ; la suspension brutale à J0 pousse au churn volontaire par frustration.
• Communication utile : chaque message doit contenir un lien de mise à jour de carte en 2 clics maximum, sur mobile d'abord.

Chapitre 5. Account updater et fraîcheur des identifiants.

Avec 2 à 3 % des cartes qui changent chaque mois, un portefeuille d'abonnés se périme mécaniquement. Au bout d'un an, près d'un tiers des identifiants stockés peuvent être obsolètes. Les réseaux offrent deux parades. Les services d'account updater d'abord, avec VAU (Visa Account Updater) et ABU (Mastercard Automatic Billing Updater). Viennent ensuite, plus structurellement, les network tokens, qui se mettent à jour tout seuls.

• Réponses updater typiques : nouveau PAN, nouvelle date d'expiration, compte fermé (stopper les prélèvements et solliciter le client), contacter le porteur.
• Traiter les réponses est aussi important que les demander : un « compte fermé » ignoré devient une série de retries facturés sur un code catégorie 1.
• Synchroniser l'updater avant les grosses vagues de prélèvement du mois, pas après.
• Les wallets (Apple Pay, Google Pay) reposent déjà sur des tokens réseau : leurs identifiants ne périment pratiquement jamais côté marchand.

{
  "responses": [
    { "merchantRef": "cust_1204", "result": "NEW_EXPIRY", "newExpiry": "2029-04" },
    { "merchantRef": "cust_0873", "result": "NEW_PAN", "panToken": "tok_new_8842" },
    { "merchantRef": "cust_2210", "result": "ACCOUNT_CLOSED", "action": "stop-billing" },
    { "merchantRef": "cust_1567", "result": "CONTACT_CARDHOLDER" }
  ]
}

Chapitre 6. Migrer de PSP et piloter par les métriques.

Le portefeuille d'identifiants stockés est l'actif le plus précieux d'un business d'abonnement, et la première source de dépendance au PSP. Une migration mal préparée peut détruire des points entiers de MRR, avec des identifiants perdus, des chaînes MIT cassées, des doubles prélèvements. La portabilité se négocie avant de signer, pas au moment de partir.

• Auditer l'actif : combien de tokens PSP, de network tokens, de mandats SEPA ? Quelle part du MRR dépend de chaque type d'identifiant ?
• Exporter les PAN : le PSP sortant transfère les PAN et dates d'expiration, chiffrés (PGP), directement vers l'environnement PCI DSS niveau 1 du PSP entrant, jamais par les systèmes du marchand. C'est une pratique standard : un PSP qui la refuse contractuellement est un signal d'alarme.
• Transférer les métadonnées MIT : exporter aussi les scheme transaction IDs initiaux et les indicateurs de mandat, pour que le nouveau PSP chaîne correctement les MIT.
• Re-provisionner les network tokens : liés au token requestor du PSP sortant, ils ne se copient pas ; ils se recréent depuis les PAN exportés (ou via le PAR), généralement sans friction client.
• Basculer progressivement : dual-run par cohortes (5 %, 25 %, 100 %), comparaison des taux d'acceptation à chaque palier, plan de retour arrière tant que la parité n'est pas prouvée.

Le tableau de bord du récurrent

SELECT
  DATE_TRUNC('month', failed_at)                    AS cohort,
  SUM(amount_eur)                                   AS failed_eur,
  SUM(CASE WHEN recovered THEN amount_eur END)      AS recovered_eur,
  ROUND(100.0 * SUM(CASE WHEN recovered THEN amount_eur END)
        / NULLIF(SUM(amount_eur), 0), 1)            AS recovery_rate_pct
FROM renewal_failures
GROUP BY 1
ORDER BY 1;