3DIS PAYMENT — Reprise des paiements, résiliation et remboursements
État de développement du 30 septembre 2026, non publié

PAIEMENTS INITIAUX DISTINCTS

Chaque composant possède une ligne et une clé permanente par contrat, période et
nature. Une garantie réussie reste payée lorsque le premier mois échoue. Reprendre
la souscription ne présente pas une seconde fois la garantie à Stripe.
Les montants et leurs sources sont figés avant l'acceptation des conditions.

Un délai réseau ne signifie pas que le paiement a échoué. L'état « unknown »
bloque toute nouvelle création automatique. Un webhook signé apporte la référence,
puis le serveur relit Stripe et vérifie contrat, montant et devise avant rapprochement.

REMPLACEMENT D'UNE CARTE REFUSÉE

Dans le lien de souscription encore valide, cliquer sur la confirmation des
paiements initiaux. Si la banque demande une authentification, Stripe affiche
la confirmation. Si elle refuse le moyen de paiement, un champ Stripe permet
de saisir une nouvelle carte. Les données bancaires ne sont pas envoyées au
serveur WordPress. Le client doit accepter explicitement l'utilisation de cette
carte pour le paiement en attente et les futures échéances du contrat accepté.

Le paiement existant est confirmé : aucun nouveau PaymentIntent n'est créé.
Le serveur relit le résultat, vérifie le montant encaissé et contrôle que la
nouvelle carte est attachée au même client Stripe, dans le même environnement,
avec autorisation de paiements futurs hors session. Seules les références Stripe
sont enregistrées, chiffrées avec SecretCodec et les sels WordPress.

Le contrat conserve la référence du paiement en régularisation (recovery_charge).
Cette référence permet de reprendre après fermeture du navigateur ou perte de
réponse. La confirmation navigateur seule n'est jamais une preuve d'encaissement.
Une modification simultanée de l'autorisation empêche un écrasement silencieux.

Limite actuelle : parcours des paiements initiaux Stripe TEST seulement.
Le portail de régularisation des échéances ultérieures reste à intégrer et tester.
Le lien de souscription est personnel, expire après 24 heures et doit rester privé.

REMBOURSEMENT

Depuis le détail administratif du contrat, sélectionner le paiement concerné
et confirmer son remboursement intégral. Le remboursement de la garantie ne
rembourse pas le premier mois et ne résilie pas automatiquement l'abonnement.
Le droit refund_3dis_payment et une requête HTTPS authentifiée sont requis.

Le verrou local empêche une seconde demande. En cas de réponse perdue, l'état
reste inconnu ; il faut rapprocher l'opération existante, jamais créer aveuglément
un remboursement supplémentaire. Un échec bancaire tardif peut remplacer un
état précédemment réussi. L'historique de l'encaissement original est conservé.

Ajouter à la destination Stripe de la nouvelle version : refund.created,
refund.updated, refund.failed et charge.refund.updated. Le gestionnaire vérifie
la signature, l'environnement, les métadonnées de rattachement, puis relit le
remboursement auprès de Stripe. Ces événements supplémentaires ne sont pas encore
configurés sur la destination de recette existante.

Limite actuelle : remboursement intégral d'une ligne Stripe TEST. Les remboursements
partiels et l'équivalent PayPal ne sont pas couverts par cette interface.

RÉSILIATION

L'action administrative confirmée suspend d'abord les nouveaux traitements locaux
(cancel_requested), puis annule l'échéancier distant s'il existe. En cas de réponse
perdue, la prochaine vérification consulte d'abord le prestataire. Le statut ne
devient cancelled qu'après confirmation. Les échéances variables ne sont alors
plus sélectionnées. Un traitement déjà présenté à la banque peut encore aboutir.
Les sommes déjà encaissées ne sont pas remboursées par cette action.

Stripe : annulation immédiate sans facture de clôture ni proratisation implicite.
PayPal : annulation de l'abonnement, suivie d'une relecture de son état.
Les remboursements éventuels sont des opérations séparées et explicites.

VALIDATION ET LIMITES DE CETTE COPIE

Tests locaux PHP/SQLite et transports simulés : absence de double présentation,
succès initial partiel, réponse perdue, signature webhook, remboursement séparé,
échec de remboursement tardif, résiliation et reprise avec nouvelle carte.
Ces tests ne remplacent pas MariaDB, WordPress, Stripe TEST et PayPal Sandbox.
La version 1.1.0-dev.2 a été installée le 30 septembre pour la recette autorisée,
avec des nouveaux flux récurrents limités au TEST. Deux paiements fictifs de 1 EUR
ont réussi, dont un après refus puis remplacement de carte sur le même paiement.
Les deux remboursements intégraux et résiliations ont été confirmés. Aucun réglage
global LIVE n'a été modifié. La copie dev.3 ajoute le suivi des factures natives ;
sa recette distante reste à effectuer. Voir le rapport de recette du projet.

HISTORIQUE DES FACTURES NATIVES STRIPE (dev.3)

Les événements invoice.* et customer.subscription.* sont relus dans l'API Stripe
après validation de signature. Le client, l'environnement, le contrat et le lien
entre abonnement et échéancier enregistré sont vérifiés avant mise à jour.
Ce lien est également contrôlé après release de l'échéancier.
Les factures sont stockées dans une table distincte 3dis_payment_invoices :
ce rapprochement ne crée jamais une nouvelle demande d'encaissement.
Un rejeu ne duplique pas une facture. Une ancienne lecture ne réouvre pas une
facture soldée. Le statut Soldée n'est pas synonyme de débit de carte : un avoir
ou un règlement externe peut solder la facture. Les remboursements natifs ne
sont pas encore rapprochés dans ce tableau et doivent être vérifiés chez Stripe.

Événements à ajouter : invoice.finalized, invoice.paid, invoice.payment_failed,
invoice.payment_action_required, invoice.voided, invoice.marked_uncollectible,
customer.subscription.created, customer.subscription.updated,
customer.subscription.deleted, customer.subscription.paused,
customer.subscription.resumed. Ne pas souscrire invoice.created inutilement :
un échec de livraison de cet événement peut retarder la finalisation Stripe.

Avant diffusion : calendrier natif fin de mois, historique des factures natives,
webhooks PayPal, portail client, notifications et parcours CF7 complet, puis
recette de migration et de non-régression et incrément de version.

Références techniques :
https://docs.stripe.com/js/payment_intents/confirm_card_payment
https://docs.stripe.com/api/payment_methods/retrieve
https://docs.stripe.com/refunds
https://docs.stripe.com/api/subscription_schedules/cancel
