Recursos para IA

Procesar pagos

Para continuar con la integración, deberás integrar el procesamiento de pagos a través de la API de Orders. Esto permitirá recibir pagos sin fricción iniciados por el cliente (CIT) o pagos iniciados por el comercio (MIT) sin necesidad del reingreso de datos.

Con Pagos automáticos, es posible procesar dos tipos de pago en función de su recurrencia:

Pagos con recurrencia programada: se trata de pagos que tienen una periodicidad pre-establecida, como suscripciones, pagos recurrentes, o renovaciones.
Pagos únicos con tarjetas guardadas (Card on File): se trata de pagos puntuales para los que no se requiere el reingreso de datos de las tarjetas, sino que se reaprovecha el medio de pago registrado previamente para procesar transacciones. Estas pueden ser CIT, en el caso de pagos one-click o recompras, o bien MIT, en el caso de débitos por consumo.

flowchart TD
    A[Procesar pago] --> B{¿Es un pago programado?}
    %% Pagos con recurrencia
    B -- Sí --> C[Pago con recurrencia programada]
    C --> C1{¿Es el primer pago de la cadena?}
    C1 -- Sí --> RCIT[CIT
Customer Initiated Transaction]
    C1 -- No --> RMIT[MIT
Merchant Initiated Transaction]
    %% Pagos UCOF
    B -- No --> U[Pago con tarjeta guardada
UCOF]
    U --> P{¿El usuario está presente?}
    P -- Sí --> UCIT[CIT
Customer Initiated Transaction]
    P -- No --> UMIT[MIT
Merchant Initiated Transaction]
    %% Ejemplos
    RCIT --> RCIT1[Alta de suscripción/ Primer pago de recurrencia]
    RMIT --> RMIT1[Pagos siguientes de la cadena/ Renovaciones automáticas]
    UCIT --> UCIT1[One-click / Recompra]
    UMIT --> UMIT1[Débitos por consumo]

Adicionalmente, la API de Orders permite elegir el modo en el que es posible procesar Pagos Automáticos.

Modos de procesamiento de Orders

Una order de Pagos Automáticos puede ser creada para ser procesada de dos modos principales: Modo síncrono y Modo asíncrono.

La definición del modo de procesamiento se realizará al momento de crear la order, mediante el parámetro processing_mode. Su valor deberá ser automatic para procesamientos síncronos, o automatic_async para procesar la order de manera asíncrona.

El modo síncrono permite que la transacción se complete en una sola etapa. A través de este modo, el pago se procesa de manera inmediata y la respuesta se recibe en tiempo real.

Para crear la order en modo síncrono, el campo processing_mode, que es responsable de definir el formato de creación y procesamiento de la transacción, debe estar como automatic.

Las operaciones permitidas son:

Crear y procesar orderAPI: responsable por la creación de la order y el procesamiento de la transacción en simultáneo.
Obtener orderAPI: permite obtener información sobre una order, incluido su status en tiempo real.
Cancelar orderAPI: responsable de la cancelación de una order ya existente, pero que aún no ha sido procesada.
Reembolsar orderAPI: permite el reembolso total o parcial de un pago realizado con tarjeta de crédito. La order será reembolsada totalmente si todas las transacciones son reembolsadas por completo.
- Reembolso total: no se debe indicar un monto a reembolsar en el body de la solicitud, que debe ir vacío.
- Reembolso parcial: se debe especificar la cantidad a reembolsar en el body de la solicitud, junto con el ID de la transacción. Todas las otras transacciones permanecerán como están y solo la transacción modificada será reembolsada.

Reglas para Pagos automáticos en el modo síncrono

Solo permite procesar pagos con tarjetas (crédito, débito o prepago).
El procesamiento de intenciones de pago con perfiles que contengan más de una tarjeta no está permitido. En esos casos, el sistema impide el pago síncrono y retorna el error invalid_payment_methods.
Por este mismo motivo, el modo síncrono solo permite la lógica de reintentos con un solo medio de pago, que puede ser definida a través del campo max_day_overdue en la creación del perfil de pago del cliente.