HTML Payment
Overview
e-SiTef 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 e-SiTef, 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 e-SiTef, 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 e-SiTef'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.
Flow
The payment flow is executed by the merchant after the customer completes the purchase.
The merchant must initiate the transaction with e-SiTef 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 e-SiTef, 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 e-SiTef 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, e-SiTef 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 e-SiTef, 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 e-SiTef asynchronously.
e-SiTef 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, e-SiTef 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 e-SiTef. As an example we have payments via SiTef, e-Rede, among others.
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).
