Visa Checkout
Portal Carat tiene la billetera digital Visa Checkout como funcionalidad para integrar la aplicación de la tienda.
Esto permite que el comerciante no tenga contacto directo con la recolección de datos de la tarjeta y los datos personales del usuario, utilizando la interfaz y estructura de comunicación desarrollada por VISA para pagos usando esta tecnología.
Rutas admitidas#
Actualmente, la integración de Visa Checkout a través de Web Services es compatible con pagos enrutados a través de SiTef, Cielo e-Commerce y Stone WS.
Interfaces Portal Carat soportadas#
Las interfaces compatibles con Portal Carat para usar Visa Checkout son:
- Pago REST
- Cancelación de REST
- Autorización previa de REST
Configuración requerida en Portal Carat#
Para que una tienda use la billetera digital Visa Checkout en Portal Carat, simplemente solicite al equipo de soporte / servicio de Portal Carat que realice esta configuración.
Requisito para la integración REST#
La aplicación de la tienda debe cumplir con el requisito de estar integrada con Visa Checkout en su interfaz gráfica y en la comunicación JavaScript del call-backs, para obtener el parámetro callid. Esto es necesario para la integración con la interfaz de pago REST de Portal Carat. Para más detalles sobre esta integración, el comerciante debe solicitar la guía de integración a VISA y desarrollar la integración con el Visa Checkout Button y LightBox.
Flujo de pago REST#
El flujo de pago para utilizar Portal Carat con Visa Checkout vía Web Services supone que la aplicación de la tienda ya cumple con los requisitos presentados en el ítem anterior, es decir, que la aplicación ya es capaz de utilizar los Web Services del Paid. En línea con el callid en manos.
La siguiente figura muestra el diagrama de flujo para integrar Portal Carat con Visa Checkout a través de servicios web (REST):
Para pagar transacciones de Visa Checkout a través de WS, la solicitud del comerciante debe enviar el wallet_transaction_id en lugar del número de tarjeta (number) en el objeto card. Opcionalmente, también puede enviar el initial_wallet_transaction_id, que te dice si es la primera vez que esto wallet_transaction_id esta siendo usado. Si no está definido, el valor deinitial_wallet_transaction_id es true. A continuación se muestra un ejemplo con la aplicación curl donde el adquirente solicita el envío del código de seguridad para el pago:
Flujo de autorización previa de REST#
Al igual que con el pago REST, la interfaz de preautorización también puede recibir los campos wallet_transaction_id y initial_wallet_transaction_id.
En caso de pagos con valores promocionales mediante Visa Checkout, VISA sugiere que los campos subtotal, discount e promo_code se envían adicionalmente tanto en el servicio de realización de preautorización como en el de captura de preautorización. Sepa mas.
El envío de estos campos no es obligatorio, sin embargo, VISA lo recomienda encarecidamente para enriquecer los datos estadísticos sobre el uso de Visa Checkout y mejorar los servicios relacionados. Estos campos se envían a los sistemas de Visa Checkout junto con la cantidad total, la moneda y la información del código de pedido. (orderId). Para aclarar el uso de estos campos, se muestra un ejemplo: asumiendo una transacción para un producto cuyo valor es de R $ 80,00, con un 10% de descuento (R $ 8,0) y resulta en un valor neto de R $ 72,00, los campos debe completarse de acuerdo con la fórmula:
REST Cancelación / Flujo de inversión#
Para cancelar o anular las transacciones de Visa Checkout a través de WS, la solicitud del comerciante debe enviar el wallet_transaction_id en lugar del número de tarjeta (number) no objeto card. A continuación se muestra un ejemplo con la aplicación curl donde el adquirente solicita el envío del código de seguridad para la reversión: