Correction d'erreurs critiques lors du paiement et des webhooks sur Magento 2 après la mise à niveau - Stripe/PayPal - Redis/Varnish

Après la mise à jour de Magento 2.4.6-p3 (PHP 8.2), la production de la boutique en ligne (B2C, ~15 000 SKU, 800-1200 commandes/jour) a connu des échecs dans la passation des commandes et une désynchronisation des paiements. Certains clients reçoivent une erreur lors de l'étape de paiement, ou la commande est créée sans transaction, et parfois elle est dupliquée. Les journaux contiennent un mélange de 500/502, de délais d'attente, de messages de blocage MySQL et d'exceptions dans le module d'intégration ERP personnalisé. J'ai également remarqué que les webhooks Stripe ne parviennent parfois pas à confirmer et que l'IPN PayPal apparaît deux fois. Il est nécessaire de localiser les causes profondes et de corriger les erreurs afin que le paiement s'exécute de manière stable sous charge.

Environnement technique : Magento Open Source 2.4.6-p3, Nginx, PHP-FPM 8.2, MySQL 8.0, Redis (sessions+cache), Varnish, Elasticsearch/OpenSearch, RabbitMQ. Déployez via GitLab CI, il y a un staging, un accès via SSH. Il existe des APM (New Relic) et des journaux centralisés (ELK). Il existe plusieurs modules personnalisés : intégration avec ERP (REST), logique de promotion, personnalisation de la caisse. Paiements : Stripe (PaymentIntents + webhooks) et PayPal.

Résultat attendu : causes corrigées des erreurs de paiement, traitement correct des webhooks/notifications, pas de duplication des commandes/transactions, fonctionnement stable sous charge. Un ensemble de modifications de code et de configuration est requis, ainsi qu'un bref rapport technique sur ce qui a été cassé et comment il a été testé.

Restrictions : l'arrêt de la production est interdit, seule une courte fenêtre de sortie de 10 à 15 minutes est autorisée. Les modifications doivent être compatibles avec les modules personnalisés actuels. Vous ne pouvez pas désactiver Varnish/Redis en production, vous pouvez effectuer des réglages de points. Les données client ne peuvent pas être téléchargées en dehors du serveur.

Étapes de travail :
1) Diagnostics : analyse des logs (Magento/system/exception, Nginx, PHP-FPM), traces New Relic, cron/file d'attente associée, lecture sur staging avec profileur activé, recherche de conditions de concurrence dans l'ordre de mise en place, contrôle d'idempotence pour Stripe/PayPal.
2) Correctifs : modifications dans le module de paiement/ERP personnalisé (transaction, nouvelle tentative, blocage/clés uniques), correction du traitement des webhooks (signature, répétitions, ordre des événements, clé d'idempotence), élimination des causes de blocage (index/ordre des enregistrements), paramètres de délais d'attente/fastcgi, optimisation de SQL/consommateur lent spécifique.
3) Validation : tests de charge sur staging (k6/JMeter) pour les scénarios de paiement 3DS/non-3DS, simulation de webhooks répétés, vérification de non-duplication, régression des codes promo/livraison/taxes.
4) Version : préparation MR, instructions de déploiement, plan de restauration, prise en charge de la version et surveillance des métriques 24 heures sur 24.

Critères d'acceptation (mesurés) :
- Sur une mise en scène avec 50 utilisateurs virtuels, le paiement a un taux de réussite d'au moins 99% lors d'un test de 30 minutes sans 500/502 à l'étape de paiement.
- En production dans les 24 heures suivant la sortie : la part des erreurs de commande <0,2 % (selon New Relic), il n'y a pas de commandes en double avec le même payment_intent_id/PayPal txn_id.
- Les webhooks Stripe sont traités avec une confirmation 2xx 99,9 % du temps, les événements répétés ne créent pas de nouvelles factures/expéditions.
- Le référentiel contient un MR avec une description des modifications et un court rapport (1 à 2 pages) avec les causes profondes et des liens vers les journaux/métriques.

Je fournirai l'accès et le matériel : SSH à la préparation/prod, accès à GitLab, New Relic, exemples d'identifiants de commande/paiement problématiques, fenêtres horaires d'incident.