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:

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.
START FUNNEL

From the merchant's website, you are redirected to the user's session link with the token obtained in the previous step.
CUSTOMER SESSION Process carried out by the paying user, selecting a bank, entering credentials, and approving their transfer
SUCCES / ERROR REDIRECT The user completes their payment session in our funnel. Upon completing the payment, 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.
NOTIFICATION RECEPTION (webhook) ****ETpay will perform a POST request to the web service URL specified by the merchant. This call confirms the successful or failed payment status 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 start of the process once the Basic Requirements 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 start of the process once the Basic Requirements 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 start of the process once the Basic Requirements 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 start of the process once the Basic Requirements 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 the payment flow for an end user.
signature_token	Signature token, returned as the API response when creating a session. It is used to validate the JWT information notifications.
JWT	JWT 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 JWT content changes, we will be able to detect it because attempting to validate the content 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 occurred during the payment.

Development of each stage

1. Create session

The first step of the payment process is to obtain a session_token, via a POST call 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_mach",
    "order_amount": 10
}

It is important to note that for automatic redirection using MACH as the payment method, the user_bank_code attribute must be present, defined with the bank code indicated above.

We have a simplified POSTMAN example in Quick Start

</aside>

<aside> ⚠️

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

</aside>

If the POST request format is correct, our API will return a response like the following, in JSON format: