Getnet
Merchants can configure transactions on Carat Portal to be routed by many acquirers and payment methods. One of these is Getnet e-commerce, hereafter mentioned as GetnetWS.
In this page, the nomenclature "GetnetWS" will be used to reference the acquirer on Carat Portal.
Thus, the store can configure Carat Portal so that transactions made with VISA cards, for example, are routed through GetnetWS while those made with MASTERCARD are routed through CIELO.
#
Supported Carat Portal interfacesThe following interfaces for integration with GetnetWS are available:
- REST Payment
- REST Pre-Authorization
- REST Cancel
- HTML Payment
- HTML Pre-Authorization
#
Allowed Authorizers / IssuersThe following authorizers / issuers are available for integration with GetnetWS:
- VISA
- MASTERCARD
- ELO
- AMERICAN EXPRESS
- HIPERCARD
#
Required credentialsThe merchant must obtain with GetnetWS the credentials listed below, and pass them to Software Express or make the registration as explained later in this document.
Parameter | Description | Format |
---|---|---|
username | Access user name. | 20 N |
password | Access password. | 40 AN |
merchantID | EC code registered on GetnetWS. | 10 AN |
terminal | Terminal identification. | 7 AN |
subMerchantId | Submerchant ID. | < 15 AN |
Important for HTML Payment: If the merchant has not registered these credentials, this authorizer will not be displayed on the credit card selection screen during the payment transaction.
#
Registration of information through the merchant's portalThe merchant can register the information obtained with GetnetWS on the Merchant's Portal on Carat Portal. In this environment, you can change the authentication settings and password of the transactions. For this purpose, the merchant must select the authorizer and enter the editing screen as in the example shown below:
In the editing environment of the Authorizer, you can change the password registered on the Carat Portal environment. In this case, the change will only occur for this authorizer. Note that if merchant uses the same GetnetWS account, it will be necessary to manually change passwords for all the other authorizers.
Also in this environment, you can also change the registration password on Getnet. It is important to remember that when changing this password on the Getnet environment all the stores associated with this account on Getnet will also have to change the password registered on the Carat Portal environment by going to the edit screen of their authorizer, otherwise Getnet will deny their transactions.
The screen for changing the password on Getnet:
The new password must follow the rules defined by Getnet. These rules can be found in the integration document.
#
SoftDescriptor Registration on Carat Portal#
SubacquiringInformation related to subacquiring are registered by our support team. The following data are required:
Parameter | Format |
---|---|
Submerchant ID | < 15 AN |
Submerchant City | < 13 A |
Submerchant State | = 2 A |
Submerchant Zip Code | = 8 N |
Submerchant CNPJ or CPF | < 15 AN |
Submerchant Street Name | < 40 AN |
MCC | = 4 N |
Soft-Descriptor | < 22 AN Learn more |
The following fields can also be sent inside Carat Portal requests:
Parameter | Field | Notes |
---|---|---|
Submerchant ID | subacquirer_merchant_id | Sent in the payment effectuation service request. |
MCC | mcc | Sent in the payment effectuation service request. |
Soft-Descriptor | soft_descriptor | Sent in the transaction creation service request. |
If the fields above are both registered in the merchant's configurations and sent inside the request, the value inside the request has precedence.
#
RecurrencyIn order to acknowledge a recurrent payment, the GetnetWS integration establishes some rules that will be explained in this section.
The fields used in recurrencies are presented below.
Field | Description | Format |
---|---|---|
acquirer.recurrency | Sent inside the request. Flag that defines whether or not the payment is recurring. | < 5 T/F |
acquirer.recurrency_tid | Sent inside the request. First transaction's TID. This field tells the first and the subsequent transactions apart. | = 18 N |
acquirer.recurrency_seq_id | Sent inside the request. Represents the current installment number. | < 3 N |
payment.tid | Received inside the response. It is the acquirer's transaction ID. | = 18 N |
If the merchant does the recurrencies by himself/herself, he/she must follow the following steps:
- Step 1: First recurrency:
- Send
acquirer.recurrency
as true; - Store
payment.tid
to use in the subsequent recurrencies.
- Send
- Step N: Subsequent recurrencies:
- Send
acquirer.recurrency
as true; - Send
acquirer.recurrency_tid
with the value of thepayment.tid
field stored in Step 1; - Send
acquirer.recurrency_seq_id
with the current installment number (from 1 up to 999).
- Send
If the merchant does the recurrencies by using Carat Portal schedule service, the recurrency fields will be sent automatically and the recurrency processing can be monitored in the schedules reports as usual.
If the merchant does the recurrencies by using Carat Portal payment with schedule service, the recurrency fields will be sent automatically and the recurrency processing can be monitored in the schedules reports as usual. However, the ID used to identify the first recurrency transaction is the initial payment transaction ID and it is not the first scheduled payment ID.
#
Transaction FlowIn this section, we will present the particularities of the Getnet transactional flow.
#
HTML PaymentIt's possible to do a payment with 3DS authentication. For this, just send the authorizer_authentication
parameter with the value true
on the transaction creation phase.
Relevant fields in the call described in HTML Transaction Creation Service and REST Transaction Creation Service:
Parameter | Description | Format | Mandatory |
---|---|---|---|
authorizer_authentication | Identifies whether the merchant wants a payment with authentication. If positive, send true . | < 5 AN | YES for credit with authentication |
iata | This element contains specific fields that will be mandatory, if are with IATA transactions. | ||
first_installment | Amount of the first installment on IATA transactions in cents. | < 12 N | Conditional (required only for IATA transactions - sale of airline tickets) |
departure_tax | Departure tax in cents. | < 12 N | Conditional (required only for IATA transactions - sale of airline tickets) |
#
Pre-AuthorizationIt isn't possible to perform a pre-authorization with issuer installment funding.
Relevant fields in the call described in HTML Transaction Creation Service and REST Transaction Creation Service:
Parameter | Description | Format | Mandatory |
---|---|---|---|
iata | This element contains specific fields that will be mandatory, if are with IATA transactions. | ||
first_installment | Amount of the first installment on IATA transactions in cents. | < 12 N | Conditional (required only for IATA transactions - sale of airline tickets) |
departure_tax | Departure tax in cents. | < 12 N | Conditional (required only for IATA transactions - sale of airline tickets) |
#
Edit Pre-AuthorizationIt's possible to re-send the pre-authorization effectuation request with the amount
field to alter its amount.
Parameter | Description | Format | Mandatory |
---|---|---|---|
amount | New pre-authorization amount in cents. | < 12 N | YES |
#
REST Payment and Pre-Authorization- The
card
.holder
field is mandatory. - GetnetWS accepts sending authentication data:
eci
,xid
andcavv
.
Parameter | Description | Format | Mandatory |
---|---|---|---|
card .holder | Card holder name. | < 26 AN | YES |
external_authentication .eci | ECI Code of the 3D Secure authenticated transaction. | = 2 N | NO |
external_authentication .xid | MPI ID for each authenticated transaction. | < 40 AN | NO |
external_authentication .cavv | Authentication code encrypted by the issuer. | < 40 AN | NO |
#
RefundTransaction refunding can be done through the Merchant’s Portal. Only transactions made on the current day can be refunded. The merchant can refund pre-authorization transactions with or without capture and payment transactions. If you refund a pre-authorization transaction with capture, Getnet will refund the capture, however, Carat Portal will display this pre-transaction with status refunded (and confirmed capture).