Aller au contenu

Dernière stable : Paiement 2.0.1. Cette page conserve les preuves historiques 2.0.0.

Paiement 2.0.0 — publication vérifiée

Publié le 5 novembre 2026 depuis le poste, avec token local, sans CI. Application Boot 4.1.2 / Java 21 ; dépendances DYNORS stables. Cette release applicative ne modifie aucun BOM et n’est pas un package Maven à ajouter aux consommateurs.

Image : registry.gitlab.com/dynors/dynors-paiement/paiement-backend:2.0.0.

Référence immuable :

registry.gitlab.com/dynors/dynors-paiement/paiement-backend@sha256:beafb81fe5fb356505f8f2463681ec4c16ccc6d98e7c3d3bb972dea572411e41

Source qualifiée : 63942b51ec42573ebeeb62619d205edb1be75342. JAR SHA-256 : a383a2f3e626472b8ab148db5ac22cb906ecb69ec1415117c8c6dd314879d613.

Deux architectures : ARM64 native et AMD64 sous émulation pour la qualification locale. UID 10001, démarrage sur PostgreSQL 17.11 privé, readiness atteinte, health 200 et refus admin/bearer invalide/métriques anonymes par 401. Les manifests, configurations et attestations ont été contrôlés dans le registre ; les JAR extraits des images récupérées ont la même empreinte que le JAR qualifié. publication.json constitue le reçu. Aucun tag latest déplacé, aucun déploiement.

Les 175 tests ont été rejoués avec le numéro stable. Le JAR stable et le dernier candidat ne diffèrent que par le manifeste et les informations de build ; classes et ressources applicatives sont identiques. Les campagnes PostgreSQL (43), broker réel (4), mapping Web-errors (20 + 20) et SIRRAT (24) restent applicables dans leurs périmètres documentés. Les deux images exactes ont en outre passé leur propre démarrage PostgreSQL. Les résultats ne constituent pas une recette PSP ou un benchmark AMD64 natif.

Corrections et migration

  • Les 18 erreurs métier possèdent des codes PAI explicites et conservent leurs statuts. Les clients comparant les anciens codes avec soulignés doivent migrer.
  • SENT exige une confirmation corrélée ; refus des leases expirées/owners incompatibles et des ACK tardifs. Aucun acquittement broker interprété comme un traitement métier ou un versement bancaire.
  • Sécurité active en dev, administration/Prometheus habilités, JWT invalide normalisé, secrets locaux durcis et suppression du Vault factice.
  • Catalogue tenant canonique DB 2.2.0 sans seeds automatiques ; refus atomique de l'ancien catalogue incompatible. Migration DATA/Ops séparée pour une installation existante.
  • Webhooks 2 : contrat request_id et header canonique X-Dynors-Signature ; qualifier les récepteurs. Boot 4 et dépendances publiques corrigées ; scan OSV du graphe publié sans avis retourné sur 185 coordonnées publiques à l'instant de contrôle.
  • Template Forge Paiement 2 et constantes SIRRAT délai/lease qualifiés localement, sans réassignation de recette ni activation. Le template n'embarque ni offres ni comptes marchands par client.

Gates avant activation

La release est disponible, sans readiness financière générale. Provider réel de credentials/Vault/ESO, Auth/PDP et parcours SLY vérifié, TLS et ACL partagés, contrats PSP et recette marchande restent à qualifier. Refund/payout non activés. Aucun paiement réel exécuté. Le profil Core JPA universel ne fait partie d'aucune garantie.

Le guide de migration détaille les responsabilités, les tests et le bootstrap Spring Data DEFERRED requis par cette composition. Les applications consommatrices adoptent le nouveau contrat volontairement ; aucune montée automatique.

Paramètres Forge/SIRRAT

Le template dynors-paiement-psp:2.0.0 porte uniquement la configuration technique. Les constantes PAIEMENT_OUTBOX_CONFIRMATION_TIMEOUT_MS=5000 et PAIEMENT_OUTBOX_LEASE_SECONDS=120 sont surchargeables par cercle ; leurs expressions alimentent les variables runtime réellement lues par Paiement. Le banc utilise une surcharge à 8000 ms, résolue/rendue par les vrais services SIRRAT avec repositories simulés, puis consommée par le composant Paiement. Aucun provisionnement de cercle réel n'est revendiqué.

Les secrets restent des références protégées Ops ; comptes marchands, prix et offres restent dans leurs domaines. SLY conserve ses paramètres canoniques dérivés. Tous les traitements financiers/bus demeurent désactivés par défaut. Le template n'est pas une nouvelle release du serveur SIRRAT, et aucune recette n'est réassignée.

Runbook SIRRAT · Release GitLab Paiement.

Statut de la documentation

Sources MkDocs et build statique actualisés. Le déploiement GitLab Pages dépend du job Pages et n'est pas déclenché par cette publication locale sans CI. Ne pas assimiler mise à jour du dépôt et mise à jour déjà visible sur docs.dynors.com.

Erratum du contrat de confirmation

Le guide du tag v2.0.0 indique à tort paiement.intent.completed.v1. Le runtime émet paiement.payment.completed, schemaVersion 1. Aucun renommage générique ni alias ; la route est provisionnée par consommateur, sans ingress ELISA automatique. Voir le contrat corrigé, exemple de payload et réserves. 50 tests locaux ciblés passent ; aucune image n’est republiée.