Description détaillée

Résumé : Des requêtes POST /operations/{id}/confirm retournent des 400 car le champ apduClientAnswers est null. Ces erreurs représentent ~5% des incidents SECIEL et apparaissent souvent en série (retries répétés pour la même operationId). Dans au moins un cas le premier confirm est en 200 avec apduClientAnswers rempli, puis une succession d'appels confirm suivants arrivent avec apduClientAnswers null et retournent 400. Les corrélations ID et cardAccountId ont été fournies. Plusieurs intervenants sont engagés (Apple/Thales via ticket CHIRP, Support Wizway, Dejamobile, équipes d'exploitation, et demande d’investigation adressée à l’équipe mobile PRIM AMOA Mobile) ; pas de cause racine confirmée à ce stade.

Statut : En cours d'investigation (multi‑équipes), sans résolution.

Actions restantes :
• Investiguer le comportement du SDK / de l’application mobile (pourquoi il enchaîne plusieurs confirm et envoie apduClientAnswers null) — PRIM AMOA Mobile
• Fournir les SEIDs ou tout autre identifiant supplémentaire permettant le traçage côté Apple/Thales (si disponibles) — dl-fr-nsbf-exploitation
• Poursuivre l’analyse côté Apple/Thales via le ticket CHIRP (réf. https://chirp.apple.com/problem/162848730) et tenter de corréler avec les correlation IDs transmis — Apple / Thales (contacts : Marco DAHLQUIST / Eddy Mimouni)
• Confirmer si marketPay génère des retries ou perd/ ne propage pas operationId (et fournir preuve/logs) — Support Wizway / équipe marketPay
• Préciser le rôle exact du proxy/pass‑through et coordonner l’analyse avec l’intégrateur du SDK (qui a relayé que plusieurs requêtes "ont bien été transmises") — Dejamobile Support
• Communiquer les résultats intermédiaires et décisions (qui déclenche les retries) pour clore la responsabilité et planifier la remédiation — Arnaud LECREUX / PRIM AMOA Mobile (suivi demandé)