Upload
alberto-braschi
View
13
Download
1
Embed Size (px)
DESCRIPTION
060614 Integration Guide E-Rede v5
Citation preview
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
Click on the hyperlinks to navigate the material in the Manual for Integration to e-Rede.
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
Click on the hyperlinks to navigate the material in the Manual for Integration to e-Rede.
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
Click on the hyperlinks to navigate the material in the Manual for Integration to e-Rede.
con
ten
ts
12.2.4
Record 17 - Net Adjustment (e-Rede) 68
Record 18 - Request 69
Types of Capture 69
Table of Adjustments 70
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
Table of Adjustments 80
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
Click on the hyperlinks to navigate the material in the Manual for Integration to e-Rede.
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
8Manual for Integration to e-Rede
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.
9Manual for Integration to e-Rede
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
10Manual for Integration to e-Rede
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
11Manual for Integration to 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
12Manual for Integration to e-Rede
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
13Manual for Integration to e-Rede
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
14Manual for Integration to e-Rede
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
15Manual for Integration to e-Rede
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
16Manual for Integration to e-Rede
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)
17Manual for Integration to e-Rede
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)
Hostingbytheserver Hostingbythemerchant
Captureofhostedcards(PersonalizedInterface)
Hostedpages(StandardInterface)
Pageshostedbythemerchant
DataCapture
18Manual for Integration to e-Rede
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)
Hostingbytheserver Hostingbythemerchant
Captureofhostedcards(PersonalizedInterface)
Hostedpages(StandardInterface)
Pageshostedbythemerchant
Flowofpayments
19Manual for Integration to e-Rede
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.
20Manual for Integration to e-Rede
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.
21Manual for Integration to e-Rede
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
22Manual for Integration to e-Rede
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)
23Manual for Integration to e-Rede
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.
24Manual for Integration 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
25Manual for Integration to e-Rede
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
26Manual for Integration to e-Rede
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
27Manual for Integration to e-Rede
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.
28Manual for Integration to e-Rede
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
29Manual for Integration to e-Rede
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
30Manual for Integration to e-Rede
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
31Manual for Integration to e-Rede
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
32Manual for Integration to e-Rede
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
33Manual for Integration to e-Rede
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
34Manual for Integration to e-Rede
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
35Manual for Integration to e-Rede
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
36Manual for Integration to e-Rede
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
37Manual for Integration to e-Rede
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
38Manual for Integration to e-Rede
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
39Manual for Integration to e-Rede
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
40Manual for Integration to e-Rede
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
41Manual for Integration to e-Rede
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
42Manual for Integration to e-Rede
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
43Manual for Integration to e-Rede
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
44Manual for Integration to e-Rede
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
45Manual for Integration to e-Rede
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
46Manual for Integration to e-Rede
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
47Manual for Integration to e-Rede
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
48Manual for Integration to e-Rede
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
49Manual for Integration to e-Rede
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>
50Manual for Integration to e-Rede
Contents
ExampleXMLrequestwithtransactioninformationforinstalmentswithinterest
<CardTxn>…</CardTxn><TxnDetails><merchantreference>12345601</merchantreference><amount>500.00</amount><Instalments><type>interest_bearing</type><Num.ber>10</Num.ber></Instalments>...
51Manual for Integration to e-Rede
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
52Manual for Integration to e-Rede
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
53Manual for Integration to e-Rede
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
54Manual for Integration to e-Rede
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
55Manual for Integration to e-Rede
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
56Manual for Integration to e-Rede
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
57Manual for Integration to e-Rede
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.
58Manual for Integration to e-Rede
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
59Manual for Integration to e-Rede
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.
Editingcriteriaofthedata
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
TID Number of the receipt for e-Rede sale
Order number Order number generated by the merchant
Record034-RevolvingCV/NSU(e-Rede)
start end Size PIC Description
1 3 3 Num. Type of record (“034”)
4 12 9 Num. PV number
13 21 9 Num. RV number
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
61 72 12 Num. CV/NSU number
73 78 6 Alpha Authorization number
79 98 20 Alpha TID
99 128 30 Alpha Order number
12.1.2
60Manual for Integration to e-Rede
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)
start end Size PIC Description
1 3 3 Num. Type of record (“035”)
4 12 9 Num. PV number
13 21 9 Num. RV number
22 29 8 Num. Date of the CV/NSU (DDMMYYYY)
30 44 15 9(13)V99 Amount of the CV/NSU
45 60 16 Alpha Card number
61 72 12 Num. CV/NSU number
73 78 6 Alpha Authorization number
79 98 20 Alpha TID
99 128 30 Alpha Order number
Editingcriteriaofthedata
Type of record “035” = CV/NSU in Instalments without interest
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
Amount of the CV/NSU Amount of the sales receipt
Card number Credit card number
CV/NSU numberSales Receipt NumberContains zeros when the CV/NSU is manual
Authorization number Authorization number
TID Number of the receipt for e-Rede sale
Order number Order number generated by the merchant
12.1.3
61Manual for Integration to e-Rede
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)
start end Size PIC Description
1 3 3 Num. Type of record (“036”)
4 12 9 Num. PV number
13 21 9 Num. RV number
22 29 8 Num. Date of the CV/NSU (DDMMYYYY)
30 44 15 9(13)V99 Amount of the CV/NSU
45 60 16 Alpha Card number
61 72 12 Num. CV/NSU number
73 78 6 Alpha Authorization number
79 98 20 Alpha TID
99 128 30 Alpha Order number
Editingcriteriaofthedata
Type of record “036” = CV/NSU in IATA Instalments
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
Amount of the CV/NSU Amount of the sales receipt
Card number Credit card number
CV/NSU numberSales Receipt NumberContains zeros when the CV/NSU is manual
Authorization number Authorization number
TID Number of the receipt for e-Rede sale
Order number Order number generated by the merchant
12.1.4
62Manual for Integration to e-Rede
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)
start end Size PIC Description
1 3 3 Num. Type of record (“037”)
4 12 9 Num. PV number
13 21 9 Num. RV number
22 29 8 Num. Date of the CV/NSU (DDMMYYYY)
30 44 15 9(13)V99 Amount of the CV/NSU
45 60 16 Alpha Card number
61 72 12 Num. CV/NSU number
73 78 6 Alpha Authorization number
79 98 20 Alpha TID
99 128 30 Alpha Order number
Editingcriteriaofthedata
Type of record “037” = CV/NSU in dollars
PV number POS code
RV number Sales Summary Number
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
Card number Credit card number
CV/NSU numberSales Receipt NumberContains zeros when the CV/NSU is manual
Authorization number Authorization number
TID Number of the receipt for e-Rede sale
Order number Order number generated by the merchant
12.1.5
63Manual for Integration to e-Rede
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
64Manual for Integration to e-Rede
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
65Manual for Integration to e-Rede
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
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 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
66Manual for Integration to e-Rede
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
column Maximumsizeofthefield Descriptionofthefield
Size PIC
1st 2 Num. Type of record
2nd 9 Num. Affiliation number of the POS
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
7th 30 Alpha Order number
12.2.3
67Manual for Integration to e-Rede
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
column Maximumsizeofthefield Descriptionofthefield
Size PIC
1st 2 Num. Type of record
2nd 9 Num. Affiliation number of the POS
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
7th 30 Alpha Order number
12.2.4
68Manual for Integration to e-Rede
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
column Maximumsizeofthefield Descriptionofthefield
Size PIC
1st 2 Num. Type of record
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
11th 30 Alpha Order number
12.2.5
69Manual for Integration to e-Rede
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
column Maximumsizeofthefield Descriptionofthefield
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
10th 30 Alpha Order number
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
70Manual for Integration to e-Rede
Contents
TableofAdjustments
Multibrandfinancialfile12.3
In Table V - Adjustments: the 6 new reasons for service charges must be included.
33-GatewayPackage41-ManualReview42-Monitoring43-BankPaymentSlips46-TokenGeneration47-RecurringPayments
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
71Manual for Integration to e-Rede
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
start end Size PIC Description
1 3 3 Num. Type of record (“035”)
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)
73 78 6 Alpha Authorization number
79 98 20 Alpha TID
99 128 30 Alpha Order number
Editingcriteriaofthedata
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)
Authorization number Authorization number
TID Number of the receipt for e-Rede sale
Order number Order number generated by the merchant
12.3.1
72Manual for Integration to e-Rede
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
start end Size PIC Description
1 3 3 Num. Type of record (“054”)
4 12 9 Num. Original RV number
13 28 16 Num. Card number
29 37 9 Num. Original PV number
38 45 8 Num. Date of the “CV” transaction
46 57 12 Num. NSU number (reasons 16, 18, and 23)
58 72 15 Num. Original transaction amount
73 78 6 Num. Authorization number
79 98 20 Alpha TID
99 128 30 Alpha Order number
Editingcriteriaofthedata
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
NSU number (reasons 16, 18, and 23)
Receipt number of the original transaction (NSU)
Original transaction amount Gross amount of the transaction captured
Authorization number Authorization number
TID Number of the receipt for e-Rede sale
Order number Order number generated by the merchant
12.3.2
73Manual for Integration to e-Rede
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
start end Size PIC Description
1 3 3 Num. Type of record (“055”)
4 19 16 Num. Card number
20 31 12 Num. NSU number (reasons 16, 18, and 23)
32 39 8 Num. Date of the original CV of the transaction
40 45 6 Alpha Authorization number
46 60 15 9(13)V99 Amount of the original transaction
61 69 9 Num. Original RV number
70 78 9 Num. Original PV number
79 98 20 Alpha TID
99 128 30 Alpha Order number
Editingcriteriaofthedata
Type of record “055” = Pending debits
Card numberOriginal card for the transaction will only be shown in cases of chargeback or cancelation
NSU number (reasons 16, 18, and 23)
Receipt number of the original transaction (NSU)
Date of the original CV/NSU of the transaction
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
TID Number of the receipt for e-Rede sale
Order number Order number generated by the merchant
12.3.3
74Manual for Integration to e-Rede
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
start end Size PIC Description
1 3 3 Num. Type of record (“056”)
4 19 16 Num. Card number
20 31 12 Num. NSU number (reasons 16, 18, and 23)
32 39 8 Num. Date of the original CV of the transaction
40 45 6 Alpha Authorization number
46 60 15 9(13)V99 Amount of the original transaction
61 69 9 Num. Original RV number
70 78 9 Num. Original PV number
79 98 20 Alpha TID
99 128 30 Alpha Order number
Editingcriteriaofthedata
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)
Receipt number of the original transaction (NSU)
Date of the original CV/NSU of the transaction
Date of the original CV/NSU of the transaction
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
TID Number of the receipt for e-Rede sale
Order number Order number generated by the merchant
12.3.4
75Manual for Integration to e-Rede
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)
start end Size PIC Description
1 3 3 Num. Type of record (“057”)
4 12 9 Num. Original PV number
13 21 9 Num. Original RV number
98 112 15 9(13)V99 Amount of the original RV
128 143 16 Num. Card number
144 151 8 Num. Date of the transaction
152 163 12 Num. NSU
165 166 20 Alpha TID
167 196 30 Alpha Order number
Editingcriteriaofthedata
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)
TID Number of the receipt for e-Rede sale
Order number Order number generated by the merchant
12.3.5
76Manual for Integration to e-Rede
Contents
new Records12.4
I - Record 058 - Gateway
Contains information about the Gateway charges.
Record 058 - Gateway
start end Size PIC Description
1 3 3 Num. Type of record (“058”)
4 12 9 Num. PV number
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
Editingcriteriaofthedata
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.
77Manual for Integration to e-Rede
Contents
II-Record059-BankPaymentSlips
Contains information about the charges for Bank Payment Slips:
Record059-BankSlips
start end Size PIC Description
1 3 3 Num. Type of record (“059”)
4 12 9 Num. PV number
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
Editingcriteriaofthedata
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
78Manual for Integration to e-Rede
Contents
III-Record060-RiskAnalysis
Contains information about the Risk Analysis charges.
Record060-RiskAnalysis
start end Size PIC Description
1 3 3 Num. Type of record (“060”)
4 12 9 Num. PV number
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
Editingcriteriaofthedata
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
79Manual for Integration to e-Rede
Contents
IV-Record61-ManualReviewofRisk
Contains information about the Manual Review charges.
Record061-ManualReview
start end Size PIC Description
1 3 3 Num. Type of record (“061”)
4 12 9 Num. PV number
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
Editingcriteriaofthedata
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
80Manual for Integration to e-Rede
Contents
TableofAdjustments
In Table III - Adjustments: the 6 new reasons for service charges must be included.
33-GatewayPackage41-ManualReview42-Monitoring43-BankPaymentSlips48-TokenGeneration49-RecurringPayments
12.5
81Manual for Integration to e-Rede
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.
82Manual for Integration to e-Rede
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.
83Manual for Integration to e-Rede
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.