External origin pre-authorization editing service
For GetnetLac route you can change the value of a non-captured preauthorization, even if it isn't present in Carat Portal's databases. Consult our support to avail which other routes have this functionality too. To use this functionality, simply call the doPreAuthorization operation with data from a pre-authorization transaction with status CON (confirmed) in addition to the amount field. Below are the details for this call.
Currently, this functionality only alows editing of pre-authorizations originated via SiTef.
This operation has one more step, in relation to a normal pre-authorization editing. The pre-authorization editing external origin transaction flow is started by consuming the beginTransaction operation, which will generate an Carat Portal record of a transaction with status = NOV, and return the nit parameter to the application, which will identify this transaction.
Pre-authorization editing external origin creation#
Call details#
- Resource:
/v1/transactions - HTTP Method:
POST - Request format:
JSON - Response format:
JSON - Header parameters:
| Parameter | Description | Format | Mandatory |
|---|---|---|---|
Content-Type | Fixed value "application/json" | = 15 A | Yes |
merchant_id | Carat Portal store's ID. Production and certification IDs are different. | ≤ 15 A | Yes |
merchant_key | Store authentication key in Carat Portal. Production and certification keys are different. | < 80 A | Yes |
Examples#
Below there are some examples of calling the pre-authorization creation service using the cURL tool.
Request:
To use this example, don't forget to define the variable {{url}} to the value
esitef-homologacao.softwareexpress.com.br
Response:
Request Parameter#
| Parameter | Description | Format | Mandatory |
|---|---|---|---|
amount | Total purchase amount (in cents). Example: 1.00 = 100 or 1,100.00 = 110000 – send amount without dots or commas | < 12N | Yes |
encrypted_card | This field must be sent with a value of "true" if the card number to be sent in the next step of the flow uses SiTef encryption. The option to send the encrypted card will only be available through routing via SiTef and prior SiTef setup is required. Options: 1. "true" 2. "false" (default) | < 5 AN | No |
merchant_usn | Unique sequential id for each order created by the store. NSU will be used in all communication with the store to identify the order. As this is a store-side access key, although it is optional for Carat Portal, it is strongly recommended that the field be formatted and sent by the store application. | < 12 N | No |
order_id | Order code to be displayed to the buyer, defined by the merchant. It should be different at each request to facilitate traceability. If the store's integration with the acquirer/routing networks (Cielo, Redecard, etc) is via SiTef (TEF), the field orderId, which has a maximum length of 40 characters, will be shortened to 12 characters due to a SiTef restriction. This reduction will be performed by keeping the characters from left to right (eg if an order code entered is 12345678901234567890 in Carat Portal, in SiTef it will only be 123456789012). | < 40 AN | No |
transaction_type | Fixed value "preauthorization" | = 15 A | Yes |
soft_descriptor | Additional text that will be presented alongside the name of the establishment in the credit card invoice. Learn more | < 22 AN | NO |
is_transaction_origin_external | Fixed value "true" | = 5 AN | Yes |
Format field caption:
AN = alphanumeric
N = numeric
N A = not applied
Response Parameters#
| Parameter | Description | Format |
|---|---|---|
code | Carat Portal response code. Any code other than ‘0’ means failure. For more information, see Responde Codes. | < 4 N |
message | Carat Portal's response message. | < 500 A |
amount | Transaction's amount defined by the store (in cents) at transaction creation. | < 12 N |
merchant_usn | Unique sequential number sent by store transaction creation. | < 12 N |
nit | Pre-authorization transaction ID in Carat Portal. | = 64 A |
order_id | Order code sent by store at transaction creation. | < 40 AN |
status | Pre-authorization transaction status in Carat Portal. | = 3 A |
Pre-Authorization Editing External Origin Service#
The execution follows the same flow as a pre-authorization editing transaction originated in Carat Portal, but it is necessary to send some additional parameters in the request.
Request Parameter#
| Parameter | Description | Format | Mandatory |
|---|---|---|---|
| acquirer | This element’s fields must be sent in cases of external origin transactions. | ||
routing_id | Routing information used by the payment done outside of Carat Portal. It is used to identify the routing inside of SiTef. This information only make sense in external origin transaction. | < 5 N | No |
authorizer_id | Code of the authorizer on Carat Portal. It must be the same value sent on the pre autorization. | < 3 N | Yes |
host_usn | Host/authorizer USN of the transaction to be captured. | = 9 N | Yes |
authorization_number | Authorization number of the transaction to be captured. | < 6 N | Yes |
authorizer_date | Pre-authorization date returned by the authorizer in DD/MM/YYYY format. | = 10 D | Yes |
order_id | Order code used in the pre-authorization initiated outside Carat Portal. | < 40 AN | No |
identification_number | CPF or CNPJ used in the pre-authorization initiated outside Carat Portal. | < 20 AN | Yes |
terminal | SiTef terminal code. In absence Carat Portal will generate a random terminal code. | = 8 AN | No |
company_code | SiTef company code. In absence Carat Portal will use company code from merchant configuration. | = 8 N | No |
Note:#
1 - When the terminal and company_code information are sent, the behavior of cardquery changes slightly. At this point, when running cardquery, Carat Portal will identify the network returned by SiTef. Once identified, it will be used instead of the one registered in the store.
2 - In operations of external origin, we are unable to validate the network that was used in the external part of the operation, which was carried out outside Carat Portal. In these cases, we are going to use the network configured on SiTef. Because of that, configuration changes, if done during operation, can cause invalid or denied requests. For example, if a pre-authorization was made on the physical medium on the 181 network and, before the capture is completed, the SiTef configuration is changed to the 125 network, the operations that are done via Carat Portal will take over the 125 network.
WARNING: The
terminalecompany_codeparameters must be sent simultaneously.
It is also necessary send a request to the Carat Portal Support Team for the permission Allows the sending of Company and SiTef Terminal through REST.
Example#
Request:
To use this example, don't forget to define the variable {{url}} to the value
esitef-homologacao.softwareexpress.com.br
Response: