Consulta y Confirmación de Pagos
Autenticación HMAC
Toda la comunicación con API de PAGO46 requiere de autenticación HMAC, favor leer la sección Autenticación HMAC antes de continuar con la integración.
Siempre Server-side Requests
Las credenciales (provider key y secret) nunca deben ser expuestas a usuarios finales no autorizados y toda la comunicación HTTP entre el Proveedor y PAGO46 debe hacerse Server-side, nunca desde el browser o app del usuario final. Exponer las credenciales puede provocar serias vulnerabilidades de seguridad para el comercio y sus consumidores.
#
Flujo GeneralAl integrarse con PAGO46 pasas a ser parte del ecosistema y red de PAGO46 la cual permitirá completar movimientos perteneciente a PAGO46 en redes externas (Payment provider). A continuación se describe los pasos generales para completar la integración:
- Obtener credenciales y datos de prueba (ambiente sandbox) para comenzar integración.
- Implementar comunicación con endpoint
check
el cual permite validar una posible deuda a cobrar al usuario. El dato principal es un código númerico que provee el usuario. - Implementar comunicación con endpoint
notify
para confirmar la recepción y confirmación del pago. Esto debe hacerse una vez el dinero se encuentra en poder del provider. - Proveer lista de puntos en formato csv o xlsx que contenga la información geográfica de los puntos físicos con una información mínima de nombre, dirección completa en texto y opcionalmente coordenadas.
- Instrucciones para realizar pagos en los puntos físicos del proveedor.
- Logo y material gráfico necesario para desplegar puntos en mapa.
Conexión VPN
Una conexión VPN no es requerida por PAGO46 entre PAGO46 y el proveedor. La autenticación HMAC, protección de credenciales y comunicación HTTPS se considera adecuado para proteger la comunicación. Si el proveedor requiere de uno conexión VPN debe contactar a su ejecutivo comercial y contacto técnico de PAGO46.
#
Diagrama de Flujo#
Verificación de DeudaCuando el usuario se acerca a un punto físico del proveedor, indicará que desea completar un pago de PAGO46 y dará un código de máximo 10 dígitos de largo. El proveedor debe consultar (validar) este pago antes de completarlo y verificar el monto y el estado.
Importante que siempre debe verificar el estado del pago para ser completado debe estar en estado pending
de lo contrario el pago no debe ser aceptado / procesado. De igual forma al momento de notificar el pago contra API se responderá error en caso de no ser un pago en estado pending
.
- Path:
/payments/provider/check/<code>/
- Method:
GET
#
Parámetros URLNombre | Tipo | Descripción | Requerido |
---|---|---|---|
code | number | Código que provee el usuario que quiere completar el pago. Ejemplo: 1234567890 | Si |
#
Parámetros Body- N/A
#
Parámetros HeaderNombre | Valor | Descripción | Requerido |
---|---|---|---|
provider-key | {provider-key} | Merchant Key del comercio | SI |
message-hash | {hash} | Hash HMAC SHA256 de autenticación. Más información | SI |
message-date | {date} | Unix milisegundos timestamp mismo que se usó para generar Hash | SI |
Content-Type | application/json | SI |
#
Response#
Ejemplo#
DataNombre | Tipo | Descripción |
---|---|---|
code | number | Código de Pago indicado previamente por usuario y en URL de request |
price | number | Valor a cobrar del pago. Este monto debe ser indicado al usuario |
price_currency | string | Tipo de moneda del pago. Posibles valores: ARS , CLP ,MXN , PEN y USD |
status | string | Estado del pago. Sólo se deben aceptar pagos en estado pending . Otros estados posibles son cancelled , expired , complete . |
creation_date | string (Date UTC ISO 8601) | Email de usuario consumidor. Mismo valor enviado en la creación |
last_notify_date | string (Date UTC ISO 8601) | Fecha y hora UTC ISO 8601 en de la creación de la orden |
#
Response CodesHTTP Code | Descripción |
---|---|
200 | OK. Respuesta exitosa. |
403 | Error. No Autorizado o Cabeceras incorrectas |
404 | Error. Pago no encontrado o URL equivocada |
#
Confirmación de Pago / MovimientoUna vez que el dinero ha sido recolectado por el proveedor en su punto físico, los sistemas del proveedor deben notificar el pago para poder ser completado por PAGO46. El proveedor debe esperar una respuesta éxitosa de lo contrario asumir que la confirmación del pago ha sido fallida.
- Path:
/payments/provider/notify/<code>/
- Method:
PUT
#
Parámetros URLNombre | Tipo | Descripción | Requerido |
---|---|---|---|
code | number | Código que provee el usuario que quiere completar el pago. Ejemplo: 1234567890 | Si |
#
Parámetros BodyNombre | Valor | Descripción | Requerido |
---|---|---|---|
status | complete | Estado del pago. Enviar siempre complete para completar el pago. | SI |
#
Parámetros HeaderNombre | Valor | Descripción | Requerido |
---|---|---|---|
provider-key | {provider-key} | Merchant Key del comercio | SI |
message-hash | {hash} | Hash HMAC SHA256 de autenticación. Más información | SI |
message-date | {date} | Unix milisegundos timestamp mismo que se usó para generar Hash | SI |
Content-Type | application/json | SI |
#
Response#
Ejemplo#
DataNombre | Tipo | Descripción |
---|---|---|
code | number | Código de Pago indicado previamente por usuario y en URL de request |
price | number | Valor a cobrar del pago. Este monto debe ser indicado al usuario |
price_currency | string | Tipo de moneda del pago. Posibles valores: ARS , CLP ,MXN , PEN y USD |
status | string | Estado del pago. Solo se deben aceptar pagos en estado pending . Otros estados posibles son cancelled , expired , complete . |
creation_date | string (Date UTC ISO 8601) | Fecha y hora UTC ISO 8601 en de la creación de la orden |
last_notify_date | string (Date UTC ISO 8601) | Fecha y hora UTC ISO 8601 en de la última modificación de la orden |
#
Response CodesHTTP Code | Descripción |
---|---|
200 | OK. Respuesta exitosa. |
304 | Error. Movimiento ya ha sido completado previamente. |
403 | Error. No Autorizado o Cabeceras incorrectas |
404 | Error. Pago no encontrado o URL equivocada |
410 | Error. Movimiento expirado, fuera de fechas para poder completarlo. |
Sin flujo de reversa
Si una notificación falla debido a problemas de conectividad o se obtiene un código de respuesta en el rango de 5xx, se quiere reintentar la petición de notificación con los mismos parámetros hasta un máximo de 3 veces. De ser posible, un tiempo de back-off de 15 segundos hasta 30 segundos entre cada intento de notificación podría ser de ayuda en caso que se presenten problemas de congestionamiento en nuestro servicio.
Cualquier duda, información extra o sugerencia no dudes en contactar a tu contacto de PAGO46 o escríbenos directamente a contacto@pago46.com.