La primera hora de un incidente de pagos y el traspaso de turno

Ante una caída de pagos, el momento más peligroso a veces llega después de la recuperación. La persona de guardia vio un pago exitoso, el equipo respiró aliviado y la lista de resultados desconocidos se perdió entre los mensajes. Al final, la disponibilidad técnica volvió antes que el control sobre el dinero. El plan de la primera hora debe mantener ambas líneas de trabajo hasta un traspaso claro a sus responsables.

Primeros 10 minutos: asigne la coordinación y defina el alcance

Declare el incidente según los criterios internos, cree un único canal de coordinación y designe a quien lo dirige. Defina por separado quién se ocupa de la recuperación técnica, de la conciliación financiera y de los mensajes a los usuarios. En un equipo pequeño una persona puede asumir varios roles, pero las responsabilidades deben estar nombradas. El enfoque de Google SRE separa la coordinación, las acciones técnicas y la comunicación; es un buen punto de apoyo cuando varios especialistas empiezan a actuar al mismo tiempo.

Registre la hora del primer síntoma confirmado y los métodos, cuentas, monedas y etapas del pago afectados. Revise los cambios recientes, los errores propios y la información disponible del proveedor. No declare caída toda la plataforma si solo está probado el problema de una ruta. Tampoco reduzca el alcance solo porque una solicitud de control conveniente funcionó.

Prepare de inmediato el primer mensaje sobre el impacto confirmado y la hora de la próxima actualización. No lo posponga hasta aclarar por completo la causa. Defina de antemano el flujo de aprobación de los mensajes a clientes, para que un especialista técnico no termine decidiendo por accidente sobre promesas públicas.

De 10 a 20 minutos: detenga el aumento del daño

Separe las solicitudes nuevas de las operaciones enviadas cuyo resultado se desconoce. Si es necesario, limite el flujo afectado según el plan acordado de antemano. No lance cobros, reembolsos ni pagos repetidos de forma masiva. Cada acción financiera debe basarse en un estado establecido y en las facultades correspondientes. Use la ruta de respaldo solo para las operaciones adecuadas y solo si ya está autorizada.

Antes de reiniciar, compruebe qué pasará con la cola y con las tareas en ejecución. Conserve los identificadores de las operaciones y la evidencia técnica sin datos personales innecesarios. Si hay indicios de acceso no autorizado, involucre de inmediato a los responsables de seguridad y aplique el procedimiento correspondiente; el plan habitual de disponibilidad puede no ser suficiente.

De 20 a 40 minutos: trabaje con la lista de resultados desconocidos

En un incidente hipotético, 12 operaciones se enviaron al proveedor, pero su resultado todavía no se conoce. Abra un registro para cada una: número interno, referencia del proveedor, monto y moneda, último estado confiable, siguiente paso y responsable. Consulte las API disponibles, las notificaciones firmadas y los reportes según las reglas del método correspondiente. Una captura de pantalla del cliente ayuda a investigar, pero no debe disparar automáticamente un pago repetido.

Un especialista restablece el procesamiento y otro lleva la conciliación de esas 12 operaciones. No borre un registro de la lista solo porque el cliente dejó de escribir. La excepción se cierra cuando el resultado está establecido y el siguiente paso se ha ejecutado, no por la antigüedad del caso.

PagerDuty define un rol específico para la persona que lleva la cronología del incidente. En un equipo de pagos conviene construir ese registro en torno a las decisiones: quién detuvo el flujo, qué cambió, con qué datos y qué resultado obtuvo. Después de varias intervenciones, es justamente esa secuencia la que permite distinguir una acción útil de una coincidencia.

Comunique distintos detalles a distintas audiencias

Ejemplo de actualización interna: «10:25 UTC. Confirmaciones demoradas en la ruta A. Envíos nuevos pausados. Revisamos 12 operaciones con resultado desconocido. El responsable técnico revisa la cola; el operador financiero concilia los registros. Próxima actualización a las 10:40 UTC». Las cifras y horas son ilustrativas; en un mensaje real use solo datos verificados.

Ejemplo de mensaje al cliente: «La confirmación de algunos pagos está demorada. Si su pedido aparece en proceso, no repita el pago por ahora. Estamos revisando las operaciones afectadas. Publicaremos la próxima actualización a las 10:40 UTC». Este texto solo sirve donde el estado de procesamiento está realmente disponible y la acción indicada es segura para el método elegido. No prometa que no habrá cobros duplicados si la conciliación aún no ha terminado.

Atlassian recomienda actualizaciones periódicas por el canal principal. Fije un intervalo claro y cúmplalo aunque no haya una causa nueva. Separe el impacto conocido de las hipótesis; no publique datos de clientes, secretos internos ni acusaciones sin confirmar contra un socio.

De 40 a 60 minutos: verifique la recuperación y traspase el trabajo pendiente

• Las nuevas operaciones permitidas pasan por las etapas esperadas.
• La cola realmente se reduce; sus elementos antiguos no quedan sin responsable.
• Las operaciones inciertas están resueltas o asignadas a responsables concretos.
• Se revisaron los abonos duplicados, las omisiones y las diferencias en el registro.
• Soporte conoce el estado actual y la próxima actualización comprometida.

La recuperación de la aceptación de pagos y el cierre de la conciliación financiera pueden ocurrir en momentos distintos. Dígalo abiertamente. Si el incidente continúa, entregue al siguiente turno las decisiones, los riesgos abiertos y los contactos. Una vez estabilizado, programe el análisis de causas y correcciones concretas, y mantenga un responsable para cada caso de cliente sin cerrar.

Dos puntos de cierre en lugar de uno

Para la recuperación técnica, defina condiciones verificables: las nuevas operaciones permitidas pasan, la latencia se mantiene dentro de los límites elegidos y la cola se reduce. El cierre financiero requiere otra evidencia: se encontraron todos los intentos afectados, se resolvieron duplicados y omisiones, se acordaron los ajustes y los casos de clientes tienen un resultado. Estas marcas pueden llegar en días distintos. No obligue al equipo a ocultar el trabajo residual para mostrar un solo estado en verde.

Durante el incidente, no cuente solo los errores, sino también la exposición monetaria. Doce operaciones desconocidas de 10 euros y doce de 10 000 euros requieren atención distinta. Agrupe los montos por moneda y tipo de obligación; no los sume en una cifra vistosa sin reglas de conversión. Marque aparte las operaciones por las que ya se entregó el producto o se prometió un pago.

El traspaso de turno como prueba de comprensión

Pida a la persona de guardia que recibe el turno que explique con sus palabras el siguiente paso de dos casos abiertos elegidos al azar. Si necesita las conjeturas verbales del turno anterior, la ficha está incompleta. Cada caso debe tener el último estado verificado, la fuente, la acción permitida y la condición de escalamiento. Un mensaje como «esperamos al proveedor» no basta: ¿qué estamos esperando exactamente y cuándo volvemos a revisar?

Tras la estabilización, elija las correcciones según el daño detectado. Si se perdió una clase de eventos, la tarea «mejorar el monitoreo» es demasiado amplia. Es mejor nombrar la señal omitida, la regla de detección y la prueba que demostrará que el problema ya no pasa inadvertido. El análisis vale la pena cuando la próxima persona de guardia recibe un sistema más confiable y un camino más corto hacia la respuesta.