Skip to main content

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 General#

Al 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:

  1. Obtener credenciales y datos de prueba (ambiente sandbox) para comenzar integración.
  2. 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.
  3. 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.
  4. 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.
  5. Instrucciones para realizar pagos en los puntos físicos del proveedor.
  6. 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#

P46 Payment Button flow

Verificación de Deuda#

Cuando 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 URL#

NombreTipoDescripción Requerido
codenumberCódigo que provee el usuario que quiere completar el pago. Ejemplo: 1234567890Si

Parámetros Body#

  • N/A

Parámetros Header#

NombreValorDescripció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-Typeapplication/jsonSI

Response#

Ejemplo#

{
"code": 1234567890,
"price": 1000,
"price_currency": "CLP",
"status": "pending",
"creation_date": "2021-01-01T00:00:00Z",
"last_notify_date": "2021-01-01T00:00:00Z"
}

Data#

NombreTipoDescripción
codenumberCódigo de Pago indicado previamente por usuario y en URL de request
pricenumberValor a cobrar del pago. Este monto debe ser indicado al usuario
price_currencystringTipo de moneda del pago. Posibles valores: ARS, CLP,MXN, PEN y USD
statusstringEstado del pago. Sólo se deben aceptar pagos en estado pending. Otros estados posibles son cancelled, expired, complete.
creation_datestring (Date UTC ISO 8601)Email de usuario consumidor. Mismo valor enviado en la creación
last_notify_datestring (Date UTC ISO 8601)Fecha y hora UTC ISO 8601 en de la creación de la orden

Response Codes#

HTTP CodeDescripción
200OK. Respuesta exitosa.
403Error. No Autorizado o Cabeceras incorrectas
404Error. Pago no encontrado o URL equivocada

Confirmación de Pago / Movimiento#

Una 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 URL#

NombreTipoDescripción Requerido
codenumberCódigo que provee el usuario que quiere completar el pago. Ejemplo: 1234567890Si

Parámetros Body#

NombreValorDescripción Requerido
statuscompleteEstado del pago. Enviar siempre complete para completar el pago. SI

Parámetros Header#

NombreValorDescripció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-Typeapplication/jsonSI

Response#

Ejemplo#

{
"code": 1234567890,
"price": 1000,
"price_currency": "CLP",
"status": "pending",
"creation_date": "2021-01-01T00:00:00Z",
"last_notify_date": "2021-01-01T00:00:00Z"
}

Data#

NombreTipoDescripción
codenumberCódigo de Pago indicado previamente por usuario y en URL de request
pricenumberValor a cobrar del pago. Este monto debe ser indicado al usuario
price_currencystringTipo de moneda del pago. Posibles valores: ARS, CLP,MXN, PEN y USD
statusstringEstado del pago. Solo se deben aceptar pagos en estado pending. Otros estados posibles son cancelled, expired, complete.
creation_datestring (Date UTC ISO 8601)Fecha y hora UTC ISO 8601 en de la creación de la orden
last_notify_datestring (Date UTC ISO 8601)Fecha y hora UTC ISO 8601 en de la última modificación de la orden

Response Codes#

HTTP CodeDescripción
200OK. Respuesta exitosa.
304Error. Movimiento ya ha sido completado previamente.
403Error. No Autorizado o Cabeceras incorrectas
404Error. Pago no encontrado o URL equivocada
410Error. 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.