3DIS PAYMENT — Configuration PayPal et état de validation
Mis à jour le 1er octobre 2026. Branche de développement 1.1.0.

1. Ce qui se configure une fois
La connexion et le webhook se configurent pour chaque application PayPal et
chaque environnement. Ils ne se recréent pas pour chaque client ni chaque
souscription. Sandbox et LIVE ont des identifiants distincts. Un webhook
Sandbox ne valide pas les notifications LIVE.

2. Configuration Sandbox
- Ouvrir PayPal Developer avec le compte marchand concerné.
- Dans Apps & Credentials, sélectionner Sandbox puis l'application dont
  le Client ID correspond à celui enregistré dans 3DIS PAYMENT → PayPal.
- Vérifier que la fonctionnalité Subscriptions est disponible dans l'application.
- Dans Sandbox Webhooks, ajouter l'URL HTTPS de SON site :
  https://VOTRE-DOMAINE/wp-json/3dis-payment/v1/webhooks/paypal
  Utiliser l'URL fournie par le plugin pour les installations en sous-répertoire.
- Sélectionner les événements nécessaires puis enregistrer.
- Copier l'identifiant de ce webhook dans 3DIS PAYMENT → PayPal →
  PayPal SANDBOX → Webhook ID ; enregistrer les modifications.
- Les champs Client ID et Client Secret doivent appartenir à cette même
  application Sandbox. Ne jamais placer un secret dans le contenu d'une page,
  une capture partagée, un journal ou une URL.
- Utiliser un profil explicitement TEST et un acheteur Sandbox distinct du
  compte marchand. Ne pas modifier le profil LIVE des clients pour la recette.

3. Événements configurés sur le site de recette
Abonnements : activation, annulation, création, expiration, échec de paiement,
réactivation, suspension, mise à jour (huit cases de l'interface PayPal).
Commandes : CHECKOUT.ORDER.APPROVED.
Captures : PAYMENT.CAPTURE.COMPLETED, DENIED, PENDING, REFUNDED, REVERSED.
Ventes : PAYMENT.SALE.COMPLETED, DENIED, PENDING, REFUNDED, REVERSED.
Les suffixes indiqués partagent le préfixe PAYMENT.CAPTURE. ou PAYMENT.SALE.
Total enregistré : 19 événements. Cette liste de souscriptions ne constitue
pas une preuve que chaque scénario a été implémenté et testé dans le plugin.

4. Signification des confirmations
Le retour du navigateur du client ne constitue pas une preuve de paiement.
Un abonnement ACTIVE n'est pas une preuve qu'une échéance est encaissée.
Le plugin doit vérifier la signature via PayPal, l'environnement, l'identité
de l'abonnement et son rattachement au contrat, puis rapprocher les opérations.
Un événement rejoué ne doit pas créer un second encaissement.
La désactivation de nouveaux achats ne doit pas empêcher la vérification des
notifications relatives à des paiements déjà engagés. Le correctif local
autorise uniquement la requête de vérification de signature dans ce cas ;
il ne réactive ni la création ni la capture de commandes.

5. Contrôles avant de déclarer la recette réussie
- Souscription réelle Sandbox approuvée par un acheteur Sandbox.
- Notification effectivement livrée à l'URL et acceptée après vérification.
- Première échéance et renouvellement rapprochés avec montant/devise exacts.
- Rejeu sans doublon, annulation, échec et remboursement vérifiés.
- Historique WordPress cohérent avec celui de PayPal.
Un HTTP 200 isolé ou le simulateur de webhook ne prouve pas l'ensemble du parcours.

6. État historique constaté le 30 septembre 2026
Application Sandbox existante sélectionnée, Client ID correspondant à WordPress.
Subscriptions disponible. Webhook créé et identifiant sauvegardé dans WordPress.
PayPal reste désactivé pour les achats ordinaires ; mode global LIVE inchangé.
La version de recette installée est 1.1.0-dev.4. Elle vérifie les signatures
même si les nouveaux achats ordinaires sont désactivés, normalise les ventes v1
et rapproche les abonnements et ventes après lecture de leur état chez PayPal.
L'association vérifie l'environnement, le contrat, le plan et l'abonnement
enregistrés. Un abonnement actif ne crée aucune ligne de paiement artificielle.
Les remboursements sont indiqués dans l'historique ; le montant réglé demeure
le montant brut avant remboursement. Le montant net remboursé n'est pas détaillé.
11 contrôles locaux simulés passent (signature invalide refusée, secret absent
refusé, capture toujours bloquée, montants v1/v2, absence de redirection réseau).
Les 16 scripts locaux passent, dont le rapprochement PayPal avec transport
simulé et registre SQLite : doublons, remboursement, lecture périmée,
contrat étranger, devise incorrecte et résiliation. Cela ne remplace pas PayPal.
Une souscription réelle Sandbox de 1 EUR/mois a été approuvée par l'acheteur
fictif. L'encaissement de 1 EUR est remonté automatiquement dans WordPress par
webhook. La résiliation depuis WordPress a ensuite été confirmée.
Le rejeu explicite de la notification de vente a été livré en HTTP 200, sans
doublon dans WordPress. Le remboursement intégral depuis le marchand Sandbox
est confirmé chez PayPal et dans l'historique WordPress. La notification dédiée
au remboursement est également confirmée SUCCESS, HTTP 200, DELIVERED.
Le renouvellement calendaire mensuel et les autres variantes ne sont pas prouvés
par ce seul scénario. La recette complète des abonnements n'est PAS encore validée.
Le Webhook ID LIVE n'est pas configuré sur le site observé.
Ne pas annoncer la disponibilité commerciale de ces nouveaux parcours à ce stade.

7. Complément de recette du 1er octobre 2026
Avec la version dev.8, deux nouveaux dossiers Sandbox ont été approuvés :
abonnement mensuel fixe et plan fini de deux versements. Dans les deux cas,
le retour sur WordPress a enregistré l'autorisation. Les premières ventes de
1 EUR sont rapprochées dans WordPress, et les prochains prélèvements ont été
arrêtés depuis WordPress. Les événements de création, activation, vente et
annulation apparaissent SUCCESS dans PayPal Developer.
Cela ne constitue pas un test de deuxième échéance distante ni d'expiration
naturelle du plan fini. Les transitions de renouvellement, suspension/reprise
et expiration sont couvertes par tests locaux avec transport simulé.

Un ancien dossier resté APPROVAL_PENDING retourne à la connexion PayPal,
y compris avec un nouvel acheteur. Les deux nouveaux dossiers fonctionnent.
La cause exacte de cet ancien blocage n'est pas établie : ne pas présenter
la création d'un nouveau dossier comme une correction du moteur PayPal.
Avant toute nouvelle tentative, vérifier l'état distant, les ventes et les
notifications pour éviter de créer deux souscriptions actives.

Notifications tardives : à partir de dev.10, une première notification reçue
après suspension, annulation ou expiration distante rapproche aussi les ventes
vérifiées et l'état du dossier. Une fermeture du navigateur avant le retour
ne doit pas faire perdre un encaissement. Une activation exige toujours une
autorisation distante confirmée ; les événements ne créent aucun nouveau débit.
Ce scénario a été reproduit par un test local échouant avant correction,
puis passant après correction. Il ne constitue pas une expiration Sandbox réelle.

8. Calendrier et diagnostic du retour
Le récapitulatif dev.9 affiche pour PayPal la date de début demandée, les
montants, le nombre de versements et leur fréquence. Il ne présente plus
des dates calculées dans le fuseau WordPress comme des dates confirmées par
PayPal. Si le début demandé est passé (ou à moins de 60 secondes lors de
la création distante), le plugin demande un démarrage immédiat à PayPal.
Le calendrier effectif est celui de PayPal. Consulter l'abonnement distant.

Le lien personnel WordPress doit être ouvert dans le navigateur utilisé pour
l'approbation. Son jeton est conservé en sessionStorage pour ce navigateur et
cet onglet ; il n'est pas ajouté à l'URL de retour PayPal. Transférer seulement
l'URL PayPal vers un autre navigateur ne transfère pas cet accès WordPress.
En cas de session perdue, rouvrir le lien personnel d'origine encore valide,
ou en générer un nouveau dans la fiche du dossier. Un nouveau lien invalide
l'ancien lien personnel ; il ne crée pas un nouvel abonnement PayPal.
Le retour ne doit jamais être considéré comme une preuve d'encaissement.

Si le navigateur reste sur paypal.com ou sandbox.paypal.com, noter l'ID
d'abonnement et vérifier son état et ses événements avant d'attribuer le
problème au retour WordPress. Si WordPress est atteint, vérifier la présence
du dossier, l'accès de session et les notifications signées correspondantes.
Ne jamais publier les mots de passe, secrets, liens personnels ou jetons.

Références officielles pour la configuration et la maintenance :
https://developer.paypal.com/api/rest/webhooks/rest/
https://developer.paypal.com/api/rest/webhooks/events-dashboard/
https://developer.paypal.com/subscriptions/webhooks
