e.Rede Rest · e-SiTef

The merchant has the ability to set up credit and debit cards transaction routing on e-SiTef by various payment methods, one of which is e.Rede REST. This is the e-commerce platform from Rede acquirer.

This page will use the nomenclature "e.Rede REST" to reference routing in e-SiTef.

Attention: E-SiTef has the e-Rede routing, but it's a previous version integration, with limited functionalities and no more updates. So e.Rede REST is recommended option now.

e-SiTef Interfaces Supported for Integration

You can use the following interfaces for integration with e.Rede REST routing:

REST Payment
REST Pre-Authorization
REST Cancel
HTML Payment
HTML Pre-Authorization
Cancel via e-SiTef Merchant's Portal

Required Credentials

The store must contact e.Rede in order to obtain the credentials listed below and then inform them to Software Express or register them on e-SiTef's merchant's portal as explained later on in this document.

Field	Description	Format
`filiation`	Merchant's identification on e.Rede REST.	< 8 AN
`token`	Access token.	< 32 AN
`threeDSecureOnFailure`	Indicate if it should continue with the authorization in case of 3DS autentication failure.	Continue or Do not
`subacquirerMerchantId`	Submerchant identification	< 32 AN
`independentSalesOrganizationId`	Independent Sales Organization identification. Applied only in case of Dynamic MCC.	< 11 AN
`paymentFacilitatorId`	Payment facilitator ID. Applied only in case of Dynamic MCC.	< 11 N

Important notice for HTML Payment: In the event that a merchant authorizer has not registered these credentials, that authorizer will not be displayed on the credit card selection screen during the payment transaction.

Registration of information through the e-SiTef Merchant's Portal

The merchant himself can register the information obtained with e.Rede REST on the e-SiTef Merchant's Portal. For this purpose, the merchant must select the authorizer and enter the editing screen as in the example shown below:

Portal e.Rede REST

Check more details about Merchant's Portal.

Flows

This section will present the differentiated or relevant fields of the e.Rede REST transactional flow.

Currently, e.Rede REST does not allow installments with interest from the card issuer, so the installments_type field cannot receive the values 3 or 6. The installments field allows a maximum of 12 installments.

Payment Transaction creation (HTML and REST)

Dynamic MCC

Relevant fields in the call described in HTML Transaction Creation Service and REST Transaction Creation Service:

Parameter	Description	Format	Mandatory
`soft_descriptor` (*)	Additional text that will be presented alongside the name of the establishment in the credit card invoice. Learn more	< 13 AN	NO
additional_data	Element for sending additional data.
`mcc` (*)	The MCC (Merchant Category Code) is a code that classifies the business by the type of goods or services it provides.	< 4 N	NO
`postpone_confirmation`	Field that allows the store to hold the transaction as a Pending Verification, and later confirm or undo it.	< 5 A	NO

(*) Notice about Soft Descriptor and MCC: In the context of marketplace or payment facilitators, it is allowed to use both fields, sending in request or by registration in e-sitef backoffice. The values sent via request take precedence over the registered values. Additionally in the same context, the submerchant Id parameter can be registered in e-SiTef, to be informed in the payment effectutation. Please contact e-SiTef customer support for these values registration.

Rede 3DS Authentication

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
back_url	Element for sending url redirection data used for MPI Rede autentication.
`url_success` (*)	Redirection URL of the customer in case of success. Must have only the relative path.	< 87 A	NO
`url_failure` (*)	Redirection URL of the customer in case of failure. Must have only the relative path.	< 87 A	NO

It's possible to do a payment with Rede 3DS MPI authentication, as long as this funcionality is enabled in merchant's e.Rede account. To use it in e-SiTef, just send the authorizer_authentication parameter with the value true on the transaction creation phase.

For debit card payments, the authentication is mandatory.

(*) Important: For REST payments with Rede MPI autentication,backurl data for success and failure cases is mandatory, for the correct user redirect to the merchant's page at the end of the authentication process.

For each case, the URL total size (registered merchant domain in e-SiTef + relative path) must have a maximum of 87 characters.

Trasaction creation for REST Payment example:

curl
--request POST "https://esitef-homologacao.softwareexpress.com.br/e-sitef/api/v1/transactions"
--header "Content-Type: application/json"
--header "merchant_id: xxxxxxxx"
--header "merchant_key: xxxxxxxxxxx"
--data-binary
{
    "merchant_usn":"123456789",
    "order_id":"testOrder001",
    "amount":"2200",
    "authorizer_id":"2",
    "installments":"2",
    "installment_type":"4",
    "authorizer_authentication":"true",
    "back_url":{
        "url_success":"/urlSucess.html",
        "url_failure":"/urlFailure.html"
    }
}
{
--verbose

In the case of authentication failure, the merchant can choose to proceed with the payment or have the payment stopped (do not proceed). This behavior must be registered in the e-SiTef backoffice, and its default value is `Do not proceed if authentication fails. For this configuration, please contact the e-SiTef service team or it can be changed in Merchant's Portal.

REST Payment

This integration also allows external 3DS authentication data (eci, xid and cavv) to be sent in payment effectuation. Learn more about this service.

This integration allows Visa Checkout wallet.

HTML Payment

In case of debit card payments, e-SiTef will force the Rede MPI 3DS authentication, despite the authorizer_authentication field in transaction creation step.

This integration allows Masterpass wallet.

Payment Confirmation

You can confirm a lower value than the one informed in the original payment created via HTML or via REST using the additional_data.postpone_confirmation field equal to true.

To do this, send the desired amount in the REST confirmation call:

Parameter	Description	Format	Mandatory
`confirm`	This field must be sent with the value `true` if you wish to confirm the transaction, or `false` if you wish to undo the payment.	< 5 T/F	YES
`amount`	Value in cents of the amount to be confirmed. If not sent, the full amount of the transaction will be confirmed.	< 12 N	NO

The e.Rede REST payment confirmation generates a new "Host USN" and "Payment authorization date".

REST Pre-Authorization

This integration also allows external 3DS authentication data (eci, xid and cavv) to be sent. Learn more about this service.

Also it is possible to send soft_descriptor and mcc fields in transaction creation, in the same way than REST Payment (see above).

This integration allows Visa Checkout wallet.

In the Pre-Authorization/Capture flow, installment's data must be sent only in the pre-authorization.

HTML Pre-Authorization

This integration allows Masterpass wallet.

Also it is possible to send soft_descriptor and mcc fields in transaction creation, in the same way than HTML Payment (see above).

In the Pre-Authorization/Capture flow, installment's data must be sent only in the pre-authorization.

Recurrency

e.Rede REST accepts transaction recurrency indication parameters. To do this, send the acquirer.recurrency field with the value true in the REST payment call. If the current transaction is not the first one, send the first transaction's TID in the field acquirer.recurrency_tid.

For more information, see the REST Payment Service page.

Parameter	Description	Format	Mandatory
acquirer	Data required only to specific acquirers / routings.
`recurrency`	Flag that defines whether or not the payment is recurring.	< 5 T/F	NO
`recurrency_tid`	First transaction's id (TID) on the card brand. This field tells the first and the subsequent transactions apart. Use only if it is a recurrent payment. This field is used only for the brands Visa and Mastercard.	< 16 AN	NO

Cancellation

The cancellation of a transaction can be done on the Merchant's Portal or via Web Service REST.

Cancellation requests can be made in up to 7 days for debit transactions and for credit transactions the default is up to 90 days, but it can vary according to the branch of operation of each establishment.

For cancellations requested on the same day of the authorization transaction or authorization with automatic capture, the processing will be carried out immediately, otherwise, the processing will be carried out in D + 1.

Partial cancellation available only on D + 1 and for transactions with capture.

Dynamic MCC Fields

Payment and Pre-Authorization REST Transaction creation service

Request Parameters

Additionally to the fields in the REST Transaction Creation Service, the fields below are used specifically in dynamic MCC transactions integrated to the e.Rede REST routing:

Parameter	Description	Format	Mandatory
`soft_descriptor`	Personalized phrase that will be printed on the bearer's invoice. For information regarding the dynamic MCC, it is equivalent to the name of the submerchant.	< 18 AN	YES
additional_data	Element for sending additional data.
`mcc`	Submerchant's MCC.	= 4 N	YES
`subacquirer_merchant_id`	Submerchant's code. Deprecated field!!! Use `additional_data.subacquirer_merchant.id` instead.	< 15 N	NO
additional_data.subacquirer_merchant	Element for sending data related to a subacquirer's merchant.
`id`	Submerchant's code.	< 15 N	YES
`address`	Submerchant's address.	< 48 AN	NO
`city`	Submerchant's city.	< 13 AN	NO
`state`	Submerchant's state, in two-digit acronym format (e.g.: SP).	= 2 A	YES
`country`	Submerchant's country. Follow the standard ISO 3166-1 alpha-2 (e.g.: BR).	= 2 A	YES
`zip_code`	Submerchant's zip code.	< 9 AN	YES
`identification_number`	Submerchant's CNPJ.	< 18 N	YES
`payment_facilitator_id`	Facilitator's code.	< 11 N	YES
`independent_sales_organization_id`	Independent sales organization code.	< 11 N	NO

Example

Request:

curl
--request POST "https://esitef-homologacao.softwareexpress.com.br/e-sitef/api/v1/transactions"
--header "Content-Type: application/json"
--header "merchant_id: xxxxxxxx"
--header "merchant_key: xxxxxxxxxxx"
--data-binary
{
    "merchant_usn": "21042858195",
    "order_id": "21042858195",
    "amount": "102",
    "installments": "1",
    "installment_type": "4",
    "mcc": "1111",
    "soft_descriptor": "LOJADOZE",
    "additional_data": {
         "subacquirer_merchant": {
            "id": "1234567890",
            "address": "Rua Acre",
            "city": "CAPIVARI",
            "state": "SP",
            "country": "BR",
            "zip_code": "07064-010",
            "identification_number": "71.789.371/0001-42",
            "payment_facilitator_id": "22349202212",
            "independent_sales_organization_id": "1234567"
        }
    }
}

Response:

{
    "code": "0",
    "message": "OK. Transaction successful.",
    "pre_authorization": {
        "status": "NOV",
        "nit": "c2d2887a2961a218e6e6effa8a39f281d386d581c8c8b4dc23a3af03b5c6b8c4",
        "order_id": "21042858195",
        "merchant_usn": "21042858195",
        "amount": "102"
    }
}

Payment and Pre-Authorization REST effectuation service

In addition to the fields mentioned in REST Payment effectuation service and REST Pre-Authorization effectuation service, the fields below are used specifically in dynamic MCC transactions integrated to the e.Rede REST routing:

Parameter	Description	Format	Mandatory
`soft_descriptor`	Personalized phrase that will be printed on the bearer's invoice. For information regarding the dynamic MCC, it is equivalent to the name of the submerchant. Required only if it was not sent in the `soft_descriptor` of the transaction initialization step.	< 18 AN	YES
`mcc`	Submerchant's MCC. Required only if it was not sent in the `additional_data.mcc` of the transaction initialization step.	= 4 N	YES
`subacquirer_merchant_id`	Submerchant's code. Required only if it was not sent in the `additional_data.subacquirer_merchant.id` of the transaction initialization step.	< 15 N	NO

ATTENTION!

It is in the transaction effectuation step that we send the accumulated dynamic MCC data. However, if the mcc field is not sent at any time and is not registered, the other dynamic MCC fields will not be passed on. This field is necessary to identify that the merchant wants to send sub-acquisition data.

Example

Request:

curl
--request POST "https://esitef-homologacao.softwareexpress.com.br/e-sitef/api/v1/preauthorizations/1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqr"
--header "Content-Type: application/json"
--header "merchant_id: xxxxxxxx"
--header "merchant_key: xxxxxxxxxxx"
--data-binary
{
    "authorizer_id":"2",
    "installments":"1",
    "installment_type":"4",
    "soft_descriptor":"outraloja",
    "mcc": "2234",
    "subacquirer_merchant_id": "223456",
    "card":{
        "number":"5448280000000007",
        "expiry_date":"0121",
        "security_code":"123"
    }
}

Response:

{
    "code":"0",
    "message":"OK. Transaction successful.",
    "pre_authorization":{
        "authorizer_code":"000",
        "authorizer_message":"Transacao OK.",
        "status":"CON",
        "nit":"1234567890abcdefghijklmnopqrstuvwxyz1234567890abcdefghijklmnopqr",
        "customer_receipt":"=== CUSTOMER RECEIPT ===",
        "merchant_receipt":"=== MERCHANT RECEIPT ===",                
        "authorizer_id":"2",
        "authorizer_date":"09/11/2018T19:40",
        "acquirer_id":"1005",
        "acquirer_name":"Redecard",
        "authorization_number":"013245",
        "merchant_usn":"20190101",
        "esitef_usn":"181109017689784",
        "order_id":"orderID",
        "sitef_usn":"212194",
        "host_usn":"999212194",
        "amount":"100",
        "issuer":"2",
        "payment_type":"C",
        "authorizer_merchant_id":"000000000000000"
    }
}

Fields conversion table

The conversion table between e.Rede REST fields and e-SiTef fields is presented below.

e.Rede REST field	e-SiTef field	Observations
softDescriptor	soft_descriptor	The e.Rede REST softDescriptor field can be sent in the transaction creation request, REST payment or pre-authorization effectuation request or be registered by the e-SiTef Support Team.
PaymentFacilitatorID	additional_data / subacquirer_merchant / payment_facilitator_id or paymentFacilitatorId	The e.Rede REST PaymentFacilitatorID field can be sent in the transaction creation request or configured when the user defines a routing using e.Rede REST. In the latter case, this field can be edited in the Merchant Portal ("Autorizadoras" > "Configurar Autorizadoras") or by sending a request to the e-SiTef Support Team.
IndependentSalesOrganizationID	additional_data / subacquirer_merchant / independent_sales_organization_id or independentSalesOrganizationId	The e.Rede REST IndependentSalesOrganizationID field can be sent in the transaction creation request or configured when the user defines a routing using e.Rede REST. In the latter case, this field can be edited in the Merchant Portal ("Autorizadoras" > "Configurar Autorizadoras") or by sending a request to the e-SiTef Support Team.
SubMerchant / MCC	additional_data / mcc or mcc	The e.Rede REST SubMerchant / MCC field can be sent in the transaction creation request, REST payment or pre-authorization effectuation request or be registered by the e-SiTef Support Team.
SubMerchant / SubMerchantID	additional_data / subacquirer_merchant_id or additional_data / subacquirer_merchant / id or subacquirer_merchant_id or subacquirerMerchantId	The e.Rede REST SubMerchant / SubMerchantID field can be sent in the transaction creation request, REST payment or pre-authorization effectuation request or configured when the user defines a routing using e.Rede REST. In the latter case, this field can be edited in the Merchant Portal ("Autorizadoras" > "Configurar Autorizadoras") or by sending a request to the e-SiTef Support Team.
SubMerchant / Address	additional_data / subacquirer_merchant / address	The e.Rede REST SubMerchant / Address field can be sent in the transaction creation.It is possible to register a default value. Contact the e-SiTef Support Team to register or change the default value of this field in your store.
SubMerchant / City	additional_data / subacquirer_merchant / city	The e.Rede REST SubMerchant / City field can be sent in the transaction creation. Contact the e-SiTef Support Team to register or change the default value of this field in your store.
SubMerchant / State	additional_data / subacquirer_merchant / state	The e.Rede REST SubMerchant / State field can be sent in the transaction creation. Contact the e-SiTef Support Team to register or change the default value of this field in your store.
SubMerchant / Country	additional_data / subacquirer_merchant / country	The e.Rede REST SubMerchant / Country field can be sent in the transaction creation. Contact the e-SiTef Support Team to register or change the default value of this field in your store.
SubMerchant / CEP	additional_data / subacquirer_merchant / zip_code	The e.Rede REST SubMerchant / CEP field can be sent in the transaction creation. Contact the e-SiTef Support Team to register or change the default value of this field in your store.
SubMerchant / Cnpj	additional_data / subacquirer_merchant / identification_number	The e.Rede REST SubMerchant / Cnpj field can be sent in the transaction creation. Contact the e-SiTef Support Team to register or change the default value of this field in your store.

ATTENTION!

When a field can be sent in more than one way, the most recent or the most specific field value will have precedence. In other words, priority follows the rule: most recent > most specific > registration data.

Example: If the SubMerchant / SubMerchantID field is sent in the effectuation step, it will have priority over the one sent at the initialization step, which has priority over the registration field.