In the following 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 Personalization Features.

Process Sumary

The moment a client decides to pay via ETpay, a flow is triggered which is summarized as follows:

  1. CREATE SESSION From the merchant's web page, a POST signal is generated to our API to obtain the session_token that allows the user to initiate his payment session.
  2. START FUNNEL From the merchant's web page, redirect to the user's session link with the token obtained in the previous step.
  3. CUSTOMER SESSION (FUNNEL) Process performed by the paying user selecting bank, entering credentials and approving his transfer.
  4. SUCCESS/ERROR REDIRECTION The user performs his payment session in our funnel. When the payment is completed the funnel will redirect to the success or error url as appropriate (both can be the same url). This redirection is only to give a visual confirmation to the end user within the merchant site.
  5. RECEIPT OF NOTIFICATION ETpay will make a POST request to the URL of the web service specified by the merchant. This call confirms the successful or failed status of the payment and r

Definitions:

Parameter Description
merchant_code Unique trade ID code, will vary between sandbox and pre-production/production environments. It is provided at the beginning of the process once the Basic Requirements are completed.
merchant_api_token Authentication token for api usage will vary between sandbox and pre-production/production environments. It is provided at the beginning of the process once the Basic Requirements are completed.
api_url Service API URL and session creation will vary between sandbox and pre-production/production environments. It is provided at the beginning of the process once the Basic Requirements are completed.
pmt_url Payment funnel URL, used in conjunction with session_token to initiate an end user's payment flow, will vary between sandbox and pre-production/production environments. It is provided at the beginning of the process once the Basic Requirements are completed.
merchant_order_id The merchant's own order identifier, used at the time of creating a payment session, is alphanumeric in format, with a maximum length of 64 characters.
order_amount Amount of purchase, used in session creation.
session_token Unique session token, it is returned as an API response when creating a session. It is used in conjunction with pmt_url to initiate an end user's payment flow.
signature_token Signature token, it is returned as an API response when a session is created. It is used to validate JWT information notifications.
JWT JWT's are a secure and easy way to transmit information over the web. They are encrypted and have a “signature” that guarantees that the content has not changed. In our case, the signature of the JWTs we send is the signature_token.
If the content of the JWT changes, we will be able to know that it is not true because when we try to validate the content using the signature_token we will get different values.
payment_token Payment attempt identifier, this identifier is returned once the payment session has occurred and allows us to identify within our system the steps and logs that occurred during the payment.

Development of each stage

Create session

The first step of the payment process consists of obtaining a session_token, by means of a POST call from the merchant's server (not from the client's browser) with the merchant_code and merchant_api_key to the [API_URL]/session/initialize endpoint. 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",
    "order_amount": 2000
}

<aside> <img src="/icons/info-alternate_blue.svg" alt="/icons/info-alternate_blue.svg" width="40px" /> A simplified example is available in POSTMAN at Quick Start

</aside>

<aside> ⚠️ Consider that both credentials and URLs change between environments as explained in the integration environments

</aside>