VIRTUAL POS Merchant s Guide Operating Manual

Transcription

1 VIRTUAL POS Merchant s Guide Operating Manual Version 1.3

2 VERSION CONTROL VERSION DATE AFFECTS BRIEF DESCRIPTION OF THE CHANGE /05/2016 ALL Initial document /11/2016 ALL Concept review and data update /12/2016 ALL Adaptation of content to the entity /01/2017 Type of operation Minimal inclusion pre-authorization information 15% greater accepted /01/2017 Type of operation Autenticación information is updated Merchant s Guide Installation Manual 2

3 CONTENTS Version control BASICS - INTRODUCTION ACCEPTED CARDS POS LANGUAGES LOCAL/FOREIGN CURRENCIES SECURITY ELEMENTS... 6 CES (SECURE ECOMMERCE)... 6 CVV... 6 VELOCITY CHECKS BACK OFFICE TOOLS CLICK PAYMENT+TOKENIZATION REGULATION OPERATIONAL ASPECTS TYPES OF AUTHORIZATION REQUESTS ONLINE NOTIFICATION SYNCHRONIZATION SYNCHRONOUS ASYNCHRONOUS SYNCHRONOUS SOAP SYNCHRONOUS WSDL CUSTOMIZATION SECURITY MEASURES ADDITIONAL SECURITY MEASURES INTERNET FRAUD DETECTION SIGNS OPERATION CONTROL SELLING ABROAD DCC (Dynamic Currency Conversion) MULTI-CURRENCY SETTLEMENT ACCESS TO THE TESTING AREA ADMINISTRATION MODULE CONSULTATION AND MANAGEMENT OF OPERATIONS Merchant s Guide Installation Manual 3

4 CONFIRMATION OF AN OPERATION MAKING A REFUND REPORT TOTALS QUERY QUERY NOTIFICATION PASSWORD CHANGE Merchant s Guide Installation Manual 4

5 1. BASICS - INTRODUCTION BBVA has reinforced its ecommerce services and has a specific unit in which managers specializing in virtual payment platforms and a back-office team work to provide our customers with differentiated and secure solutions, as well as a wide range of services in the field of online sales. The BBVA Merchant's Guide includes aspects to be taken into account by merchants wishing to use the BBVA Virtual POS in implementing their online purchases, as well as all the functionalities (operating profiles, types of authorization requests, security level of payments, etc.) and technical specifications required to connect the merchants to the Virtual POS. It also details the options available in BBVA's administration application, which is very useful for managing the merchant's orders ACCEPTED CARDS The same cards are accepted as those admitted in merchants with a physical POS, namely Visa, Visa Electron, MasterCard and Maestro. The possibility of operating with JCB cards is available upon request, as well as American Express and Diners Club POS LANGUAGES Virtual POS supports 13 different languages: - Castilian - English - French - German - Dutch - Italiano - Swedish - Portuguese - Valencian - Polish - Catalan - Galician - Euskera. Merchant s Guide Installation Manual 5

6 1.3. LOCAL/FOREIGN CURRENCIES Transactions can be processed with the vast majority of the world's currencies, for example: - Euros - Dollars - Pounds - Yen - Canadian Dollar - New Mexican Peso - Swiss Franc - Brazilian Real At BBVA, we give you the option to receive payment for sales made in the same currency as the original operation. In this way, the merchant eliminates exchange rate risks. For more information go to section 4. SELLING ABROAD SECURITY ELEMENTS BBVA's Virtual POS offers the highest level of security features to protect merchants from possible fraudulent payments: CES (SECURE ECOMMERCE) BBVA's virtual POS system integrates CES (Secure Electronic Purchase) which, under the international Verified by Visa and MasterCard SecureCode protocols (both based on 3DSecure technology), provides high security and payment protection. By applying these protocols, the cardholder authentication is achieved when making the purchase, i.e. the customer is identified as the legitimate cardholder of the card being used. CVV BBVA's virtual POS system requires the card's CVV2 (series of three numbers on the back of the card) to be entered as an anti-fraud measure. Merchant s Guide Installation Manual 6

7 VELOCITY CHECKS The security filters or Velocity Checks that are configured in the virtual POS allow fraud prevention. Different parameters of the purchase data are validated, such as IP, card number, number of attempts, and if the operation does not pass these security filters, the operation is denied BACK OFFICE TOOLS The operations of the virtual POS can be consulted and managed from a tool available to our merchants: the ADMINISTRATION MODULE (See Appendix 6). From this tool you can perform, among others, queries of virtual POS transactions, totals queries, cancellations of operations and partial or total refunds. In addition, BBVA's e-commerce solution includes a system for periodic information reporting that complements the information that is usually sent to merchants. These files contain information about the settled transactions, the Chargeback claims that have been received, confirmed fraud that affects the merchants and document retrieval requests CLICK PAYMENT+TOKENIZATION 1-Click Payment or Tokenization consists of the card data being stored in the gateway itself, providing the merchant with an Alias (Token) so that it can request payments to that card without the need for the buyer to enter that information each time. This simplifies and streamlines the checkout process for recurring buyers, which is especially useful in mobile environments. Since merchants do not process or store card data, they do not have to comply with the requirements of PCI-DSS Regulations. PCI-DSS (Payment Card Industry - Data Security Standard) are the security standards (technical and operational requirements) that must be met by all participants in the industry who process or store card data (financial institutions, merchants, service providers, software companies, etc.) To activate this option, you will need to request it at your branch, through Línea Comercio or, if you already have one assigned, your ecommerce manager. Merchant s Guide Installation Manual 7

8 1.7. REGULATION By its nature, the Virtual POS is subject to rules that derive from its participation in international payment channels and BBVA's management of them. These regulations are included in the contract for establishments signed between BBVA and the merchant. Some of the most pertinent rules are listed below: 1. The merchant may only process transactions originating from the website(s) registered in the contract with BBVA. 2. The website must meet the following requirements, among others: o The name of the merchant and the name of the owner, whether natural or legal, of this website must appear on the homepage and on the site's payment page, as well as the merchant's registered address or domicile (including the country). o Cancellation of purchases and product return policy. o Policy on shipment of goods and delivery time, or on service delivery, as appropriate. o Customer Care Service details, address and telephone number. o Personal data protection and privacy policy. 3. The merchant will immediately cancel card transactions when an undue charge has been made, or the sale and delivery of goods has not fully materialized. 4. The merchant may not store the card data at its facilities by any means, except if this is required from an operational point of view. In which case it will be subject to the VISA and MASTERCARD PCI/DSS Security program. Even in this case it is strictly forbidden to save the CVV2 under any circumstances. Merchant s Guide Installation Manual 8

9 5. The merchant may only process operations under the same number of establishments that fall under the activity code with which it is registered. In addition, in cases where the merchant engages in special activities (tobacco, medicines, adult content, airlines or gambling), it must expressly request prior authorization from BBVA to transmit the proposal to the card brands. 6. The merchant will be subject to Spanish laws for the Protection of Consumers and Users, and in particular to the articles that regulate Non- Face-to-Face Sales. To this end, Law 3/2014, dated March 27, which modifies the Text of the General Law for the Protection of Consumers and Users and other related laws, approved by Royal Legislative Decree 1/2007, dated November 16, and implementing Directive 2011/83/EU of the European Parliament. 2. OPERATIONAL ASPECTS 2.1. TYPES OF AUTHORIZATION REQUESTS Depending on each merchants' needs, the Virtual POS offers a wide variety of authorization requests, which the merchant can combine according to its needs. Standard payment (Ds Merchant TransactionType = 0 ) This is the most general case. In it the transaction is initiated by the cardholder who is present during the transaction process. Once the purchase request has been received by the merchant, the Virtual POS asks the customer for the data to carry out the authorization transaction. If the cardholder's bank has an authentication system, the cardholder will be asked by the issuing bank to provide proof of authentication, if the transaction has been processed by a terminal configured with secure purchase. The Authorization request is made in real time, producing an immediate charge to the cardholder's account associated with the card (credit or debit). It should be noted that the guarantees on both types of cards are identical. The transaction is captured automatically by the Virtual POS and sent daily to the batch process to be credited to the merchant. Merchant s Guide Installation Manual 9

10 The cardholder receives proof of payment. Pre-authorization (Ds Merchant TransactionType = 1 ) NOTE: according to the regulations on international brands, this operation is restricted to those merchants engaged in one of the following activities: hotels, travel agencies or car rental. This can be used when the exact amount of the transaction cannot be determined at the time of purchase or, for some reason, the merchant does not want the amount to be immediately debited from the customer's account. The transaction is transparent for the cardholder, who at all times acts exactly as in the previous case, that is to say, provides his or her data and it is authenticated if applicable, receiving the corresponding receipt from the Virtual POS. The pre-authorization request is made in real time, with the amount of the sale being withheld in the cardholder's account. The transaction is not captured and, therefore, there are no accounting effects on the cardholder's account and, consequently, no payment to the merchant (in the case of debit cards, some issuing entities do make accounting entries to the cardholder, which are automatically cancelled after a few days). All pre-authorizations must have a Pre-authorization Confirmation within a maximum period of 7 calendar days. Otherwise it will lose its validity as a payment guarantee. Pre-authorization confirmation (Ds Merchant TransactionType = 2 ) Inseparably complements the previous operation. The cardholder is not present and it is, therefore, always initiated by the merchant. This must be done within 7 days of the original pre-authorization and its amount must be LESS, EQUAL or, at most, up to 15% higher than the amount of the original transaction. Merchant s Guide Installation Manual 10

11 This transaction has an accounting effect, with the entry being automatically adjusted in the cardholder's account and it is sent to the batch process for payment to the merchant. The preauthorization confirmation is guaranteed payment and retains the conditions regarding the secure transaction of its original preauthorization. The Virtual POS will validate that the original operation exists and the amount to be confirmed. The operation will be rejected if there is an error. Pre-authorization cancellation (Ds Merchant TransactionType = 9 ) The cardholder is not present and it is, therefore, always initiated by the merchant. This must take place within 7 days of the original preauthorization. The Virtual POS will validate that the original operation exists and the operation will be rejected if there is an error. Partial or Total Refund (Ds Merchant TransactionType = 3 ) These are accounting transactions initiated by the merchant. You can also use the Virtual POS administration module to manage them manually. The Virtual POS verifies that the original authorization desired to be refunded exists, and that the sum of the amounts refunded never exceeds the original authorized amount. They have an accounting effect in the cardholder's account (some issuing entities may take a few days to credit the cardholder's account) and, therefore, are captured automatically and sent to the settlement process that will proceed to make the corresponding debit in the merchant's account. Recurring transaction (Ds Merchant TransactionType = 5 ) Allows the cardholder to sign up* to a regular service offered by the merchant. The total amount of this service will be paid by making a certain number of installments. Merchant s Guide Installation Manual 11

12 Through this operation, the merchant shall report the total amount to be paid, the minimum number of days from which payment of the next installment can be made and the deadline for payment of the last installment, which may not exceed 12 months. The transaction flow is similar to the normal authorization request. In addition, the customer must be informed of the total amount to be paid and the installments making it up. Authentication is carried out with these data. Conversely, the request for authorization, which will have an accounting effect, will only be made for the amount of the first installment as a normal authorization request. Subsequently, the merchant will send successive authorization transactions at the expiration of each installment. *The Pagol Click system, described later in this section, facilitates the subscription service by tokenization, so it is not necessary to know the number of installments to process and the periodicity may exceed 12 months. Successive Transaction (Ds Merchant TransactionType = 6 ) Inseparably complements the previous operation. The cardholder is not present and it is therefore always initiated by the merchant. This must be carried out according to the terms of the original recurring transaction in terms of amount, installments and deadline. These points will be validated by the Virtual POS, which will reject the transaction if there is an error. This transaction has an accounting effect, producing an entry in the cardholder's account for each installment and being sent to the daily settlement process for payment to the merchant. Successive transactions retain the same security conditions with respect to the original recurring transaction, except in cases where the original transaction was considered secure but the customer was not positively authenticated. In this case the successive ones are not considered secure. Merchant s Guide Installation Manual 12

13 A new request for authorization must therefore be made for each installment. Authentication (Ds Merchant TransactionType = 7 ) This type of operation can be used by the merchant when the sale amount cannot be precisely determined at the time of sale. The operation is similar to that of the pre-authorizations, since there is no posting line, but for this type of transaction nothing will be withheld from the cardholder's account. The CVV2 will be validated, and it will be checked whether the expiry date is correct and the card is active. It will not be validated whether the cardholder has a positive balance. For operations under 3D Secure, the card issuing bank will verify the cardholder's identity under its authentication criteria. Subsequently and within the following 45 calendar days the merchant will send an authentication confirmation that will complete the original operation. Authentication confirmation (Ds Merchant TransactionType = 8 ) Inseparably complements the previous operation. The cardholder is not present and it is therefore always initiated by the merchant. This amount may be different from the original transaction (even up to 15% MORE than the original amount). This transaction has an accounting effect, producing an entry in the cardholder's account and is sent to the daily settlement process for payment to the merchant. Authentication confirmations retain the same security conditions as the original authentication. The Virtual POS will validate that the operation exists and will reject it if there is an error. Merchant s Guide Installation Manual 13

14 Deferred Pre-authorization (Ds Merchant TransactionType = O ) These operations are similar to pre-authorizations but available for all sectors of activity. In real time, an authorization is obtained from the issuing bank that will have to be confirmed within 72 hours if the operation is to be carried out definitively. If, after 72 hours from the day/time of the preauthorization, the confirmation has not been sent, the authorization will be cancelled automatically and cannot be confirmed. Unlike traditional pre-authorizations, the amount of the Deferred Preauthorization Confirmation must be exactly the same as their respective pre-authorization. The pre-authorization request is made in real time, with the amount of the sale being withheld in the cardholder's account. The transaction is not captured and, therefore, there are no accounting effects on the cardholder's account and, consequently, no credit to the merchant (in the case of debit cards, some issuing entities do make accounting entries to the cardholder, which are automatically cancelled after a few days). To activate the Deferred Preauthorization service, this must be explicitly requested by the merchant at its BBVA branch. Deferred Pre-authorization confirmation (Ds Merchant TransactionType = P ) Inseparably complements the previous operation. The cardholder is not present and it is, therefore, always initiated by the merchant. It must be done within 72 hours of the original pre-authorization and its amount must be THE SAME as the original transaction. This transaction has an accounting effect, with the entry being automatically adjusted in the cardholder's account and it is sent to the batch process for payment to the merchant. The preauthorization confirmation is guaranteed payment and retains the conditions regarding the secure transaction of its original preauthorization. Merchant s Guide Installation Manual 14

15 The Virtual POS will validate that the original operation exists and the amount to be confirmed. The operation will be rejected if there is an error. Deferred Pre-authorization cancellation (Ds Merchant TransactionType = Q ) The cardholder is not present and it is, therefore, always initiated by the merchant. It must take place within 72 hours of the original pre-authorization. The Virtual POS will validate that the original operation exists and the operation will be rejected if there is an error. Recurring Deferred Pre-authorization (Ds Merchant TransactionType = R ) Similar to the Recurring Transaction it allows the cardholder to sign up to a regular service offered by the merchant. It differs, however, in that the first authorization shall not be valid for accounting purposes unless confirmation is made within 72 hours of pre-authorization. Unlike traditional pre-authorizations, the amount of the Recurring Deferred Preauthorization Confirmation must be exactly the same as their respective preauthorization. If, after 72 hours from the day/time of the preauthorization, the confirmation has not been sent, the authorization will be cancelled automatically and cannot be confirmed. The total amount of this service will be paid by making a certain number of installments. Through this operation, the merchant shall report the total amount to be paid, the minimum number of days from which payment of the next installment can be made and the deadline for payment of the last installment. Recurring and Successive Transaction Deferred Pre-authorization confirmation (Ds Merchant TransactionType = S ) The same type of transaction is used for both the confirmation of the 72 hours recurring pre-authorization (first operation) as for successive payments linked to this first authorization. Merchant s Guide Installation Manual 15

16 Inseparably complements the previous operation. A new request for authorization must therefore be made for each installment. The cardholder is not present and it is, therefore, always initiated by the merchant. This transaction has an accounting effect, producing an entry in the cardholder's account for each installment and being sent to the daily settlement process for payment to the merchant. Successive transactions retain the same security conditions with respect to the original recurring transaction, except in cases where the original transaction was considered secure but the customer was not positively authenticated. In this case the successive ones are not considered secure. 1-Click Payment+Tokenization This operation allows merchants the option of storing customer card data without the need for PCI DSS compliance. It is the recommended payment method for subscriptions with no pre-defined expiry date or for merchants who want to facilitate the subsequent payments of their customers by eliminating a step in the purchase process. The merchant will send a first payment in the customer's presence, to which subsequent payments can be added without the customer being present. The merchant will not have access to card data. The operations will be identified by a reference that will be generated at the time of the first payment and that will be provided to the merchant in the operation's response. This request can be made by any of the different inputs: realizarpago (makepayment) or WebService. When processing the transaction, if the merchant accesses through the realizarpago input, we will ask the cardholder for the card number along with the expiry date and the CVV2. We will process the operation, storing the card data (only card and expiry date, not CVV2) and associate it to a reference. This reference shall be reported to the merchant together with the payment response and expiry date. There is also the possibility to report encrypted card digits in the response: ******1234. Once the merchant already has a reference, its can send subsequent debits for all types of transactions: authorization, preauthorization, etc. The validity of this reference will coincide with the card's expiry date. Merchant s Guide Installation Manual 16

17 The merchant may also request a reference for those transactions processed by the merchant a year in advance (provided the card has not expired). IMPORTANT - in all virtual POS terminals the following payment methods are activated by default: 0, 3, 5, 6, 7, 8. If you want to use any payment method not included in the previous ones, you must request it from your management office or your e-commerce manager. The main characteristics of each type of operation are summarized below: Transaction Type Started by Accounting Original Operation Validations Guarantee - Secure Transaction Authorization Cardholder Yes When conditions are met Preauthorization Cardholder NO When conditions are met Confirmation of preauthorization Merchant YES Preauthorization: 7 days Amount < or = Same as the original Cancellation of Preauthorization Merchant NO Preauthorization: 7 days Amount = Refund automatic merchant YES Authorization: Sum of amounts refunded < or =120 days Recurring Cardholder YES When conditions are met Successive Merchant YES Recurring: amount, installments and deadline If the original has been authenticated Authentication Cardholder NO When conditions are met Authentication confirmation Deferred Preauthorization Merchant YES Authentication: 45 days Same as the original Cardholder NO When conditions are met Deferred Preauthorization Confirmation Merchant YES Preauthorization: 72 hours maximum Amount = Same as the original Deferred Preauthorization Cancellation Merchant NO Preauthorization: 72 hours maximum Deferred Recurring Preauthorization Cardholder NO When conditions are met Deferred recurring pre-authorization confirmation Merchant YES Recurring Preauthorization: 72 hours maximum Amount = If the original has been authenticated Successive Preauthorization Merchant YES Recurring Pre-authorization: amount, installments and deadline If the original has been authenticated Merchant s Guide Installation Manual 17

18 2.2. ONLINE NOTIFICATION We recommend receiving the result of the transaction by notification via HTTP, which will allow us to receive communications online and in real time with the result of each purchase made on your website. A more detailed description of this option can be found in the Installation section. NOTE: this mechanism does not make sense in HOST to HOST (WebService) connections as the merchant never loses control of the session during the purchase. The IPs from which these notifications can be received are: SYNCHRONIZATION This parameter is related to the online notification described in the previous section. Allows four values: SYNCHRONOUS This implies that the result of the purchase is first sent to the merchant and then to the customer and with the value Even if the confirmation is incorrect, the operation does not change. ASYNCHRONOUS Implies that the result of the authorization is communicated both to the merchant and the customer. SYNCHRONOUS SOAP The notification sent to the merchant is a SOAP request to a service that the merchant must have published. With this type of notification, the SIS does not reply to the cardholder until it receives the merchant's confirmation that is has received the notification. In the event that the SOAP response sent by the merchant has a KO value or an error occurs in the notification process, a negative response will be given to the cardholder and the transaction will not be authorized. This type of notification will only apply to the following operations: Authorization, Preauthorization, Recurring Transaction and Authentication. For all other operations, the notification shall be sent synchronously. Merchant s Guide Installation Manual 18

19 SYNCHRONOUS WSDL Just like Synchronous SOAP, but in this case the SOAP server developed by the customer conforms to the specifications of a WSDL that is attached in the Installation section CUSTOMIZATION The screens that are displayed to the customer during the checkout process can be customized. By default, the image displayed in the payment is as follows: There is a customization tool that can be accessed by the merchants and that allows you to modify the colors, logo, information to display on the payment page, buttons, etc. In order to access this service, the merchant must request access to the tool from its branch, Línea Comercios or, if they have one assigned to them, their ecommerce manager. It is also recommended to request the specific manual that exists to carry out such customization. Merchant s Guide Installation Manual 19

20 3. SECURITY MEASURES Since they are carried out in a non-face-to-face environment, Virtual POS operations are the most susceptible to receiving fraudulent card payments where the cardholder is not the one making the purchase. To reduce the risk of these transactions, BBVA will apply a number of conditions that limit each merchant's operations. These limitations have to be adjusted to values that do not place conditions on the merchant's sales expectations but at the same time avoid exaggerated deviations from its usual turnover (in most cases they mean that an attack is taking place with stolen and/or fraudulent cards.) Maximum number of operations per day (authorized and denied) Maximum amount per operation S Maximum daily cumulative maximum amount Maximum number of operations (accepted and denied) per card per day Maximum amount per card per day Maximum number of transactions (accepted and denied) per user (IP address) per day Maximum amount per user (IP address) per day Operational restriction by country Etc. Any modification of the security measures will have to be requested at your BBVA branch. ADDITIONAL SECURITY MEASURES To protect the interests of your merchant and reduce the volume of incidents to a minimum, we suggest taking the following additional security measures when accepting card payments. INTERNET FRAUD DETECTION SIGNS When any of the following signs appear on an online purchase, the merchant must be suspicious of it, but when more than one sign appears, the merchant must take steps to avoid becoming a victim of fraud. Merchant s Guide Installation Manual 20

21 First time shopper in the store Multiple operations with the same card or user or IP address in a short period of time Multiple operations with the same card (or similar numbering cards) with different delivery addresses. Operations with similar card numbers. Orders with the same shipping address but made with multiple cards Multiple cards used from the same IP address, or with the same address or DNI of the registered user. Orders consisting of multiple quantities of the same product Orders with a higher-than-normal amount Orders in which the delivery has to be express, or even "next day". The criminals want these products obtained fraudulently as soon as possible, for a possible resale and are not concerned about the extra charge for delivery. Orders for high value products. These products have a high resale value. Orders shipped to international addresses. Operations of purchasers, IP addresses or card numbers that have previously processed transactions rejected for possible fraud or that have been reported as fraudulent. OPERATION CONTROL The VIRTUAL POS ADMINISTRATOR MODULE informs the buyer's IP ADDRESS and it should be verified that: The same user (same IP address) has not paid (or tried to pay) with more than two different cards. A single user (IP), or the same card, have not performed multiple operations in a short period of time. Merchant s Guide Installation Manual 21

22 Purchases are not being made with generated cards (the first digits of the card numbers are the same but the last ones change). When making different purchases, the same user (IP) or the same card has not been registered on the website with different data. If the terminal has rejected the first card operation, verify that no further transactions have been processed with the same IP or the same card for lower amounts. Using the response message (campo "DS_Response") or the ADMINISTRATION MODULE OF THE TPV VIRTUAL you are informed whether the transaction has been accepted (codes 000 to 099) or denied (other codes). Denial codes type 2xx indicate that the card is blocked due to loss, theft, counterfeiting of the card or fraudulent use of the card's numbering. In these cases the merchant will have to block the user (identifiable by IP address and registration data) in order not to allow it the option of trying any new payment. Also in the response message there is the field "Ds_Card_Country" which reports the I.S.O. code of the country where the card was issued. Through the comparison with the buyer's IP address, suspicious behavior can be filtered (e.g. a card issued in one country but operated by an IP from another country). Check the validity of the customer's registration data: Validate phone numbers using phone directories. Validate that the phone code and/or its prefix matches the geographical area of the order's shipping address. Validate correspondence between ZIP code and city of shipment. Validate the address by sending a confirmation order. Establish control limits based on multiple parameters. The merchant can significantly reduce its risk of exposure to fraud by applying proprietary transaction controls to identify high-risk transactions before sending them for processing. Such controls help to determine whether a cardholder or a transaction should be manually reviewed by the merchant. Apply revision limits based on the number and/or amount of operations performed by the same user in a given period of time. Merchant s Guide Installation Manual 22

23 Apply adjustment limits based on the amount of the sale. Ensure that these review limits are based on multiple parameters, including delivery address, phone number or address. Contact those buyers who exceed these limits to determine if the operation is legitimate and must be accepted, assuming that this operation has been accepted by the issuing bank. Do not allow buyers to use more than one user, or more than one card for each purchase. Change the operation controls and adjustment limits according to the own trading experience depending on each product, shipping locations and customers' purchasing patterns. If the operation does not pass all the indicated controls, the merchant must reject the card as a means of payment and cancel the POS transaction, if applicable. The merchant's management must be aware of these security measures, train all employees who manage card payments and periodically verify compliance with these security measures. If this is not the case, there is a risk that fraudulent transactions may be returned to the merchant and, if the number of transactions that have been lost or fraudulent is significant, the terminal may be blocked and the contract with BBVA terminated. 4. SELLING ABROAD BBVA's Virtual POS system adapts to the international expansion needs of merchants by integrating solutions that facilitate sales outside our borders: DCC (Dynamic Currency Conversion) This allows customers all over the world to pay in their own currency or in euros depending on the card's original currency. If the merchant has this option enabled, the system detects the card's currency, and the user is given the possibility to choose the currency in which to pay for the purchase, whether in Euros or in his/her original currency. In any case, the merchant will receive the payment in euros regardless of the currency in which the customer has made the payment. Merchant s Guide Installation Manual 23

24 MULTI-CURRENCY SETTLEMENT This service offers the possibility of settling the sales made by the merchant in the transaction's original currency (currencies traded in BBVA), enabling savings to be made on economic differences in exchange rates between the time of the transaction and settlement. Currencies that are not traded in BBVA (or have restricted use) will continue to be settled in euros. The merchant will have no financial losses due to exchange differences between the time of the transaction and the settlement of the remittance, or between settlement and its retrocession in the event of subsequent claims. There is no additional cost to the merchant. The merchant will receive the settlement of as many remittances as transactions in different currencies processed, provided they are currencies traded in BBVA. The rest of the invoicing will be settled grouped in a single remittance equivalent in euros. Merchant s Guide Installation Manual 24

25 CURRENCIES CURRENTLY TRADED IN BBVA To activate either of these two options, you must request it at your branch or through your ecommerce manager. 5. ACCESS TO THE TESTING AREA In order to carry out the installation tests, BBVA has a test environment identical to the production environment, but where sales are not valid for accounting purposes. Access to this environment requires access to ports and The characteristics of the test environment are detailed below. Payment URLs: Merchant s Guide Installation Manual 25

26 REDIRECTION INPUT - REALIZAR PAGO (MAKE PAYMENT): TEST ENVIRONMENT DATA The merchant will receive an with the access data and configuration of its business's test environment: Merchant number (Ds_Merchant_MerchantCode): XXXXXXXXX Terminal (Ds_Merchant_Terminal): 01 Secret code: sq7hjruobfkmc576ilgskd5sru870gj7 Card: Expiry date: 12/20 Security code: 123 CIP: ADMINISTRATION MODULE BBVA's Virtual POS system includes an administration tool where you can carry out all the formalities related to your business. It offers the possibility to consult the details of the sales made in real time. In addition to consulting the operations made, you can have a control of the accounting closures, manage refunds and display transactions that have not been completed correctly, obtaining information on the reason for refusal. By accessing the address (test environment) and (real environment), with username and password, which we will provide you with beforehand, you will be able to carry out all the management operations related to your business. Merchant s Guide Installation Manual 26

27 Once you have confirmed that the username and password entered are correct, you will have access to the Administration modules enabled for your merchant: Administration: Transaction query and POS management User: Management of your password and permissions to other business users, if any. Documentation: Availability of documentation related to your POS. Users and the level of access to administrative functions will be provided by BBVA in accordance with their needs. CONSULTATION AND MANAGEMENT OF OPERATIONS Within the "Administración" (Administration) module and in the "Consultas (Queries) section, you can intuitively query and manage all of a Virtual POS's operations. You will be able to view their details, make (total or partial) refunds, and manually confirm the types of operations that require it indicated above, for example, Deferred Authorizations. Merchant s Guide Installation Manual 27

28 The Virtual POS offers this possibility for the last 360 days of operations, and always carried out at intervals of 30 days maximum. That is, from 1 to 30 or 31 of the month or from to for example. In addition, all these operations can be exported to Excel and in.txt format. You can customize the transaction information by selecting "Columnas a mostrar (Columns to show). The response codes that are displayed in the "Resultado operación y código" (Operation result and code) field can be found in the Developer's Manual- Response codes (Ds_Response). The last column "Opciones" (Options) allows the merchant to consult the detail of the operation performed, make a copy of the receipt, as well as generate and query total or partial refunds of the operation. CONFIRMATION OF AN OPERATION Merchants with pre-authorization operations or deferred authorizations may generate confirmations and cancellations from the administration module. Merchant s Guide Installation Manual 28

29 Likewise, if the merchant works with the pre-authentication operation, it will be able to generate their confirmations. MAKING A REFUND Users who have configured the authorization to make refunds must select the option "Generar devolución (Generate refund) of the desired operation, which is in the last column. When you access this option, the transaction data is displayed, and a box to indicate the amount to be refunded, which may be partial or total (it must never exceed the amount of the original transaction). In the case of the DCC operation, you must enter the amount in POS currency: A refund receipt page will then be displayed that you can print or file if you wish. You can check a refund by clicking on the "Resumen devoluciones (Refunds Summary) option, which will appear in the last column:. ^ Authorized 182,03 _..., Merchant s Guide Installation Manual 29

30 REPORT By clicking on the "Informe" (Report) section on the left side of the screen, you can obtain a summary of the OK and not OK operations from the selected period. TOTALS QUERY By clicking on the "Totals" section on the left side of the main page, the system will ask for the period whose totals you want to consult and, optionally, the make of card. You then see the screen with the total amounts and number of operations, differentiated by each operation category, and a distinction between those authorized and those refused. Merchant s Guide Installation Manual 30

31 QUERY NOTIFICATION By clicking on the "Notificaciones" (Notifications) option, which appears on the left hand side of the page, you will be able to view the result of the OnLine Notification of the operations sent to the merchant in a desired date range and the result of the Notification will be displayed, informing you if the Notification has been correct or an error has occurred, in which case the error is reported. You can enter the purchase order number of the operation, if you know it, and the search will be quicker. Merchant s Guide Installation Manual 31

32 PASSWORD CHANGE For security reasons, you should change your password periodically. To do this, you must go to the "usuarios" (users) section and fill in the information. Merchant s Guide Installation Manual 32