Types of transactions

Authorization

An authorization refers to the process that is executed after the user enters the requested information and it is sent to the network to make the payment.

Recurring payment

It is a periodic charge made by PlacetoPay for the same value with an interval (daily, monthly, annual) according to the indication given in the request.

To make use of this functionality, in the payment structure of the Recurring Payment it is necessary to send the mandatory data for this structure in the recurring object.

Pre-authorization

Pre-authorization is a transaction used to reserve (checkin) an amount of money on a credit card. This amount can later be debited (checkout). During the process, the amount may change (reauthorization) according to the merchant’s needs or modifications in the services chosen by the cardholder.

For more information about CHECKIN, REAUTHORIZATION y CHECKOUT see Payments -> preAuthorization

Below, we will explore each step in detail to help you integrate preauthorization payments effectively.

Step 1: Initiate the preauthorization flow (Check-in)

Initiate the pre-authorization by creating a transaction of type checkin. This reserves the funds on the customer’s card without charging them.

Send a RequestBody to API Gateway -> Transaction Processing.

• action must be checkin.
• Mixed or split payments are not allowed.
• The currency remains fixed throughout the entire flow.
• The response will include a preAuthorization object with the necessary values for the following steps.

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

Step 2: Adjust the held amount (Reauthorization)

This optional step allows you to update the held amount before capturing it.

This is done by sending a RequestBody to API Gateway -> Transaction Operations.

• action must be reauthorization.
• You must include internalReference and authorization from the previous step.
• The currency must match the Check-in.
• You can perform multiple reauthorizations.

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

Step 3: Finalize the transaction (Checkout)

This step captures or releases the held amount.

This is done by sending the RequestBody to the API Gateway -> Transaction Operations.

• action must be checkout.
• If amount.total is 0, the hold is released.
• You must include internalReference and authorization from the last step.

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

With this three-step process, you can safely and effectively handle preauthorized payments using the Gateway API. Always ensure the internalReference, authorization, and reference values are consistent across all steps to avoid transaction errors.

Dispersion

This type of transaction is used to split the payment between different entities besides the main site. That is, when making a transaction, part of the value is directed to the site authenticated in the transaction, and another part is sent to an airline or other sites. Additionally, this allows each part of the transaction to be processed by different providers.

The dispersal transaction is made up of a parent session of type DISPERSION that contains the total value of the transaction and the general state of the process, and also by daughter sessions of type AUTH_ONLY that contain the information of each of the parties. scattered. The authorization and receipt data of the parent transaction will be the same as the first transaction processed.

In the event that a transaction remains pending, the other pending transactions will not be processed until it is resolved, leaving a status of PENDING_PROCESS. The parent transaction will maintain its PENDING state until all child sessions are resolved.

In the event that a transaction fails or is rejected, other pending transactions will automatically be rejected as well, without establishing contact with the network. If a child transaction has already been approved previously, it maintains its state and the parent transaction will change its state to APPROVED_PARTIAL.

Transactions can be reversed together or separately. If a rollback is sent to a child transaction, only the child transaction will be rolled back. If a rollback is sent to the parent transaction, all transactions will be rolled back.

Airline dispersion

When a dispersal is made to an airline, it will be prioritized and processed first. If 3DS or credit is configured, this configuration will be used only in processing the airline transaction.

Airline dispersions are limited to just two parties: one from the main business and one from the airline. It is also possible to perform a spread in which the total value of the transaction is redirected to the airline, by not sending the trade spread or sending it with a zero value.

Business dispersion

Merchant spreads allow a split transaction to be made across up to 3 sites, including the authenticated site. Child transactions will be processed in the order sent in the transaction.