English version below

Post Mortem

Référence incident

TSR-1392

Service concerné

Oney.

Impact client

Les paiements Oney étaient bloqués à un statut inconnu.

Synthèse de l’incident

• 26 février : migration d’application chez un prestataire externe. Début de l’incident.
• 26 février 16h10 : création d’un ticket auprès de nos équipes techniques.
• 27 février : 14h18 : remontée de nouveaux cas marchands.
• 27 février 14h26 : escalade de la demande.
• 27 février 14h30 : début des analyses techniques et compréhension de l’incident.
• 27 février 17h18 : identification de d’un nouveau statut de paiement. 
• 28 février 11h11 : ticket ouvert chez le support du prestataire externe et poursuite des analyses internes.
• 3 mars & 4 mars : plusieurs relances et échanges avec le support du prestataire externe pour identifier l’origine de l’envoi de ce nouveau statut. 
• 4 mars 18h01 : reversement des nouvelles transactions. Fin de l’incident.
• 5 mars 9h28 : décision d’annuler les transactions avec le prestataire sur la période d’incident concernée.
• 5–14 mars : plusieurs relances et échanges avec le prestataire externe pour annuler l’ensemble des transactions.
• 14 mars 17h44 : confirmation par le prestataire externe de l’annulation des transactions.

Contexte

N/A 

Root cause

Une migration d’application avec un nouveau parcours a été effectuée par notre prestataire externe. C’est l’application avec ce nouveau parcours qui a envoyé un statut qui n’était pas reconnu par nos services.

Actions à entreprendre par Payplug

Symptômes	Actions
Non communication de la migration par le prestataire externe.	Communication par le partenaire des migrations et des dates impliquées en amont.
Non détection de l’incident de la part du prestataire externe.	Vérification le jour du déploiement du bon fonctionnement du service.

‌

==============ENGLISH VERSION==============

Post Mortem

Incident reference

TSR-1392

Payment services affected by the incident

Oney.

Client impact

Oney payments were blocked at an unknown status.

Incident Overview

• February 26: application migration with an external service provider. Incident begins.
• February 26 - 4:10 PM: ticket created with our technical teams.
• February 27 - 2:18 PM: new merchant cases reported.
• February 27 - 2:26 PM: request escalated.
• February 27 - 2:30 PM: technical analysis and understanding of the incident begins.
• February 27 - 5:18 PM: identification of a new payment status.
• February 28 - 11:11 AM: ticket opened with the support of the external service provider and continuation of internal analysis.
• March 3 & 4: multiple follow-ups and exchanges with the external provider’s support to identify the origin of the new status transmission.
• March 4 - 6:01 PM: reversal of new transactions. Incident ends.
• March 5 - 9:28 AM: decision to cancel transactions with the provider for the affected incident period.
• March 5–14: multiple follow-ups and exchanges with the external provider to cancel the transactions.
• March 14 - 5:44 PM: confirmation from the external provider of the cancellation of the transactions.

Context

N/A

Root cause

An application migration with a new workflow was carried out by our external service provider. It is the application with this new workflow that sent a status that was not recognized by our services.

Actions to be taken by Payplug

Symptoms	Actions
Lack of communication regarding the migration by the external service provider.	Communication by the partner regarding the migrations and the involved dates in advance.
Failure to detect the incident by the external service provider.	Verification of the proper functioning of the service on the deployment day.