A continuación se especificará como implementar el servicio de pagos con el funcionamiento básico, existen personalizaciones para el comportamiento del servicio de pago las cuales se detallan en Características de personalización adicionales.
Al momento que un cliente decide pagar mediante ETpay, se gatilla un flujo que se resume de la siguiente forma:
Parámetro | Descripción |
---|---|
merchant_code | Código único de identificación de comercio, variará entre ambientes sandbox y pre-productivo/productivo. Se entrega al inicio del proceso una vez completados los Prerrequisitos básicos. |
merchant_api_token | Token de autenticación para el uso de la api, variará entre ambientes sandbox y pre-productivo/productivo. Se entrega al inicio del proceso una vez completados los Prerrequisitos básicos. |
api_url | URL de la api de servicios y creación de sesión, variará entre ambientes sandbox y pre-productivo/productivo. Se entrega al inicio del proceso una vez completados los Prerrequisitos básicos. |
pmt_url | URL del funnel de pagos, se utiliza en conjunto al session_token para iniciar el flujo de pago de un usuario final, variará entre ambientes sandbox y pre-productivo/productivo. Se entrega al inicio del proceso una vez completados los Prerrequisitos básicos. |
merchant_order_id | Identificador de orden propio del comercio, se utiliza al momento de crear una sesión de pago, es de formato alfanumérico de largo máximo 64. Usualmente se utiliza el número de orden de compra. |
order_amount | Monto de la compra, se utiliza en la creación de sesión. |
session_token | Token de sesión único, es retornado como respuesta de la API al momento de crear una sesión. Se utiliza en conjunto con pmt_url para iniciar el flujo de pago de un usuario final. |
signature_token | Token de firma, es retornado como respuesta de la API al momento de crear una sesión. ****Se utiliza para validar las notificaciones de información de los JWT |
JWT | Los JWT son una forma segura y fácil de transmitir información a través de la web. Estos vienen encriptados y poseen una “firma” que garantiza que el contenido no ha cambiado. En nuestro caso, la firma de los JWT que enviamos es el signature_token. |
Si el contenido del JWT cambia, podremos saber que no es verídico ya que al intentar validar el contenido usando el signature_token obtendremos valores diferentes. | |
payment_token | Identificador de intento de pago, este identificador se retorna una vez ya ocurrida la sesión de pago y permite identificar dentro de nuestro sistema los pasos y logs que ocurrieron durante el pago. |
El primer paso del proceso de pago consiste en obtener un session_token, mediante una llamada de tipo POST desde el servidor del comercio (no desde el browser del cliente) con el merchant_code y merchant_api_key al endpoint [API_URL]/session/initialize. El body debe ser un JSON con las siguientes variables:
{
"merchant_code": "your_merchant_code",
"merchant_api_token": "your_merchant_api_token",
"merchant_order_id": "your_order_id",
"order_amount": 2000
}
<aside> <img src="/icons/info-alternate_blue.svg" alt="/icons/info-alternate_blue.svg" width="40px" /> Tenemos un ejemplo simplificado en POSTMAN en Inicio Rápido
</aside>
<aside> ⚠️ Considerar que tanto las credenciales y URLs cambian entre ambientes como se explica en los ambientes de integración
</aside>