Web + PAM integration (Español)
Este libro describe como integrar y comunicarse satisfactoriamente con el PAM desde una aplicación Android, con el objetivo de proveer una session de apuestas para clerks.
Introduction
Introducción
Este documento describe los requerimientos y el flujo para integrar el PAM (Aplicación web) con una aplicación Web. Solo se presentarán los detalles de una sesión de apuestas.
Una sesión de apuestas es un período donde un agente realiza apuestas en el nombre de un cliente. Esta sesión termina cuando el cliente ha realizado todas las apuestas deseadas.
Este documento asume que la aplicación web está embedida dentro de otro sitio como un iFrame, y considera el flujo un flujo de pago con comunicación en 3 pasos:
- Validación de balance disponible: Previo a continuar con la operación a realizar.
- Confirmación de apuestas: Luego de confirmar una apuesta.
- Sesión finalizada: cuando el cliente deja el mostrador.
Integration basics
Para cumplir satisfactoriamente con el flujo propuesto, nuestra aplicación requiere de una comunicación bi-direccional entre la aplicación padre y la web app.
Pre-requisitos
Pre-requisitos
- Tener acceso a la private key del partner para generar tokens seguros
- Configurar el user agent mediante la url como se indique. Esto deberá ser provisto por el equipo de desarrollo y puede variar entre implementaciones.
Detalles técnicos
Autenticando el admin user sin contraseña
Para correctamente autenticar a un usuario dentro de la aplicación, se necesita un token con un cuerpo específico, respetando las normas propuestas por el standard JWT RS256, donde, el cuerpo incluye la siguiente estructura:
{
sub: // adminUserName,
rol: // roles,
aid: // agentId,
nam: // name,
oth: // email,
tit: // title,
}
* Los tokens generados loguean a un admin user si existiese o crean uno de no existir. No se modifican los admin users bajo
ningún concepto
Campos requeridos:
- Sub: El nombre de usuario
- Rol: Un array de roles a aplicar (Cuando se crean agentes, el array debería estar formado por: [*clerk])
- Aid: es el master agent a asignar el usuario, provisto por el partner.
Otros campos:
- Nam: Nombre del agente
- Oth: Email del agente
- Tit: Titulo del agente
* Estos campos son opcionales, no tienen ningún impacto más que ser descriptivos del bodeguero.
Creando la URL de la Retail App
La aplicación retail esta construida en base a un path básico y parámetros adicionales.
La ruta base es: https://pwallet.partner-domain.com/admin/pos/retail.
Set de parametros opcionales:
- Token: El valor de este parametro deberia ser generado de forma segura con el private key provisto en la sección de requisitos #2, siguiendo Autenticar el admin user sin contraseña
- userAgent: Provisto por el equipo de LinePros, este valor identificará el tipo de comunicacion entre nuestra aplicación y la aplicación padre. Es de alta importancia.
- customerId: Si fuese provisto, la session de apuesta se realizará para ese cliente.
- customerEmail: De existir un cliente para este email, se iniciara una sesión de apuestas para él, de lo contrario se creará un cliente asociándole este email.
- customerPhone: De existir un cliente para este teléfono, se iniciara una sesión de apuestas para él, de lo contrario se creará un cliente asociándole este teléfono.
Notes:
- Si fuere provisto, customerId toma precedencia sobre los otros atributos.
- customerEmail y customerPhone realizan una operación OR en la base de datos. Si hubiese mas de un cliente asociado a los mismos, ocurrirá un error y no se continuará con la sesión. Recomendamos usar uno o el otro, no ambos al mismo tiempo.
Examples:
- https://pwallet.partner-domain.com/admin/pos/retail?token=<authToken>&userAgent=<parentAppUserAgent>
Redirecciona al modo retail con una nueva sesión. - https://pwallet.partner-domain.com/admin/pos/retail?token=<authToken>&userAgent=<parentAppUserAgent>&customerId=12345
Para obtener el cliente con id 12345 - https://pwallet.partner-domain.com/admin/pos/retail?token=<authToken>&userAgent=<parentAppUserAgent>&customerEmail=test@domain.com
Para obtener el cliente con el email test@domain.com - https://pwallet.partner-domain.com/admin/pos/retail?token=<authToken>&userAgent=<parentAppUserAgent>&customerPhone=1234590
Para obtener el cliente con el telefono 1234590
Detalles de la comunicación desde la Aplicación Web a la aplicación padre
Esta implementación es usada para enviar datos desde la Aplicación Web hacia la Aplicación padre.
/* eventName puede ser cualquier evento aqui descrito */
window.addEventListener('message', (event) => {
if(eventName in event.data) {
const payload = event.data[eventName];
handleEvent(eventName, payload);
}
});
* `handleEvent` es un ejemplo, no un método que debería ser implementado.
Nombres de los eventos
Verificación del Balance
Este método envía una solicitud de balance al wrapper pidiendo la confirmación de que el importe de la apuesta se encuentra disponible y puede ser utilizado por el cliente para la sesión de apuestas actual.
window.addEventListener('message', (event) => {
if('balance-check' in event.data) {
const { amount, currencyCode } = event.data['balance-check'];
// Su lógica para manejar un monto total de {total} en {currencyCode} currency
}
});
Antes de proceder a realizar la apuesta, se debe recibir la confirmación del balance. De lo contrario la apuesta no se realizará.
Esperamos una respuesta en el mensaje con el siguiente formato:
{
‘balance-check’: {
success: Boolean,
error?: Any, // This exists only when success is false, if extra data is needed to be sent.
data?: Any // This exists only when success is true, if extra data is needed to be sent.
}
}
Confirmación de apuesta(s)
Este método recibe dos argumentos, un array de wagerIds (integer) y un totalAmount (float). Este monto total deberá ser menor o igual que el importe previamente confirmado en la llamada del método de checkBalance.
window.addEventListener('message', (event) => {
if('notify-wagers' in event.data) {
const { wagerIds, totalAmount } = event.data['notify-wagers'];
// Su lógica para recibir un array de {wagerIds}, por un monto total de {totalAmount}
}
});
WagerIds puede ser uno o varios id de apuestas, el totalAmount es la cantidad total apostada entre todas esas apuestas.
No se espera que este método envíe ninguna respuesta a la aplicación web. Sólo está pensado para la conciliación entre sistemas y para proporcionar un mapeo de las transacciones financieras a las apuestas.
Sesión finalizada
Este método se llama en la aplicación web siempre que el proceso de apuestas de un empleado con un cliente haya finalizado. Esto sólo ocurrirá si el recibo ha sido enviado al cliente por correo electrónico o mensaje de texto.
Este método, al igual que la confirmación de la apuesta, no espera ninguna respuesta hacia la Aplicación web.
window.addEventListener('message', (event) => {
if('session-ended' in event.data) {
// Su lógica para manejar finalización de sesión con un cliente.
}
});
Detalles de la comunicación desde el padre a la Aplicación Web
Nos comunicamos desde el padre a la aplicación web invocando una llamada postMessage en el objeto window del iframe.
const iframe = document.getElementById('linepros-iframe');
iframe.contentWindow.postMessage(<expected_response_for_each_method>, '*');
La respuesta debe ser siempre la definida en cada método, otros mensajes no funcionarán.