060614 Integration Guide E-Rede v5

Manual for

Integration to e-Rede

estamos todos ligados

01

02

03con

ten

ts

Click on the hyperlinks to navigate the material in the Manual for Integration to e-Rede.

Introduction to the guide 7 Scope 7 Support 8

Related Documentation 8

Overview of business integration 9

Introduction 9 Connectivity in e-Rede 10

SSL Technology 11

Overview of the integration of merchants 12

Integration and communication methods 12

Hosting by the Server method 13 Considerations about using the Hosting by the Server method 14 The Hosting by the Merchant method 14 Considerations about using the Hosting by the Merchant method 15 Considerations for the combination of payments hosted by the server and by the merchants 15 Comparison between the Hosting by the Server method and the Hosting by the Merchant method 16

Processing methods 20

One-step processing 20

Two-step processing 20

Types of transactions 22

Origin of the merchant’s transactions 24 Transaction frequency of merchants - Recurring Payment 25

Steps for integration to e-Rede 26

1.1

2.1

3.13.2

3.3

3.2.1

3.3.1

3.3.2

3.3.3

3.43.4.13.4.2

2.22.3

1.21.3

3.53.63.7

3.8

04


Gather information and supporting documentation 26

Choose an integration method 26 Determine any feature regarding Optional Mandatory Payment 26

Get an account password 27

Determine the input and output field 27

Enable integration of the application 28

Integration test 28

Configure in production mode 28

Guidelines for integration to e-Rede 29

Querying transactions 30

Best practice guidelines for payments 30

Website security 30

Payment guarantee before shipping 30

Troubleshooting 31

Time limits for sessions 31

Integration of the payments hosted by merchants 32

Stages of information flow 32

Card holder’s interface 33

Tests 33

Integration of the payments hosted by the server 34

Personalized Interface 34

Standard Interface 35

Use of iFrames 35

Stages of information flow 35

Tests 36

3.8.13.8.23.8.3

3.8.43.8.53.8.63.8.73.8.8

3.93.103.11

3.12

4.1

4.24.1.1

3.11.1

3.12.1

3.11.2

055.15.25.35.45.5

con

ten

ts

Protection of payment transations 37

Authentication of 3-D Secure payments 37 Summary of 3-D Secure transactions for Hosting by the Merchant 37 Summary of 3-D Secure transactions for Hosting by the Server 37

Address Verification Service (AVS) 39

Card Security Code (CSC) 40

Transaction integrity 41 Using a unique transaction reference from the Merchant for transaction attempts 41 Checking that the values of the response fields correspond to the values of the request 42

Storing the card numbers securely 42

Fraud management 43

Supplementary resources of the transactions 44

vTID configuration 44

Token Generation Service 45

Introduction 45

Generating Tokens 46

Requirements 46

Token format 46

Generating Tokens 46

Use of Tokens 47

Payment transactions that use tokens 47

Other uses 47

Querying transactions 47

Transactions involving instalments 48

Elements of the Request 48

06

0708

6.1

6.26.36.4

6.5

7.1

8.18.2

6.1.1

6.1.2

6.4.1

6.4.2

6.4.3

09

8.2.1

8.3.1

8.4.1

8.2.28.2.3

8.3

8.4

9.1


con

ten

ts

Overview of the technical integration 51

Introduction 51

About the XML Request 51

About the XML Response 51

Integration with e-Rede 51

The XML Request 52

The XML Response 53

Failure scenarios 54

Other considerations 55

Transport layer 55

Authentication of the merchants 55

Messages 55

Overview of the tests 56

Overview 56

Electronic Statement 57

File of multibrand credit sales 58

Record 033 - Request (e-Rede) 58

Record 034 - Revolving CV/NSU (e-Rede) 59

Record 35 - CV/NSU in instalments without interest (e-Rede) 60

Record 36 - CV/NSU in IATA instalments (e-Rede) 61

Record 37 - CV/NSU in Dollars (e-Rede) 62

Types of Capture 63

Table of Adjustments 63

File of multibrand debit sales 64 Record 13 - Details of the sales receipts (e-Rede) 64 Record 14 - Unscheduling of predated sales (total and partial) - e-Rede 65

Record 015 - Cleared predated e-Rede transactions 66 Record 16 - Uncleared predated transactions (distributor) 67

10

1112

10.1

10.2

10.310.4

11.1

12.1

10.1.1

10.2.110.2.2

10.4.110.4.210.4.3

10.1.2

12.1.112.1.212.1.312.1.412.1.512.1.612.1.7

12.212.2.112.2.2

12.2.3


con

ten

ts

12.2.4

Record 17 - Net Adjustment (e-Rede) 68

Record 18 - Request 69

Types of Capture 69


Multibrand financial file 70

Record 053 - Net Adjustments and Unscheduling 71

Record 54 - Debit adjustments (via bank) - e-Rede 72

Record 55 - Pending e-Rede debits 73

Record 056 - Cleared e-Rede debits 74

Record 057 - Unscheduling of instalments (e-Rede) 75

New Records 76


Glossary 8113

12.2.512.2.612.2.712.2.8

12.312.3.112.3.212.3.312.3.412.3.5

12.412.5


con

ten

ts

7Manual for Integration to e-Rede

Contents

01 Introduction to the guide

Rede’s new online payment solution, known as “e-Rede”, offers the best Internet sales solution for its clients, by focusing its strategy on the excellence of the forms of payment and an advanced fraud prevention system. A complete and robust solution for all kinds of merchants, with new services and applications.

The product offers different solutions on a single platform. Thus, upon adopting Rede’s solution, instead of hiring multiple providers, the merchant will have available a single system that enables access to various forms of payment, credit and debit cards, bank payment slips, an anti-fraud system, new features, and management of the operations.

With this integration guide you can develop:

•TransactionTypes •SecurityFeatures •Meansforcapturingtransactions •Configurationsforaccessdata

1.1 Scope


Contents

For assistance or information related to the services of e-Rede, merchants should contact our customer service by phone:

Capitals and Metropolitan Regions4001 4433

Other locations0800 728 4433

The following publications contain material directly related to this document.

1.2

1.3

Support

Related Documentation

Reference Description

e-Rede Developers’ Reference GuideTechnical reference from the developers to integrate e-Rede to the API.

Appendix 1 - 3DSTechnical reference for the integration of 3-D Secure transactions.

Appendix 2 - Recurring PaymentTechnical reference for the integration of recurring payment transactions.

Appendix 7 - Record of airline transactionsTechnical reference for the integration of additional information from the transaction records of airlines (e.g., details of the airlines, flights, and passengers).

Appendix 17 - Anti-fraud moduleTechnical reference for the integration of transaction classifications and the risk management services of e-Rede.

Appendix 24 - Bank payment slipsTechnical reference for the generation of bank payment slips by e-Rede.

Manual for interface integrationTechnical reference for the integration of the Standard and Personalized Interfaces.


Contents

02 Overviewofbusinessintegration

The purpose of this section is to explain the features of the e-Rede system and how the website of a merchant can interact with these features.

When used with the Hosting by the Server method, e-Rede also greatly reduces efforts to comply with the Payment Card Industry Data Security Standard (PCI DSS) - see Glossary - thus eliminating the need for merchants to control and safely store sensitive card data.

Hosting by the Server refers to an integration method in which e-Rede manages the interaction of the screen with the cardholder for the purpose of collecting the card details.

The other operation method is Hosting by the Merchant, in which the merchant’s website does not direct the cardholder to be managed by e-Rede. Instead, the merchant is responsible for collecting card data and transferring it to e-Rede. To use this method, the merchant must satisfy the additional requirements for compliance with the PCI DSS.

2.1 Introduction


Contents

In order for merchants already accredited in the network, as well as new ones to also connect to e-Rede, there are some important steps to be followed.

During the merchant’s first contact, a pre-registration is done. We will send an e-mail with the password for access to Rede’s website and with this the merchant can access the services on the site and change the password to a permanent one which will be used for future access.

The merchant awaits receipt of the password for testing on e-Rede. Both for the first contact and in the email in which we send the test password, the merchant will be informed that some necessary items must be arranged in order to be approved and to receive a production password to transact with Rede. These necessary items include:

•PossessionofanSSLSecurityCertificate;

•Beingreadywithyoursite,withapurchasingenvironmentthatisalreadycertified,sothatwecanperformanaccesstest.

To request approval, the merchant will be contacted by Rede (via email) stating that the process is now available for its site.

When the merchant enters in contact with Rede, if the above-mentioned items are not all ready, approval is not confirmed. Therefore, the missing items must be arranged before contacting us. After approval testing, the merchant receives its production password and must access Rede’s website and, in the tab e-Rede > Settings (Configurações), include the Call Back URL, the IPs, and the settings required for the AVS, bank payment slip, etc., depending on which services will be used.

2.2 connectivity in e-Rede


Contents

A merchant that receives and transmits the data of card holders and transactions through a web application must securely protect this information as it travels between the cardholder’s browser, the merchant’s application, and e-Rede’s Server.

The merchant’s application must use the Secure Sockets Layer (SSL) technology to provide the necessary security and encryption to transmit sensitive cardholder and transaction information.

It is also recommended that a merchant use a secure method to receive the data of cardholders. The e-Rede Server uses SSL to encrypt the details of the cardholder and other sensitive details of transactions, as well as providing secure transmission to the cardholders when the merchants use the Hosting by the Server integration method.

When the cardholder’s browser connects to the application of the merchant using SSL, the address prefix of the website is changed to https://,and an indication is displayed in the address bar of the browser informing that the communication is encrypted and secure.

2.3 SSLTechnology


Contents

03 Overviewoftheintegrationofthemerchants

e-Rede has 3 forms of integration:

Simplified - The transaction takes place on the Rede site via login and password. It is the method in which the customer has no development and uses all the technology of Rede. It is used by small and medium-sized merchants that want to accept payments online but do not have a shopping site - in this case the Rede website functions as a virtual POS, generally used by Dentists/Doctors, travel agencies, or even storefront websites in which the consumer verifies the product and enters into contact with the merchant’s call center.

Integrated - The transaction is carried out on the merchant’s site which can use the Standard or Personalized (we will discuss this in the appropriate topic) Interfaces.

Webservice(APINetwork) - More robust solution in which the merchant’s server directly connects with Rede’s server.

3.1 Methodsofintegrationandcommunication


Contents

This method involves the merchant, cardholders, and e-Rede, and allows e-Rede to control the payment pages and safely receive and process the cardholder’s details on behalf of the merchant.

The merchant redirects the cardholder to e-Rede for him to insert the card details. The cardholder is redirected to the merchant who, in turn, sends a Transaction Query to e-Rede, in order to obtain the result of the transaction.

As an alternative to the redirection model, the secure page for entering the card data can be displayed as an iFrame. A standard page template is available for merchants.

The method of Hosting by the Server is only used for internet-based payment applications which involve a browser.

There are two methods of implementing Hosting by the Server:

•Captureofhostedcards(PersonalizedInterface) - The merchant manages the flow of XML requests to e-Rede for authorization of transactions.

•Hostedpages(StandardInterface) - e-Rede manages the transaction authorization processes.

Refer to Section 5, Integration of the Payments Hosted by the Server.

3.2 HostingbytheServermethod


Contents

ConsiderationsaboutusingtheHostingbytheServermethod

TheHostingbytheMerchantmethod

Merchants must use this method when:

•Theywante-RedetocollectthedetailsofthecardholderandwishtosimplifythecompliancewiththePCIDSSrequirements.

•Theyareonlyintegratingabrowser-basedapplication.Thismethodcannotbeusedforothercallcentersorotherapplications.

The cardholder’s browser can be redirected from the merchant’s website to e-Rede.

Note: This occurs if you are using the iFrame method.

This method involves the merchant and e-Rede and is used by merchants who wish to control the transaction process, communicate directly, and manage their own payment pages. They must also safely collect the details of the cardholders.

The merchant’s application communicates directly with e-Rede and, therefore, the cardholder does not need to leave the merchant’s website and the session is not divided.

Refer to Section 4, Integration of the Payments Hosted by Merchants.

3.2.1

3.3


Contents

ConsiderationsaboutusingtheHostingbytheMerchantmethod

Considerationsforthecombinationofpaymentshostedbytheserverandbythemerchants

Merchants must use this method when:

• TheywillcollectthedetailsofthecardholdersandfulfilltherequirementsforcompliancewiththePCIDSS.

• Theyneedtousefunctionssuchascapture,cancellations/reversals,orqueries,whichdonotincludedatafromthecards used in the transaction.

• Theydonotwantthecardholder’sbrowsertoberedirectedfromthemerchant’swebsitetoe-Rede,ordonotwishtouseiFrameforprocessingpayments.

Merchants must use a combination of the methods of Hosting by the Server and Hosting by the Merchant when:

• TheyusethemethodofHostingbytheServerfortheirInternetpaymentsandtheHostingbytheMerchantmethodfortheircallcenterorotherpaymentapplications.

• TheywanttousetheHostingbytheServermethodforpaymenttransactionsandtheHostingbytheMerchantmethodforothertransactions,suchascancellations/reversals,queries,etc.

3.3.1

3.3.2


Contents

ComparisonbetweentheHostingbytheServermethodandtheHostingbytheMerchantmethod

3.3.3

The merchant manages the flow of XML transaction authorization requests and 3-D Secure authentication. The merchant requests a session ID and a URL to redirect the cardholder to the Personalized Interface, in order to capture the card details and then complete the transaction.

The Personalized Interface allows the use of dynamic fields to capture additional information from the cardholders.

e-Rede manages the 3-D Secure authentication processes and the authorization of transactions. The merchant requests a page from the Standard Interface which contains all the payment elements, except the card details. This displays a session ID, a URL to display the capture page of the Standard Interface for the cardholder to enter the card details.

e-Rede sends the transaction for authentication and authorization.

The Standard Interface doesn’t allow dynamic capture fields.

The merchant displays the page for capturing payment details and controls the 3-D Secure processes and authorization of transactions.

The cardholder does not leave the merchant’s website.

The following is a comparison of the two methods:

Hostingbytheserver Hostingbythemerchant

Captureofhostedcards(PersonalizedInterface)

Hostedpages(StandardInterface)

Pageshostedbythemerchant

summary

(continued)


Contents

There are up to nine dynamic capture fields available for viewing on the capture page.

These fields are used to capture additional cardholder information, which is displayed as part of the query transaction.

Dynamic capture fields are not available.

Dynamic capture fields are not available.

Identification of the type of card is available to determine the card’s emblem beforethe authorization process.

The identification of the type of card is available for limited use after the authorization process.

The identification of the type of card is available for limited use after the authorization process.

The merchant controls the authorization process by managing the flow of XML requests to e-Rede.

e-Rede manages the authorization processes.

The merchant controls the authorization process.

(continued)





DataCapture


Contents

When a card transactionis processed, the following actions are performed, with each one of them executing a call to e-Rede:

When a card transactionis processed, the actions are similar to those of the Personalized Interface; however, fewer calls are made to e-Rede.

There is no configuration of e-Rede sessions and the cardholder does not leave the merchant’s website.

1.ConfiguringasessionofthePersonalizedInterface:

i)The merchant sends a simple XML request, which displays a session ID and a URL.

ii)The session ID, along with the URL, allows the merchant to direct the cardholder to the Personalized Interface page (using the method implemented by the merchant - iFrame or redirecting), in which the card details are entered, captured, and stored by e-Rede for 10 minutes.

The gateway_reference element can be used to control the data provided.

iii)Once the data is submitted, the cardholder is redirected to the merchant’s website to complete the transaction by sending an XML authorization request.

Throughout this process, the cardholder does not need to leave the merchant’s website.

1.ConfiguringasessionoftheStandardInterfaceandProcessingtheTransaction:

i)The merchant sends an XML request to a capture page of the Standard Interface. The request contains all the elements of the payment, except the card details. During this stage, the merchant must enter the value, currency, type of transaction, and, optionally, information about risk/fraud. This displays a session ID, a URL, and the gateway_refence.

ii)The session ID, along with the URL, allows the merchant to display the capture page of the Standard interface to the cardholder (using the method implemented by the merchant - iFrame or redirecting). The card details are entered, captured, and sent to e-Rede for authorization and completion of the transaction.

The gateway_refence element can be used to control the data provided.

1.Transactionprocessing:

i)The merchant displays the capture page (which is hosted on its own server) to the cardholder. The payment details are entered and sent to e-Rede for authorization and transaction completion.

The gateway_reference element can be used to control the data provided.

(continued)





Flowofpayments


Contents

2.Queryingthecaptureddata:

This is an optional request to check if the details of the card were captured correctly. The response to this request will also include the card’s emblem, country of issue, expiry date, card issuer, and the masked PAN (card number), whenever applicable.

2.Queryingthecaptureddata:

This is an optional request - available to the merchant the moment that the cardholder returns to its website - to verify if the card details were captured correctly and the result ofthe authorization request.

The response to this request will also include the emblem of the card, the transaction authorization data, issuing country, expiry date, card issuer, and the masked PAN (card number), whenever applicable.

2.Queryingthecaptureddata: There is no card capture for the Hosting by the Merchant.The transaction query will only display the result of the transaction.

3.Processingatransaction:

In this phase, the merchant can send a card transaction to e-Rede (mentioning the captured details supplied from step 1 of the authorization request) instead of the PAN (card number).

After this step, the transaction is completed.


Contents

Processingmethod

One-stepprocessing

This is a method of processing in which it is necessary to conduct only one transaction to complete the payment. For processing credit and debit cards, the most common example is the “auth” type of transaction.

The situations in which this method is suitable are:

• Instantaccessservicessuchassoftwaredownloads;

• Thesaleofphysicalgoodsthatwillbeshippedonthesameday.

The type of transaction that may be used with the one-step method is:

3.43.4.1

Typeoftransaction Uses

auth Request authorization to debit the card and, if approved, start the payment from the cardholder to the merchant.


Contents

Two-stepprocessing

This is a processing method in which it is necessary to make two separate transactions to complete processing. For processing credit and debit cards, the most common example is the “pre” transaction to perform the authorization, followed by a “fulfill” transaction for settlement.

The situations in which this model is appropriate are:

• Itemsorderedthatarenotavailabletoshipatthetime;

•Whenitisnecessarytoperformadditionalinternalprocessespriortosettlement.

The types of transactions that can be used with the two-step model are:

The card details are only needed for the “pre” type of transaction. They are not required to complete the transaction.

Typeoftransaction Uses

pre (pre-authorization) Reserves funds on the card, but does not debit or settle the transaction until a valid “fulfill” request is received.

fulfill Begins the settlement of a valid “pre” transaction to conclude the process in two steps.

3.4.2


Contents

Typesoftransactions

The following displays a complete list of transaction types:

3.5

Typeoftransaction

Typeofe-Redetransaction Description

Authorization authRequests authorization to debit the card and settle the transaction pursuant to the merchant’s agreement.

Authorization pre

The first phase of a two-step ”auth” transaction for a credit card.

A successful “pre” transaction verifies the card details and reserves funds for the subsequent “fulfill”. It also allows merchants to perform any fraud services for which they are configured.

The funds of a “pre” are not settled immediately. To settle the transaction, a valid “fulfill” request must be sent to e-Rede.

Capture fulfill

Allows a merchant that uses two-step processing to confirm the earlier “pre” transaction to attend the client’s order.

A merchant that uses this mode performs two transactions to settle the amounts in its bank account.

The first “pre” transaction reserves the amount in the credit card holder’s account.

The second transaction (fulfill) transfers this amount from the card’s account to the merchant’s account.

There are two ways to confirm a “pre” transaction:

1. Manually, through Rede’s web services. This is more suitable for small volumes of transactions.

2. Using the “fulfill” command to directly perform the confirmation transactions, using the merchant’s internal management system.

(continued)


Contents

Reversal of capture

cancel

Allows merchants to cancel a previous “fulfill” transaction in the two-step processing mode. A “cancel” transaction must only be done on the same day that the “fulfill” was effected.

This command cannot be used by merchants that operate in one-step processing mode.

Only one “cancel” transaction can be made in relation to the original “fulfill” transaction, since this function removes the “fulfill” transaction; that is, only the transaction which had the “fulfill” on the date of the cancel may be altered.

This function must be enabled for the merchant in its account profile.

There are two ways of carrying out a “cancel” transaction in relation to a “fulfill” transaction:

1. Manually, through Rede’s website. This is more suitable for small volumes of transactions.

2. Using the “cancel” command to directly perform the reversal of a “fulfill” transaction, using the merchant’s internal management system.

Typeoftransaction

Typeofe-Redetransaction Description

Chargeback cancel

Allows merchants to reverse a previous “auth” transaction. A “cancel” transaction must only be performed on the same day that the “auth” was effected.

A “cancel” transaction can be only performed in relation to the original “auth” transaction, since this function removes the “auth” transaction. Only the transaction that had the “auth” on the same day of the “cancel” can be altered.

This feature must be enabled for the merchant in its account profile.

There are two ways to carry out a “cancel” transaction in relation to an “auth” transaction:

1. Manually, through Rede’s website. This is more suitable for small volumes of transactions.

2. Using the “cancel” command to directly perform the cancelation of an “auth” transaction, using the merchant’s internal management system.

Querying transactions

queryEnables recovery of details of a previous transaction, by sending a request to e-Rede.


Contents

Originofthemerchant’stransactions

The origin of the merchant transaction feature allows a merchant to indicate the origin of a transaction hosted by it, as follows:

• e-Commerce

If this field is not filled in, the default value, which is set in the merchant’s account profile, will be used.

3.6


Contents

Transactionfrequencyofmerchants-RecurringPayment

In addition to single operations (i.e., a transaction in which a single payment is used to complete the cardholder’s order), e-Rede can also process Recurring Payments.Merchants need to have an ID that is enabled for processing repeated transactions, as well as the appropriate privileges, to effect repeated card payments.

• ScheduledRecurringPayments - The merchants set up a plan of Recurring Payments with an instruction, and e-Rede manages all subsequent transactions. Recurring Payments are suitable when the instalments have fixed values, although the first and last payment may vary. For example, a subscription TV service can bill regular payments over 36 months, according to a fixed payment plan.

•HistoricalRecurringPayments - Merchants send a request to setup a recurring transaction, with the initial transaction made by card. Then, the subsequent transactions will be sent, thus allowing the merchant to launch all payments with the account number generated for the card. The amount and frequency of each instalment may vary. For example, a music download site can bill in accordance with the songs that are purchased, regardless of the amount.

3.7


Contents

Stepsforintegrationtoe-Rede

Merchants need to perform the following steps to complete the integration to e-Rede.

GatherinformationandsupportingdocumentationMerchants need:

•GuideforIntegrationofMerchantstoe-Rede•Samplecodefortheirwebsite(writteninASP,.Net2008or.Net2010)

choose an integration methodMerchants choose between:

• TheHostingbytheServermethod•TheHostingbytheMerchantmethod•Acombinationofthetwomethods

DetermineanyfeatureregardingOptionalMandatoryPaymentThe optional features include:

•Authenticationof3-DSecurecardholders(e.g.,MasterCard®SecureCode™,VerifiedbyVisa™).• Two-stepprocessing-separate“pre”and“fulfill”transaction.• “Fulfill”reversaltransaction•Authorizationreversaltransaction•Recurringtransactions•GeneratingTokens•AVS•CSC•Riskandfraudservices

3.8

3.8.1

3.8.2

3.8.3


Contents

3.8.4

3.8.5

Getanaccountpassword

When the merchant account is set up, it is also provided with a password. The password is valid for a maximum of 12 months and the merchant is responsible for changing it whenever an individual leaves its organization.

Determinetheinputandoutputfields

Merchants need to determine how to obtain the input fields from XML Requests and where to store them in the output fields of the XML Responses of their applications.

Some considerations:

• Sessionvariables - When using the Hosting by the Server method (with or without card details), some applications may require the collection of session variables and for them to be sent to e-Rede via the XML Request. The session variables are displayed in the XML Response, thus allowing the application to continue with the order process using the same session.

•Merchant’stransactionreference(merchant_reference) - Merchants need to determine how to produce a single value for a transaction using the “Merchant reference” field.


Contents

3.8.6

3.8.7

3.8.8

Enableintegrationoftheapplication

To enable the integration of the application, merchants usually need a web developer familiar with the application and the programming language being used.This guide, along with the code examples and the e-Rede Developers’ Reference Guide, provides information and best practice guidelines to make the task easier.

Integration test

Merchants test their integration by performing integration tests in the e-Rede test environment. They need to test all the response codes that are likely to be found in production.To access the test environment, use the following URL:

https://scommerce.userede.com.br/Beta/wsTransaction

Configureinproductionmode

After completing the tests to confirm that the merchant’s integration is working properly, the merchant needs to let e-Rede know that it can validate the test results and provide the merchant with a production password and instructions on how to change from the test mode to production mode. This will allow the merchant to begin performing real transactions.

https://ecommerce.userede.com.br/Transaction/wsTransaction


Contents

Guidelinesforintegrationtoe-Rede

Merchants need to understand the transaction reference field (merchant_reference) when integrating their payment application.

The merchant_reference field is a unique identifier assigned by the merchant to each transaction. This unique value is used by the merchant to query e-Rede’s database and retrieve a copy of a lost/missing transaction receipt, through the use of a function that queries transactions hosted by merchants.

Merchants can use a value like an order number or invoice number as the merchant_reference. To allow cardholders to repeat a rejected transaction and maintain the same order number or invoice number, the merchant_reference must be modified by attaching extra characters to each subsequent attempt (e.g., merchant_reference = “00789/1” on the first attempt, “00789/2” on the second attempt , “00789/3” on the third attempt, etc.).

In the event of a failure (e.g., if the XML Response does not reach the merchant’s website due to a communication error), the merchant may need to check if the operation was successful. The use of a single merchant_reference facilitates cross-referencing of the transaction data when conducting a transaction query. If each transaction attempt does not receive a unique merchant_reference number, the transaction query command may not display the correct transaction attempt that is being searched, because it only displays the most recent transaction.

3.9


Contents

Querying transactions

Bestpracticeguidelinesforpayments

The transaction query command allows merchants to search a transaction via the transaction ID key (gateway_reference) or merchant reference, so that these fields contain a single value.

If the transaction query finds a transaction, the results will contain the same fields as the original transaction.

If there are multiple transactions that match the search criteria (e.g., if the merchant_reference assigned by the merchant is not unique), only the most recent transaction will be displayed.

Websitesecurity

Merchants must guarantee that their web environment maintains adequate security and complies with PCI DSS guidelines.

Paymentguaranteebeforeshipping

Merchants need to guarantee the integrity of the responses and the identification and authentication of e-Rede during the payment process.

Whenever possible, it is necessary to implement the following services: 3-D Secure of MasterCard® SecureCode™, and Verified by Visa™.

3.10

3.113.11.1

3.11.2


Contents

Troubleshooting

This section contains suggestions and solutions to problems that may occur during the integration of e-Rede.

Timelimitsforsessions

The time limit for current payments hosted by the server is set at 15 minutes.

A current session may shut down (e.g., due to a communication failure) while a cardholder is entering the card details in e-Rede. If the cardholder returns to the merchant’s website, this will occur in a new session - the old session will not be completed.

To determine the status of the lost transaction, the merchant needs to do a transaction query based on the merchant_reference.

3.12

3.12.1


Contents

04 IntegrationofthepaymentshostedbymerchantsFor merchant-hosted payments, the cardholder places an order and provides the card details (number, CVC, and expiry date) to the merchant.

The merchant assumes the higher risk responsibilities related to the protection of cardholder details.

The stages of the information flow for the Merchant Hosting are:

1. The merchant’s application collects the details of the cardholder’s order.

2. The cardholder makes a purchase and provides the card’s details directly to the merchant’s online store.

3. The merchant’s application prepares the XML request and sends it to e-Rede using HTTPS POST.

4. e-Rede transfers the transaction to the card issuer for authorization.

5. After processing, e-Rede generates an XML response and returns it to the merchant’s application. The XML Response indicates whether the transaction was approved or rejected. The results must be stored by the merchant for future reference.

6. A receipt is displayed by the merchant for the cardholder.

4.1 Stagesofinformationflow


Contents

tests

Cardholder’sinterface

With the payments hosted by the merchant, the integration captures the details of the cardholder and presents a receipt after the transaction is processed by e-Rede.

The following pages are displayed to the cardholder on the merchant’s website:

• Thecheckoutpageofthemerchant’sapplicationiscreatedaspartoftheapplicationanddisplaystheitemsselectedforpurchasebythecardholder,includingthetotalamounttobepaidandanytaxesordeliverycharges.Thecardholderacceptsthecheckoutdetailsandthepaymentamountandentersthecard details.

• Thereceiptpageofthemerchant’sapplicationconfirmspaymentapprovalanddisplaysdetailsoftheitemspurchased.Generally,thispageprovidesaprintoption.

Merchants must meet the e-Rede test requirements prior to activation.

Complete tests, including tests for error conditions, are fundamental.

4.2

4.1.1


Contents

05 IntegrationofthepaymentshostedbytheserverThe Hosting by the Server payment method manages the payment pages and collects the details of the cardholder on behalf of the merchant.

The cardholder’s browser redirects the access to e-Rede in order to process the transaction.

Then, the cardholder’s browser is directed to a web page indicated by the merchant in the transaction, together with an XML Response. The merchant sends a transaction query to e-Rede in order to obtain the results of the transaction.

PersonalizedInterface

The merchant manages the flow of XML requests to e-Rede for transaction authorizations.

First, the merchant sends a simple XML Request, which displays a session ID and a URL. Together, the session ID and the URL allow the merchant to redirect the cardholder to the page with the Personalized Interface for capture of card details, and, then complete the transaction.

The Personalized Interface allows the use of dynamic fields to capture additional information from the cardholders.

5.1


Contents

StandardInterface

e-Rede manages the processes of transaction authorization.The merchant sends an XML request to a Standard Interface page that contains all the payment elements, except the card details. It displays a session ID and a URL, allowing the merchant to display the capture page of the Standard Interface to the cardholder for the entry of card details which, in turn, is sent for authentication and authorization by e-Rede.

The Standard Interface does not allow dynamic capture fields.

UseofiFrames

The secure page for entering the card data can be displayed as an iFrame. A standard page template is available for merchants.

Stagesofinformationflow

The stages of information flow for the Hosting by the Server method are:

1. The cardholder makes a purchase and provides shipping details to the merchant’s online store.

2. The cardholder clicks a “pay” or “complete purchase” button and the online store redirects the cardholder’s browser to e-Rede.

3. e-Rede displays screens to request the details of the card and the payment.

5.2

5.3

5.4


Contents

4. The payment details are then transferred to the issuer to process the transaction and, then, the result of the transaction is displayed - a receipt number if the transaction is successful, or a message requesting the proper information, if it is rejected.

5. e-Rede redirects the cardholder to the merchant’s website. The merchant sends a transaction query to e-Rede to obtain the results of this transaction.

6. The online store interprets the response, displays the receipt, and confirms the order with the cardholder.

tests

Merchants must meet e-Rede’s test requirements before activation.

The complete tests, including tests for error conditions, are fundamental.

5.5


Contents

06 Protectionofpaymenttransactions

This section discusses the security features of the payments.

Authenticationof3-DSecurepayments

The 3-D Secure security protocol is used for MasterCard® SecureCode™, and Verified by Visa™ to reduce credit and debit card fraud, by authenticating credit and debit card holders and ensuring that the card is being used by the legitimate owner.

3-D Secure authentication is done just before a merchant performs a “pre” or “auth” transaction.

Merchants wishing to use 3-D Secure will have this feature enabled in e-Rede.

Summaryof3-DSecuretransactionsforHostingbytheMerchant

The merchant’s application collects the cardholder’s details and sends them to e-Rede.

As soon as the details of the payment and the cardholder are received, e-Rede forwards them to the card’s system, which determines if the card is registered in 3-D Secure.

A message containing the results of the registration verification is transferred to the merchant.

6.1

6.1.1


Contents

If the card is registered, the message includes the payment authentication request (PAReq), which contains the details needed for the merchant to redirect the cardholder to the Access Control Server (ACS) of the issuing bank, in order to perform the authentication process.

The message also includes the information needed to redirect the cardholder to the merchant’s website, as soon as the authentication is complete.

Besides this, the redirection process transfers the payment authentication response (PARes) generated by the issuing bank, which contains information about the verification result. For cards not registered in 3-D Secure, the merchant may continue with the authorization process if necessary; however, the choice is the merchant’s and, in the event of the transaction being disputed, the merchant will be responsible.

Summaryof3-DSecuretransactionsforHostingbytheServer

e-Rede collects the details of the payment and the cardholder and forwards them to the card’s system, which determines if the card is registered in 3-D Secure.

A message containing the results of the registration verification is transferred to e-Rede.

If the card is registered, the message includes the payment authentication request (PAReq), which contains the details needed for the server to redirect the cardholder to the Access Control Server (ACS) of the issuing bank, in order to perform the authentication process.

6.1.2


Contents

The message also includes the information needed to redirect the cardholder to the merchant’s website as soon as authentication is completed.

Besides this, the redirection process transfers the payment authentication response (PARes) generated by the issuing bank, which contains information about the verification result. For cards not registered in 3-D Secure, the merchant may continue with the authorization process if necessary; however, the choice is the merchant’s and, in the event of the transaction being disputed, the merchant will be responsible.

AddressVerificationService(AVS)

The Address Verification Service (AVS) is a security feature of Mastercard transactions in which the billing address entered by the cardholder is compared with the address in the database of the card issuer.

An AVS result code is displayed in the XML Response message and it indicates the degree of correlation (or non-correlation) of the address. The merchant’s application is responsible for deciding how to control the payment transaction based on the AVS result code.

If an issuing bank does not support AVS, an appropriate result code will be displayed in the transaction response to indicate that the service is not supported.

For more details, see the e-Rede Developers’ Reference Guide.

6.2


Contents

CardSecurityCode(CSC)

The Card Security Code (CSC) is a security feature used for transactions without the presence of the card and it enables comparison with the Card Security Code held by the card issuer.

Validation of CSC is mandatory in some countries and regions. However, some issuing banks do not support CSC validation, and, although the CSC data may be included in the message of a transaction, these issuing banks will display a CSC response code to indicate that this service is not supported.

For Visa™ and MasterCard® cards, the CSC is the three-digit number printed on the signature panel on the back of the card, as shown below:

The CSC data must never be stored or kept. In a standard Hosted by the Server transaction, e-Rede requests the CSC from the cardholder.

The level of correspondence between the cardholder’s CSC kept by the issuing institution and the CSC provided by the cardholder for the transaction, will determine if the transaction is accepted or rejected.

When the CSC is not accepted, the transaction is rejected.

6.3


Contents

transaction integrity

The following guidelines can be used by merchants to maximize transaction integrity.

Usingauniquetransactionreferencefromthemerchantfortransactionattempts.

Each transaction attempt must be assigned a unique transaction from the merchant (merchant_reference).Most applications and programming environments on the web generate a single session for each cardholder that can be used as the unique transaction reference of the merchant to be displayedin the XML Response.

Alternatively, a unique transaction reference can be created through the combination of the order number or invoice number with the payment attempt counter. A date and time record can also be included with the reference ID of the transaction to ensure that each ID is unique.

Before sending a transaction to the payment server, the unique transaction reference from the merchant must be stored with the order details in the merchant’s database.

This reference is necessary in order to be able to reliably use the transaction query function to search and retrieve transaction details.

6.4

6.4.1


Contents

Checkingthatthevaluesoftheresponsefieldscorrespondtothevaluesoftherequest.

Make sure that the important fields of the XML Response (e.g., the amount and the transaction reference of the merchant) correspond to the values entered in the original XML request.

Storingthecardnumberssecurely.

It is recommended that merchants do not store credit card information in the database of their websites. When the card numbers need to be stored, the hardware must be securely encrypted or the numbers must be stored as disguised values.

6.4.2

6.4.3


Contents

Fraudmanagement

e-Rede has a fraud management option which allows merchants to apply standard or personalized sets of risk rules for classifying real-time or offline transactions.

Transactions can be classified and cross-referenced with matrices and data models, as well as in relation to the origins of both internal and external data, in order to generate a risk score based on rules related to:

•Validationoftransactions

•Purchasevalue

•VelocitySeriesofthecardnumber,e-mailaddress,andIPaddress

•Blacklists,greylists,andwhitelistsofcardnumbers,e-mailaddresses,IPaddresses,merchants,etc.

• Inconsistent/poorlycorrespondinginformation(e.g.,issuerandcountryoftheIP,issuerandcountryforthedelivery)

•Detailsoftheproductsinrelationtotherisks

•VerificationrulesforschemessuchasCSCandAVS

Based on the risk score, the transactions may be accepted, rejected, or marked for review via a manual evaluation.

6.5


Contents

07 SupplementaryresourcesofthetransactionsMerchants may implement supplementary resources available on e-Rede, including data in addition to the XML Request.

Variou supplementary resources can be combined into one XML Request.

vTIDconfiguration

The vTID configuration service allows the alteration of a new password of a vTID, sending a transaction to e-Rede.

This service only applies to the transactions received from the IP addresses specified in the IP filtering related to the vTID in the configuration process.

7.1


Contents

08 TokenGenerationService

Introduction

The Generation of Tokens is a mechanism for storing card data related to a transaction without storing the actual number of the card (PAN).

This service allows merchants to send card data to e-Rede and receive unique tokens that offer the same functionality of a card number, but without the security implications of the related data.

Each token generated during this process is unique to a card number and a particular merchant.

Although the storing of a token eliminates some responsibilities from the merchant in relation to the PCI-DSS, it does not eliminate these needs completely. A merchant that captures the card data before transferring it to e-Rede is still responsible for ensuring compliance with the PCI-DSS.

To use tokens with e-Rede, a merchant must contract this service.

8.1


Contents

GeneratingTokens

Requirements

To utilize the Token Generation Service, a merchant needs:

•Ane-RedeaccountconfiguredtoprocesscardswhichhaveTokenGenerationenabled

Tokenformat

Regardless of the length of the card number, each token has 40 characters. Tokens are generated according to the following rules:

• TheycanbecomposedofuppercaselettersfromAtoZanddigitsfrom0to9.

GeneratingTokens

The two ways to generate a token using the Token Generation Service are:

•Usingaspecifictypeoftransactionandthespecializedtokengenerationmessageinwhichtheresponseofthetransactiongeneratesatoken.Itisnotnecessarytoprovidetheexpirydateorothercardinformationinordertogenerateatoken.

•WhenamerchantusestheTokenGenerationService,theresponsetoasuccessfulcardtransactionrequestwillincludeatoken.

The algorithms used by the Token Generation Service will not generate the same token for two different card numbers of a merchant.

8.28.2.1

8.2.2

8.2.3


Contents

UseofTokens

other uses

A merchant using the Token Generation Service that receives a token as a response to a transaction request or receives a token as part of a transaction request for tokens can provide the token instead of the card number in any subsequent transaction related to that card.

Paymenttransactionsthatusetokens

Merchants continue to use the same format of previous transactions, but replace the card number with a token and qualify the transaction that is using a token by inserting the element pan type = “token” into the XML.

Although the card number is replaced by the token, the expiry date must be provided and optionally, the CVV.

Querying transactionsWhen a merchant is using the Token Generation Service, the token generated by a transaction is displayed as part of a transaction query related to the transactions performed after the merchant was configured for this service.

8.3

8.4

8.3.1

8.4.1


Contents

09 transactions involving instalments

Within e-Rede, the merchant has the option of performing transactions in the instalment mode. The instalment can be With Interest or Without Interest.

The following element can be sent in the XML request and will be included in the transaction authorization request.

Elementsoftherequest

•Request•Transaction•TxnDetails-SeeSection2.2.1.3ofthee-RedeDevelopers’ReferenceGuide• Instalments

Nameoftheelement Instalments

Position Request.Transaction.TxnDetails

ElementsoftheInstalments

NameoftheElement Description Values/Limitations

typeIndicates to the issuer if the instalment is charged interest.

interest_bearingzero_interest

numberIndicates to the issuer the number of instalments to be paid.

Numerical

9.1

Notes:1. “interest_bearing” means Instalments with interest2. “zero_interest” means Instalments without interest3. When it is a WHOLE PAYMENT transaction, the “Instalments” tag MUST NOT be used


Contents

ExampleXMLrequestwithtransactioninformationforinstalmentswithoutinterest

<Transaction> <CardTxn>…</CardTxn> <TxnDetails> <merchantreference>12345601</merchantreference> <amount>500.00</amount> <Instalments> <type>zero_interest</type> <number>10</number> </Instalments> ...

INCORRECTexampleofanXMLRequestforawholepaymenttransaction.Inthiscase,thetag“Instalments”mustnotbeused.

<Transaction> <CardTxn>…</CardTxn> <TxnDetails> <merchantreference>12345601</merchantreference> <amount>500.00</amount> <Instalments> <type>interest_bearing</type> <number>10</number> </Instalments> ...

CORRECTexampleforawholepaymenttransaction

<Transaction> <CardTxn>…</CardTxn> <TxnDetails> <merchantreference>12345601</merchantreference> <amount>500.00</amount>


Contents

ExampleXMLrequestwithtransactioninformationforinstalmentswithinterest

<CardTxn>…</CardTxn><TxnDetails><merchantreference>12345601</merchantreference><amount>500.00</amount><Instalments><type>interest_bearing</type><Num.ber>10</Num.ber></Instalments>...


Contents

10 Overviewofthetechnicalintegration

Introduction

AbouttheXMLRequest

The XML Request is used to create a transaction in the methods of Hosting by the Server and Hosting by the Merchants.

AbouttheXMLResponse

The XML Response contains a unique transaction ID generated by e-Rede. This transaction ID must be stored in the merchant’s order database as part of the transaction record, in case it is necessary to manually perform a reversal or cancellation using e-Rede’s website.

The transaction ID or a unique Merchant_reference element is necessary to query a transaction. If it is not possible to ensure that the Merchant_reference is unique, the merchant must use the transaction ID in the transaction query requests.

10.1

Integration with e-Rede

Each processing method requires the sending of specific information, which tends to be grouped into similar areas (main elements) of XML. The names of the main elements are the first to be introduced.

Each one of them is placed in its context in XML and its secondary elements are discussed. This includes any restrictions on the format, length, and type of transaction of each element.

10.2

10.1.1

10.1.2


Contents

There are certain features of the XML Request and XML Response which apply to all the services - these elements are addressed in this section. The other features are only used for a service or a group of specific services - these elements are addressed in the documentation for that service.

Overviews of the XML Request and the XML Response are as follows:

TheXMLRequest XML Requests must contain the following version description:<Request version=’2’>

The following information must be collected from the cardholder for each transaction (i.e., for each transaction using the card number- this does not apply when using token generation):

• Thecardnumber•Theexpirydateofthecard

Note: In the case of payments hosted by the server, e-Rede will collect the data on behalf of the merchant.

Besides the card information, it is also necessary to collect the following details about the transaction:

• Theamountandthecurrencyofthetransaction•Auniquereferencenumbergeneratedbythemerchant’ssystemtoenablethetransactionstobedistinguishedfromeachother

• Thetypeoftransactiontoenablethecorrectprocessingmodel-“pre”or“auth”

The additional information fields may be necessary to utilize other features.

10.2.1


Contents

The XML Request is prepared using these fields.

For the Hosting by the Server method, the URL that e-Rede needs for redirecting the cardholder must also be included.At this point in the process, the cardholder’s session with the merchant’s application is interrupted and he is redirected to e-Rede.

TheXMLResponse

The XML Responses must contain the following version description:<Responseversion=’2’>

For the Hosting by the Server method, the browser displays the XML response to the merchant’s website.

Transactions may display multiple results. These results can be grouped into two categories:

•Bankresponses-thetransactionissenttothebank•Errorcodes-anerroroccurredthatpreventedthetransactionbeingsenttothebank

10.2.2


Contents

Failurescenarios

Under normal conditions for the Hosting by the Server method, the cardholder is redirected to the merchant’s website as soon as the payment transaction is processed. Merchants need to accompany the initiated orders in which the cardholder does not return to the website.

Merchants need to manage their system to determine if the cardholder has abandoned the order, or if the payment has been made successfully and if the order can be received manually. In this scenario, the merchant’s application will not receive a transaction ID generated by e-Rede and the merchant will have to consult e-Rede with the unique Message Reference that was provided in the corresponding XML Request message.

There may be a miscommunication at any time between sending a redirection to the cardholder (via the merchant’s application) and the return of the cardholder to the website. For example, the cardholder can choose to go to a different website, or the internet connection may fail. This will cause a “pending” order or a state of ambiguity in the merchant’s system. To address this situation, e-Rede provides a method by which merchants can determine the status of all requests.

Using the transaction ID generated by e-Rede, or a unique Message Reference provided by the merchant’s application, a transaction query is executed to determine the status of a transaction at any time.

The Transaction Query can also be used in the Hosting by the Merchant method, if an XML request is not answered.

Depending on the volume of transactions that are expected to be processed, the following suggestions are offered for cleaning the failed transactions.

10.3


Contents

other considerations

TransportLayer

The transport layer of the e-Rede messages is equivalent to the HTTPS internet standard protocol. The merchant’s host releases all the messages in e-Rede. All the messages exchanged between the merchant’s host and e-Rede will be encrypted by SSL (TLS/SSLv3 with symmetric cipher strength of at least 2048 bits) and authenticated by the server.

Authenticationofthemerchants

There is a password shared between the software of the merchant and e-Rede. This password will be provided to the merchant by e-Rede as soon as the integration is complete.

Messages

All interactions between the software of the merchant and e-Rede will be of the “request response” type and use the HTTPS internet standard protocol, with the exception of the interaction involving the redirecting of the cardholder’s browser. All interactions will be initiated by the software of the merchant and all communication will occur via the Internet available to the public.

10.410.4.1

10.4.2

10.4.3


Contents

11 Overviewofthetests

overview

e-Rede operates a production system and a system for testing.

Merchants sign up for a test system account and validate their integration and transaction processing in this system before attempting processing in the production system.

No transaction in the test system is forwarded to the banks, and funds are not transferred. Instead, a set of test numbers may be used to generate automated responses that simulate contact with banks.

Once the tests are completed successfully, merchants can start processing transactions in their production account.

11.1


Contents

12 electronic statementFor merchants that use electronic statements to perform their reconciliations, new specific records have been created to demonstrate the e-Rede transactional data.

In the extract file we demonstrate the NSU - in the transaction messaging the NSU will be demonstrated by the auth_host_reference parameter.

NOTE:Itisimportanttodeveloptherecordsbelowbecausetheyfacilitatereconciliationandallcustomerswhousee-Redewillreceivethisinformation.


Contents

Editingcriteriaofthedata

Type of record “033” = Request - Request for documentation

PV number POS code

RV number Sales Summary number

Card number Card number

Date of the CV/NSU (DDMMYYYY) Date of the Numerical Sales Receipt, in the format DDMMYYYY

CV/NSU number Sales Receipt number.

Authorization code Transaction authorization number

TID Number of the receipt for e-Rede sale

Order number Order number generated by the merchant

Fileofmultibrandcreditsales

Record033-Request(e-Rede)

This record must accompany Record 005 - Request,and be shown only to the clients who are authorized to make sales using e-Rede.

12.1

Record033-Request(e-Rede)

start end Size PIC Description

1 3 3 Num. Type of record (“033”)

4 12 9 Num. PV number

13 21 9 Num. RV number

22 37 16 Alpha Card Number

40 47 8 Num.Date of the CV/NSU transaction (DDMMYYYY)

48 59 12 Num. CV/NSU number

60 65 6 Alpha Authorization code

66 85 20 Alpha TID

88 117 30 Alpha Order number

12.1.1


Contents

Record034-RevolvingCV/NSU(e-Rede)

This record must accompany Record 008 - Revolving CV/NSU, and only be shown to customers who are authorized to make sales using e-Rede.


Type of record “034” = CV/NSU Revolving Credit

PV number POS code

RV number Sales Summary Number

Date of the CV/NSU (DDMMYYYY) Date of the numerical sales receipt, in the format DDMMYYYY

CV/NSU amount Amount of the sales receipt

Card number Credit card number

CV/NSU number Sales Receipt Number contains zeros when the CV/NSU is manual

Authorization number Authorization number



Record034-RevolvingCV/NSU(e-Rede)





22 29 8 Num. Date of the CV/NSU (DDMMYYYY)

30 44 15 9(13)V99 CV/NSU amount

45 60 16 Alpha Card number


73 78 6 Alpha Authorization number

79 98 20 Alpha TID


12.1.2


Contents

Record35-CV/NSUinInstalmentswithoutinterest(e-Rede)

This record must accompany Record 012-CV/NSU in Instalments without interest, and be shown only to customers who are authorized to make sales using e-Rede.

Record35-CV/NSUinInstalmentswithoutinterest(e-Rede)






30 44 15 9(13)V99 Amount of the CV/NSU




79 98 20 Alpha TID



Type of record “035” = CV/NSU in Instalments without interest

PV number POS code



Amount of the CV/NSU Amount of the sales receipt


CV/NSU numberSales Receipt NumberContains zeros when the CV/NSU is manual




12.1.3


Contents

Record36-CV/NSUinIATAInstalments(e-Rede)

This record must accompany Record 018 - CV/NSU in IATA Instalments, and be shown only to customers who are authorized to make sales using e-Rede.

Record036-CV/NSUinIATAInstalments(e-Rede)










79 98 20 Alpha TID



Type of record “036” = CV/NSU in IATA Instalments

PV number POS code



Amount of the CV/NSU Amount of the sales receipt






12.1.4


Contents

Record37-CV/NSUinDollars(e-Rede)

This record must accompany Record 024-CV/NSU in Dollars, and be shown only to customers who are authorized to make sales using e-Rede.

Record037-CV/NSUinDollars(e-Rede)










79 98 20 Alpha TID



Type of record “037” = CV/NSU in dollars

PV number POS code


Date of theCV/NSU(DDMMYYYY) Date of the Numerical Sales Receipt, in the format DDMMYYYY

Amount of the CV/NSU in dollars Amount of the sales receipt






12.1.5


Contents

TypesofCapture

TableofAdjustments

TypesofCapture1 = Manual

2 = POS

3 = PDV

4 = TO

5 = Internet

6 = Magnetic card reader

8 = e-Rede

9 = Others

In Table V - Adjustments: the 6 new reasons for service charges must be included.

33-GatewayPackage41-ManualReview42-Monitoring43-BankPaymentSlips44-TokenGeneration45-RecurringPayments

12.1.6

12.1.7


Contents

Fileofmultibranddebitsales

Record13-DetailsoftheSalesReceipts(e-Rede)

This record must accompany Record 005-Details of the sales receipts, and be shown only to customers who are authorized to make sales using e-Rede.

12.2

Recordtype13-Detailsofthee-RedeSalesReceipts

column Maximumsizeofthefield Descriptionofthefield

Size PIC

1st 2 Num. Type of record

2nd 9 Num. Affiliation number of the POS

3rd 9 Num. Sales Summary Number

4th 8 Num. Date of the CV (DDMMYYYY)

5th 15 9(13)V99Gross amount (for Purchases and Withdrawals, this field will consist of “Purchase amt.”+“Withdrawal amt.”)

6th 19 Alpha Card number

7th 12 Num. CV number

8th 20 Alpha TID

12.2.1


Contents

Record14-Unschedulingofpredatedsales(totalandpartial)-e-Rede

This record must accompany Record 008 - Unscheduling of predated sales (total and partial), and be shown only to customers who are authorized to make sales using e-Rede.

Recordtype14-Unschedulingofpredatedsales(totalorpartial)-e-Rede


Size PIC



3rd 9 Num. Sales Summary Number

4th 8 Num. Date of the CV (DDMMYYYY)

5th 12 Num. CV number (NSU)

6th 15 9(13)V99 Gross total of the CV

7th 20 Alpha TID

8th 30 Alpha Order number

12.2.2


Contents

Record015-Clearedpredatede-Rede transactions

This record must accompany Record 009 - Cleared predated transactions, and be shown only to customers who are authorized to make sales using e-Rede.

Recordtype15-Clearedpredatede-Redetransactions


Size PIC



3rd 12 Num. NSU number of the transaction

4th 8 Num. Date of transaction

5th 15 9(13)V99 Gross amount

6th 20 Alpha TID


12.2.3


Contents

Record16-Unclearedpredatedtransactions(distributor)

This record must accompany Record 010 - Uncleared predated transactions (distributor), and be shown only to customers who are authorized to make sales using e-Rede.

Recordtype16-Unclearedpredatedtransactions(Distributor)-e-Rede


Size PIC



3rd 12 Num. NSU number of the transaction

4th 8 Num. Date of the transaction

5th 15 9(13)V99 Gross amount

6th 20 Alpha TID


12.2.4


Contents

Record17-NetAdjustment(e-Rede)

This record must accompany Record 011 - Net Adjustment, and be shown only to customers who are authorized to make sales using e-Rede.

Recordtype17-e-RedeNetAdjustments


Size PIC


2nd 19 Num. Card number

3rd 8 Num. Date of the “CV” transaction

4th 9 Num. Number of the original RV

5th 9 Num. Original PV number

6th 8 Alpha Original RV date

7th 15 9(13)V99 Transaction amount

8th 12 Num. NSU number (reasons 16, 18, and 23)

9th 6 Alpha Authorization number

10th 20 Alpha TID


12.2.5


Contents

Record18-Request

Typesofcapture

This record must accompany Record 012 - Request, and be shown only to customers who are authorized to make sales using e-Rede.

Recordtype18-e-Rederequest


Size PIC

1st 2 Num. Type of record (“12”)

2nd 9 Num. PV number

3rd 9 Num. RV number

4th 16 Alpha Card number

5th 15 9(15)v99 Amount of the CV/NSU transaction

6th 8 Num. Date of the CV/NSU transaction (DDMMYYYY)

7th 12 Num. CV/NSU number

8th 6 Alpha Authorization code

9th 20 Alpha TID


Typesofcapture1 = Manual

2 = POS

3 = PDV

4 = TO

5 = Internet

6 = Magnetic card reader

8 = e-Rede

9 = Others

12.2.6

12.2.7


Contents

TableofAdjustments

Multibrandfinancialfile12.3

In Table V - Adjustments: the 6 new reasons for service charges must be included.


New records will be added to inform the TID and order number. These records will be complementary to the records: 035 - Net Adjustments and Unscheduling, 038 - Debit adjustments (via bank), 044 - Pending debits, 045 - Cleared debits, and 049 - Unscheduling instalments; and must be shown in sequence despite not having a sequential number.

Additionally, four new records were created to demonstrate the charging of the new services and to add the new reasons in the table of adjustments.

58 - Gateway59-BankPaymentSlips60-Riskanalysis61-ManualReview

12.2.8


Contents

Record053-NetAdjustmentsandUnscheduling

This record must accompany Record 0035 - Net Adjustments and Unscheduling, and be shown only to customers who are authorized to make sales using e-Rede.

Record053-e-RedeNetAdjustmentsandUnscheduling



4 19 16 Num. Card number

20 27 8 Num. Date of the “CV” transaction

28 36 9 Num. Original RV number

37 45 9 Num. Original PV number

46 60 15 9(13)V99 Transaction amount

61 72 12 Num. NSU number (reasons 16, 18, and 23)


79 98 20 Alpha TID



Type of record “053”= Adjustment entries

Card numberOriginal card for the transaction - will only be shown in cases of chargeback

Date of the transaction Date of the sale that is being adjusted

Original RV number RV number in which transaction was submitted

Original PV number Original PV number of the transaction

Transaction amount Transaction amount (CV)

NSU number (reasons 16, 18, and 23)

Receipt number of the original transaction (NSU)




12.3.1


Contents

Record54-Debitadjustments(viabank)-e-Rede

This record must accompany Record 038 - Debit adjustments(via bank), and be shown only to customers who are authorized to make sales using e-Rede.

Record054-Debitadjustments(viabank)-e-Rede






38 45 8 Num. Date of the “CV” transaction


58 72 15 Num. Original transaction amount

73 78 6 Num. Authorization number

79 98 20 Alpha TID



Type of record “054” = Debit adjustments (via bank)

Original RV number RV number in which transaction was submitted.

Card numberOriginal card for the transaction - will only be shown in cases of chargeback

Original PV number POS code that led to the debit

Date of the transaction Date of the sale that caused the debit



Original transaction amount Gross amount of the transaction captured




12.3.2


Contents

Record55-Pendinge-Rededebits

This record must accompany Record 044 - Pending debits, and be shown only to customers who are authorized to make sales using e-Rede.

Record055-Pendingdebits-e-Rede





32 39 8 Num. Date of the original CV of the transaction


46 60 15 9(13)V99 Amount of the original transaction



79 98 20 Alpha TID



Type of record “055” = Pending debits

Card numberOriginal card for the transaction will only be shown in cases of chargeback or cancelation



Date of the original CV/NSU of the transaction


Authorization number Authorization from the issuer

Amount of the original transaction

Amount of the original transaction

Original RV number Original RV number

Original PV number Original PV number



12.3.3


Contents

Record056-Clearede-Rededebits

This record must accompany Record 045 - Cleared Debits, and be shown only to customers who are authorized to make sales using e-Rede.

Record056-Cleareddebits-e-Rede





32 39 8 Num. Date of the original CV of the transaction


46 60 15 9(13)V99 Amount of the original transaction



79 98 20 Alpha TID



Type of record “056”= Cleared debits

Card numberOriginal card for the transaction will only be shown in cases of chargeback or cancelation

NSU number(reasons 16, 18, and 23)




Authorization number Authorization of the issuer

Amount of the original transaction Amount of the original transaction

Original RV number Original RV number

Original PV number Original PV number



12.3.4


Contents

Record 057 - Unscheduling ofinstalments(e-Rede)

This record must accompany Record 049 - Unscheduling of instalments, and be shown only to customers who are authorized to make sales using e-Rede.

Record057-Unschedulingofinstalments(e-Rede)





98 112 15 9(13)V99 Amount of the original RV


144 151 8 Num. Date of the transaction

152 163 12 Num. NSU

165 166 20 Alpha TID



Type of record “057”= Unscheduling of instalments

Original PV number PV code that led to the adjustment

Original RV number Number of the Summary that led to the adjustment

Amount of the original RV Amount of the original Summary of Sales

Card number Card number

Date of the transaction Date of the transaction

NSU Receipt number of the original transaction (NSU)



12.3.5


Contents

new Records12.4

I - Record 058 - Gateway

Contains information about the Gateway charges.

Record 058 - Gateway




13 17 5 Num. Number of emissions in the period

18 32 15 9(13)V99Total amount of the emissions in the period

33 40 8 Num.Start of the emission period (DDMMYYYY)

41 48 8 Num.End of the emission period (DDMMYYYY)

49 63 15 9(13)V99 Amount per emission for this period


Type of record “058” = Gateway

PV number POS code

Number of emissions Number of emissions for the period

Total amount of the emissions Total amount of the emissions in the period

Start of the emission (DDMMYYYY) Start of the emissions for this period

End of the emission (DDMMYYYY) End of the emissions for this period

Amount per emission Amount per emission for the period

To demonstrate the charging of the new services, four new records were created.


Contents

II-Record059-BankPaymentSlips

Contains information about the charges for Bank Payment Slips:

Record059-BankSlips




13 17 5 Num. Number of emissions in the period

18 32 15 9(13)V99 Total amount of the emissions in the period

33 40 8 Num. Start of the emission period (DDMMYYYY)

41 48 8 Num. End of the emission period (DDMMYYYY)

49 63 15 9(13)V99 Amount per emission for this period


Type of record “059” = Bank slip

PV number POS code

Number of emissions Number of emissions for the period

Total amount of the emissions Total amount of the emissions in the period

Start of the emission (DDMMYYYY) Start of the emissions for this period

End of the emission (DDMMYYYY) End of the emissions for this period

Amount per emission Amount per emission for the period


Contents

III-Record060-RiskAnalysis

Contains information about the Risk Analysis charges.

Record060-RiskAnalysis




13 17 5 Num.Number of queries conducted in the period

18 32 15 9(13)V99Total amount for the queries in the period

33 40 8 Num. Start of the query period (DDMMYYYY)

41 48 8 Num. End of the query period (DDMMYYYY)

49 63 15 9(13)V99 Amount per query for this period


Type of record “060” = Risk Analysis

PV number POS code

Number of queries Number of queries during the period

Total amount for the queries Total amount for the queries during the period

Start of the queries (DDMMYYYY) Start of the queries for this period

End of the queries (DDMMYYYY) End of the queries for this period

Amount per query Amount per query for the period


Contents

IV-Record61-ManualReviewofRisk

Contains information about the Manual Review charges.

Record061-ManualReview




13 17 5 Num.Number of reviews performed during the period

18 32 15 9(13)V99Total amount for the reviews during the period

33 40 8 Num. Start of the review period (DDMMYYYY)

41 48 8 Num. End of the review period (DDMMYYYY)

49 63 15 9(13)V99 Amount per review for this period


Type of record “061” = Risk Analysis

PV number POS code

Number of reviews done Number of reviews done in the period

Total amount for the reviews Total amount for the reviews in the period

Start of the review (DDMMYYYY) Start of the reviews for this period

End of the review (DDMMYYYY) End of the reviews for this period

Amount per review Amount per review for the period


Contents

TableofAdjustments

In Table III - Adjustments: the 6 new reasons for service charges must be included.


12.5


Contents

13 Glossary

term Description

3-D secure

A standard data encryption protocol used to reduce transaction fraud for credit and debit cards, by authenticating cardholders and guaranteeing that the card is used by the rightful owner.

Accesscode An identifier used to authenticate the merchant via e-Rede.

Acquirer Company in which the merchant is affiliated and where its credit and debit transactions are processed.

AddressVerificationService(AVS)

A security feature used for transactions that compares the billing address entered by the cardholder with the address in the database of the card issuer.

Cardtoken The identifier of the stored details of the card which will be used later for a payment transaction.

CardSecurityCode(CSC)A security feature used for transactions without the presence of the card; it compares the Card Security Code with thecode kept by the card issuer.

PersonalizedInterfaceThe merchant manages the flow of XML requests to e-Rede for the authorization of transactions, including 3-D Secure authentication.

StandardInterface e-Rede manages the 3-D Secure authentication processesand the authorization of transactions.


Contents

term Description

iFrame(integratedstructure) The secure page for entering the card data can be displayed as an iFrame.

Issuingbank The bank or financial institution that issues the credit or debit cards to the cardholder.

HostingbytheMerchant

Method of implementing e-Rede in which the merchant’s application directly communicates with e-Rede and, therefore, the cardholder does not need to leave the merchant’s website and the session is not divided.

merchantreference A unique identifier assigned by the merchant to each transaction (e.g., an order number or invoice number).

One-stepprocessing Processing method in which it is only necessary to perform a single transaction to complete processing.

PCI-DSSThe Payment Card Industry Data Security Standard (PCI DSS) provides a framework for the development of a robust data security process for card payments.

Recurringpayments Automatic recurring payments.

Hostingbytheserver

The method of implementing e-Rede in which themerchant redirects the cardholder to the Payment Serverin order to insert the card details. The two options forhosting by the server are the capture of hosted cardsand capture of hosted pages.


Contents

term Description

TokenGeneration

The token generation service allows merchants to send card data to e-Rede and receive unique tokens that offer the same functionality of a card number without the security implications of the related data.

Each token is unique to a card number and to a particular merchant.

Storing tokens eliminates some responsibilities of the merchant related to the PCI-DSS.

Transactionquery

The transaction query command allows merchants to search a transaction. The search is performed on the Transaction ID key ( gateway_reference ) or merchant_reference.

transaction originThe functionality of the transaction origin allows a merchant to indicate the origin of a transaction hosted by it (e.g., e-Commerce).

Typeoftransaction Type of card transaction or other transaction that can be processed using e-Rede.

Two-stepprocessing Processing method in which it is necessary to perform two separate transactions to conclude processing.

XMLRequest A request for e-Rede to effect a credit or debit transaction.

XMLResponse A response frome-Rede indicating the result of the transaction.

Rede Call Center:4001 4433(capitals and metropolitan areas)

0800 728 4433(other localities)

Rede Web Portal:userede.com.br

Resolve everythingin one call.

Date post:	18-Jul-2016
Category:	Documents
Upload:	alberto-braschi
View:	12 times
Download:	1 times

060614 Integration Guide E-Rede v5

Documents