Getnet WS · e-SiTef

Merchants can configure transactions on e-SiTef 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 e-SiTef.

Thus, the store can configure e-SiTef so that transactions made with VISA cards, for example, are routed through GetnetWS while those made with MASTERCARD are routed through CIELO.

Supported e-SiTef interfaces

The following interfaces for integration with GetnetWS are available:

REST Payment
REST Pre-Authorization
REST Cancel
HTML Payment
HTML Pre-Authorization

Allowed Authorizers / Issuers

The following authorizers / issuers are available for integration with GetnetWS:

VISA
MASTERCARD
ELO
AMERICAN EXPRESS
HIPERCARD
VISA ELECTRON
MAESTRO

Required credentials

The 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 portal

The merchant can register the information obtained with GetnetWS on the Merchant's Portal on e-SiTef. 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 e-SiTef 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 e-SiTef 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 e-SiTef

Subacquiring

Information 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 e-SiTef 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.

Recurrency

In 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.
Step N: Subsequent recurrencies:
- Send acquirer.recurrency as true;
- Send acquirer.recurrency_tid with the value of the payment.tid field stored in Step 1;
- Send acquirer.recurrency_seq_id with the current installment number (from 1 up to 999).

If the merchant does the recurrencies by using e-SiTef 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 e-SiTef 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 Flow

In this section, we will present the particularities of the Getnet transactional flow.

HTML Payment

It'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.

Pre-Authorization

It isn't possible to perform a pre-authorization with issuer installment funding.

Edit Pre-Authorization

It'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 and cavv.

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

Refund

Transaction 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, e-SiTef will display this pre-transaction with status refunded (and confirmed capture).