Mapa de responsabilidades de un pago: de soporte a finanzas

«Para nosotros todo salió bien» es una respuesta inútil si el almacén no puede despachar el pedido y el cliente ya pagó. Sin un mapa de responsabilidades, cada área mira su parte: el proveedor ve la operación, contabilidad busca la liquidación, el desarrollador revisa la notificación. El problema suele quedarse atascado en la frontera entre esos registros. Para resolverlo, el mapa debe decir quién confirma el hecho, quién está facultado para actuar y quién acompaña al cliente hasta el resultado.

Caso práctico: dónde buscar 120 euros

Ejemplo hipotético. Una tienda recibió un pedido de 120 euros. El proveedor muestra una operación exitosa, pero en la cuenta de liquidación todavía no está ese importe. El operador escribe «el dinero se perdió» y pasa el caso a los desarrolladores. Esa descripción es demasiado amplia: mezcla el estado del pago con la liquidación posterior.

Primero, un empleado de la tienda vincula el número de pedido con el identificador de la operación. Después, el equipo de pagos revisa el estado de la operación en el proveedor y el informe en el que debería aparecer. Tesorería busca la liquidación correspondiente y su referencia bancaria. El desarrollador interviene si los datos del proveedor y del sistema interno no coinciden. El importe de una liquidación puede agrupar muchas operaciones y ajustes, así que buscar exactamente 120 euros en el extracto bancario no resuelve nada por sí solo.

Supongamos que el informe hipotético contiene una venta de 120 euros y, por separado, una comisión de 3 euros. Si no hay otros movimientos, el importe liquidado es de 117 euros. Es la aritmética del ejemplo, no la tarifa de ningún servicio. Mientras no se verifiquen la fecha de disponibilidad de los fondos y la composición de la liquidación, es incorrecto concluir que el comprador pagó 3 euros de menos.

Primero los roles, después los nombres de las empresas

El comercio vende un producto o servicio. En su sistema están el pedido, las condiciones de compra, los datos de cumplimiento y el historial de comunicación con el cliente. Por eso ni siquiera un extracto bancario detallado explicará si se envió un paquete concreto o si se activó una suscripción. Para esas preguntas se necesita el registro propio del vendedor.

El PSP, payment service provider, reúne capacidades de pago para la empresa. El conjunto concreto depende del producto: conexión de métodos de pago, enrutamiento, panel de gestión, informes. El procesador realiza el tratamiento técnico de los mensajes de pago. Un mismo proveedor puede combinar varios roles, así que el nombre «PSP» por sí solo no describe la cadena contractual. Esa combinación la explica la guía de Adyen sobre proveedores de pago.

El adquirente gestiona la aceptación de pagos con tarjeta del lado del vendedor y participa en la liquidación. El emisor emite la tarjeta del comprador. En el modelo de tarjetas, entre ambos opera la red de pago. Hay definiciones breves de adquirente y emisor en el glosario oficial de Adyen. Para una transferencia bancaria directa el esquema es otro: no se le pueden aplicar todos los términos de tarjetas.

Anote la responsabilidad en forma de acciones

• Pedido y cumplimiento: ¿quién puede detener el despacho, corregir la composición del pedido y confirmar la recepción de la mercancía?
• Pago: ¿quién lee el estado de referencia, verifica el importe y la moneda, ve los motivos de rechazo?
• Reembolso: ¿quién lo aprueba según las reglas de la tienda y quién verifica el resultado en el proveedor?
• Liquidación: ¿quién concilia el informe con el extracto bancario y abre un caso si hay discrepancias?
• Incidente: ¿quién informa al cliente del plazo de la próxima actualización, aunque todavía no haya una respuesta definitiva?

Cada acción necesita un responsable principal, un suplente y acceso a una fuente de datos concreta. No dé acceso total a todos «por si acaso». A un agente de soporte normalmente le basta con ver el estado de la operación y su vínculo con el pedido; el permiso para cambiar los datos bancarios de liquidación debe evaluarse por separado.

Traspase la investigación junto con la pregunta

Un caso titulado «desapareció el pago» no tiene un límite verificable. Reformúlelo: «El pedido O-120 está vinculado al pago P-817; el proveedor confirmó el cobro, el pedido interno sigue en espera. Hay que determinar si se recibió el evento y por qué no cambió el pedido». Aquí ya están claros el objeto, el último estado confirmado y el hecho que falta. Los identificadores del ejemplo son ficticios.

Para el traspaso basta un paquete breve: número de pedido, enlace al registro autorizado del proveedor, importe y moneda, hora con zona horaria, comportamiento esperado y real, acciones ya realizadas. Indique por separado qué está bloqueado ahora: el despacho, el reembolso o la búsqueda de la liquidación. No adjunte el perfil completo del cliente si la cuestión se resuelve con dos referencias.

El equipo que recibe el caso debe confirmar el siguiente paso. Mientras no haya confirmación, el responsable anterior sigue llevando el caso. Es una regla de trabajo propuesta, no una característica de la red de pagos. Cierra ese hueco incómodo en el que quien envía ya considera el ticket ajeno y quien lo recibe aún no lo considera propio.

Un responsable no necesita tener todos los permisos

Separe tres funciones: establecer la causa, autorizar la acción con dinero y comunicar el resultado. Por ejemplo, el desarrollador puede demostrar que el evento se perdió, pero la decisión de reembolsar la toma un empleado autorizado. Soporte lleva la correspondencia, pero no modifica los datos bancarios de liquidación. Este esquema mantiene la rapidez sin convertir cada incidente en una excusa para ampliar accesos.

Ponga a prueba el mapa en un cambio de guardia. A las 18:00 el especialista principal se va; su suplente debe encontrar las evidencias, entender el riesgo de una acción repetida y dar la hora de la próxima actualización. Si para eso necesita el chat personal del empleado que se fue, el proceso depende de una persona más de lo que parece.

En la revisión semanal, cuente el número de traspasos entre equipos y el tiempo sin una siguiente acción asignada. Estos indicadores ayudan a ver la demora organizativa por separado de la espera del banco. Considere cerrada la investigación cuando se haya restablecido el vínculo entre registros y se haya ejecutado una acción confirmada por la fuente, no cuando se envió la última petición de «revisarlo de su lado».

Qué aclarar con un intermediario

Si la conexión se hace a través de una plataforma, pregunte quién es la parte del contrato y quién transfiere el dinero. Por ejemplo, un payment facilitator puede dar de alta a subcomercios y recibir los fondos de liquidación para pagarlos después; este modelo lo describe la ayuda de Adyen. Pida el esquema de su configuración concreta, incluidos los países y las personas jurídicas.

Deje constancia aparte de las obligaciones de protección de los datos de tarjeta. Delegar el procesamiento en un tercero no libera al comercio de todas sus obligaciones: el PCI SSC señala la necesidad de entender el reparto de responsabilidades. Acuerde el alcance concreto de la verificación con la organización que recibe sus informes PCI.

Antes del lanzamiento, entregue al siguiente turno un caso abierto sin explicaciones verbales. Que el empleado nombre el hecho que falta, el lugar donde verificarlo y el responsable del siguiente paso. Si esas tres respuestas no pueden obtenerse de la ficha, lo que hay que corregir es el propio traspaso del trabajo.