Pago REST
Descripción general#
Portal Carat dispone de dos interfaces de integración con la tienda online, POST/HTML y Web Services (REST), que permiten a la tienda interactuar con lo Portal Carat de forma adecuada, dependiendo del idioma y plataforma de ejecución de la tienda online.
En la interfaz REST, la recogida de datos de la tarjeta y del pago la realizará la Tienda Virtual y Portal Carat solo será responsable de realizar el pago con la entidad financiera.
En esta interfaz, los pagos con tarjeta de crédito, débito o voucher están disponibles.Para los pagos bancarios, como la transferencia bancaria o el boleto, utilice la interfaz POST/HTML.
Y para saber más sobre estas nomenclaturas (Bin, Software Express, Carat, e-Sitef) Leer más
Comunicación#
Para realizar una transacción de Web Service, toda la comunicación se realizará a través de HTTPS/SSL. Es importante que el servidor comercial admita al menos una codificación de 128 bits. El servidor de la tienda debe realizar llamadas a direcciones específicas para transacciones REST.
Cada servicio debe ser llamado utilizando URL base concatenada del recurso deseado (ver el capítulo referente al servicio que se va a consumir). El método HTTP (GET, POST o PUT) indica la acción esperada en el recurso elegido. A bajo se muestran las URL base de Portal Carat:
URL base de producción:
https://esitef.softwareexpress.com.br/e-sitef/api
URL base de aprobación:
https://esitef-homologacao.softwareexpress.com.br/e-sitef/api
Todas las llamadas realizadas a los servicios serán respondidas sincrónicamente .
Atención:
Nunca use la IP en lugar del dominio esitef.softwareexpress.com.br. La IP puede cambiar en cualquier momento y sin previo aviso, por lo que es importante utilizar el dominio para acceder al Portal Carat.
Importante:
Además de los parámetros de devolución del servicio descritos en esta especificación, Portal Carat puede devolver otros parámetros sin previo aviso.
Es importante que la aplicación esté preparada para recibir los parámetros desconocidos además de los parámetros ya especificados y simplemente ignorarlos.
Flujo#
El flujo de pago será iniciado por la aplicación de la tienda electrónica después de que el cliente finalice la compra y complete su información de pago.
Existen dos tipos de flujo de pago: con confirmación automática, donde Portal Carat se encarga de confirmar el pago con las Redes Adquirientes y con confirmación tardía, donde la aplicación se encarga de confirmar el pago, consumiendo el servicio de confirmación.
La confirmación tardía se utiliza generalmente cuando la aplicación de la tienda online permite el pago con más de una tarjeta o si se realiza alguna validación antes de realizar el pago.
Pago con confirmación automática#

Descripción del flujo:
- El comerciante crea una transacción en API, pasando información como el código de la tienda, el número de cuotas y el código de pedido y obtiene un NIT (Número de identificación de la transacción) en respuesta.
- La tienda virtual luego procede a consumir el servicio de procesamiento de pagos, pasando el NIT y los datos de la tarjeta del comprador. Si tiene éxito, la transacción de pago cambiará su estado a
CON(confirmado).
Ejemplo
Para usar este ejemplo, no olvide definir la variable {{url}} con el valor
esitef-homologacao.softwareexpress.com.br
Pedido:
Respuesta: (tenga en cuenta el estado de la transacción, que es CON de Confirmado)
Pago con confirmación tardía#

Descripción de flujo:
- Asi como en el flujo de pago con confirmación automática, el comerciante crea una transacción en API, pasando los detalles del pago. Además, debe enviar el parámetro
postpone_confirmationcon valortrue. - La tienda virtual luego procede a consumir el servicio de procesamiento de pago, pasando el NIT y los datos de la tarjeta del comprador. Si tiene éxito, la transacción de pago cambiará su estado a
PPC(pago pendiente de confirmación). - En conclusión, la tienda virtual llama al servicio de confirmación de pago, volviendo a pasar el NIT y el parámetro
confirmcon un valor detrue, dando como resultado una transacción con estadoCON(confirmado). También existe la posibilidad de que el comerciante deshaga la transacción en lugar de confirmar. Para esto, el parámetroconfirmdebe enviarse con un valor defalse, lo que dará como resultado una transacción con statusPPN(deshecho).
Ejemplo
Para usar este ejemplo, no olvide definir la variable {{url}} con el valor
esitef-homologacao.softwareexpress.com.br
Tenga en cuenta el parámetro
postpone_confirmationincluido con el valortruey el estado de la transacción que ahora esPPC.
Respuesta: