Checkout Web
Overview#
Carat Portal has two interfaces for integration with the virtual store, HTTPS POST and HTTPS Web Services, enabling the proper way of interaction between the store and Carat Portal, according to the programming language and the platform of the virtual store.
The HTML interface was defined to have a simple and quick integration with the payment method and the existing services on Carat Portal, without losing its flexibility. The default interface has only two required parameters, performing the collection of other parameters on the portal itself or through settings made by the store manager on Carat Portal's back office. However, if the virtual store wants to send definitions or restrictions for a particular service, acquirer or even the number of installments, it can be done through the set of parameters sent at the beginning of the transaction, before redirecting the client.
And to learn more about these nomenclatures (Bin, Software Express, Carat, e-Sitef) Learn more
Flow#
The payment flow is executed by the merchant after the customer completes the purchase.
The merchant must initiate the transaction with Carat Portal by submitting the purchase data as shown below.
The payment flow without redirection consists of the following steps:
- After the customer completes the purchase, the merchant creates a new transaction on Carat Portal, through a POST in the URL to start a transaction, informing all necessary parameters. Learn more.
- As response to POST, the store will receive an Carat Portal URL to which the customer must be redirected. This URL will be different for each payment transaction.
- The customer will follow the payment flow according to the informed authorizer, and ends the payment.
- At the end of the payment flow, Carat Portal will redirect the customer back to the store, according to the configuration of return URLs already informed in the merchant registration, or to the
back_url's sent on the creation of the payment transaction.
For each payment transaction status change on Carat Portal, the merchant will receive a status notification POST, informing its status. Learn more.
All outgoing calls will be answered synchronously except for the status notification that will be performed by Carat Portal asynchronously.
Carat Portal allows the merchant to set up the payment method responsible for authorizing the transactions of a given flag. For example, a merchant may prefer routing VISA card transactions to CIELO Mastercard card transactions to REDE.
This flexibility to configure routing gives the merchant the ability to process promotions according to the card's issuer.
Thinking on how to prevent the user to select the issuer Visa, but end up typing a Mastercard card number, Carat Portal provided a mechanism of verification and change of the Authorizer that will respond for the authorization of the transaction.
Payment without redirecting the customer#
The image below illustrates the HTML 2.0 Payment flow without redirecting the customer to an environment external to Carat Portal. As an example we have payments via SiTef, e-Rede, among others.
HTML 2.0 Payment Flow Without redirecting the buyer#
Payment redirecting the customer to the Authorizer#
The image below illustrates the HTML Payment 2.0 flow using an authorizer that requires customer redirection to their system (e.g. PayPal, Banco do Brasil, MercadoPago, among others).
