A continuación se describe como es la gestión de transacciones de pago y cobro.
Utilizamos PayIn para referirnos a una transacción financiera mediante la cual se automatiza el cobro. Puede estar relacionado a un préstamo o a una comisión por el servicio de Lend2B.
Utilizamos Payout para referirnos a una transacción financiera mediante la cual se automatiza un pago. Puede estar relacionado al pago de un adelanto a un proveedor, al pago de una comisión, al pago de un impuesto.
En esta primer etapa nos vamos a referir a la creación de transacciones de PayIn y PayOut relacionadas con prestamos y adelantos.
Creación de transacciones PayIn y PayOut
En la instancia donde se aprueba un préstamo (base, extendido, refinanciado), se genera una transacción de PayIn que será ejecutada en la fecha definida como fecha de cobro del préstamo.
En la instancia donde se aprueba un adelanto, se genera además un una transacción de PayOut que será ejecutada en la fecha definida de pago del adelanto.
Origen y destino de los fondos
Para un PayIn, los fondos se “toman” desde el Comprador y se “acreditan” en el Lender, cancelando de esta forma la deuda contraída en el préstamo.
Para un PayOut, los fondos se “toman” desde el Lender y se “acreditan” en el Proveedor, cancelando de esta forma el pago de la factura que dio origen al financiamiento del lender.
Medios de pago
En esta instancia del producto, las transacciones se realizan a través de movimiento de dinero entre cuentas. Para el PayOut hablamos típicamente de Transferencias, para PayOut, la figura puede variar depende del mercado donde estemos realizando el desarrollo. En Argentina puede utilizarse un DEBIN (debito inmediato), en Chile un PAC (pago automático en cuenta)
Para poder efectivizar estas transacciones, es necesario en cada mercado contar con la integración a un riel de pago.
Ejecución de la transacción
De acuerdo al tipo de implementación que realicemos con el riel de pago, podemos tener ejecuciones programadas por lotes o bien ejecuciones Online.
a. Ejecución por lotes: seguramente necesitemos subir un archivo en algún sitio indicado por el riel, X días antes de la ejecución, una vez resueltas las transacciones, recibiremos o descargaremos un archivo con el resultado de cada transacción.
b. Ejecución online: seguramente existirán APIs que utilizaremos para en envío y recepción de respuestas sobre el estado de la transacción.
Análisis de resultados
De acuerdo al tipo de integración que tengamos con riel podemos tener diferentes respuestas finales a una transacción:
a. Aprobada
b. Rechazada
Si fue rechazada, pueden ser diversos los motivos de rechazo (se habilitarán sub estados) y las acciones que tenemos que tomar:
cuenta origen o destino invalida (inhabilitada, inexistente)
cuenta origen sin fondos disponibles
falla técnica (timeout, error de comunicación, otros)
5.1 Transacción Payout aprobado - Acciones
Para el caso del PayOut de un Adelanto, debe:
Pasar el estado de la Factura a Pago confirmado,
Pasar el estado del Adelanto también a Pago confirmado,
Informar al ERP que el pago fue ejecutado
5.2 Transacción PayIn aprobada - Acciones
Para el caso de un PayIn de un Préstamo, debe:
Verificar que el movimiento este acreditado en la cuenta del lender
Si esta acreditado → Pasar el estado del Préstamo a Pago confirmado y liberar el disponible en la sublínea correspondiente.
Si no está acreditado → Pasar el estado del Préstamo a Pago confirmado (el Comprador realizó el pago independientemente de la acreditación) e iniciar las gestiones necesarias con el riel de pagos para detectar y resolver el error (pendiente diseñar proceso). No se debe liberar el disponible hasta tanto se cierre la controversia.
5.3 Transacción PayIn o PayOut con cuenta de origen o destino invalida
En este caso se deben desarrollar circuitos de notificación al lender y al comprador o proveedor involucrado según corresponda para poder subsanar el error. Se avanzará sobre una nueva sección en el Menú de la Consola respectiva para la gestión de tareas (actualización de cuentas bancarias). Ej: Solicitudes a completar.
Si existe como servicio la consulta de validez de la cuenta, previo a realizar la transacción, evaluar la posibilidad de poder hacerlo.
PayOut, cuenta de origen inexistente/inhabilitada: es la cuenta del lender, esto tiene que disparar un alerta al administrador de lend2b para que contacte al lender y corrija la situación. Tarea a enviar desde Lend2B a la Consola del Lender cuando se recibe la respuesta desde el riel de pagos.
si la situación no puede subsanarse de inmediato, deben armarse procesos para notificar al destinatario de la situación y cuando se realizará el pago. Definir tiempos para completar la tarea de actualización de cuenta bancaria ? Que pasa si no se cumple ??
si existe otra cuenta para automatizar el pago, lend2B debe actualizar la cuenta y poder ejecutar nuevamente los pagos. El lender completa la Solicitud con la nueva cuenta. La misma deberá impactar en los datos de la Consola lend2B.
PayOut, cuenta destino inexistente/inhabilitada: es la cuenta del proveedor, esto tiene que disparar alerta al lender, para que contacte al proveedor y corrija su situación. Tarea a enviar desde la Consola Lender a la del Proveedor cuando se recibe la respuesta desde el riel de pagos.
si el proveedor no puede solucionar la situación (habilitar la cuenta para recibir la transferencia) o no puede proporcionar otra cuenta, el pago quedará en suspenso (Estado del Adelanto: Pago a confirmar) hasta tanto se solucione la situación. (profundizar sobre suspenso).
si existe otra cuenta para automatizar el pago, el lender debe actualizar la cuenta y poder ejecutar nuevamente los pagos. El proveedor completa la Solicitud con la nueva cuenta. La misma deberá impactar en los datos de la Consola lender.
PayIn cuenta origen inexistente/inhabilitada: es la cuenta del comprador, esto tiene que disparar alerta al lender, para que contacte al comprador y corrija su situación. Tarea a enviar desde la Consola Lender a la del Comprador cuando se recibe la respuesta desde el riel de pagos.
si el comprador no puede solucionar la situación (habilitar la cuenta para realizar el pago) o no puede proporcionar otra cuenta, el cobro quedará en suspenso hasta tanto se solucione la situación. (profundizar sobre suspenso) Definir tiempos para completar la tarea de actualización de cuenta bancaria ? Que pasa si no se cumple ? El estado del Préstamo debería ser Pago no confirmado ??
si existe otra cuenta para automatizar el cobro, el lender debe registrar la cuenta en la consola lender, y poder ejecutar nuevamente los pagos. El proveedor completa la Solicitud con la nueva cuenta. La misma deberá impactar en los datos de la Consola Comprador.
PayIn cuenta destino inexistente/inhabilitada: es la cuenta del lender, esto tiene que disparar un alerta al administrador de lend2b para que contacte al lender y corrija la situación. Tarea a enviar desde Lend2B a la Consola del Lender cuando se recibe la respuesta desde el riel de pagos.
si la situación no puede subsanarse de inmediato, deben armarse procesos para notificar al originante de la situación y cuando se realizará el cobro. Definir tiempos para completar la tarea de actualización de cuenta bancaria ? Que pasa si no se cumple ??
si existe otra cuenta para automatizar el cobro, lend2b debe actualizar la cuenta y poder ejecutar de alguna forma los cobros en forma manual con tareas a completar en las Consolas.
5.4 Transacción de PayIn o PayOut con cuenta origen sin fondos disponibles.
Cuando esta situación sucede, deben poder gestionarse políticas de reintentos.
Políticas de reintento posibles:
Montos:
siempre intentar debitar el total del importe
definir estrategia de cobros/pagos parciales:
si existe la consulta de disponible, se puede definir volver a reintentar por el disponible en ese momento.
si no existe la consulta de disponible, se deben definir criterios de montos (10tx por el 10%, 5tx por el 20%, 4tx por el 25%, 2 tx por el 50%, etc). Esto debe poder trabajarse como configuración con el lender, y entendiendo esquema de costos del riel. Puede ser una configuración de la asociación Lender/mercado???
Cantidad de reintentos: Especifica la cantidad de veces que se re intenta cuando una transacción es rechazada por fondos no disponibles. Puede ser una configuración de la asociación Lender/Mercado??
Periodicidad de reintentos: se puede definir periodos de cantidad de minutos, horas o días según el caso. Puede ser una configuración de la asociación Lender/Mercado??
Reglas de reintento iniciales:
Estas son las reglas que utilizaremos en una primera versión del módulo:
Montos: siempre debitaremos por el importe total del préstamo/adelanto.
Cantidad de reintentos: realizaremos una cantidad inicial de 5 reintentos. (a validar con el Lender)
Periodicidad de reintentos:
Resultados de ejecución de reintentos
Si con los reintentos, logra cobrarse el prestamo o pagarse el adelanto, se continúa con el circuito previsto para transacciones aprobadas de PayIn/Payout descripto mas arriba.
Si con los reintentos no logra cobrarse el prestamo, este pasa a estado de “mora” siguiendo el proceso actual de notificaciones y demas acciones previstas.
Si con los reintentos no logra pagarse el adelanto, deben gestionarse los mecanismos alternativos como el caso de cuenta origen erronea en Payout descriptos mas arriba.
5.5 Transacción de PayIn o PayOut con falla técnica.
Esta situación sucede cuando por algún motivo, falla la comunicación entre Lend2B y el riel de pago o entre el Riel de Pago y el banco.
Se definen entonces políticas de reintentos:
Monto: siempre por el importe total
cantidad de reintentos: realizaremos una cantidad inicial de 5 reintentos. (puede definirse configuración en la asociación Lender/Mercado, revisar practicas recomendadas por el riel de pago)
periodicidad de reintentos: inicialmente establecemos la periodicidad cada 3 minutos. (puede definirse configuración en la asociación Lender/Mercado, revisar practicas recomendadas por el riel de pago)