3DIS PAYMENT — exploitation des abonnements, recette 1.1.0-dev.6

STATUT
Version de recette, pas une déclaration de validation commerciale complète.
Les tests locaux utilisent des prestataires simulés. Les preuves Stripe TEST
et PayPal Sandbox sont distinguées dans les rapports de recette du projet.

ENVIRONNEMENTS
Un contrat conserve test ou live dans son instantané serveur. Le choix global
du prestataire ne transforme jamais un contrat existant. TEST reste le choix
par défaut dans Créer une souscription. LIVE exige une confirmation lors de
la création dans l'administration, l'activation dans Réglages des abonnements,
un prestataire activé, ses identifiants LIVE et son secret/identifiant webhook.
La licence reste vérifiée avant les opérations d'encaissement.
La présence des champs ne prouve pas la validité des identifiants : vérifier
la livraison signée des événements du bon compte et du bon environnement.
Les webhooks continuent à rapprocher les opérations lorsque les nouveaux
prélèvements sont désactivés. Résiliation et remboursement restent accessibles
aux comptes disposant des droits correspondants et exigent une confirmation.
Désactiver le réglage LIVE ne résilie PAS les échéanciers natifs prestataires.

ÉCHÉANCES ET ABSENCE DE CRON
Stripe et PayPal exécutent leurs échéanciers fixes sur leurs serveurs.
WordPress prépare les échéances Stripe avec consommation fournie par une source.
WP-Cron déclenche un lot limité. Une visite exécutant WordPress peut aussi
traiter au maximum un contrat, au plus une fois toutes les cinq minutes,
avec verrou atomique. Aucun endpoint public de prélèvement n'est ajouté.
Les requêtes REST, AJAX, CLI et cron sont exclues de ce rattrapage par visite.
Sans visite ni cron, aucun rattrapage WordPress ne s'exécute. Une page servie
intégralement depuis un cache/CDN ne déclenche pas PHP. Le plugin ne modifie
pas DISABLE_WP_CRON. Sur un hébergement sans fastcgi_finish_request, le travail
de fin de requête peut prolonger sa durée. Un cron hébergeur reste préférable
pour une cadence régulière et un volume important, sans être imposé.
Une erreur de source conserve l'échéance : aucun montant zéro de remplacement.
Une réponse de paiement incertaine ne provoque jamais un nouveau débit aveugle.

RÉGULARISATION
L'administrateur peut régénérer un lien client valable 24 heures depuis le
contrat. Le nouveau lien invalide l'ancien. Il est personnel, limité au contrat
et doit être transmis uniquement au client concerné. Le jeton n'est stocké
que sous forme de condensat. La page doit contenir [3dis_billing_checkout].
Une page privée exige en plus les droits WordPress nécessaires.
Pour une échéance variable, la régularisation reprend le PaymentIntent existant.
La carte de remplacement est vérifiée avant d'être utilisée pour les suivantes.
Pour un échéancier fixe Stripe, le bouton propose les factures ouvertes du
contrat sur le site sécurisé de Stripe. Client, abonnement, environnement,
devise et domaines des liens sont vérifiés. Aucune facture n'est créée.
La liste est limitée à 100 factures ; une indication signale les suivantes.
La confirmation bancaire ne remplace pas le rapprochement auprès de Stripe.
PayPal utilise ses propres tentatives et outils de gestion d'abonnement ;
ce bouton de régularisation Stripe ne s'applique pas aux contrats PayPal.

ALERTES
La synthèse vers l'adresse d'administration est facultative et désactivée
par défaut. Une visite ou un lot cron peut l'envoyer au plus une fois par heure
s'il existe des anomalies. Elle contient jusqu'à 50 références de contrats,
leur environnement et leur état, sans coordonnées bancaires ni jeton client.
Une erreur du transport mail ne modifie aucun paiement. La synthèse suivante
peut être tentée après une heure. wp_mail ne garantit pas la réception :
configurer et vérifier la messagerie de l'hébergement. Aucun courriel client
automatique ni campagne de relance n'est implémenté dans cette recette.

LIMITES À NE PAS CONFONDRE AVEC UNE RECETTE VALIDÉE
Le parcours autonome/API marchand de souscription est distinct du paiement
ponctuel CF7. Le tag ponctuel ne doit pas être présenté comme une souscription
récurrente complète ; les endpoints ponctuels refusent les profils récurrents.
PayPal : abonnements fixes et fractionnement ; consommations variables et
paiements initiaux séparés sont refusés dans cette intégration.
Les mensualités futures PayPal et la fin automatique de son fractionnement
n'ont pas été vérifiées de bout en bout dans la recette actuelle.
La préparation LIVE du code ne constitue pas un essai d'encaissement réel.

RÉFÉRENCES PRESTATAIRES
https://docs.stripe.com/api/invoices/object
https://developer.paypal.com/subscriptions/payment-failure-retry/
