pagador platform post integration - braspag · pagador – post integration manual phone: (21)...

PAGADOR PLATFORM POST INTEGRATION

Version 1.11

07/30/2013

PAGADOR – POST Integration Manual

Phone: (21) 2111-4700 / (11) 3320.9050 of 42 http://suporte.braspag.com.br

TABLE OF CONTENTS

1. INTRODUCTION ................................................................................................................................................. 4

1.1 About this Manual ............................................................................................................................................... 4

1.2 About the Platform ............................................................................................................................................. 4

2. INTEGRATION PROCESS ..................................................................................................................................... 5

3. PAGADOR’S EXTRA FUNCTIONALITIES ............................................................................................................... 5

4. PAGADOR’S NEW FUNCTIONALITIES .................................................................................................................. 6

5. WHICH TYPES OF INTEGRATION MAY I USE?...................................................................................................... 8

6. INTEGRATION BY POST: DIFFERENCE BETWEEN THE Index AND Passthru MODEL ............................................. 8

6.1 Post Index ............................................................................................................................................................ 8

6.2 Post Passthru ....................................................................................................................................................... 9

7. TECHNICAL STEPS .............................................................................................................................................11

8. ACCEPTANCE OF METHODS OF PAYMENT AND TESTS.......................................................................................25

9. BRASPAG SUPPORT ..........................................................................................................................................29

ANNEX 1 – USE OF THE ENCRYPTION COMPONENT ............................................................................................... 29

ANNEX 2 – INTEGRATION FLOWS THROUGH THE POST FOR CREDIT CARDS .......................................................... 32

ANNEX 3 – Web service Interfaces (Consultation) .................................................................................................. 33

ANNEX 4 – DESCRIPTION OF SAMPLE FILES ............................................................................................................ 39

ANNEX 5 – BRASPAG SUPPORT ............................................................................................................................... 40



HISTORY OF CHANGES

Version Date Description

1.4 12/29/2009 Mandatory CPF and CNPJ parameters for sending in "PARAMETERS TO BE SENT IN STEP 1 (Send post)"

1.5 4/7/2010 Update of Table 3 with new methods of payment, new Annexes.

1.6 9/12/2011 Formatting and spell check, change in Table 2 with new CIELO platform information, update of codes for methods of payment in Table 3, update of methods of payment with capture delay.

1.7 2/22/2012 Change São Paulo office phone number.

1.8 4/5/2012 Inclusion of new parameters, Multi Currency; Multi Language; BraspagOrderID and JustClick.

1.9 5/15/2012 Iclusion of new payment methods: 524 to 532

1.9.1 6/19/2012 Iclusion of new payment method: 35

1.9.2 9/28/2012 Inclusion of payment methods relating to debit; Insertion of the parameter BraspagOrderId; Insertion of Return Error Braspag Codes

1.9.3 11/13/2012 Inclusion of Payment Method: 190 PAGGO (Mobile)

1.9.4 1/2/2013 Inclusion, on Table 1 of the Post Index, of the following parameters: TRANSACTIONTYPE, TRANSACTIONCURRENCY and TRANSACTIONCOUNTRY

1.9.5 2/25/2013

Inclusion of Payment Method: 535, 536, 537, 538, 539, 540, 541, 542, 543, 544 e 545; Removal of Payment Method: 105; Change in the parameter ExtraDynamicurl

1.9.6 7/24/2013 Inclusion of payment method: 546; Removal of payment methods: 46, 54, 55, 56, 90, 91,110, 154, 190;

1.9.7 9/24/2013

Inclusion of payment methods: 547,548 e 549 Changing the name of payment method 546 (From Givex to Giftcards Alelo); Inclusion of DDD parameter on the tables 1 and 2 related to Cielo mobile payment method;

1.9.8 11/12/2013 Inclusion of payment methods: 550 and 551

1.9.9 12/10/2013 Inclusion of payment method: 552

1.9.10 02/21/2014 Change the payment method name Cielo Mastercard Maestro for Cielo Mastercard Débito

1.9.11 07/30/2014 Inclusion of payment methods: 565



1. INTRODUCTION

1.1 About this Manual

The objective of this document is to instruct the Merchant developer on how to integrate the Braspag Pagador system, describing the functionalities, methods to be used, listing information to be sent and received, and providing examples.

1.2 About the Platform

The PAGADOR platform aims at assisting the e-commerce establishment in processing punctual transactions through a single integration with all methods of payment, and real time response.



2. INTEGRATION PROCESS

The integration process with PAGADOR is simple and it can be summarized in the following steps: 1. Receive a Kickoff e-mail with technical manual (this document), acceptance test environment data and ID_Loja for the test. (The ID_Loja parameter is a Single identifier for the Merchant always used in any communication between the Merchant and the Pagador system). 2. Prepare the virtual Merchant to send the transaction, by POST or Web service, to the Pagador System the moment the buyer (Merchant customer) chooses the “Pay” option. 3. After sending and accepting the test affiliations, you can conduct test transactions with those methods of payment registered for your Merchant. 4. Repeat the process integrating the Merchant to the Braspag production environment with real affiliations of the establishment with banks and card operators.

3. PAGADOR’S EXTRA FUNCTIONALITIES

Besides the real time authorizations, Braspag offers some additional services through PAGADOR, such as: a) Encryption component: developed to provide greater security in information transit in integrations by POST. The method for using the encryption component is described in Annex 1. b) Automatic reconciliation of Bank Slips: Pagador can automatically reconcile bank slips as soon as they are paid and the bank sends a return file to Braspag. It is essential to use Status Change Return (described in item 6 below) for this functionality. Important: Automatic reconciliation of bank slips will only occur through an agreement between the bank, the establishment and Braspag. Without this agreement, the system will not identify payment of the bank slips. Contact Customer Relations for more information about this. c) Return of Payment Status Change (USE HIGHLY RECOMMENDED BY BRASPAG) Used to inform the Merchant when the status of a pending payment changed to “PAID”, for

ATTENTION! Use of the Encryption component for integration by POST HIGHLY RECOMMENDED for providing greater security in transactions.



example: a bank slip paid and reconciled, credit card transaction captured changing the transaction status to “PAID”, etc. This RETURN is very useful to update the Merchant sales’ system automatically and in real time concerning the change in status of a transaction to “PAID” without the Merchant operator having to check the status in the Braspag Administrative Environment. It can also be useful in cases where, due to some failure in communication, the Merchant has not received confirmation of the transaction. d) Web services for consulting transactions (annex 4)

� GetDadosComprador: This method returns all buyer related data. � GetDadosEntrega: This method returns all delivery related data. � GetDadosPedido: This method returns all order related data. � GetDadosCartao: This method returns all data related to the card used in the purchase. � GetDadosExtras: This method returns all extra fields related to the order.

e) Capture Delay for credit card transactions: Pagador offers the possibility of capturing credit card transactions with a delay of up to 5 consecutive days. This delay may be useful for several situations, such as, for a Merchant to conduct an anti-fraud analysis and then capture the transaction if analysis releases it. Ask the implementation team about accepting this modality. f) Pagador together with Pagador Recorrente: If the establishment has contracted Pagador and Pagador Recorrente, it can carry out Recorrente’s 1st transaction in real time through integration with Pagador (see details in Annex 5).

4. PAGADOR’S NEW FUNCTIONALITIES

• Multi-Language

o It is possible to choose the language shown in the POST flow pages where there is interaction with the end user (payment pages).

o The languages available are: Portuguese (BR); English (US) and Spanish (ES). o This change will be carried out through the parameter: LANGUAGE (table 3) o If the Merchant does not send the LANGUAGE parameter, the payment pages

will be exhibited in the preferred language of the end user’s browser. o If the language sent by the Merchant or the end user’s browser is not supported,

the payment pages will be exhibited in English (US).

• JustClick o JUSTCLICK SHOP is a solution for charging punctual credit card transaction

(one payment or installments) with a real time and on-line response for e-commerce and call-centers, using the 1-Click Shop concept (shop with 1 click) or sale without typing. The platform receives the data for a sale and connects to PAGADOR for processing it.

o One-click shop permits online payment using credit cards by skipping the data entry phase for payment or even the entire shopping cart process, because the card data have already been previously informed by the buyer in past purchases and will be repeated in future purchases with his approval.

o Parameter: SAVECREDITCARD (table 2) – Indicates whether the card will be saved or not in the JustClick Platform

o CREDITCARDTOKEN Parameter (table 2) – Credit card token generated by the JustClick Platform

o It is necessary to get in contact with the Braspag Commercial Team to use this functionality.



Note: It can only be used in Post Integration with Passthru

• Multi-Currency

o It is possible to specify in which currency/country payment will be processed o It is necessary to check the payment method compatibility list that support

multi-currency. o This information will be sent in the following parameter:

TRANSACTIONCURRENCY (ISO 4217) and TRANSACTIONCOUNTRY (ISO 3166-1 Alfa-3)

Note: 1. It can only be used in Post Integration with Passthru

2. The currency does not need to be tied to the country of origin of the transaction, but rather to the method of payment.

Ex: A transaction carried out in Brazil using the dollar as currency.

• Dynamic URL

o Each transaction can be returned to a specific Return URL. o The client sends the EXTRADINAMICURL parameter to the URL to which the

end of the transaction will be sent. This information should be contained in all transactions.

o In order to use this functionality, it is necessary to request activation from the Implementation Team through the Support Tool.

• Nested Transactions o Nested Transactions are understood as the possibility for a customer to send "n"

transactions, using diverse methods of payment (Credit Card, Bank Slip and Debit Card), through a single identified returned by Braspag with each transaction (BraspagOrderID - BOI);

o The BraspagOrderID will be returned by Braspag with each transaction, whether conducted by Post or WS ;

o Nesting “n” transactions sent by the client (as long as the same BOI is sent for the other transactions); Braspag’s validation of the BOI with each request;

o Use of more than one method of payment.

In order to use this functionality, it is necessary to request activation from the Implementation Team through the Support Tool (http://suporte.braspag.com.br).



5. WHICH TYPES OF INTEGRATION MAY I USE?

Braspag offers three types of integration for an establishment to send transaction to Pagador:

� Integration by POST: Passthru or Index models (described in this manual) � Integration by Web service (request manual from Customer Relations Area)

(it is also possible to use a combination of the above types) The advantage of integration through Web service is that it is faster and more resistant to failure since all communication is made from server to server, without any chance for user interference. However, not all methods of payment can be used with this integration, for example, online debits, where it is necessary for the buyer (Merchant customer) to be directed to the bank environment to make the transaction. Integration by Web service does not need the use of the Encryption component. All it needs is access restriction to your server's IPs. Integration by POST (Index or Passthru) permits the use of practically all methods of payment, with just a few exceptions. Depending on the integration and technical form of implementation, this integration may involve the buyer’s computer (Merchant customer), which reduces resistance to failures and permits buyer interference (Merchant customer) in the process. For example, he can press ESC or F5 and interrupt the transaction without knowing the result. This manual only covers integration by POST (Index and Passthru). The manual for integration by Web service may be requested separately from Customer Relations through the support tool.

6. INTEGRATION BY POST: DIFFERENCE BETWEEN THE INDEX AND PASSTHRU MODEL

6.1 Post Index

In the integration by POST Index model, the buyer can choose the method of payment in the Braspag server (on a Braspag page with the look and feel of the Merchant). See example below:



In this model, it is possible to customize some parameters such as the image of the header and footer, background color of the method of payment screen and the background color of the title bar “Choose you desired method of payment”, size, type and font color.

6.2 Post Passthru

In the integration by POST Passthru model, the buyer chooses the method of payment on the Merchant’s website, as in the image below. There is greater flexibility in this model in relation to page layout for choosing the methods of payment since 100% of the design is defined by the Merchant. **For integration in the Passthru model, the developer must pay attention to the extra parameters specified in Table 2.



In both POST integration models, credit card or banking data will always be entered on a Braspag, Card Operator or Bank page, and never in the Merchant environment. Instructions on how to opt for the Passthru or Index model were sent together with the ID_Loja in the Kickoff e-mail.



7. TECHNICAL STEPS

ATTENTION! A1 – The use of frame and iframe resources in the call to Pagador system URLS IS NOT supported, because this practice causes interference in page operations for certain browser configurations / versions, due to loss of session. A2 – Support for programming languages, font codes or any fragment thereof, internal to the development of the integration will not be supported, even when supplied or cited in advance. A3 – As mentioned, the reconciliation of automatic bank slips only occurs through an agreement between the bank, the establishment and Braspag. Without this agreement, the system will not identify payment of the bank slips. Check with Customer Relations. It is extremely important for the establishment to require its bank manager to send only those payments already cleared in the payment confirmation files. Braspag will not be held responsible for payment information not cleared by the bank. Whenever possible, we will try to inform when a confirmed payment has not been cleared so manual reconciliation can be made. But Braspag DOES NOT GUARANTEE THE CLEARING OF SUCH.



1. Merchant sends a POST to Braspag, kicking off a transaction. See data to be sent in the POST in Table 1 below. The POST’s destination URL will be provided with the ID_Loja, in the Kickoff e-mail. This POST will be encrypted using the Encryption Component described in Annex 1.

2. Braspag receives the POST from the Merchant and begins the transaction with the

financial institution (credit card operator or bank) opening a new page for the buyer to enter card or bank account data for authorization.

3. The operator authorizes or denies the transaction.

4. The result of the transaction is returned to Braspag and stored.

5. Braspag sends a Return POST to the Merchant, informing the transaction authorization

result in real time. In Table 4, see the data that will be sent to the Merchant in this POST by Braspag. The Merchant will provide Braspag a URL to which this POST will be sent (Return URL). This step is highly recommended, but optional, since Braspag may also show the transaction result directly to the buyer (Merchant customer). However, in this case, the Merchant will not receive the return of the transaction so it can be stored in the Merchant database. In this case, the Merchant administrator would need to always check the status of the transactions in the Braspag Administrative Environment. The return POST is sent encrypted and it will be necessary to use the encryption component for correct receipt (described in Annex I).

6. Braspag sends the Status Change Return. This step is highly recommended. This

Return, sent by POST, is used to inform the Merchant server of payment for a transaction that did not have an immediate return, such as a bank slip which is only paid after the buyer (Merchant customer) makes the payment and the bank sends the reconciliation file to Braspag. Thus, by confirming payment (reconciling the bank slip), the Braspag server will send the POST informing the Merchant server that payment has been made. Another example where this Return is very useful is when the Merchant uses capture delay in credit card transactions. As soon as the transaction is captured and its Status changes to “PAID”, Braspag automatically sends the Status Change Return to the Merchant URL registered in the Braspag system. In Table 5, see the data contained in the Return by POST. The Status Change POST is sent encrypted and it will be necessary to use the encryption component for correct receipt (described in Annex I).

Observation: in a case where the method of payment chosen by the buyer is the Bank Slip, steps 2), 3) and 4) are replaced by: “The Braspag Server generates a bank slip and exhibits it on the screen for the buyer so the bank slip can be printed and paid by the Merchant customer."

ATTENTION! It is extremely important for the Status Change URL (step 6) to only accept the POST from IPs informed by Braspag (request the list of IPs from the Customer Relations Area). Thus, the system will guarantee not receiving a forged (fraudulent) receipt, ensuring transaction security through the use of Encryption (Annex 1).



6.1. STEP 1: Parameters to be sent in the Send POST The Send POST forwarded to Braspag will contain the following parameters in accordance with the chosen model.

� POST INDEX MODEL Table 1 – Post Index Parameters

Parameter Description Size min Max

Mandatory ?

ID_Loja Single Merchant identifier 38 38 Yes

VENDAID Number of 1 50 Yes

VALOR Total amount of order in cents (ex.: R$ 1.00 = 100)

Yes

NOME Buyer’s Name 1 255 Yes

CPF Buyer’s CPF (if individual taxpayer) 11 14 Yes

RAZAO_PJ Name of company (if legal entity) 1 255 Yes

CNPJ CNPJ Number (if legal entity) 14 18 Yes

LOGRADOURO Buyer’s Street Address (ex.: St., Ave., Boul...)

1 255 No

ENDERECO Buyer’s Address (ex.: street name) 1 255 No

NUMERO Buyer’s Address Number No

COMPLEMENTO Buyer’s Address Complement No

BAIRRO Buyer’s District 1 255 No

CIDADE Buyer’s City 1 255 No

CEP ZIP Code 8 9 No

ESTADO Buyer’s State 2 2 No

PAIS Buyer’s Country 1 255 No

NASC Buyer’s Date of Birth (format: dd/mm/yyyy 10 10 No

MARITAL STATUS Buyer’s Marital Status (Single = S; Married = C; 1 1 No

GENDER Buyer’s Gender (M or F) 1 1 No



PROF Buyer’s Profession 1 255 No

DDD Dial code number of direct distance (Cielo for payment with mobile phone use that field for DDD)

2 Only for payment

Cielo Mobile

FONE Buyer’s Phone Number (for Oi Paggo, send cell phone number with Area Code in this field)

1 64 Only for Cell Phone

FAX Buyer’s Fax Number 1 64 No

E-MAIL Buyer’s E-mail 1 255 No

LOGRADOURO_D Street Address for Delivery (ex.: Street, Avenue, Road... )

1 255 No

ENDERECO_D Address for delivery 1 255 No

NUMERO_D Address Number for Delivery No

COMPLEMENTO_D Address Complement for Delivery No

BAIRRO_D District for delivery 1 255 No

CIDADE_D City for Delivery 1 255 No

CEP_D ZIP Code for Delivery 8 9 No

ESTADO_D State for delivery 2 2 No

PAIS_D Country for delivery 1 255 No

TRANSACTIONTYPE –

Novo! Indicates the type of transaction (Table 4) 1 1 Sim

TRANSACTIONCURRENCY – Novo!

Indicates the transaction currency (ISO 4217) 3 3 Sim

TRANSACTIONCOUNTRY – Novo!

Indicates the transaction country (ISO 3166-1 Alfa-3)

3 3 Sim

BRASPAGORDERID –

New!

Order identifier created internally. If this field has already been filled in it means the transaction has already gone through Braspag and it wants to add more transactions to the same order

GUID

No

LANGUAGE – New! Language used on payment pages. (Table 3) 5 5 No

EXTRA [name you want to give the field]

Additional information the Merchant wants to associate to the transaction. This parameter is never returned. It can only be accessed by the Administrative environment

1 768 No



(back office). If a parameter is sent with the name “ExtraInfo”, it will appear as “Info” in the back office. DYNAMIC URL – should be sent in this parameter and it may contain up to 500 characters and it is not mandatory.

IMPORTANT: The string sent should contain at least the mandatory parameters: VENDAID, VALOR, NOME/RAZÃO_PJ and CPF/CNPJ.

Example of POST Index sent in Step 1

<form name="form1" method="post" action="https://www.pagador.com.br/pagador/index.asp"> ID_Loja <input type="hidden" name="Id_Loja" value=""><br> Venda_ID <input type="text" name="VendaId" value=""><br> Valor <input type="text" name="Valor" value=""><br> Name <input type="text" name="Nome" value=""><br> CPF <input type="text" name="Cpf" value=""><br>

<input type= "submit">

Example of Encrypted POST Index sent in Step 1

<form name="form1" method="post" action="https://www.pagador.com.br/pagador/index.asp"> Id_Loja <input type="hidden" name="Id_Loja" value=""><br> Crypt <input type="hidden" name="crypt" value=""><br> <input type= "submit"> </form>



� PASSTHRU MODEL In the Passthru Model, the URL to which the POST should be sent is different from the one used in the Index model. The parameters should also be encrypted using the Encryption Component described in Annex 1. The two URLs are informed together with the Id_Loja in the Kickoff. The parameters that should be sent to Pagador in the Passthru model are the same as in Table 1, plus the CODPAGAMENTO, PARCELAS and TIPOPARCELADO parameters. Table 2 – Additional parameters to be sent in the PASSTHRU model


Mandatory

ID_Loja Single Merchant identifier 38 38 Yes

VENDAID Number of 1 50 Yes

VALOR Total amount of order in cents (ex.: R$ 1.00 = 100) Yes

NOME Buyer’s Name 1 255 Yes

CPF Buyer’s CPF (if individual taxpayer) 11 14 Yes

CODPAGAMENTO Identification of the method of payment (Table 8)

2 3 Yes

PARCELAS Number of installments in which the total sum will be divided (standard = 1)

1 2 Yes

TIPOPARCELADO

Cielo New Platform: Cash = 0 Installment Merchant, no interest = 1 Installment issuer, with interest = 2 Other Purchasers: Cash = 0 Installment Merchant, no interest = 1 Installment issuer, with interest = 2

1 1 Yes

RAZAO_PJ Name of company (if legal entity) 1 255 Yes

CNPJ CNPJ Number (if legal entity) 14 18 Yes

LOGRADOURO Buyer’s Street Address (ex.: St., Ave., Boul...) 1 255 No

ENDERECO Buyer’s Address (ex.: street name) 1 255 No



NUMERO Buyer’s Address Number No

COMPLEMENT Buyer’s Address Complement No

BAIRRO Buyer’s District 1 255 No

CIDADE Buyer’s City 1 255 No

CEP Buyer’s ZIP Code 8 9 No

ESTADO Buyer’s State 2 2 No

PAIS Buyer’s Country 1 255 No

NASC Buyer’s Date of Birth (format: dd/mm/yyyy

10 10 No

ESTCIVIL Buyer’s Marital Status (Single = S; Married = C; 1 1 No

GENDER Buyer’s Gender (M or F) 1 1 No

PROF Buyer’s Profession 1 255 No

DDD Dial code number of direct distance (Cielo for payment with mobile phone use that field for DDD)

2 Only for payment

Cielo Mobile

FONE Buyer’s Phone Number (for Oi Paggo, send cell phone number with Area Code in this field)

1 64 Only for Cell

Phone

FAX Buyer’s Fax Number 1 64 No

E-MAIL Buyer’s E-mail 1 255 No

LOGRADOURO_D Street Address for Delivery (ex.: Street, Avenue, Road... )

1 255 No

ENDERECO_D Address for delivery 1 255 No

NUMERO_D Address Number for Delivery No

COMPLEMENTO_D Address Complement for Delivery No

BAIRRO_D District for delivery 1 255 No

CIDADE_D City for Delivery 1 255 No

CEP_D ZIP Code for Delivery 8 9 No

ESTADO_D State for delivery 2 2 No



PAIS_D Country for delivery 1 255 No

BRASPAGORDERID – New!

Order identifier created internally. If this field has already been filled in it means the transaction has already gone through Braspag and it wants to add more transactions to the same order

GUID

No

CREDITCARDTOKEN –

New! Credit card token Stored in JustClick 36 36 No

SAVECREDITCARD –

New!

Indication to save the credit card or not for use in JustClick (this is a Boolean parameter: True or False)

4 5 No

TRANSACTIONTYPE –

New! Indicates the type of transaction (Table 4) 1 1 Yes

TRANSACTIONCURRENCY – New!

Indicates the transaction currency (ISO 4217) 3 3 Yes

TRANSACTIONCOUNTRY – New!

Indicates the transaction country (ISO 3166-1 Alfa-3)

3 3 Yes

LANGUAGE – New! Language used on payment pages. (Table 3)

5 5 No

EXTRA [name you want to give the field]

Additional information the Merchant wants to associate to the transaction. This parameter is never returned. It can only be accessed by the Administrative environment (back office). If a parameter is sent with the name “ExtraInfo”, it will appear as “Info” in the back office. DYNAMIC URL – should be sent in this parameter and it may contain up to 500 characters and it is not mandatory.

1 768 No

Example PASSTHRU POST sent in Step 1

<form name="form1" method="post" action="https://www.pagador.com.br/pagador/Passthru.asp"> Id_Loja <input type="hidden" name="Id_Loja" value=""><br> VendaId <input type="text" name="VendaId" value=""><br> Valor <input type="text" name="Valor" value=""><br> Nome <input type="text" name="Nome" value=""><br> CPF <input type="text" name="Cpf" value=""><br> CodPagamento <input type="hidden" name="codpagamento" value=""><br> Parcelas <input type="hidden" name="PARCELAS" value= ""><br> Tipoparcelado <input type="hidden" name="TIPOPARCELADO" value= ""><br> <input type= "submit"> </form>



IMPORTANT: The string sent should include at least the mandatory parameters: VENDAID, VALOR, NOME/RAZAO_PJ, CPF; CNPJ, CODPAGAMENTO, PARCELAS, TIPOPARCELADO.

Table 3 – Transaction Language (LANGUAGE–indicates the language to be used on the payment pages).

Code Presentation Language

pt-BR Portuguese (Brazil)

en-US English (American)

Es-ES Spanish

Table 4 – Type of Transaction (TRANSACTIONTYPE – indicates the type of transaction that is being sent).

Code Type of Transaction

1 Pre-Authorization

2 Automatic Capture

3 Pre-Authorization with Authentication*

4 Automatic Capture with Authentication

* With Authentication only for Cielo methods of payment. * Payment Cielo Mobile Pós Pago and Payment Cielo Mobile Pré Pago only accept the value type Transaction 3 and 4

Example of Encrypted Passthru POST sent in Step 1

<form name="form1" method="post" action="https://www.pagador.com.br/pagador/passthru.asp"> Id_Loja <input type="hidden" name="Id_Loja" value=""><br> Crypt <input type="hidden" name="crypt" value=""><br> <input type= "submit"> </form>



6.2. STEP 5: Parameters to be received by the Merchant in the Return POST After conclusion of transaction authorization (Step 4), the Merchant will receive a Return POST in the URL registered in our database (Return URL, Step 5) with the following parameters from Table 5 (below). Table 5 - Parameters to be received by the Merchant in the Return POST


FORMAPAGTO Method of payment used by the buyer 1 128

CODPAGAMENTO Method of payment code (Table 8) 2 3

CODRETORNO Code for the transaction error sent by the operators or by the banks 1 128

DESRETORNO Description of transaction error – description of operator or bank (empty if there are no errors)

0 512

VENDAID Order number 1 50

VALOR Amount of the order in cents (R$ 1.00 = 100)

CODAUTORIZACAO Code for the credit card authorization or the bank slip code. 1 768

TRANSID Transaction code (for the credit card) 1 256

RespostaAVS Return from address verification made with the card administrator (If AVS is activated)

1 64

PARCELAS Number of installments for the transaction 1 2

LINHADIGITAVEL Bank slip field 47 54

LANGUAGE – New! Language sent by the Merchant (this field will only return of the Merchant sent it) (Table 3)

5 5

BRASPAGORDERID Identifier of the request internally created 36 36

CREDITCARDTOKEN – New!

Credit card token Stored in JustClick (only for customers who have activated JustClick) 36 36

Important: The return URL in Step 5 may only use port 80 (standard for http) or port 443 (standard for https). No other port may be used, for example, URL http://www.loja.com:5555/retorno.asp IS NOT VALID and may not be used. The return POST is sent encrypted and it will be necessary to use the encryption component for correct receipt.



6.3. STEP 6: Parameters received by the Merchant in the Status Change Response When order payment status changes to “Paid”, if previously configured for such, the Merchant will receive another POST in the registered URL (Status Change URL) to indicate confirmation of the payment. This URL is different from the one used for the first POST in Step 5! The parameters the Merchant will receive are in Table 6 below. Table 6 – Parameters Received by the Merchant in Step 6 (Payment Status Change Response)


NumPedido Order number 1 50

Status Status of the Payment (Table 7) 1 1

CODPAGAMENTO Method of payment code (Table 8) 2 3

Table 7 - Status of the Payment

Status Description

0 Paid

1 Authorized, pending capture

2 Not authorized

ATTENTION! Step 6 (Status Change Response) is HIGHLY RECOMMENDED by Braspag.



When accessed by the Braspag Server, sending the POST from Table 6, the URL registered for the Status Change Return provided by the Merchant should exhibit a code informing receipt of the status change and that is was successfully processed. The Code is just the following XML: <status>OK</status> If the Merchant’s status change URL is accessed by the Braspag server and it does not exhibit the confirmation code, the Braspag Server will try again, a total of three times, once per hour. If the <status>OK</status> is still not exhibited, it will be understood that the Merchant server does not respond, and an e-mail will be sent to the person in charge of the Merchant, informing that the order in question has been paid.

� Example of a pseudo-code about what the page of the Merchant that receives the Status Change POST could look like:

That is, the font code for the page indicating Success should contain ONLY <status>OK</status> and nothing else. Observation: The Payment Status Change URL of Step 6 may only use port (standard for http) or port 443 (standard for https). No other port may be used, for example, URL http://www.loja.com:5555/status.asp IS NOT VALID and may not be used.

Example of POST your URL:

FORM/POST PARAMETERS

Status: 0 NumPedido: 16135 CODPAGAMENTO: 501

RAW BODY

NumPedido=16135&Status=0&CODPAGAMENTO=501

Read POST Numpedido, Status and Codpagamento. Try to update the Numpedido transaction status in the Merchant database to PAID. If able to update normally: Print <status>OK</status>

ATTENTION! It is of utmost importance for the Status Change URL (step 6) to only accept the POST from IP numbers informed by Braspag. The system will thus guarantee non receipt of a forged (fraudulent) POST, guaranteeing security in the transaction. If the Merchant uses encryption, the Return Post and the Status Change Post will be sent encrypted and it will be necessary to use encryption component/web service for correct receipt (Annex 1).



Table 8 –Payment Methods

Codes Methods of Payment

06 Boleto Bradesco

07 Boleto Caixa Econômica Federal

08 Boleto HSBC

09 Boleto Banco do Brasil

10 Boleto Real ABN AMRO

11 Débito Bradesco (SPS)

12 Itaú Shopline

13 Boleto Citibank

14 Boleto Itaú

15 BBPag

16 RealPague

28 Real FLV

30 Débito Banrisul

31 Débito Unibanco

32 Financiamento BBPag

34 Financiamento Eletrônico Bradesco

35 PAYPAL EXPRESS CHECKOUT

92 Débito HSBC

111 SafetyPay

123 Cielo Visa Electron

124 Boleto Santander

500 Cielo VISA

501 Cielo MASTERCARD

502 Cielo AMEX

503 Cielo DINERS

504 Cielo ELO

505 Banorte VISA

506 Banorte MASTERCARD



507 Banorte DINERS

508 Banorte AMEX

509 Redecard Webservice VISA

510 Redecard Webservice MASTERCARD

511 Redecard Webservice DINERS

512 PagosOnLine VISA

513 PagosOnLine MASTERCARD

514 PagosOnLine AMEX

515 PagosOnLine DINERS

516 Payvision VISA

517 Payvision MASTERCARD

518 Payvision DINERS

519 Payvision AMEX

520 Banorte Cargos Automaticos VISA

521 Banorte Cargos Automaticos MASTERCARD

522 Banorte Cargos Automaticos DINERS

523 AMEX 2P

524 SITEF VISA

525 SITEF MASTERCARD

526 SITEF AMEX

527 DITEF DINERS

528 SITEF HIPERCARD

529 SITEF LEADER

530 SITEF AURA

531 SITEF SANTANDER VISA

532 SITEF SANTANDER MASTERCARD

535 SUB1 – VISA

536 SUB1 – MASTERCARD



537 SUB1 - AMEX

538 SUB1 – DINERS

539 SITEF SONDA

540 SUB1 – NARANJA

541 SUB1 – NEVADA

542 SUB1 – CABAL

546 Alelo GiftCard

547 Cielo Payment by Mobile - Pós Pago

548 Redecard Hipercard

549 Cielo Payment by Mobile - Pré Pago

550 CredSystem

551 Boleto Caixa - SIGCB

552 Cielo Mastercard Débito

565 CREDZ

995 SIMULADO CAPTURA AUTOMÁTICA USD

996 SIMULADO CAPTURA AUTOMÁTICA EUR

997 Simulado

8. ACCEPTANCE OF METHODS OF PAYMENT AND TESTS

Each method of payment has its respective rules for acceptance. In order to speed up the acceptance process, we list all the requirements for each of the methods so the acceptance process and the Merchant can get started quickly. Any of the methods of payment can change the acceptance requirements at any time, without advance notice, and this manual will not necessarily accompany these changes in real time. Acceptance requirements: The operators 1 - Cielo and 2 - Pagamento Fácil Bradesco (see below) require that the following information be showed to the buyer (Merchant customer) after the transaction (in Step 5):

1. Cielo

a) Show all POST fields returned by Pagador (in Step 5). No field may be hidden.

b) Only for VISA, when the CODRETORNO sent by PAGADOR is “ “ (space), replace with



00.

2. Pagamento Fácil Bradesco

a) The authorization code should be exhibited as follows (16 characters per group): J34JK20K0AL0L10L I88S710ALGNDI875 0987HH658910J56D 94KA84LP84JF8209 09649KSDO01899ID OK99008877GG6FTS 0L9K8J7H6G5F4D3S P01Q9OW23E4R9OI8 Z12X3CV6B78N9M09 019283IDM95JD86DE ODKU876309OISJH3 859OOK0192873JSH7 JD873JS8J20KSH74JF JD8J398O5KDF8J39D JD739JD7834JDF9H2 JDYJ28DH38YHD832

b) Bradesco also requires that the Merchant phone number for contact be shown. c) It should contain the date and time of the purchase. d) It should contain the payment period terms, such as: “Deadline for payment: 1 day.” e) The delivery data should be explained. In the case of a service, the period for releasing

the service. f) At the bottom of the page, the statement "Any doubt regarding the quality of the

delivery of these products / services, contact us at the phone shown above." TESTS The acceptance Merchants can be created with the following payment options: Cielo Visa (71), Cielo MasterCard (120), Amex (18), Bradesco Debit Card (11) and ABN AMRO Bank Slip(10). It is necessary to inform the implementation team of the test affiliation provided by the Acquirers. Every payment option has its characteristics. In order to run tests in the best manner possible, pay attention to the characteristics below. Important Observation about Test Cards The test card numbers shown below are not actually “cards”, but rather sequences of numbers that pass the credit card validity test. Thus, they are treated by acquiring systems as invalid cards. Therefore, in a production environment, they can never have a positive return, normally returning an error like “invalid card” or “transaction denied”. In an acceptance test environment, a positive return is possible; however, it is not guaranteed. Therefore, the objective behind testing with “test cards” is only to verify the information flow, check whether the Merchant system can send the information correctly to the Pagador system, and whether it is also able to correctly receive return information. After testing with “test cards”, tests can also be run with real credit cards, but it is necessary to be careful, because the test amount will be discounted from the card. It is thus best to run tests with low amounts.

� Amex There is a way to run tests. For such, you can use a testing card: Cardholder’s Name: TEST – Card no.: 345678000000007 – Security code 1234 – expiration 05/13

� Pagamento Fácil Bradesco



There is a way to run tests. For such, you should fill in all fields with the number “1”.



� ABN AMRO Bank Slip

There is a way to run tests. Simply choose the method of payment for the bank slip and check whether the bank slip was generated correctly on the screen.

� Cielo Use the test cards contained in the e-commerce KIT provided by the Acquirer when contracting the affiliation.

Why can I only test these methods of payment, but not method of payment X? These methods of payment for testing are sufficient for testing Merchant integration. If the Merchant successfully tested the issuance of an ABN AMRO bank slip, then it can successfully issue any bank slip. Simply send the corresponding method of payment Code for the other bank skip (see Table 3) and the bank slip from the other bank will be issued with the same success. The same occurs with other methods of payment, if the Merchant has been successfully integrated, the integration will function normally for any credit card, whether Master, VISA, Diners or Amex.



9. BRASPAG SUPPORT

See annex 7 below.

ANNEX 1 – USE OF THE ENCRYPTION COMPONENT

All data that travel between Braspag and the Merchant should be encrypted, for greater security. There are 3 ways for the Merchant to implement Encryption:

� DLL Cryptography. This is a DLL especially created by Braspag for the Merchant, which should be recorded (installed) in the server of the Merchant’s website. It will carry out all necessary encryption operations. It cannot be used in non-Windows environments (such as Linux, Unix, etc)

� Java Encryption Component This is an encryption component created in Java. The advantage is the possibility of using it in any environment, Linux, Unix, etc., but installation and use are more complex.

� Web service Cryptography. This is the ideal option for using cryptography, and it is generally the easiest to be implemented in any environment. The Merchant uses the Braspag web service, sending it the data to be encrypted or decrypted, and it receives the corresponding answer. The connection is made safely, with SSL (just like all Braspag web services), and the web service only accepts IP connections explicitly permitted by the Merchant. Ask RC for a web service cryptography manual, if needed.

Observation: more than one form of encryption can be used simultaneously. Request the sample files for your programming language. DLL Component (ASP and PHP) This is a DLL library in order to use the methods shown below for encrypting the fields to be sent in the POST. In order to install the library, you should save the file locally, click on Start, Execute and enter “regsvr32 C:\[DIRETORIO_DA_BIBLIOTECA]\BraspagCOM.dll”

ATTENTION! The use of the Encrypted Component is HIGHLY RECOMMENDED for POST integration.



Table 9

Method Function

bool setField(const char* field, const char* value)

Add a field and value pair to an encrypted string.

char* getEncrypted() Encrypts all fields already added by the setField and returns the resulting encrypted string.

bool setEncrypted(const char* cipher)

Receives the encrypted string as the parameter and it decrypts it, leaving the fields and values contained therein ready to be extracted by the getField

char* getField(const char* field) Returns the value of the field passed on as a parameter, if it was contained in the encrypted string and if it has been decrypted by setEncrypted.

void clearFields() Clear the fields

Example of use: Table 10

Encrypt Decrypt

Set crypt = erver.CreateObject("Braspag.Encryption") crypt.setField("valor", "100");

Set crypt = erver.CreateObject("Braspag.Encryption") crypt.setEncrypted(string_criptografada);

crypt.setField("vendaid", "10001"); string_criptografada = crypt.getEncrypted()

valor = getField("valor"); vendaid = getField("vendaid");

Post: <input type="hidden" name="Id_Loja" value="00000000-0000-0000-0000-000000000000"> <input type="hidden" name="crypt" value="<% Response.write string_criptografada %>"> JAVA Component This is a library used to encrypt those fields to be sent in the POST. When sending the data, create the object of encryption and then call the setField (field, value) method for all fields in the form EXCEPT Id_Loja. In the end, it is necessary to call the getEncrypted (key) method passing the encryption key (informed by Braspag). This method returns a string that contains the already encrypted fields. Only two fields should be passed on the form: Id_Loja which should be in clear text (not encrypted) and the “crypt” field, which should have the content returned using the getEncrypted (key) method



braspag.Encryption bCrypt = new braspag.Encryption(); bCrypt.setField("VENDAID", "1234"); bCrypt.setField("valor", "1500"); bCrypt.setField("NOME", "JOAO DA SILVA"); encryptedStr = bCrypt.getEncrypted("CHAVE");

<input type="hidden" name="Id_Loja" value="00000000-0000-0000-0000-000000000000"> <input type="hidden" name="crypt" value="dpBNUIyrxdH/JBu6... ...dfiubnOuyv76fOIf87">

When receiving the data, only the "crypt" field on the form will be sent to the page. This field should be read and passed on as the 1st parameter for the setEncrypted method. The second parameter for the setEncrypted method should be the encryption key (informed by Braspag). Right after that, you can call the getField () method, passing on the field you want to read.

braspag.Encryption bCrypt = new braspag.Encryption(); bCrypt.setEncrypted(encryptedStr, "CHAVE"); vendaid = bCrypt.getField("VENDAID"); amount = bCrypt.getField("valor"); name = bCrypt.getField("NOME");



ANNEX 2 – INTEGRATION FLOWS THROUGH THE POST FOR CREDIT CARDS



ANNEX 3 – Web service Interfaces (Consultation)

Consultation modalities permit conducting consultations of orders.

� GetDadosPedido Method This method will permit consulting the order status in Braspag via Web service. This method receives the following parameters:

Table 11 – Parameters received by the GetDadosPedido method

Parameter Description Max. Mandatory ?

merchantId

Merchant’s only identifier. Provided by Braspag. {00000000-0000-0000-0000-000000000000}

38 Yes

orderId Order number 20 Yes

� Return of GetDadosPedido Method The GetDadosPedido method will return the parameters shown below: Table 11.1 – Parameters returned by the GetDadosPedido method

Parameter Description Max. Type

CodigoAutorizacao Authorization code or empty if the order has not been authorized string

CodigoErro Error code or empty if there was no error string

MensagemErro Error message or empty if there was no error

string

CodigoPagamento Method of payment code – Table 9 string

FormaPagamento String containing the name of the method of payment string

NumeroParcelas Number of installments string

Status Order status – see table 8.1 int

Valor Order value float

DataCancelamento

Date and time of order cancellation, if it has been cancelled – format mm/dd/yyyy hh:mm:ss tt (tt = AM/PM)

string



DataPagamento Date and time of order payment, if it has been paid – format mm/dd/yyyy hh:mm:ss tt (tt = AM/PM)

string

DataPedido Date and time of order - format mm/dd/yyyy hh:mm:ss tt (tt = AM/PM)

string

TransId Transaction number at the acquirer string

BraspagTid Single identifier of the transaction at Braspag

string

Table 11.2 – Possible return statuses of the GetDadosPedido method

Status Code Description

Initiated 1 The order was sent to the acquirer, but it has not been finalized yet.

Finalized 2

The order has been finalized – if it has been authorized, the CodigoErro field will be empty. If it has been refused, the CodigoErro field will be filled in with the code returned by the acquirer.

Payment 3 The order has been authorized and confirmed.

Cancelled 4 The order has been cancelled.

ATTENTION! The order may be treated as paid only when status 3 (Paid) is returned.



� GetDadosCartao Method

This method returns all data related to the card used in the purchase and it receives the following parameters:

Table 12 – Parameters received by the GetDadosCartao method

Parameter Description Max. Mandatory

merchantId

Single Merchant identifier. Provided by Braspag. {00000000-0000-0000-0000-000000000000}

38 Yes


� Return of GetDadosCartao Method

The GetDadosCartao method will return the parameters below: Table 12.1 – Parameters returned by the GetDadosCartao method


Autenticada If the card has been submitted for authentication or not. - Bool

NumeroComprovante Proof of order number - string

Emissor Name of the cardholder - string

NumeroAutenticacao Identification of authentication of the card number at the issuing bank.

- string

NumeroAutorizacao Authorization Code - string

NumeroCartao Masked Card Number - string

NumeroTransacao Transaction Number - string



� GetDadosComprador Method This method returns all buyer related data. This method receives the following parameters: Table 13 – Parameters received by the GetDadosComprador method


merchantId


38 Yes


� Return of GetDadosComprador Method The GetDadosComprador method will return the following parameters: Table 13.1 – Parameters returned by the GetDadosComprador method


DataNascimento Buyer’s date of birth - string

Email Buyer’s E-mail - string

EstadoCivil Buyer’s marital status - string

Fax Buyer’s Fax - string

Identificacao Buyer’s Identification (CPF and CNPJ) - string

Nome Buyer’s Name - string

Profissao Buyer’s Profession - string

RazaoSocial If the buyer is a Merchant, this field will return the company name.

- string

Sexo Buyer’s gender - string

Telefone Buyer’s phone number - string



� GetDadosExtras Method

This method returns all extra fields related to the order. This method receives the following parameters: Table 14 – Parameters received by the GetDadosExtras method


merchantId


38 Yes


� Return of GetDadosExtras Method The GetDadosExtras method will return the following parameters: Table 14.1 – Parameters returned by the GetDadosExtras method


Campo Parameter passed on by the client - List

Valor Value of the parameter provided - List

� GetDadosBoleto Method This method returns all data related to the bank slip used in the purchase. This method receives the following parameters: Table 15 – Parameters received by the GetDadosBoleto method


merchantId


38 Yes




� Return of GetDadosBoleto Method The GetDadosBoleto method will return the following parameters: Table 15.1 – Parameters returned by the GetDadosBoleto method


NumeroDocumento Same as OrderID issued by the client.

- string

Instrucoes Information for payment of the bank slip. - string

Sacado Name of the recipient. - string

NossoNumero Identifier of the bank slip at the bank.

- string

LinhaDigitavel This is the numerical representation of the barcode.

- string

DataDocumento Date on which the bank slip was generated or issued. - string

Datavencimento Due date for the bank slip. - string

Cedente Contains the information concerning whoever issued the bank slip. (Merchant Data)

- string

Banco Financial institution responsible for billing

- string

Agencia Bank agency for bank slip payment - string

Conta Bank account for bank slip payment - string

Carteira Contains the code for the portfolio being used. - string

ValorDocumento Value of the Bank Slip - string



ANNEX 4 – DESCRIPTION OF SAMPLE FILES

There are some sample files in ASP together with this manual. If your Merchant uses the Index mode, you should look at the index.asp, formapgto.asp, recebe.asp and confirmacao.asp files. If your Merchant uses the Passthru mode, the files are index-passthru.asp, forma-passthru.asp, recebe.asp and confirmacao.asp index.asp Contains the catalog for the Merchant products. By clicking on the product he wants to buy, the buyer will be redirected to the registration screen. recebe.asp This page informs the buyer whether the purchase was made successfully or if there has been an error. It receives the purchase data: method of payment used, code and description of error, if any, order number, value, authorization code and transaction code. This is the page used in Step 5 in the diagram on Page 6. formapgto.asp The buyer enters his data and confirms the purchase. After this screen, the buyer will be redirected to the Braspag screen, where he will choose the method of payment (Step 1 in the diagram on Page 6). After finalizing the purchase, the buyer is once again redirected to the Merchant page (Step 5 in the diagram on Page 6, this Return URL is registered in our database). index-passthru.asp This is the sample file for the passthru mode. Contains the catalog for the Merchant products. By clicking on the product he wants to buy, the buyer will be redirected to the registration screen. The only difference between this file and index.asp is the page that will be called up next. formapgto-passthru.asp The buyer enters his data, chooses the method of payment he will use and confirms the purchase. After finalizing the purchase, the buyer is once again redirected to the Merchant page (page registered in our database). confirmacao.asp This page receives the POST confirming payment and it informs Braspag concerning its receipt. It receives the order number and the payment status and returns an XML saying <status>OK</status>. This is the page used in Step 6 in the diagram on Page 6.



ANNEX 5 – BRASPAG SUPPORT

STANDARD OF SERVICE – PROCEDURE FOR OPERATIONAL SUPPORT VERSION 1.7

1. SERVICE: The purpose of this document is to instruct the client concerning internal

procedures for Operational Support, response times in several stages of problem classification and to inform the systemic service levels.

This document may suffer periodic changes.

2. TECHNICAL: AVAILABILITY: This item deals with the availability of services provided the client in a production environment. Braspag maintains a dedicated team to not permit higher levels than those described in the SLA defined in the contract. * The (acceptance) test environments may undergo periodic updates and their availability may be compromised for an undetermined period of time. The same may occur with the environments not characterized as critical missions and consultation environments. 2.2. RESPONSIBILITY FOR THE SERVICE: Braspag is not responsible for any eventual downtime in any method of payment or error in affiliation registration. Support is trained, however, to provide information concerning the origin of these problems so they can be handled directly by the client. 3. COVERAGE AND PROCEDURES FOR OPERATIONAL SUPPORT: 3.1. BUSINESS HOURS: Braspag will attend to Support’s requests from Monday to Friday, 9:00 am to 6:00 pm, Brasília team. 3.2. CUSTOMER SERVICE CHANNELS AND CONTACT NORMS: WEB SUPPORT TEAM: This is the main support channel for Braspag clients. The calls can be opened and accompanied through the website: http://www.braspag.com.br/suporte/. A login and password are required for using it. If you still do not have a password, please request one at [email protected], informing your Merchant’s ID, Merchant name, complete name and telephone for contact. E-MAIL: There will be no support by e-mail. All messages sent to the old support e-mail will receive an automatic reply with instruction for the web support system. TELEPHONES: Phones should not be used for severity 3 or severity 4 calls.



ATTENTION: Calls to support can only be made with the call ticket number, obtained in the Braspag web support system at http://www.braspag.com.br/suporte/ Phone: +55 (21) 2111-4713 * Service calls to other extensions will not be permitted. * It is not permitted to open calls in e-mails or personal calls to Braspag employees. 3.3. CLASSIFICATION OF PROBLEMS AND RESPONSE TIMES: Problems will be classified by criticalness / severity and they will have response periods compatible with the urgency of demand. The table below describes possible demands, their classifications and expected response times: Table 16 – Parameters received by the GetDadosExtras method

Description of the Problem Severity Maximum

Response Time Examples

Doubts concerning integration, configuration and problems in the acceptance test environment, doubts related to a payment transaction, doubts in the acceptance process with banks and acquirers, or any other problem that does not generate transaction loss in a production environment.

Severity 4 (minimum)

48 work hours

How is my Visa acceptance test

process? Could I configure a return URL for my test environment?

Configuration in a production environment, implementation of the method of payment already accepted, bugs that generate incorrect information without impact on the purchase experience or on the production environment that does not hamper the purchase process (buyer perspective).

Severity 3 (moderate)

24 work hours

I didn’t receive the 2nd Post? Could I

activate the encryption key?

Impossible to conduct transactions with methods of payment already installed or any bug / problem in the production environment with an impact on the client purchase process (buyer perspective)

Severity 2 (serious)

2 hours Slow transactions

Any availability problem in a production environment that makes the system unable to receive and authorize transaction with all the methods of payment.

Severity 1 (critical)

30 minutes Apparently the server is out.



3.4. EMERGENCY SERVICE: Emergency Technical Support will be provided over the following lines: +55 21 8301-0143 (BR-RJ) +00 55 21 8301-0143 (USA) It can only be activates in the case of Severity 1, in accordance with the above table. Note: If your call is not handled immediately because our on-duty support team is on another call, or is already handling the problem, you must leave a message with the following information: Name Company name Phone for contact Which Method of Payment is not available. We will get back to you as soon as possible. The calls can be handled in Portuguese and English. 4. PROCEDURE FOR SOLVING CRITICAL PROBLEMS: In the case of downtime, the IT team is immediately activated by SMS and emails for immediate solution of the problem. If there is any conflict concerning the characterization of the problem, the Braspag IT manager should be contacted and he will define the level to be handled. In the absence of the IT Manager, any Department Manager may make the decision. The phone number in this case is 55 (21) 2111-4700. 5. UPDATES AND SCHEDULED INOPERATIVENESS: Within the standards described in item 2.1 in this document, Braspag may make the service inoperative for updates and server migration. When this procedure occurs, it should be carried out in the early morning hours to generate as little impact as possible on the operations of all clients. 6. OMBUDSMAN: The client who feels harmed by the process or whose service rules have been violated should forward his complaint to [email protected]. This message will trigger an internal process and the client will be contacted by an Ombudsman within 48 work hours. Note: At any time, the client may contact his account manager at Braspag. This contact will be provided when the partnership is officially started. 7. REPORT ON FAILURES: In cases of downtime, if requested, the client’s account manager at Braspag will send a Report with technical details about the failure, within 48 work hours.

pagador platform post integration - braspag · pagador – post integration manual phone: (21)...

Documents