HTML Payment

Overview#

Online Payment 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 Online Payment, 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 Online Payment, 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 Online Payment'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 Online Payment by submitting the purchase data as shown below.

The payment flow without redirection consists of the following steps:

  1. After the customer completes the purchase, the merchant creates a new transaction on Online Payment, through a POST in the URL to start a transaction, informing all necessary parameters. Learn more.
  2. As response to POST, the store will receive an Online Payment URL to which the customer must be redirected. This URL will be different for each payment transaction.
  3. The customer will follow the payment flow according to the informed authorizer, and ends the payment.
  4. At the end of the payment flow, Online Payment 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 Online Payment, 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 Online Payment asynchronously.

Online Payment 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, Online Payment provided a mechanism of verification and change of the Authorizer that will respond for the authorization of the transaction.

Learn more.

Payment without redirecting the customer#

The image below illustrates the HTML 2.0 Payment flow without redirecting the customer to an environment external to Online Payment. 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).