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.
When a customer decides to pay through ETpay, a flow is triggered that can be summarized as follows:
| 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. |
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>