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.

Note: If a CHECKIN, REAUTHORIZATION, or CHECKOUT transaction fails due to an abnormal status, it will be canceled and marked as rejected, but it can be retried. The failed transaction will have a VR status.

Check-In

The CHECKIN transaction is used to obtain authorization from the bank (provider). It is defined as a debit to a credit or debit card that serves as a guarantee deposit for the use of a good or service. Flow

Checkin Request

To ensure quick integration, CHECKIN requests are similar to those of the processTransaction method, with the following differences:

  • The "action" must be checkin.
  • The payment reference will be reused in subsequent REAUTHORIZATION and CHECKOUT operations.
  • The payment currency will also remain the same in REAUTHORIZATION and CHECKOUT.
  • Dispersion details (multiple transactions to different collectors with the same cardholder information) are not considered.
  • Recurrence details (recurring charges from a proprietary database) are not included.

IMPORTANT: The preAuthorization node contains the data that will be used in subsequent REAUTHORIZATION and CHECKOUT operations. Additionally, it reflects the general status of the pre-authorization process.

Re-Authorization

Not applicable to Puerto Rico

For Transerver Retail, reauthorizations are limited exclusively to incremental adjustments to the amount previously authorized during the CHECKIN process or a prior REAUTHORIZATION.
This means it is not possible to reduce the authorized amount. If a reauthorization is attempted with an amount equal to or lower than the previously authorized value, the transaction will fail; in cases where a lower amount needs to be processed, the CHECKOUT process must be used instead.

The REAUTHORIZATION transaction modifies the previously defined security deposit amount in a CHECKIN transaction, requesting a new authorization from the bank (provider).

Reauthorization Request

A CHECKIN request must be made before processing a REAUTHORIZATION. Considerations:

  • The payment reference is overwritten by the original CHECKIN session.
  • The payment currency is overwritten by the original CHECKIN session.
  • The values for internalReference and authorization must match those provided in the CHECKIN response within the preAuthorization node.
  • Multiple REAUTHORIZATION transactions can be performed before CHECKOUT.
  • Each reauthorization must be for an amount greater than 0.

After this operation, the pre-authorization remains in a pending state until a CHECKOUT is performed.

Check-out

The CHECKOUT transaction confirms the security deposit amount previously separated with a CHECKIN or REAUTHORIZATION transaction. This formalizes the transaction (purchase/settlement) with the provider.

Checkout Request

Key considerations:

  • A CHECKOUT can be performed without a prior REAUTHORIZATION.
  • The payment reference is overwritten by the original CHECKIN session.
  • The payment currency is overwritten by the original CHECKIN session.
  • The values for internalReference and authorization must match those provided in the CHECKIN response within the preAuthorization node.
  • If the CHECKOUT amount is 0, the pre-authorization is canceled, and the retained amount is released.

IMPORTANT: The values of status, authorization, and receipt within the preAuthorization node change after a successful CHECKOUT. These updated values must be used in REVERSE requests.

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.