Comment fonctionne 3DIS PAYMENT avec Contact Form 7 ?

Guide technique 3DIS PAYMENT

Ce guide explique comment relier Contact Form 7 à un profil Stripe ou PayPal, calculer le montant et la TVA, tester un seul produit puis contrôler la transaction et ses webhooks avant la mise en production.

Parcours de paiement 3DIS PAYMENT avec Contact Form 7 — Un parcours intégré au formulaire CF7.

Moyens de paiement Stripe et PayPal proposés par 3DIS PAYMENT — Stripe et PayPal selon la configuration du profil.

Prérequis

WordPress

Site protégé par HTTPS, version compatible, accès administrateur et sauvegarde récente.

Contact Form 7

Un formulaire publié avec des noms de champs stables et une adresse e-mail acheteur valide.

Prestataire

Compte Stripe ou PayPal, identifiants de test puis de production et droits nécessaires aux webhooks.

Installation et licence

Depuis Extensions, choisissez Ajouter puis téléversez le ZIP officiel de 3DIS PAYMENT.
Activez le plugin et ouvrez le menu 3DIS PAYMENT.
Dans Licence, saisissez la clé reçue après achat ou utilisez l’essai de 15 jours.
Vérifiez que le code produit, la formule, la date et le nombre d’activations correspondent à l’offre.
Contrôlez la présence des pages Profils, Stripe, PayPal, Transactions, Diagnostics et Aide.

La clé ne doit jamais être affichée dans une page publique ou une capture destinée au Web. Pour déplacer l’installation, désactivez l’ancien domaine avant d’activer le nouveau lorsque cela est possible.

Configurer Stripe

Ouvrez la page Stripe et renseignez séparément les identifiants de test et de production. Commencez dans l’environnement de test. Enregistrez l’URL de webhook indiquée par le plugin dans le tableau de bord Stripe et sélectionnez les événements requis par la version installée. La signature du webhook doit être conservée dans les réglages protégés.

La carte constitue le moyen principal. Apple Pay, Google Pay ou Link s’affichent uniquement si le compte, le domaine, le navigateur, l’appareil, la devise et le client sont éligibles. Leur absence ne signifie pas nécessairement que Stripe est en panne. En revanche, si aucune carte n’est disponible, contrôlez le profil et les identifiants.

Configurer PayPal

La page PayPal distingue Sandbox et Live. Utilisez une application PayPal Developer et des comptes Sandbox pour les tests. Un compte personnel réel n’est pas utilisé comme compte marchand de test. Le paiement par carte sans compte PayPal dépend des règles et de l’éligibilité décidées par PayPal.

Si votre catalogue doit proposer uniquement Stripe, laissez PayPal désactivé dans les profils publics. Conserver des identifiants PayPal dans les réglages globaux ne doit pas rendre PayPal visible lorsqu’il n’est pas sélectionné par le profil.

Créer un profil de paiement

Un profil décrit un parcours commercial précis. Donnez-lui un nom explicite tel que « ACHAT — Nom du produit ». Associez le formulaire Contact Form 7, choisissez la devise, le taux de TVA, le mode de résolution du montant et de la quantité, les fournisseurs autorisés et le comportement après confirmation.

Réglage	Valeur recommandée pour un produit public
Formulaire CF7	Formulaire « Commande — Nom du produit »
Montant	Dynamique pour plusieurs formules, fixe pour une offre unique
TVA	20 % pour les profils concernés
Quantité	Champ dynamique contrôlé ou quantité fixe de 1
Fournisseur	Stripe seul tant que PayPal n’est pas commercialement activé
Environnement	Hérité si le réglage global est maîtrisé, sinon explicite au profil
Licence	Activée pour un produit sous licence avec le bon code produit

Tester un seul profil sans basculer tous les produits

Créez un profil réservé au test ou dupliquez le profil du produit concerné. Définissez son environnement de test au niveau du profil lorsque la version le permet. Associez temporairement uniquement la fiche ou la page de recette à ce profil. Les autres produits restent reliés à leurs profils commerciaux en production.

Le mode « Hériter du réglage global » applique l’environnement global. Il ne permet pas d’isoler un produit si le réglage global est basculé. Pour un test ciblé, utilisez donc un environnement propre au profil, puis restaurez l’association commerciale après validation.

Préparer le formulaire Contact Form 7

Le formulaire doit contenir les données nécessaires à la commande : prénom, nom, e-mail, société, adresse, formule, quantité et acceptation des conditions. Ajoutez les classes ou noms attendus par le profil pour le montant, la quantité et la formule de licence. La balise ou le composant 3DIS PAYMENT doit être présent dans la dernière partie du formulaire.

L’adresse e-mail de l’acheteur doit provenir d’un champ valide. Dans les en-têtes CF7, utilisez la balise réellement présente dans le formulaire. Une balise comme [your-email] devient invalide si le formulaire utilise [billing_email]. L’expéditeur doit utiliser une adresse du domaine qui existe réellement ; l’adresse de l’acheteur peut être utilisée en Reply-To.

Montant fixe, montant dynamique et formule

Pour un prix fixe, le profil contient le montant autorisé. Pour plusieurs formules, le formulaire transmet un identifiant stable et le serveur associe cet identifiant au prix. Ne faites pas confiance à un champ HTML modifiable par le visiteur. Les règles de calcul doivent vérifier le produit, la formule et la quantité.

Le prix affiché sur la fiche est exprimé HT lorsque la grille commerciale le prévoit. Le formulaire présente le HT, la TVA et le TTC avant le paiement. Le montant final envoyé à Stripe ou PayPal doit correspondre exactement au TTC calculé selon la devise et les règles d’arrondi.

Transactions, retour et webhooks

La page de retour informe le client, mais elle ne suffit pas à confirmer durablement une commande. Le navigateur peut être fermé ou redirigé avant la fin. Le webhook envoyé par le prestataire permet au serveur de recevoir l’état de la transaction. Le journal doit relier le fournisseur, le profil, le montant, la devise et l’identifiant externe.

Un webhook peut être envoyé plusieurs fois. Le traitement doit être idempotent : la même confirmation ne crée pas plusieurs commandes ou licences. En cas de doute, recherchez l’identifiant de transaction et consultez son historique avant de relancer manuellement une opération.

Statuts et diagnostic

Symptôme	Cause probable	Contrôle
Aucun moyen de paiement disponible	Profil, clés ou environnement incomplet	Association produit, fournisseurs cochés, clés et mode test/live
Montant incorrect	Formule, quantité ou classe dynamique incohérente	Identifiants, règles serveur, HT, TVA et TTC
Paiement réussi sans licence	Émission désactivée ou mauvais code produit	Profil, endpoint, produit, plan et journal du webhook
E-mail non reçu	Adresse, SMTP ou délivrabilité	Journal SMTP, destinataire, SPF, DKIM, DMARC et indésirables
Double e-mail	Webhook rejoué sans idempotence	Identifiant externe et nombre de tentatives

Passage en production

Terminez un paiement accepté et un paiement refusé en test.
Vérifiez le montant, la quantité, le retour, le webhook et la transaction.
Contrôlez l’émission et le renvoi de licence si le produit en utilise une.
Renseignez les identifiants Live et le webhook de production.
Basculez uniquement le profil commercial concerné et vérifiez Stripe comme fournisseur actif.
Réalisez une transaction réelle de faible montant ou selon votre procédure interne.

Mises à jour et désinstallation

Avant une mise à jour, sauvegardez la base WordPress et les réglages. Consultez les notes de version, puis testez un profil de recette. La désactivation du plugin ne doit pas être utilisée comme moyen d’annuler une transaction déjà engagée. La version 1.0.1 conserve les données commerciales à la désinstallation ; exportez les informations nécessaires avant toute intervention sur la base.

FAQ

Pourquoi un profil de recette apparaît-il sur une fiche publique ?

La fiche a été associée au mauvais profil. Créez ou sélectionnez le profil `ACHAT` dédié, puis vérifiez le parcours public.

Comment afficher Stripe seul ?

Cochez Stripe dans le profil et désactivez PayPal. Vérifiez ensuite que le profil, et non un réglage hérité inattendu, pilote la page.

Comment renvoyer une licence ?

Depuis License Platform, utilisez le bouton de renvoi sur la licence existante. Cette action ne doit pas générer une nouvelle clé.

Comment vérifier que le paiement est définitif ?

Contrôlez le statut dans Transactions et la réception du webhook correspondant, pas seulement la page de retour.

Besoin d’un contrôle supplémentaire ?

Préparez l’identifiant du profil, la version du plugin, le statut et l’extrait de journal utile avant de contacter le support.

Contacter le support

Références officielles

Pour la configuration détaillée des fournisseurs et du formulaire, référez-vous également aux documentations officielles.

Stripe Payment Element — intégration et comportement du composant de paiement
PayPal Checkout — création et validation des paiements
Contact Form 7 — balises et traitement des formulaires

Architecture, intégration et maintenance — 3DIS PAYMENT

Référence : 1.0.1 · documentation vérifiée dans le code le 29 septembre 2026. Cette partie complète le guide d’utilisation. Les exemples doivent être adaptés puis testés sur un formulaire ou contenu de recette. Ils ne modifient pas automatiquement votre site.

Composants et responsabilités

Dans includes/, Profiles charge la configuration du profil ; Amount résout prix et quantité ; Core/Money représente les montants en unités monétaires mineures. Integrations/ContactForm7 enregistre la balise, valide le contexte et raccorde le cycle CF7. Rest/PaymentController crée les sessions et paiements ; Providers/Stripe et Providers/PayPal dialoguent avec le prestataire. Webhooks/WebhookController traite ses notifications. Transactions conserve les transactions, événements et transitions. License/LicenseIssuer relie une vente configurée au serveur de licences.

Le profil est un contenu WordPress 3dis_pay_profile dont les réglages sont dans _threedis_payment_profile. Les tables {prefix}3dis_payment_transactions et {prefix}3dis_payment_events conservent l’état commercial et les événements. Le préfixe dépend de l’installation : ne supposez pas qu’il vaut wp_.

Contrat du formulaire

La balise suivante rattache le composant au profil numérique 123, à remplacer par votre profil réel. Utilisez le générateur du profil pour une intégration existante.

[3dis_payment payment profile:123]

Vérifiez ensemble le formulaire associé au profil, le nom du composant, la classe du prix, celle de quantité et les classes de coordonnées. En mode dynamique, le champ doit être trouvé dans le formulaire CF7 attendu. Une valeur readonly ou une signature du montant ne prouve pas que le prix demandé correspond au catalogue : la règle métier serveur reste indispensable.

Filtres d’intégration des montants

threedis_payment_validate_dynamic_amount($money, $profile, $field, $source, $context) : cinq arguments ; retour attendu de type ThreeDIS\Payment\Core\Money. Un autre type provoque le refus. Pour un catalogue, résolvez le prix à partir du produit et de la formule enregistrés côté serveur.
threedis_payment_validate_dynamic_quantity($quantity, $profile, $field, $source, $context) : contrôle métier de quantité ; respectez les bornes et le type attendus par le résolveur.
threedis_payment_resolved_amount($money, $profile, $context) : point de transformation après résolution. Un callback doit préserver la devise, l’unité et la validité du montant.
threedis_payment_currencies($currencies) : registre des devises et unités mineures. Un ajout au registre ne rend pas automatiquement la devise disponible chez le prestataire.

En PHP, new Money(2900, 'EUR') représente 29,00 EUR. Ne convertissez pas des prix par des calculs flottants non contrôlés. Limitez chaque callback à son profil et placez-le dans une extension métier ou le mécanisme d’intégration du site, jamais dans les fichiers distribués. Shop fournit déjà un contrôle de prix pour ses propres produits : ne le remplacez pas par un callback qui accepte aveuglément le prix du navigateur.

Flux réseau et états

Les routes sous /wp-json/3dis-payment/v1 sont POST /sessions, POST /payments, POST /payments/{uuid} pour le statut et POST /payments/{uuid}/capture. Les notifications utilisent POST /webhooks/stripe et POST /webhooks/paypal. Leur accessibilité publique est nécessaire aux visiteurs et prestataires ; les callbacks appliquent leurs contrôles de session, contexte ou signature. Ne remplacez pas ces contrôles par un simple accès public sans jeton.

La machine d’états couvre notamment created, awaiting_customer, requires_action, processing, paid, failed, cancelled et expired. Les états de remboursement sont distincts. Leur présence n’indique pas qu’un remboursement a été demandé chez le prestataire. Une page de retour ou un courriel CF7 ne doit pas être traité comme preuve unique de paiement.

Le raccordement CF7 utilise notamment wpcf7_before_send_mail, wpcf7_mail_sent, wpcf7_mail_failed et wpcf7_spam. Lors d’une intégration PDF, stockage ou licence, vérifiez quel événement prouve réellement l’état attendu avant de produire un effet définitif.

Recette d’une intégration et recherche de panne

Sur un profil de test dédié, vérifiez formule, quantité, unité, devise, TVA et environnement. Ne basculez pas le compte global pour tester un seul produit.
Testez refus, annulation, authentification supplémentaire et succès avec les moyens de test du prestataire.
Rapprochez l’UUID local, l’identifiant prestataire, l’état et le webhook. Contrôlez une notification répétée : elle ne doit pas provoquer une seconde émission de licence.
Vérifiez séparément les courriels, la licence créée et le téléchargement. Le succès d’une étape ne valide pas les suivantes.

Si aucun moyen n’apparaît, contrôlez d’abord l’autorisation de PAYMENT, le profil, ses fournisseurs et l’environnement, puis les clés et erreurs réseau. Une licence commerciale du produit vendu et la licence autorisant PAYMENT sur la boutique remplissent deux fonctions différentes.

Sauvegarde, mise à jour et restauration

Sauvegardez base complète, profils, tables de transactions et configuration protégée ; conservez les secrets uniquement dans une sauvegarde chiffrée à accès restreint. Excluez du cache les réponses de session et de paiement. Après mise à jour, purgez les anciens scripts et rejouez la recette de test. Le contrôle de licence propre à Optimizer ne doit pas être supposé identique dans PAYMENT.

En cas de retour arrière, conservez les transactions arrivées depuis la sauvegarde : restaurer aveuglément une ancienne base peut perdre des paiements confirmés. Mettez le parcours concerné en maintenance, rapprochez les transactions du prestataire et restaurez une version compatible avec le schéma. Dans PAYMENT 1.0.1, le fichier uninstall.php conserve les données commerciales par défaut ; supprimer l’extension n’annule aucun paiement.

Pour le support, transmettez versions, profil, environnement, statut et identifiants non secrets. Masquez clés, jetons, données personnelles et coordonnées bancaires. Cette mise à jour documentaire n’exécute pas de paiement ni d’envoi de courriel.

Retrouver les autres documentations 3DIS · Assistance technique

Abonnements et paiements en plusieurs fois : version 1.1.0

Version 1.1.0 publiée le 1er octobre 2026 dans le serveur de distribution. Les limites de recette sont détaillées à la fin de ce chapitre ; la mise en service LIVE exige la configuration et la vérification du compte marchand. Le guide du paiement ponctuel ci-dessus reste distinct de ce nouveau parcours.

Scénarios couverts par l’intégration

Stripe : abonnement fixe, paiement fractionné avec ajustement du dernier versement, consommation seule ou abonnement plus consommation ; jusqu’à deux paiements initiaux séparés issus de sources serveur.
PayPal : abonnement fixe et paiement fractionné à versements égaux. Les consommations variables et les paiements initiaux séparés sont refusés dans cette intégration.
Fréquences proposées : mensuelle ou annuelle. Les montants de consommation sont fournis par le système du marchand ; PAYMENT ne calcule pas ses tarifs métier.

Une garantie encaissée constitue un paiement, pas un simple blocage temporaire de fonds. Le formulaire, le contrat commercial, les CGV et leur acceptation restent sous la responsabilité du marchand. PAYMENT conserve l’autorisation financière. Arrêter les prélèvements ne résilie pas le contrat commercial et ne rembourse pas les paiements déjà encaissés.

Configurer les prestataires une fois par environnement

Choisissez le bon compte marchand et le mode TEST/Sandbox. Enregistrez dans PAYMENT les identifiants de cette même application.
Stripe : créez une destination de webhook dans Workbench vers https://VOTRE-SITE/wp-json/3dis-payment/v1/webhooks/stripe. Le secret de signature de la destination est distinct de la clé secrète API et de la clé publiable. Enregistrez-le dans les réglages Stripe TEST du plugin.
PayPal Developer : ouvrez Apps & Credentials, choisissez Sandbox et l’application correspondante. Ajoutez le webhook https://VOTRE-SITE/wp-json/3dis-payment/v1/webhooks/paypal, puis copiez son Webhook ID dans les réglages PayPal Sandbox du plugin.
Activez les événements nécessaires au cycle de paiement : une sélection limitée aux événements « created » ne permet pas de suivre encaissements, échecs, remboursements et arrêts. Suivez la liste du guide livré avec la version installée.
Les clés, secrets et destinations LIVE sont distincts. La réussite d’un essai Sandbox ne configure pas le LIVE. Le webhook se configure par application et environnement, pas pour chaque client.

Références officielles : configuration des webhooks Stripe et configuration des webhooks PayPal.

Créer une souscription depuis un système générique

Créez et publiez un profil récurrent, puis utilisez l’administration « Créer une souscription » ou l’API marchande authentifiée POST /wp-json/3dis-payment/v1/billing/contracts. L’appel HTTPS exige un utilisateur autorisé par la permission manage_3dis_payment.

Le corps JSON fournit profile_id, customer_id, contract_id, provider (stripe ou paypal), environment (test ou live), start_at au format AAAA-MM-JJ HH:MM:SS et timezone, par exemple Europe/Paris. Les montants sont relus côté serveur dans le profil et les sources, puis figés avant acceptation. Le navigateur ne choisit pas librement le montant ni l’identité d’un autre client.

La réponse contient contract_uuid, checkout_token, expires_in (24 heures) et status. Le lien personnel pointe vers une page contenant


			Ouverture de votre échéancier de paiement…
			
			
				Remplacez la carte refusée pour régler le paiement en attente.
				
				 J’autorise l’utilisation de cette carte pour ce paiement et les prochaines échéances de l’autorisation de paiement enregistrée.
				
				
			
			
				 J’autorise les paiements initiaux et futurs selon les montants, les modalités et les échéances présentés dans ce récapitulatif.
				Cette autorisation concerne uniquement les paiements. Le contrat commercial et son acceptation sont gérés séparément par le marchand.

, avec #contract=UUID&access=JETON. Ce lien est confidentiel. Un nouvel accès généré pour le même dossier invalide le précédent sans créer un nouvel abonnement.

Raccorder un tableau SQL ou un endpoint de consommation

Sur le même WordPress, configurez une source SQL autorisée et la correspondance de ses colonnes. Le plugin lit les données serveur du tableau, pas son affichage HTML. Une source SQL peut être exposée par GET /wp-json/3dis-payment/v1/billing/sources/IDENTIFIANT/amount, avec authentification administrative ou clé Bearer propre à cette source. Cette route lit un montant ; elle ne prélève pas.

Pour une source distante, configurez une URL HTTPS fixe et un jeton Bearer. PAYMENT transmet customer_id, contract_id, period et currency. La réponse, après correspondance des noms de champs, doit contenir ces quatre valeurs identiques, une reference et amount_minor entier. Par exemple, 1750 représente 17,50 EUR. Si le format décimal est configuré, transmettez une chaîne exacte telle que « 17.50 ». Une réponse absente, ambiguë ou étrangère au dossier bloque le prélèvement ; elle n’est jamais remplacée par zéro.

Les noms métier des colonnes restent libres grâce aux correspondances. N’exposez ni requête SQL libre, ni clé marchande, ni secret de base de données au navigateur. Une modification de la configuration d’une source après souscription nécessite un contrôle administratif.

Associer Contact Form 7

Associez explicitement le profil récurrent au formulaire CF7.
Ajoutez une seule balise nommée [3dis_billing_reference paiement profile:mon-profil]. Ne la combinez pas avec la balise de paiement ponctuel.
Placez Ouverture de votre échéancier de paiement… Remplacez la carte refusée pour régler le paiement en attente. J’autorise l’utilisation de cette carte pour ce paiement et les prochaines échéances de l’autorisation de paiement enregistrée. J’autorise les paiements initiaux et futurs selon les montants, les modalités et les échéances présentés dans ce récapitulatif. Cette autorisation concerne uniquement les paiements. Le contrat commercial et son acceptation sont gérés séparément par le marchand. et le shortcode CF7 dans deux blocs séparés de la page. Ne les imbriquez pas dans un formulaire HTML.
Après confirmation des conditions financières requises, le formulaire reçoit une preuve valable dix minutes, liée au dossier, au profil et au formulaire. Une transmission réussie ne peut pas être rejouée.

Ce raccordement ne transforme pas automatiquement un formulaire public en contrat. Le serveur marchand doit établir une correspondance fiable entre son client et le dossier financier. Un échec explicite d’envoi peut permettre une reprise des mêmes données ; un résultat inconnu exige une vérification des journaux avant toute nouvelle tentative.

Échéances, notifications et reprise

Les échéanciers fixes natifs s’exécutent chez Stripe ou PayPal. Les consommations variables nécessitent une exécution WordPress par cron ou par le rattrapage limité lors d’une visite exécutant PHP. Une page entièrement servie depuis le cache ne déclenche pas ce traitement. Le plugin ne modifie pas la configuration cron de l’hébergement.

Une autorisation active ne prouve pas l’encaissement. L’historique est rapproché avec les données du prestataire après vérification des notifications. Dans l’administration, les paiements pilotés par le plugin et les opérations natives du prestataire figurent dans deux tableaux distincts. Une catégorie vide ne signifie pas qu’aucun paiement n’existe.

Le calendrier effectif PayPal est celui du prestataire : le récapitulatif distingue le début demandé des dates effectivement appliquées. Ouvrez le lien personnel WordPress dans le même navigateur et le même onglet que l’approbation ; déplacer seulement l’URL PayPal ne transfère pas l’accès conservé en session. En cas de perte de session, reprenez le lien personnel valide ou régénérez-le depuis la fiche du dossier.

Validation obtenue et limites restantes

Les essais Sandbox ont confirmé l’approbation, le retour WordPress, le premier encaissement, les notifications, l’arrêt, le remboursement et le rejeu sans doublon. Les 29 scripts PHP de recette passent. La version dev.10 corrige le rapprochement des premières notifications arrivant après suspension, annulation ou expiration distante.

La deuxième mensualité PayPal et la fin naturelle du plan restent à observer à distance. Un nouvel échéancier Sandbox a été conservé actif à cet effet. Les simulations de ces transitions ne sont pas présentées comme des prélèvements réellement exécutés. Un ancien dossier Sandbox présente encore une boucle de connexion inexpliquée. La réception de courriels réels et les encaissements LIVE ne sont pas validés par ces essais.

Toutes les documentations 3DIS · Contacter le support

Version 1.1.1 — intégration des conditions de Shop 0.3.6

Depuis le 2 octobre 2026, PAYMENT transporte la référence des conditions acceptées dans son devis signé et fournit le contrôle serveur préalable à la création du paiement. Shop gère les pages CGV/CGU sélectionnées dans chaque produit, l’affichage, les archives et leur export. Mettez PAYMENT à jour avant Shop.

Cette intégration concerne les achats Shop utilisant un profil dynamique et un formulaire CF7 correctement associés. La preuve est liée au produit, à l’offre, au formulaire et à la session. Une nouvelle transaction exige une acceptation valide des documents courants ; une modification de la page source impose une nouvelle acceptation. Les réglages Stripe/PayPal et les autorisations propres aux abonnements restent distincts.

Shop peut ajouter les textes aux courriels CF7 de confirmation. Configurez E-mail (2) et son destinataire, puis vérifiez la réception ; le module n’active pas cet e-mail automatiquement. Une archive d’acceptation ne constitue pas une preuve d’encaissement.

Consultez le guide détaillé des pages CGV/CGU, de l’archivage et des téléchargements d’essai. Les tests de cette intégration ont utilisé un produit fictif sans paiement réel ni envoi de courriel.

PAYMENT 1.1.2 — Fiabilisation des mises à jour sous licence

Publication du 2 octobre 2026. La recherche conserve une cadence de douze heures. WordPress affiche la version disponible ; seul l’administrateur décide de cliquer sur « Mettre à jour ». Aucun réglage de mise à jour automatique n’est activé par cette correction.

La recherche vérifie les métadonnées signées et les conserve 24 heures, sans y stocker le jeton de téléchargement. Un jeton neuf est demandé au moment du téléchargement. La licence, la version, la signature, la destination, l’expiration, la taille et l’empreinte SHA-256 sont vérifiées ; un refus ou un fichier altéré empêche l’installation.

Le bouton de vérification de licence relance aussi la recherche, avec une limite d’une fois par minute et un verrou contre les appels concurrents. Une visite de l’administration peut effectuer le contrôle arrivé à échéance même lorsque WP-Cron est désactivé. Cela ne modifie pas la configuration cron de l’hébergement. Les anciens liens signés conservés dans une annonce WordPress ne sont plus réutilisés.

Les licences, données et réglages existants sont conservés. Shop et PAYMENT embarquent désormais chacun leur copie isolée du SDK pour éviter une dépendance à l’ordre de chargement. Multistep 0.4.10 possédait déjà ce mécanisme ; les versions associées sont Shop 0.3.8, PAYMENT 1.1.2, Multifiles 1.2.1 et CFDB Optimizer 1.1.2.

Sur 3dis-development.com, les quatre candidats ont conservé leur licence valide ; les quatre téléchargements officiels ont été vérifiés, puis les quatre mises à jour manuelles natives vers les versions stables ont réussi. Les tests locaux couvrent aussi le refus des liens expirés, des fichiers corrompus et des autorisations refusées. Ces contrôles concernent le mécanisme de mise à jour, pas une nouvelle recette de tous les paiements ou formulaires.

Si le site héberge lui-même son serveur de licences, la maintenance pendant une mise à jour AJAX peut interrompre la demande de jeton. Le parcours WordPress dans une page complète a été validé sur cette configuration. Ne pas contourner un refus en exposant publiquement le ZIP ; utiliser le paquet officiel autorisé et le téléversement administrateur si nécessaire. Sauvegarder le site avant toute mise à jour.