Cómo funciona Checkout

Checkout te permite recibir pagos en línea haciendo una integración muy sencilla desde tu sitio o aplicación.

Ciclo de vida

1. Cuando tus usuarios estén listos para completar el proceso de pago, tu aplicación debe crear un CheckoutSession.
2. Redireccionar al usuario a la URL provista, esta URL contiene nuestro Checkout con todas sus funcionalidades listas.
3. El usuario ingresa los datos requeridos para completar el pago.
4. El usuario es redireccionado de vuelta al sitio del comercio.
5. Después de la transacción, una notificación es enviada para que la aplicación conozca el estado del pago.

Para utilizar PlacetoPay Checkout, es necesario realizar una integración de código mediante servicios HTTP, donde tu aplicación o tienda en línea redirigirá a los usuarios a Checkout para que completen el proceso de pago. A continuación, se detallan los pasos necesarios para comenzar la integración.

Integración

En el siguiente diagrama se describe de forma visual y con más detalle el ciclo de vida de una sesión de pagos en Checkout.

Consideraciones de Seguridad

Los endpoints de Webcheckout NO deben consumirse directamente desde el navegador (ej: JavaScript/AJAX). Esto expone credenciales API y datos sensibles a riesgos de:

• Interceptación de claves por scripts maliciosos
• Exposición de datos en consola del cliente
• Vulnerabilidad a ataques XSS

Iniciar Checkout

Crear una sesión de pago
Para aceptar un pago a través de Checkout, es necesario crear una sesión de pago (Checkout Sesssion) utilizando el método API - Crear sesión (CreateRequest).
Al llamar a este servicio, se obtendrá la URL de proceso (processUrl) y el identificador de solicitud (requestId).
Puedes ver más en el apartado Crear Sesión

Registro del Pago en Proceso
En tu sistema, crear un registro que relacione el pago en proceso con el requestID proporcionado.
El estado inicial de todos los pagos es pendiente (PENDING).

Redirección del Usuario
El usuario debe ser redireccionado a la URL de proceso (processUrl) proporcionada por PlacetoPay Checkout.

Proceso de Pago o Suscripción
En la interfaz de Checkout, el usuario completará el proceso de pago o suscripción. Checkout se encargará de recopilar todos los datos necesarios.

Redirección de vuelta al sitio del comercio
Una vez que el proceso de pago esté completo, el usuario puede ser redirigido de vuelta a la URL de retorno (returnUrl) especificada en la solicitud inicial (CreateRequest).

En este punto es probable que el proceso de pago haya finalizado. Para conocer el estado del pago debes esperar la notificación o consultar el estado de la sesión.

Notificación asincrónica

Cuando una sesión tenga un estado final, PlacetoPay enviará una notificación asincrónica a tu sitio informando la finalización del proceso de pago. Asegúrate de manejar adecuadamente esta notificación para mantener la integridad de los datos.

Consulta de sesiones

Se debe consultar las sesiones para poder completar el ciclo de vida.

Consulta del estado de la sesión
Al llegar al sitio del comercio, se debe consultar el estado de la sesión.
Esto se puede lograr utilizando el método API - Consultar sesión (getRequestInformation).

Actualización y Reglas de Negocio
Según el estado final del pago obtenido, debes ejecutar las reglas de negocio correspondientes y actualizar la información relacionada con el pago en tu sistema.

Estados de sesión

Las sesiones pueden atravesar diferentes estados, cada uno con su propio significado y secuencia de cambios. A continuación, presentamos los estados posibles y cómo se relacionan entre sí:

PENDING Pendiente: Se presenta en tres situaciones: en primer lugar, es el estado inicial de la sesión e indica que el proceso está en espera de acciones por parte del usuario; en segundo lugar, cuando hay transacciones rechazadas, permitiendo al usuario la oportunidad de realizar nuevos intentos; y, por ultimo, cuando existe una transacción pendiente de validación lo que indica que la sesión se encuentra en un estado de espera hasta que se confirme y valide la transacción. En resumen, es un estado de espera e indica que el proceso no ha finalizado.

APPROVED Aprobado: Este estado se presenta cuando las transacciones se han aprobado y el proceso se ha completado con éxito. Este es un estado final de proceso.

REJECTED Rechazado: Este estado se presenta cuando la sesión es cancelada por parte del usuario. También puede ocurrir cuando la sesión llega al tiempo de expiración sin un pago aprobado. Este es un estado final de proceso.

APPROVED_PARTIAL Aprobado Parcial: Se presenta en sesiones de pago parcial cuando el usuario ha pagado una parte del monto total solicitado pero otra parte aún está pendiente o ha fallado. En este momento el usuario aún puede completar la totalidad del pago con otras transacciones.

PARTIAL_EXPIRED Parcial Expirado: Se presenta en sesiones de pago parcial cuando el usuario solo pagó una parte del monto total solicitado y el tiempo disponible para completar el pago ya ha finalizado. En este momento el proceso ya ha finalizado y no se puede completar. Este es un estado final de proceso.

Estados en sesiones

Estados en sesiones de pago parcial

Finalización de la sesión

Una sesión de checkout es el flujo o proceso que permite al usuario generar un resultado final. Este resultado puede ser una de las siguientes entidades:

• Transacción de pago (payment): Una transacción de pago única o múltiple según el tipo de sesión configurada.
• Tokenización (subscription): Una suscripción que almacena el método de pago del usuario para futuros cobros.
• Autopago (autopay): Un autopago que permitirá realizar cobros automáticos recurrentes.

Una vez que la sesión de checkout ha generado su resultado final, el proceso de la sesión termina definitivamente. A partir de este punto, cualquier modificación u operación adicional debe realizarse sobre las entidades resultantes (payment, subscription o autopay), no sobre la sesión de checkout.

Ejemplos de operaciones post-sesión

Las siguientes operaciones se realizan sobre las entidades resultantes y no afectarán el estado de la sesión:

• Reverso de transacción: Si una transacción de pago (payment) es reversada posteriormente, este cambio no se reflejará al consultar la sesión. La sesión seguirá mostrando el estado APPROVED que tenía al momento de su finalización.

• Reembolso de pago: Los reembolsos (totales o parciales) se realizan sobre la transacción de pago, no sobre la sesión. Al consultar la sesión, no verás información sobre reembolsos realizados.

• Cancelación de suscripción: Si una suscripción (subscription) es cancelada después de haber sido creada exitosamente, la sesión de checkout que la originó seguirá mostrando el estado APPROVED y no reflejará la cancelación.

• Cancelación de autopago: Similar a las suscripciones, si un autopago (autopay) es desactivado o cancelado, este cambio no aparecerá en las consultas de la sesión original.

Para realizar seguimiento o modificaciones de estas entidades, el comercio integrador debe utilizar las APIs correspondientes a cada tipo de entidad:

• API de Pagos para transacciones
• API de Tokens para suscripciones
• API de Autopay para autopagos

¿Qué sigue?

Listo, ahora que entiendes el ciclo de vída puedes continuar con:

• Crear Sesión
• Plugins y librerías