Raccordement d'un dossier financier à Contact Form 7

Périmètre
Le formulaire et le contrat commercial restent ceux du marchand. Le moteur
reçoit un dossier financier créé par l'API marchande authentifiée ou par
l'administration. Il ne transforme pas un formulaire arbitraire en contrat
juridique et ne signe aucun document commercial.

Configuration du parcours avec référence préalable
1. Configurer un profil récurrent et l'associer explicitement à l'ID du formulaire
   CF7 dans les réglages du profil de paiement. Un profil sans formulaire associé
   ne peut pas autoriser la transmission d'un formulaire récurrent.
2. Dans le formulaire, ajouter une seule balise nommée :
   [3dis_billing_reference paiement profile:mon-profil]
   Ne pas la combiner avec la balise de paiement ponctuel [3dis_payment].
3. Sur la page WordPress, placer [3dis_billing_checkout], puis le shortcode CF7
   comme deux blocs distincts. Ne jamais placer le checkout dans le contenu
   du formulaire : cela imbriquerait des formulaires HTML.
4. Créer le dossier financier via le serveur marchand ou l'administration et
   ouvrir le lien personnel sur cette page. L'identité et les références client
   sont vérifiées par le raccordement serveur, pas déduites d'un champ libre.
5. Après autorisation et confirmation des paiements dus, le récapitulatif remet
   une preuve CF7 valable dix minutes. Si elle expire, recharger la page depuis
   le lien personnel encore valide. Une première échéance future ne déclenche
   pas artificiellement un prélèvement anticipé.
6. CF7 valide normalement les champs et l'antispam. Juste avant l'envoi, PAYMENT
   recontrôle l'état financier et réserve la transmission de façon atomique.

Ce raccordement ne crée pas automatiquement un dossier à partir des valeurs
brutes d'un formulaire public. Lorsqu'un formulaire public produit déjà un contrat
chez le marchand, son traitement serveur doit fournir la référence financière
par l'API marchande existante. Cette association ne doit jamais reposer uniquement
sur un identifiant client arbitraire envoyé par le navigateur.

Sécurité et reprise
La preuve CF7 est liée au dossier, au profil et au formulaire. Elle ne permet pas
d'appeler les endpoints d'autorisation, d'encaissement ou de régularisation.
Le jeton personnel de checkout n'est pas envoyé dans la soumission CF7.
Les champs techniques commencent par un soulignement ; vérifier les règles
d'export des éventuels addons tiers et ne pas les inclure dans les mails.
Le registre conserve uniquement un HMAC des valeurs et empreintes des fichiers,
pas les données personnelles ni les pièces jointes du formulaire.
Un mail réussi ne peut pas être rejoué avec cette autorisation. Un échec explicite
du mail permet de retenter les mêmes données et fichiers. Une réponse inconnue
ou un processus interrompu reste bloqué pour éviter un double envoi ; vérifier
les journaux CF7/SMTP avant toute intervention. Aucune relance automatique d'e-mail.
Une autorisation PayPal active ne suffit pas si le premier paiement est déjà dû :
une vente rapprochée, payée et non remboursée est nécessaire.

Recette
Les tests locaux utilisent SQLite et un cycle CF7 simulé. Ils vérifient l'accès,
le rattachement, les paiements dus, les doubles transmissions, l'échec du mail
et l'expiration. Ils ne constituent pas une preuve de réception d'e-mail.
La recette WordPress réelle doit vérifier les messages, les interactions avec
les autres addons et une destination de messagerie explicitement autorisée.
