Next, we will specify how to implement the payment service with the basic operation. There are customizations for the behavior of the payment service, which are detailed in Additional Customization Features.

Process summary


When a customer decides to pay through ETpay, a flow is triggered that can be summarized as follows:

  1. CREATE SESSION ****From the merchant’s website, a POST request is sent to our API to obtain the session_token that allows the user to start their payment session.
  2. START FUNNEL ****From the merchant’s website, the user is redirected to the session link using the token obtained in the previous step.
  3. CUSTOMER SESSION (FUNNEL) Process carried out by the payer, selecting a bank, entering credentials, and approving their transfer
  4. SUCCESS/ERROR REDIRECT The user completes the payment session in our funnel. Once the payment is completed, the funnel will redirect to the success or error URL as applicable (both can be the same URL). This redirect is only intended to provide a visual confirmation to the end user within the merchant’s site.
  5. RECEIVING NOTIFICATION ****ETpay will perform a POST request to the web service URL specified by the merchant. This call confirms the successful or failed status of the payment and requires an information validation step.

Definitions:

Parameter Description
merchant_code Unique merchant identification code. It will vary between sandbox and pre-production/production environments. It is provided at the beginning of the process once the Prerrequisitos básicos are completed.
merchant_api_token Authentication token for API usage. It will vary between sandbox and pre-production/production environments. It is provided at the beginning of the process once the Prerrequisitos básicos are completed.
api_url URL of the services API and session creation. It will vary between sandbox and pre-production/production environments. It is provided at the beginning of the process once the Prerrequisitos básicos are completed.
pmt_url URL of the payment funnel. It is used together with the session_token to start the payment flow for an end user. It will vary between sandbox and pre-production/production environments. It is provided at the beginning of the process once the Prerrequisitos básicos are completed.
merchant_order_id Merchant’s own order identifier, used when creating a payment session. Alphanumeric format with a maximum length of 64. Usually the purchase order number is used.
order_amount Purchase amount. Used when creating the session.
session_token Unique session token, returned as the API response when creating a session. It is used together with pmt_url to start an end user payment flow.
signature_token Signature token, returned as the API response when creating a session. It is used to validate the JWT information notifications.
JWT The JWT are a secure and easy way to transmit information over the web. They are encrypted and have a “signature” that guarantees the content has not changed. In our case, the signature of the JWTs we send is the signature_token.
If the JWT content changes, we will be able to detect it because attempting to validate it using the signature_token will yield different values.
payment_token Payment attempt identifier. This identifier is returned once the payment session has occurred and allows identifying within our system the steps and logs that happened during the payment.

Development of each stage


Create session

The first step of the payment process is to obtain a session_token, via a POST request from the merchant’s server (not from the customer’s browser) with the merchant_code and merchant_api_key to the endpoint [API_URL]/session/initialize. The body must be a JSON with the following variables:

{
    "merchant_code": "your_merchant_code",
    "merchant_api_token": "your_merchant_api_token",
    "merchant_order_id": "your_order_id",
    "user_bank_code": "cl_tapp_pay",
    "order_amount": 10
}

<aside> <img src="/icons/info-alternate_blue.svg" alt="/icons/info-alternate_blue.svg" width="40px" />

We have a simplified POSTMAN example in ‣

</aside>

<aside> ⚠️

Keep in mind that credentials and URLs change between environments as explained in the integration environments

</aside>