Tipos de transacciones

Autorización

Una autorización hace referencia al proceso que se ejecuta luego de que el usuario ingresa la información solicitada y ésta es enviada a la red para realizar el cobro.

Pago Recurrente

Es un cobro periódico realizado por PlacetoPay para un mismo valor con un intervalo (diario, mensual, anual) según la indicación dada en la petición.

Para hacer uso de esta funcionalidad, en la estructura payment del Pago recurrente es necesario enviar en el objeto recurring los datos obligatorios para esta estructura.

Pre-autorización

La pre-autorización es una transacción utilizada para reservar (checkin) un monto de dinero en una tarjeta de crédito. Posteriormente, este monto puede ser debitado (checkout). Durante el proceso, el monto puede cambiar (reauthorization) según las necesidades del comercio o modificaciones en los servicios elegidos por el tarjetahabiente.

Para conocer más sobre CHECKIN, REAUTHORIZATION y CHECKOUT consultar Pagos -> Preautorización

A continuación, exploraremos cada paso en detalle para ayudarte a integrar pagos con preautorización de forma efectiva usando la API Gateway.

Paso 1: Iniciar el flujo de preautorización (Check-in)

Inicia la preautorización creando la transacción de tipo checkin. Esto reserva los fondos en la tarjeta del cliente sin cobrarlos.

Envía una RequestBody a API Gateway -> Procesamiento de transacción.

  • action debe ser checkin.
  • No se permiten pagos mixtos ni dispersos
  • La moneda se mantiene fija durante todo el flujo
  • La respuesta incluirá un objeto preAuthorization con los valores necesarios para los pasos siguientes.

RequestBody -> Checkin

{
    "auth": ...,
    "action": "checkin",
    "payment": {
        "reference": "1234567890",
        "description": "Testing about checkin",
        "amount": {
            "currency": "USD",
            "total": 10
        }
    },
    ...
}

Paso 2: Ajustar el monto retenido (Reauthorization)

Este paso opcional permite actualizar el monto retenido antes de capturarlo.

Esto se hace enviando el RequestBody a API Gateway -> Operaciones sobre una transacción .

  • action debe ser reauthorization.
  • Debes incluir internalReference y authorization del último paso.
  • La moneda deben coincidir con el Check-in
  • Puedes realizar múltiples reautorizaciones

RequestBody -> Reauthorization

{
    "auth": ...,
    "internalReference": 30,
    "authorization": "235263",
    "action": "reauthorization",
    "payment": {
        "reference": "1234567890",
        "description": "Testing about reauthorization",
        "amount": {
            "currency": "USD",
            "total": 15
        }
    },
    ...
}

Paso 3: Finalizar la transacción (Checkout)

Este paso captura o libera el monto retenido.

Esto se hace enviando el RequestBody a API Gateway -> Operaciones sobre una transacción .

  • action debe ser checkout.
  • Si payment.amount.total es 0, el monto retenido se libera.
  • Debes incluir internalReference y authorization del último paso.
  • La moneda deben coincidir con el Check-in

RequestBody -> Checkout

{
    "auth": ...,
    "internalReference": 30,
    "authorization": "235263",
    "action": "checkout",
    "payment": {
        "reference": "1234567890",
        "description": "Testing about checkout",
        "amount": {
            "currency": "USD",
            "total": 20
        }
    },
  ...
}

Con este proceso de tres pasos, puedes gestionar de forma segura y eficaz los pagos preautorizados utilizando la API Gateway. Asegúrate siempre de que los valores internalReference, authorization y reference sean consistentes en todos los pasos para evitar errores en la transacción.

Dispersión

Este tipo de transacción es utilizada para dividir el pago entre diferentes entidades además del sitio principal. Es decir, al realizar una transacción, parte del valor es direccionado al sitio autenticado en la transaccion, y otra parte es enviada a una aerolínea u otros sitios. Además, eso permite que cada parte de la transacción sea procesada por diferentes proveedores.

La transacción de dispersión está conformada por una sesión padre de tipo DISPERSION que contiene el valor total de la transacción y el estado general del proceso, y también por sesiones hijas de tipo AUTH_ONLY que contienen la información de cada una de las partes dispersadas. Los datos de autorización y recibo de la transacción padre serán los mismos de la primera transacción procesada.

En caso de que una transacción quede pendiente las demás transacciones pendientes no serán procesadas hasta que esta se resuelva, quedando con un estado de PENDING_PROCESS. La transacción padre mantendra su estado PENDING hasta que todas las sesiones hijas se resuelvan.

En caso de que una transacción falle o sea rechazada, las demás transacciones pendientes automáticamente también serán rechazadas, sin establecer contacto con la red. Si una transacción hija ya hubiese sido aprobada anteriormente, esta mantiene su estado y la transacción padre cambiará su estado a APPROVED_PARTIAL.

Las transacciones pueden ser reversadas juntas o separadas. Si se envía una reversión a una transacción hija, solo esta será reembolsada. Si se envía una reversión a la transacción padre, todas las transacciones serán reversadas.

Dispersión de aerolínea

Cuando una dispersión es realizada a una aerolínea, esta será priorizada y procesada primero. Si 3DS o crédito están configurados, esta configuración será utilizada solamente en el procesamiento de la transacción de la aerolínea.

Las dispersiones de aerolínea son limitadas a apenas 2 partes: una del comercio principal y otra de la aerolínea. También es posible realizar una dispersión en la que el valor total de la transacción es redireccionado a la aerolínea, al no enviar la dispersión del comercio o enviarla con valor cero.

Dispersión de comercios

Las dipersiones de comercios permiten realizar una transacción dividida en hasta 3 sitios, incluyendo el sitio autenticado. Las transacciones hijas serán procesadas en el orden enviado en la transacción.