How To Understand And Understand The Bank Account In European Credit Card Transactions

Title Page CyberSource Global Payment Service Planning Guide December 2014 CyberSource Corporation HQ P.O. Box 8999 San Francisco, CA 94128-8999 Phone: 800-530-9095

CyberSource Contact Information For general information about our company, products, and services, go to http://www.cybersource.com. For sales questions about any CyberSource Service, email sales@cybersource.com or call 650-432-7350 or 888-330-2300 (toll free in the United States). For support information about any CyberSource Service, visit the Support Center at http://www.cybersource.com/support. Copyright 2014 CyberSource Corporation. All rights reserved. CyberSource Corporation ("CyberSource") furnishes this document and the software described in this document under the applicable agreement between the reader of this document ("You") and CyberSource ("Agreement"). You may use this document and/or software only in accordance with the terms of the Agreement. Except as expressly set forth in the Agreement, the information contained in this document is subject to change without notice and therefore should not be interpreted in any way as a guarantee or warranty by CyberSource. CyberSource assumes no responsibility or liability for any errors that may appear in this document. The copyrighted software that accompanies this document is licensed to You for use only in strict accordance with the Agreement. You should read the Agreement carefully before using the software. Except as permitted by the Agreement, You may not reproduce any part of this document, store this document in a retrieval system, or transmit this document, in any form or by any means, electronic, mechanical, recording, or otherwise, without the prior written consent of CyberSource. Restricted Rights Legends For Government or defense agencies. Use, duplication, or disclosure by the Government or defense agencies is subject to restrictions as set forth the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and in similar clauses in the FAR and NASA FAR Supplement. For civilian agencies. Use, reproduction, or disclosure is subject to restrictions set forth in subparagraphs (a) through (d) of the Commercial Computer Software Restricted Rights clause at 52.227-19 and the limitations set forth in CyberSource Corporation's standard commercial agreement for this software. Unpublished rights reserved under the copyright laws of the United States. Trademarks CyberSource, The Power of Payment, CyberSource Payment Manager, CyberSource Risk Manager, CyberSource Decision Manager, CyberSource Connect, Authorize.Net, and echeck.net are trademarks and/or service marks of CyberSource Corporation. All other brands and product names are trademarks or registered trademarks of their respective owners. 2

Contents CONTENTS Recent Revisions to This Document 7 About This Guide 8 Audience 8 Purpose 8 Conventions 8 Note, Important, and Warning Statements 8 Text and Command Conventions 9 Related Documents 9 Customer Support 9 Chapter 1 Payment Types 10 Bank Transfers 10 Direct Debits 10 Bank Cards 11 Global Bank Cards 12 Regional and Country-Specific Bank Cards 13 Risk Types 14 Compliance 14 Merchant Account Descriptor Requirements 14 Excessive Credit Card Chargebacks or Excessive Direct Debit Returned Items 15 Merchant Remittance Funding 15 Dormant and Closed Accounts 15 Chapter 2 Business Implementation 16 Countries and Currencies 16 Selecting Countries 16 Selecting Currencies 16 Global Payment Service Planning Guide December 2014 3

Contents Planning Your Business Implementation 17 Contacting Your Account Representative 17 Providing Company Information 17 Signing the Merchant Agreement 17 Creating a Reserve Account 18 Opening Your CyberSource Account and Completing the Intake Process 18 Closing Your CyberSource Account 18 Chapter 3 Transaction Life Cycle 19 Transactions and Events 19 Transaction Life Cycle 20 Order Tracking 21 Merchant Reference Code 22 Transaction Reference Number (Reconciliation ID) 22 Request ID 23 Payment Reference Number 23 Forwarding the Transaction to the Processor 23 Fulfilling the Order 24 Expected Payment Receipt Times 25 Exceptions 26 Funding 26 Timing of Funding 27 Funding Exceptions 27 Request IDs and Request Tokens 27 Financial Reconciliation 28 Financial Reports 28 Collection Report 28 Remittance Report 29 Report Schedule 29 Order Reconciliation 30 Payment Submission Detail Report 30 Payment Events Report 31 Chapter 4 Technical Implementation 33 Guidelines for Displaying Bank Information 33 Testing 33 Global Payment Service Planning Guide December 2014 4

Contents Chapter 5 Bank Transfers and Bank Transfer Refunds 35 Bank Transfers 35 Flow of Identifiers for Order Tracking for Bank Transfers 36 Transaction Status Changes 37 Payment Confirmation and Shipping the Goods 37 Design Considerations 38 Web Site Modifications 39 Missing Bank Transfer Payments 41 Bank Transfer Refunds 42 Types of Refunds 42 Requesting a Follow-on Refund 43 Flow of Identifiers for Order Tracking for Bank Transfer Refunds 43 Transaction Status Changes 44 Reconciling a Refund 45 Chapter 6 Real-Time Bank Transfers 46 Benefits of Real-Time Bank Transfers 46 Customer Experience 47 Transaction Flow 48 Flow of Identifiers for Order Tracking 49 Payment Confirmation and Shipping Goods 50 Enrolling for the Service 50 Chapter 7 Boleto Bancário Payments 51 Overview of Boleto Bancário Processing 51 Requirements 53 Business Requirements 53 Web Site Requirements 54 Technical Requirements 54 Expiration Date Requirements 55 Limitations 55 Information About Your Transactions 55 Reply Messages 55 Reports 56 Query for a Single Transaction 56 Transaction Details 57 Abandoned Boletos Bancários 57 Payment Discrepancies 57 Global Payment Service Planning Guide December 2014 5

Contents Chapter 8 Direct Debits and Direct Debit Refunds 58 Direct Debits 58 Flow of Identifiers for Order Tracking for Direct Debits 59 Payment Confirmation and Shipping Goods 60 Direct Debit Reversals 61 Using Chargebacks and Banking Reversal Codes for Reconciliation 61 Design Considerations 63 Web Site Modifications 63 Direct Debit Refunds 63 Types of Refunds 64 Requesting a Follow-on Refund 64 Flow of Identifiers for Order Tracking for Direct Debit Refunds 64 Transaction Status Changes 66 Reconciling a Refund 66 Chapter 9 Bank Cards 67 Bank Card Types 67 Online and Offline Processing 68 Online Bank Card Flow 68 Offline Bank Card Flow 69 Reconciliation 71 Bank Card Refunds 71 Web Site Modifications 71 API for Bank Card Implementation 71 Appendix A Reason Codes 72 Reason Codes for the Simple Order API 72 Appendix B Researching a Missing Bank Transfer Payment 75 Index 78 Global Payment Service Planning Guide December 2014 6

Recent Revisions to This Document REVISIONS Release December 2014 September 2013 February 2013 November 2012 Changes Removed requirement to send request token fields with follow-on bank transfer and direct debit refunds. See the following sections: Bank transfers: "Requesting a Follow-on Refund," page 43 and "Flow of Identifiers for Order Tracking for Bank Transfer Refunds," page 43 Direct debits: "Requesting a Follow-on Refund," page 64 and "Flow of Identifiers for Order Tracking for Direct Debit Refunds," page 64 This revision contains only editorial changes and no technical updates. This revision contains only editorial changes and no technical updates. This revision contains only editorial changes and no technical updates. November 2011 Removed all CyberSource processor information. Removed Chapter 9, Direct Debits in the United Kingdom. This functionality is not supported. Global Payment Service Planning Guide December 2014 7

About This Guide ABOUT GUIDE Audience This guide is written for merchants who want to use the Global Collect processor to offer the Global Payment services to customers. Purpose This guide describes the business and technical implementations a merchant must complete in order to make bank transfers and bank transfer refunds, real-time bank transfers, boleto bancario payments, and direct debits and direct debit refunds. Conventions Note, Important, and Warning Statements Note A Note contains helpful suggestions or references to material not contained in the document. Important An Important statement contains information essential to successfully completing a task or learning a concept. Warning A Warning contains information or instructions, which, if not heeded, can result in a security risk, irreversible loss of data, or significant cost in time or revenue or both. Global Payment Service Planning Guide December 2014 8

About This Guide Text and Command Conventions Convention Usage bold Field and service names in text; for example: Include the ics_applications field. Items that you are instructed to act upon; for example: Click Save. monospace XML elements. Code examples and samples. Text that you enter in an API environment; for example: Set the davservice_run field to true. Related Documents The Global Payment Service Developer Guide (PDF HTML) describes the tasks a merchant must complete in order to make bank transfers and bank transfer refunds, real-time bank transfers, boleto bancario payments, and direct debits and direct debit refunds. Credit Card Services Using the Simple Order API (PDF HTML) describes the tasks you must complete to integrate the credit card services into your existing management system. Credit Card Services Using the SCMP API (PDF HTML) describes the tasks you must complete to integrate the credit card services into your existing order management system. Getting Started with CyberSource Advanced for the Simple Order API (PDF HTML) describes how to get started using the Simple Order API. Getting Started with CyberSource Advanced for the SCMP API (PDF HTML) describes how to get started using the SCMP API. The Reporting Developer Guide (PDF HTML) describes how to download reports. Refer to the Support Center for complete CyberSource technical documentation: http://www.cybersource.com/support_center/support_documentation Customer Support For support information about any CyberSource service, visit the Support Center at: http://www.cybersource.com/support Global Payment Service Planning Guide December 2014 9

Payment Types CHAPTER 1 Bank Transfers Bank transfers (giros) provide customers with the bank account information for a local payment-receipt bank account that CyberSource provides. Customers instruct their banks to transfer money into this account. After payment is received CyberSource funds your merchant bank account. CyberSource supports bank transfers in many countries. Contact your CyberSource sales representative for the most up to date list. Bank transfers have virtually no consumer dispute rights because the customer initiates the movement of funds. Fraud risk is also low because of the high level of customer identification required by the bank to initiate a bank transfer. However, you do have credit risk until settlement or the risk that the customer might reconsider the purchase and choose not to pay. Accordingly, it is customary to delay shipping until you receive payment confirmation. For more details about how bank transfers work, see Chapter 5, "Bank Transfers and Bank Transfer Refunds," on page 35. Direct Debits Customers provide their bank account information and authorize you to transfer money out of their accounts. Direct debits are used for domestic fund transfers only, so CyberSource provides you with a local payment-receipt bank account. When payment is received into the account CyberSource funds your merchant bank account. Direct debits are similar to electronic checks used in the U.S. Global Payment Service Planning Guide December 2014 10

Chapter 1 Payment Types CyberSource supports direct debits in Austria, Germany, the Netherlands, and Spain. Note Direct debit is a general term for the payment type that is used throughout the documentation. Direct debits can be called by other names, depending on the country. For example, in Germany, one of the large direct debit systems is called ELV, which stands for Elektronisches Lastschrift Verfahren and means electronic debit method. A mandate is a signature or another form of permission that you obtain to transfer funds from the customers account. In specific countries the customers bank requires a mandate to process a direct debit. Other banks may require a mandate if you want to dispute reversals. Contact Cybersource Customer Support for requirements related to mandates in the supported direct debit countries. Direct debits are subject to extensive dispute rights and high dispute fees. You should research the rules as a part of your due diligence process because rules differ per country. Direct debit payments are also subject to fraud risk because there is low identification or authentication required to initiate a direct debit. These payments are also subject to customer credit risk because there is no initial authorization that verifies whether the bank account has sufficient funds. It is customary to delay shipping until you receive payment confirmation. For information about how direct debits work, see Chapter 8, "Direct Debits and Direct Debit Refunds," on page 58. Bank Cards Each of the Global Payment Service payment types and bank cards is classified as either online or offline. Bank Cards can be either global or local. Online when you submit an order, you receive an immediate confirmation about the availability of the funds. Most of the common global bank cards are processed online. For online payment types, you typically start the process of order fulfillment soon after you receive confirmation of the order. Offline you submit an order you do not know if the funds are available until you receive confirmation of the payment. You should not ship the goods until you receive this payment confirmation. Offline bank cards take typically five days longer than online cards to process and for you to receive payment confirmation. Bank transfers the processing time is difficult to estimate because the time depends on the customer and the banking system. However, 2 weeks is customary. Direct debits the processing time is typically 2 or 3 days. Global Payment Service Planning Guide December 2014 11

Chapter 1 Payment Types Online Payment Types American Express Carta Si Italian Visa-branded or MasterCard branded in-country bank card Carte Bleue French Visa-branded or MasterCard-branded in-country bank card; for this card your capture requests must be for 0.99 euros or more Dankort Danish Visa-branded in-country bank card Delta U.K. Visa debit card Electron European Visa debit card Eurocard Regional brand of MasterCard JCB Laser Irish Visa-branded in-country bank card MasterCard Maestro U.K. in-country bank card Visa Offline Payment Types Bank Transfer sometimes called giro Diners Club Direct Debit Global Bank Cards Global bank cards are cards that are accepted worldwide: American Express Diners Club JCB MasterCard Visa You might already have implemented one of these global bank cards through a different payment processor that might not have multi-currency processing for support of international payment. You might want to consider implementing support for these cards through the Global Payment Service for the following reasons: Multi-currency processing: Customers can pay in their local currency. Contact your CyberSource Customer Support representative to find out what currencies are supported. Single set of reports for all transaction activities originating in a certain country. You do not have to move your existing domestic bank card processing away from your current processor. However, if you want to use the Global Payment Service and are already processing international payments through another processor, you will need to switch those transactions to be processed with the Global Payment Service. Global Payment Service Planning Guide December 2014 12

Chapter 1 Payment Types Except for Diners Club, global bank cards are authorized and settled online, resulting in low credit risk to you. Because Diners Club is an offline card outside of the U.S., you do not receive an immediate online authorization and bear significant credit risk for this card. For information about offline processing, see "Bank Cards," page 11, and "Offline Bank Card Flow," page 69. With the global bank cards, customers have limited dispute rights. You bear fraud risk for global bank cards with the exception of Visa and MasterCard transactions that are covered by Payer Authentication. For information about global bank cards, see Chapter 9, "Bank Cards," on page 67. Regional and Country-Specific Bank Cards Although global bank cards are extensively used in Australia, Canada, and the U.S., many European customers prefer instead to use regional or country-specific bank cards. Even though customers can choose to pay with a global bank card, by showing that you support local bank cards, you can improve your store presence and sales. These regional cards use payment networks other than those of global bank cards, but processing is similar to global cards. The Global Payment Service allows you to accept the following country-specific and regional bank cards: Carte Bleue French Visa branded or MasterCard branded bank card. Using this card your capture requests must be for 0.99 euros or more Carta Si Italian Visa branded or MasterCard-branded in-country bank card Dankort Danish Visa branded in-country bank card Delta U.K. Visa debit card Electron European Visa debit card Eurocard Regional brand of MasterCard Laser Irish Visa-branded bank card Maestro U.K. bank card Country specific bank cards are subject to chargeback rules, and you bear fraud risk. Because consumer dispute rules differ by country, you should thoroughly research the rules as a part of your due diligence processes. Some of the above cards use online authorizations, while others do not and are considered offline cards. The credit risk for online cards is considered low because you receive an authorization from the customer's bank. Offline cards have significant credit risk because you do not receive an immediate online authorization. Accordingly, it is customary to delay shipping physical goods until you receive payment confirmation for these cards. For more information, see "Bank Cards," page 11. Global Payment Service Planning Guide December 2014 13

Chapter 1 Payment Types Risk Types With each type of payment comes a certain amount and type of risk: Credit risk the customer does not have the required funds in the account to cover the payment. To avoid credit risk, do not ship the goods until the payment has been confirmed. Fraud risk an unauthorized person is using the bank account or bank card. Consumer dispute rights the customer disputes a charge against the bank account or bank card. You may be required to return the amount of the disputed charge to the customer s account. Disputes can create both administrative and financial costs for you. Compliance Accepting payments from a country other than your own requires that you observe the processing rules and practices of the payment systems in those countries. The following two sections outline areas of compliance which have particular focus. In addition to these two sections, other sections in this guide describe operational requirements that you must follow to be compliant. Merchant Account Descriptor Requirements The merchant account descriptor is a fixed text field that is associated with either a merchant credit card account or merchant direct debit services. The purpose of the descriptor is to communicate merchant name information to the customer so that they can be reminded of the circumstances that triggered the payment. Clearly stated, merchant descriptors reduce the possibility of a credit card chargeback or a returned direct debit, which is similar to a credit card chargeback. Accordingly, the merchant descriptor displayed on the customers statement should be a close match to the name on your Web site. It is not good practice to consolidate multiple Web sites into a single direct debit account or credit card account and use a generic descriptor that more-or-less covers all offerings. Global Payment Service Planning Guide December 2014 14

Chapter 1 Payment Types Excessive Credit Card Chargebacks or Excessive Direct Debit Returned Items You are responsible for maintaining good customer support, rapid problem resolution, a high level of customer satisfaction, and transaction management processes that minimize account takeover fraudulent transactions. All of these are required to prevent an excessive number of credit card chargebacks or an excessive number of returned direct debits. In the event that credit card chargebacks or direct debit returned items become excessive, CyberSource may require you to undertake business process changes to reduce chargebacks and/or returned items. In the event that the chargebacks and/or returned items are not reduced to a satisfactory level, CyberSource may terminate the account. Merchant Remittance Funding In conjunction with the processing of global payment transactions, you can request that CyberSource convert transaction proceeds to a currency other than the currency in which the transaction took place for funding into an operating account. The process of currency conversion involves a foreign exchange rate to determine how much the transaction currency is worth in terms of the funding currency. The foreign exchange rate may be explicitly stated as a rate or implicitly stated as a transaction amount and a funded amount and may vary from day to day. The foreign exchange rate may also include a mark-up to cover the foreign exchange risk, sales commissions, and handling costs. Dormant and Closed Accounts In the event that a refund, credit, chargeback and/or direct debit return exceeds the available balance in your account, CyberSource may terminate your ability to process any further transactions. Global Payment Service Planning Guide December 2014 15

Business Implementation CHAPTER 2 Countries and Currencies Selecting Countries You can process global payments in many countries. Contact your CyberSource account representative for the current list. If you want to add any payment types, contact your CyberSource Technical Account Manager. CyberSource will provide you with pricing information and may need to collect additional information from you. Selecting Currencies With payments such as bank transfers and direct debits have currency restrictions: All the payments that originate from a particular country must be funded with a single currency and into a single bank account. During the intake process, you must inform CyberSource of the funding currency that you want to use for each processing currency. You will have a separate bank account for each funding currency, and you must provide CyberSource with detailed information of each funding bank account you use. Global Payment Service Planning Guide December 2014 16

Chapter 2 Business Implementation Planning Your Business Implementation Contacting Your Account Representative Contact your account representative to discuss your basic business needs: Payment types you want to accept Countries where you want to do business Currencies that you want to use to process payments and receive funds CyberSource can recommend payment types to accept based on your business model and the countries where you want to do business. Based on this information, CyberSource quotes a price for services. Providing Company Information When you accept the quote you must provide information about your company, the company s financial status, and your projected transaction volumes, by payment type and country. Based on this information CyberSource assesses the risk of underwriting your account. The assessment takes approximately 2 weeks to complete. In this relationship CyberSource is the merchant account provider and bears the ultimate risk of any chargebacks, reversals or returns. Signing the Merchant Agreement If CyberSource accepts the risk of underwriting your account, CyberSource supplies a merchant agreement. All business arrangements, including the terms and conditions relating to the reserve account, are identified in the agreement. The agreement is organized according to the payment types and the countries involved. As part of the agreement you are required to read this guide so that you understand the implications and requirements of the payment types and countries. Global Payment Service Planning Guide December 2014 17

Chapter 2 Business Implementation Creating a Reserve Account As part of the agreement, you might be required to create a reserve account that covers chargebacks and credits in the event that your organization is unable to meet these obligations. The amount and type of reserve can vary depending on the payment type and other variables: A rolling 6-month reserve each month CyberSource collects typically 5% 15% of your sales activity for that month. At the end of the seventh month, CyberSource returns to you what was collected during the first month, and so on. This type of reserve takes into account the seasonal nature of your business. A prepaid reserve that you provide. A flat reserve that is a percentage of your volume, with a maximum amount. If you plan to process bank cards, CyberSource typically requires a rolling reserve. If you plan to process direct debits, CyberSource typically requires a prepaid or flat reserve. No reserve is usually required for processing bank transfers. CyberSource is entitled to review and adjust the amount of the reserve regularly during the term of the agreement on the basis of actual risk and monetary volume associated with your CyberSource Global Payment Service account. Opening Your CyberSource Account and Completing the Intake Process After the merchant agreement is endorsed, CyberSource opens and configures your account. CyberSource processes any required forms necessary to open your local bank account. In some circumstances CyberSource opens new terminal IDs and merchant IDs for online and offline card acceptance. Important When opening your account you must inform CyberSource if you plan to use multiple CyberSource merchant IDs. For example, you may have separate business units within your company each with a CyberSource merchant ID. You must have a separate processor merchant ID for each CyberSource merchant ID. Your CyberSource account manager will work with you so that CyberSource has all the information it needs about the countries, currencies, payment types, and bank accounts that you will be using. CyberSource informs you when the local bank accounts are ready to receive funds from customers. Closing Your CyberSource Account To stop accepting payment types in a particular country or to close your CyberSource account, contact your CyberSource Technical Account Manager. Global Payment Service Planning Guide December 2014 18

Transaction Life Cycle CHAPTER 3 Important Bank card processing with the Global Payment Service is similar to domestic bank card processing. Global bank card processing is not discussed at length here. CyberSource assumes that you already have a system for processing bank cards. Transactions and Events A transaction occurs when you request that CyberSource moves money in the form of a payment or a refund. You initiate transactions. An event is related to a transaction that you have submitted. You do not initiate events; banks initiate events. For example, you submit a transaction to CyberSource for a direct debit. Later, a payment Event occurs indicating that the bank has received the customer s payment. CyberSource supplies two reports to help you keep track of your transactions and events: Payment Submission Detail Report for transactions Payment Events Report for events For more information see "Order Reconciliation," page 30. Global Payment Service Planning Guide December 2014 19

Chapter 3 Transaction Life Cycle Transaction Life Cycle This section focuses on the alternative global payment types, which are bank transfers, direct debits, and their associated refunds. CyberSource provides several tools that help you keep track of your transactions and indicate when to fulfill your orders and perform reconciliation. Figure 1 Transaction Life Cycle When you submit the transaction to CyberSource, it immediately goes through error checkpoint #1. CyberSource makes sure that the request has all the required fields and no invalid data. If the request has an error, CyberSource rejects it and you immediately receive notification in the reply. The transaction s status is set to CANCELLED. If the request has no errors, the transaction s status changes to PENDING. Search for the transaction in the Business Center. The Transaction Search Details page displays a transaction s status. You can search for one or more transactions using specific criteria. Basic information and current status of the transaction are displayed. Global Payment Service Planning Guide December 2014 20

Chapter 3 Transaction Life Cycle Figure 2 Transaction Search Details Screen Order Tracking After you submit your transaction, several identifiers become associated with it. You can use these identifiers to keep track of the transaction in the CyberSource reports and the Transaction Search Details screens in the Business Center: Merchant reference code (merchant reference number) Transaction reference number (reconciliation ID) Request ID Payment reference number used for bank transfers only Request token Global Payment Service Planning Guide December 2014 21

Chapter 3 Transaction Life Cycle Figure 3 Transaction Identifiers Identifiers for the Transaction Merchant Merchant Reference Code Transaction Reference Number (also called Reconciliation ID) CyberSource Request ID Payment Reference Number (for bank transfers) Merchant Reference Code You generate the merchant reference code and include it in the request. This field is a string and can contain a combination of data, such as your order ID and customer ID. The merchant reference code appears on all CyberSource daily reports. You can use it to search for the transaction in the Business Center. CyberSource recommends that you use a unique value for each order and that you use the same value for all requests that you send to CyberSource related to an order. For example, if you request a direct debit refund use the same merchant reference code for the direct debit refund that you used for the direct debit. This practice helps you track the order in your system and CyberSource s system. Transaction Reference Number (Reconciliation ID) CyberSource generates the transaction reference number (reconciliation ID) and returns it to you in the reply. CyberSource uses this number to track transactions with the payment processor. The value is guaranteed to be unique and it appears in various reports. Note You can reconcile your orders with their corresponding payments by using either the merchant reference code or the transaction reference number. Global Payment Service Planning Guide December 2014 22

Chapter 3 Transaction Life Cycle Request ID CyberSource generates a unique request ID for each request that you send and returns the ID in the reply. The request ID is useful if you need to discuss a specific request with CyberSource Customer Support. You can use the request ID from the original request to request a refund. You include the request ID of the payment, and CyberSource uses that value to find information about the payment. Payment Reference Number The payment reference number is a unique value for each bank transfer. You receive this value in the bank transfer reply, and you must display it to the customer. The customer must send in the number with each bank transfer so that the payment can be matched to the corresponding order. Forwarding the Transaction to the Processor How a transaction gets processed depends on the transaction type and the processor. The following table describes the status of each transaction type. Table 1 Transaction Processing Type of Transaction Payment Status Bank Transfer Status changes to TRANSMITTED. Transaction appears in the Payment Submission Detail Report. Direct Debit or Direct Debit Refund or Bank Transfer Refund Transaction bypasses error checkpoint #2. See Figure 1. Transaction is sent to the processor. Status changes to TRANSMITTED. Transaction appears in the Payment Submission Detail Report. All transactions that you submit before 12:00 A.M. Pacific time are reported in the next day s Payment Submission Detail Report. The report is usually available for download by 6.00 A.M. Pacific time. For more information see "Payment Submission Detail Report," page 30. Global Payment Service Planning Guide December 2014 23

Chapter 3 Transaction Life Cycle Fulfilling the Order For offline payment methods such as bank transfers, direct debits, or offline bank cards, you should ship the goods after you receive the payment confirmation. If a transaction status is ERROR or ON HOLD, do not ship the goods until the error is resolved and the customer s payment is received. Inform customers when they place their orders that you do not ship until you receive payment confirmation. Use the Payment Events Report to determine when the customer s payment is received. When the payment is received, CyberSource changes the transaction s status to PAYMENT. The Payment Events Report will contain a line item for that transaction with the event type set to Payment. For all payment methods except direct debits, this status indicates that you can ship the goods. For direct debits you should wait an additional 3 to 4 business days before shipping the goods. During this time, monitor the Payment Events Report to ensure the direct debit has not been reversed. The payment receipt times vary depending on the payment method and other variables. Monitor the Payment Events Report daily to keep track of incoming payments for orders that need to be fulfilled. For information about when to expect payment for each payment type, see "Expected Payment Receipt Times," page 25. For more information about the Payment Events Report, see "Payment Events Report," page 31. Note For all countries the Global Payment Service settlement processing does not occur on Saturday or Sunday. Payment Events Report that you download on Sunday or Monday generally does not contain any payment events for the Global Payment Service. Figure 4 Fulfilling the Order Global Payment Service Planning Guide December 2014 24

Chapter 3 Transaction Life Cycle Refunds go through the same process as described previously. You can view refunds being settled with the customer by monitoring the Payment Events Report. When CyberSource receives notification from the processor that the refund has been processed, CyberSource changes the refund transaction s status to REFUND. The next day s Payment Events Report contains a line item for that refund transaction with the event type set to Refund. Expected Payment Receipt Times Direct debit payments and online bank card payments are processed through the customer s bank in 2 or 3 business days. Offline bank card payments are processed in 5 business days. Bank transfer processing times vary depending on the customer. Table 2 shows typical times for bank transfer processing based on how the customer submits the bank transfer to their bank. Table 2 Processing Times for Various Bank Transfer Methods Activity Customer Mails to Bank Customer Brings to Bank in Person Handling 2 to 3 business days N/A N/A Customer Uses Online Banking Bank s processing time 2 to 3 business days 2 to 3 business days 1 business day Payment processor s processing time 1 business day 1 business day 1 business day Total days 5 to 7 business days 3 to 4 business days 2 business days For bank transfers that are still unpaid: You might need to remind the customer that payment is due. Transactions that are not paid continue to show on the Transaction Search Screens for at least 60 days. They remain with a status of TRANSMITTED. You should periodically purge old pending orders from your database. Note If you also use CyberSource for processing online bank cards through other processors, you might notice a difference in payment receipt times between the online bank cards processed through the Global Payment Service and the online bank cards processed through other processors. This difference can occur because other processors typically require the transactions to be batched to them once a day instead of submitted as CyberSource receives them. Global Payment Service Planning Guide December 2014 25

Chapter 3 Transaction Life Cycle Exceptions After a transaction is settled, which is when the customer s payment is received, several exceptions can occur. They are displayed in the Payment Events Report: Direct debits a reversal occurs when the customer claims that the money was taken in error or without permission, or when there are insufficient funds in the customer s account. The event in the Payment Events Report is Reversal. For more information see "Direct Debit Reversals," page 61. Bank transfers an unmatched bank transfer payment occurs when the bank receives a payment but the payment cannot be matched to the original order. This is because the customer made in error transcribing the bank transfer information. For more information see "Researching a Missing Bank Transfer Payment," page 75. If a chargeback occurs for a bank card the event in the Payment Events Report is Chargeback. Before a chargeback occurs a Request For Information (RFI) occurs. This is the first step in the chargeback process. It occurs when the customer s bank contacts the payment processor requesting information about the merchant and the transaction. CyberSource Customer Support sends you a notification email when an RFI occurs. You should monitor the Payment Events Report daily for these events and update your systems accordingly. In the Business Center, a table at the bottom of the Transaction Search Details screen for the original transaction lists the history of events. To request an inquiry for a transaction go to the CyberSource Support Center. Funding When a transaction s status is PAYMENT or REFUND, the next step is funding. This is the process during which your bank account receives the funds due to you. During funding any reserves, reversals and refunds that you owe are subtracted from the funding amount. In contrast with bank cards, funding and settlement are separate occurrences for bank transfers and direct debits. For bank cards, funding and settlement are the same thing. When the customer s bank pays (settlement) the money transfers directly to your bank account (funding). For bank transfers and direct debits, settlement occurs when the customer s payment is received in a local account that CyberSource sets up for you. Funding occurs weekly and CyberSource deposits all your payments for the week minus any reserves, reversals, or refunds. When a transaction is funded its status does not change from its current state of PAYMENT or REFUND. When funding happens no event appears in the Payment Events Report. Instead, you can assume the transaction will be funded within 4-11 days after its status changes to PAYMENT or REFUND. You can see the status of the transaction in the Transaction Search Details screen. Global Payment Service Planning Guide December 2014 26

Chapter 3 Transaction Life Cycle Timing of Funding For the Global Payment Service, funding occurs weekly. If you have a high order volume you might be eligible to fund twice a week. Depending on the country, funding can occur at different times during the week. Note Funding does not occur on weekends and holidays. All days listed are business days. The Global Collect processor starts the funding process on Friday of each week. Your merchant bank account is funded with a same-day-value transaction that is initiated on Tuesday of the following week. You should receive funds on Tuesday or Wednesday. Figure 5 Global Collect Funding Process Funding Exceptions If the net amount to be funded in the weekly period is less than 100 euros or equivalent, the funding is delayed and processed when the funding amount reaches 100 euros. If a failure occurs during the funding cycle CyberSource contacts you. CyberSource funds those transactions in the next funding cycle. If CyberSource detects transactions that are suspicious, your funding can be put on hold until CyberSource can discuss the transactions with you. Request IDs and Request Tokens Request IDs and request tokens are identifiers that CyberSource includes in the replies for all services. You must store the contents of the request ID and request token fields because you need these values when you send a request for a follow-on service. Important Although the names of the request ID and request token fields that you receive are the same in each reply, the contents of the fields are different. Global Payment Service Planning Guide December 2014 27

Chapter 3 Transaction Life Cycle Financial Reconciliation Financial reconciliation is the process of verifying that the funds CyberSource deposited into your bank account have been received by your bank. Financial Reports For financial reconciliation for transactions performed with the Global Collect processor, you receive two reports in PDF format: the Collection Report and the Remittance Report. Each report describes the movement of funds into your funding accounts. These reports are available in the Business Center. Collection Report The Collection Report describes the total amount of the payments you received in each foreign currency, the amount for each foreign currency and the exchange rates used. Figure 6 shows an example of a Collection Report with activity in eight foreign currencies. The report number lists the contract number just to the right of the year. The term contract number is synonymous with account number or merchant agreement number. The report example is for account number 1935. Figure 6 Collection Report Example Collection Report Report number: Report date: Report period: 2003-1935 - 017 24-04-2003 18-04-2003 to 24-04-2003 Description Exch. rate Curr Amount Reported payments in CHF Reported payments in CZK Reported payments in DKK Reported payments in EUR Reported payments in FRF Reported payments in GBP Reported payments in NOK Reported payments in SEK 3,424.00 3,680.92 2,175.00 6,019.85 1,272.00-626.00 4,710.00 1,710.00 0.593981 0.027876 0.117595 0.873193 0.133011 1.414872 0.112921 0.095655 USD USD USD USD USD USD USD USD 2,033.79 102.61 255.77 5,256.49 169.19-885.71 531.86 163.57 Total USD 9,060.61 Global Payment Service Planning Guide December 2014 28

Chapter 3 Transaction Life Cycle Remittance Report The Remittance Report, Figure 7 describes the total amount of the payment transfer made to your merchant bank account. The information in the Remittance Report example is consistent with the Collection Report example, see Figure 7. Figure 7 Remittance Report Example Remittance Report Date: 24-04-2003 Contract Description Currency Amount Collection Reports 20031935-017-USD 1935 18-04-2003 24-04-2003 USD 9,060.61 9,060.61 R0004100 Total USD 9,060.61 The amount in USD will be transferred to your account 3016163416, First Fidelity Bank, Newark Report Schedule The availability of the Collection Report and Remittance Report depends on whether your settlement period is on a weekly schedule or a twice-weekly schedule. Table 3 Schedule for Collection Report and Remittance Report Schedule Settlement Period Collection Report Available Weekly Saturday to Friday Monday Tuesday Twice-weekly Wednesday to Friday Monday Tuesday Saturday to Tuesday Wednesday Thursday Remittance Report Available Global Payment Service Planning Guide December 2014 29

Chapter 3 Transaction Life Cycle Order Reconciliation Order reconciliation is the process of verifying that all successful orders that you have initiated with CyberSource are settled, shipped, and funded. In general, your transactions will be split into the categories in the table below. CyberSource provides you with various tools to help you determine when a transaction is in a particular category or point in its life cycle. These tools include: Payment Submission Detail Report Payment Events Report All of these reports are described in the following sections. Table 4 Reconciliation Reports Transaction Categories Awaiting payment Received payment Note Your own system must monitor whether the goods have been shipped. For direct debits, you must wait 3 or 4 days to ensure that there is no reversal. Status PENDING or TRANSMITTED PAYMENT Available Tools to Identify Transactions in the Category Payment Submission Detail Report: The presence of the transaction in the report indicates the status is TRANSMITTED. PENDING transactions do not appear in this report. Payment Events Report: Look for a Payment event. The Payment Submission Detail Report and the Payment Events Report are daily reports detailing transactions that had a status change in the past 24 hours. If you use these reports you must monitor them daily. Payment Submission Detail Report This daily report includes all transactions that you submitted to CyberSource in the past 24 hours without any errors. See "Forwarding the Transaction to the Processor," page 23, for more information. For the Global Payment Service the report includes: Bank card captures and credits Bank transfers and bank transfer refunds Direct debits and direct debit refunds Global Payment Service Planning Guide December 2014 30

Chapter 3 Transaction Life Cycle You can use the report to: Confirm the orders that you have submitted and that will be processed Trigger order fulfillment for online payment types online bank cards Estimate settlement amounts and revenue The report contains transactions that you submit from 12:00 A.M. to 12:00 A.M. Pacific time. The report is typically available for download by 6:00 A.M. Pacific time the next day. Note If you use CyberSource services for any payment services other than the Global Payment Service, including all credit card and check processing, those transactions will also appear in this report. Each transaction entry in the report includes: Request ID Merchant reference code Transaction reference number (reconciliation ID) Payment type Currency code Amount CyberSource service that was called Payment processor. For information about the format of the report and how to download it, see the Reporting Developer Guide. Payment Events Report This report describes events that occurred for your transactions in the past 24 hours. You can you use this report to do the following: Trigger order fulfillment for offline payment types bank transfers, direct debits, and offline bank cards Reconcile confirmed payments and refunds to orders for all of the Global Payment Service payment types Note If you use CyberSource for specific payment services, such as TeleCheck electronic checks, those transactions are also described in this report. The Payment Events report is available for download by 6:00 A.M. Pacific time the next day. Global Payment Service Planning Guide December 2014 31

Chapter 3 Transaction Life Cycle Each event that occurs has a separate record in the report. The types of events listed in the report are: Payments Refunds Chargebacks Reversals Corrections Unmatched bank transfer payments Any unanticipated events reported by the payment processor Each record includes the request ID, merchant reference code, transaction reference number (reconciliation ID), type and date of the event, and other event details. For information about the format of the report and how to download it, see the Reporting Developer Guide. Important Notes about Payment Events Report Generation The report is generated each day that CyberSource receives a data file from the processor before CyberSource s cut-off time. Because CyberSource does not receive a data file from the processor on weekends or holidays, the report that you download on Mondays will contain information for multiple days of processing. Ensure that your implementation can handle reports that span multiple processing days. If the generation of the report is delayed on a particular day, you are notified. Because the report generated after a delay can span more than one day, ensure that you can track the delayed reports. CyberSource regenerates the entire report, not just the selected transactions that need to be regenerated. You are notified as soon as the new version of the report is available. Ensure that your implementation can recognize and process only the transactions that were modified or added to the report. Global Payment Service Planning Guide December 2014 32

Technical Implementation CHAPTER 4 Important For API information for bank transfers, direct debits, and their associated refunds, see the Global Payment Service Developer Guide. For API information for the various types of bank cards, see Credit Card Services Using the Simple Order API or Credit Card Services Using the SCMP API. Guidelines for Displaying Bank Information When you implement bank transfers or direct debits you must display bank account information to customers or request it from them. The representation of the account information varies from country to country. To minimize delays or errors in transferring funds, CyberSource recommends that you pay attention to how the bank account information is displayed in each country. For example, some countries require only a bank account number, that other countries also require a special bank code. Testing CyberSource recommends that you test your implementation to ensure that you are sending direct debit requests or bank transfers to, and handling replies from, the CyberSource services correctly. CyberSource performs the same basic validation checks that are performed for production transactions. Test transactions are not forwarded to the payment processor. Global Payment Service Planning Guide December 2014 33

Chapter 4 Technical Implementation The requirements for test transactions are: Use your regular CyberSource merchant ID to perform testing. Match the country and currency information. When testing the Simple Order API, use the test URL: https://ics2wstest.ic3.com/commerce/1.x/transactionprocessor When testing the SCMP API, use the CyberSource test server: https://ics2test.ic3.com Using specific amounts in your test transactions to trigger specific responses enables you to generate the responses that your system must process. For information about amounts and decline (error) responses returned by the simulator for both the Simple Order API (reason code) and the SCMP API (rflag and msg description), see the Global Payment Service Developer Guide. Global Payment Service Planning Guide December 2014 34

Bank Transfers and Bank Transfer Refunds CHAPTER 5 Bank Transfers A bank transfer (a giro) is a payment method in which the customer transfers the payment to your bank account that CyberSource set up for you. This method is in contrast to many common payment types in which you retrieve the money from the customers account. With bank transfers you give customers your bank account information instead of collecting the customer s bank account information. Customers then instruct their banks to transfer money to your account. Bank transfers are commonly used throughout Europe and Asia. Contact your CyberSource sales representative for the most current list of countries in which CyberSource supports bank transfers. Global Payment Service Planning Guide December 2014 35

Chapter 5 Bank Transfers and Bank Transfer Refunds Flow of Identifiers for Order Tracking for Bank Transfers The following figure shows the flow of information and identifiers that occurs for a bank transfer. Figure 8 Bank Transfer Identifier Flow In the figure, solid lines (steps 1-3) indicate actions that happen during the purchase process. Dashed lines (steps 4-8) indicate actions that happen during payment and reconciliation. See "Order Tracking," page 21, for definitions of the identifiers. 1 The customer pays by bank transfer, and you send a request to CyberSource with the merchant reference code. 2 CyberSource includes the bank information, a transaction reference number (reconciliation ID) and a payment reference number in the reply. 3 You display the payment reference number, the bank information and the payment instructions to the customer. 4 The customer initiates the bank transfer, providing the bank account information and the payment reference number in the request. 5 The bank receives the payment and identifies it by the payment reference number. 6 The processor processes the settlement transaction. 7 The processor notifies CyberSource of the payment. CyberSource updates the transaction status in the CyberSource system as shown in Figure 9 and the payment is matched to its original order. Global Payment Service Planning Guide December 2014 36

Chapter 5 Bank Transfers and Bank Transfer Refunds 8 You receive confirmation of the payment in the Payment Events Report and you update your corresponding pending orders. The report includes the payment reference number for the bank transfer, the transaction reference number (reconciliation ID), and your merchant reference code for the payment. Transaction Status Changes The following figure shows the status changes that a bank transfer goes through. Figure 9 Bank Transfer Transaction Status Using the Business Center, you can view a transaction status in the Transaction Search Details screen. The status is listed as the Action in the small table in the top right corner of the screen. Payment Confirmation and Shipping the Goods Use the Payment Events Report to determine when a bank transfer payment has been received so that you can ship the goods. Look for an event type of Payment. For information about the report, see "Fulfilling the Order," page 24. You can reconcile your orders to their corresponding payments using the bank transfer payment reference number. This number is the CyberSource-generated transaction reference number (reconciliation ID) or your own merchant reference code. If you plan to use the merchant reference code to reconcile make sure it is a unique value when you include it in the request. Global Payment Service Planning Guide December 2014 37

Chapter 5 Bank Transfers and Bank Transfer Refunds Design Considerations Consider these factors when designing your system: With bank transfers, you should not ship the goods until you receive confirmation of the customers payment. See "Fulfilling the Order," page 24. Consider informing customers that you do not ship until you receive payment. Timing of the payment depends on the customer. Customers can pay in several ways: By physically going to their banks with the bank transfer instructions By sending the bank transfer instructions by post By using online banking In some countries customers round up or down the amount of the bank transfer to a whole number. Design your system to accommodate slight variations between the original order amount and the confirmed payment amount that appears in the Payment Events Report. If you decide to ship goods prior to receiving payment confirmation, you must design a system that can accommodate situations in which the customer does not pay. For bank transfers that remain unpaid for several weeks, CyberSource recommends that you develop a system for reminding the customer. Some customers might decide not to go through with their orders without alerting you. You need to develop a system for deleting old unpaid bank transfers. If a customer requests a refund for a bank transfer, confirm that you have already received the bank transfer payment, before giving the refund. Also, design your system to collect the customer s bank account information when you process a refund because you did not have to collect it when you processed the original payment. You can have a situation in which the customers instructions to the bank are incorrect, and the payment cannot be matched to the original request that you submitted to CyberSource. For more information see "Missing Bank Transfer Payments," page 41. Global Payment Service Planning Guide December 2014 38

Chapter 5 Bank Transfers and Bank Transfer Refunds Web Site Modifications Figure 10, page 40, displays the basic web site flow for bank transfers. The most important modification that you need to make to your web site is adding the bank transfer confirmation page that you display to the customer. You must display the information listed below on the confirmation page. Omitting any of this information results in delays, lost orders, or unnecessary customer service. You may want to email this information directly to the customer in addition to displaying it on the confirmation page. Instructions for your customer's financial institution Payment reference number Payment amount Bank details When you will ship the order The time allowed for payment after which you cancel the order Figure 11 shows a suggested confirmation page for bank transfers. For guidelines on the bank account number structures used in various countries, see the Global Payment Service Developer Guide. Global Payment Service Planning Guide December 2014 39

Chapter 5 Bank Transfers and Bank Transfer Refunds Figure 10 Web Site Flow for Bank Transfers Consumer shops in pages localized by country and language Pay by: Bank card Bank Transfer Direct Debit First Name Last Name Billing Address and so on... Continue Order confirmation summarizing invoice information: items being purchased, total amount, billing address, and so on. Buy Thank you for your bank transfer purchase. Payment reference number Banking account information Please print this for your records and complete a bank transfer form. Actions on order: 1. Merchant records order in their pending order database. 2. Merchant requests bank transfer with merchant reference code and customer name and address. 3. CyberSource processes requests and returns payment reference and banking information. Global Payment Service Planning Guide December 2014 40

Chapter 5 Bank Transfers and Bank Transfer Refunds Figure 11 Bank Transfer Confirmation Page Example Missing Bank Transfer Payments With bank transfers you give customers your bank account information and the payment details that they must provide to their banks. If a customer gives an incorrect payment reference number to the bank you will receive a bank transfer payment that cannot be matched to its original request. In this situation the customer will probably call to say that the bank transfer payment has gone through but no goods have been received. If a payment cannot be matched to its original order there will be a line in the Payment Events Report with the following details: Request ID equals 1 followed by 25 0s (zeros) Merchant reference number is blank Event type is Payment Global Payment Service Planning Guide December 2014 41

Chapter 5 Bank Transfers and Bank Transfer Refunds The incorrect payment reference number that the customer provided will be in the trans_ ref_no field in the CSV version of the report or the <TransactionReferenceNumber> field in the XML version of the report. The amount of the payment will also be in the report. Use this information to try to find the original order and match the payment to the order. You can use the Business Center to research a missing bank transfer payment. See Appendix B, "Researching a Missing Bank Transfer Payment," on page 75. You must wait at least 5 days after the funds are debited from the customer s account before initiating an inquiry. Warning Global Collect's practices prohibit customer cash payments instead of a bank account transfer when funding a bank transfer. If you allow your customers to fund bank transfers with cash, you are doing so at your own risk because these payments cannot be traced or researched. Bank Transfer Refunds You can submit a request to refund up to 100% of a bank transfer. You can also request multiple partial refunds of a bank transfer. The sum of the partial refunds cannot exceed 100% of the original bank transfer. CyberSource recommends that before giving the refund, you confirm that you have already received the bank transfer payment. Types of Refunds There are two types of bank transfer refunds: follow-on refunds and stand-alone refunds. A follow-on refund uses information from a previous bank transfer. A stand-alone refund does not depend on a previous transaction. A follow-on refund must occur within a limited number of days of the request for the bank transfer. If you are using the API to make these transactions, a follow-on refund must occur within 60 days of the bank transfer request. If you are using the Business Center to make these transactions, a follow-on refund must occur within 180 days of the bank transfer request. After the time limit for a follow-on refund has passed, the only kind of refund you can make is a stand-alone refund. Global Payment Service Planning Guide December 2014 42

Chapter 5 Bank Transfers and Bank Transfer Refunds Requesting a Follow-on Refund A request for a follow-on bank transfer refund must include the request ID that was returned in the reply for the bank transfer. Flow of Identifiers for Order Tracking for Bank Transfer Refunds To process a bank transfer refund you must obtain the customer s bank account information and include it in the request to CyberSource. You must link the refund to the original bank transfer request. See information about bank transfer refunds in the Global Payment Service Developer Guide. CyberSource recommends that when you request a refund, you use the same merchant reference code that you used for the bank transfer. Using the same code makes it easier for you to link the refund to the original bank transfer in your own system and in CyberSource reports and Transaction Search Screens. The following figure shows the flow of information and identifiers that occurs for a bank transfer refund. Figure 12 Bank Transfer Refund Identifier Flow Global Payment Service Planning Guide December 2014 43

Chapter 5 Bank Transfers and Bank Transfer Refunds In Figure 12, page 43, solid lines (steps 1-3) indicate actions that happen during the refund initiation process. Dashed lines (steps 4-6) indicate actions that happen during refund payment and reconciliation. See "Order Tracking," page 21, for definitions of the identifiers. 1 You collect the customer s bank information and send it along with the merchant reference code from the original bank transfer in a request to CyberSource. To request a follow-on refund, send the following additional field, which is not shown in the figure: Request ID of the original bank transfer. 2 CyberSource sends the refund request to the payment processor. 3 The payment processor sends the refund request to your local payment-receipt bank. 4 Your bank transfers the money to the customer s bank and notifies the processor. 5 The payment processor notifies CyberSource that the refund is complete, and CyberSource updates the transaction status. 6 You download the Payment Events Report, which contains the merchant reference code and the refund s transaction reference number. Depending on which processor you are using this number may not be the same as the bank transfer s transaction reference number. Transaction Status Changes The following figure shows the status changes for a bank transfer refund. Figure 13 Bank Transfer Refund Transaction Statuses Changes You can view a transaction s status in the Transaction Search Details screen. The status is listed as the Action in the small table in the top right corner of the screen. You can use the Payment Events Report to confirm that a refund has been given to the customer. Look for a Refund event for the refund. Global Payment Service Planning Guide December 2014 44

Chapter 5 Bank Transfers and Bank Transfer Refunds Reconciling a Refund View the Payment Events Report to get the confirmation that the refund has been processed by the payment processor. See "Payment Events Report," page 31. The report contains the transaction reference number (reconciliation ID) and the merchant reference code (merchant reference number) for the refund. The transaction reference numbers that you receive for all of the refunds will be the same as the number for the bank transfer. Global Payment Service Planning Guide December 2014 45

Real-Time Bank Transfers CHAPTER 6 CyberSource provides real-time bank transfers in the following countries: Austria Belgium Denmark Finland Germany Netherlands Norway Sweden Benefits of Real-Time Bank Transfers This section compares real-time bank transfers to traditional bank transfers. Real-time bank transfers provide these major benefits: Increased Order Conversion with a traditional bank transfer the customer might never complete the bank transfer because it is an offline payment that requires a visit to a bank or the mailing of a form. Real-time bank transfers eliminate these inconveniences by providing a payment method that the customer can use immediately, which results in a higher rate of completed orders. Improved Order Reconciliation with a traditional bank transfer the customer must use a payment reference number that you provide. If the customer enters the number incorrectly or omits it, you will have to initiate manual reconciliation processes to match the payment to the order. Real-time bank transfers eliminate this problem by automatically forwarding the payment reference number to the customer s bank in a protected format. Global Payment Service Planning Guide December 2014 46

Chapter 6 Real-Time Bank Transfers Customer Experience You need to add real-time bank transfer as a distinct payment type that the customer can select on your web site s payment page. Although real-time bank transfers and traditional off-line bank transfers share some banking infrastructure elements, the customer s experience will be very different. Real-time bank transfer is a functional description of the payment flow. However, it is not a term that the customer knows. Therefore, use different terminology, such as Internet banking, on Web pages and in messages that the customer sees. The terminology you use will depend on the customs of the specific country in which you are doing business. The customer s experience of real-time bank transfers differs by country: Not all banks offer real-time bank transfers. In countries where real-time bank transfers are offered, banks and banking networks have implemented differently. There is no single worldwide or European standard. Depending on the country, there are a few possible variations: Only one bank selection is offered. In this situation, CyberSource recommends that you name the bank and display the bank s logo as the payment type. A banking network is offered. After the customer selects the banking network as a payment type, the customer selects his or her bank from the list of banks. In this situation, CyberSource recommends that you name the network and show the network logo as the payment type. A banking network is offered. However, you must show each specific bank in the network and the customer must select the bank on your payment page. In this situation, CyberSource recommends that you show the name of the network and the network logo above the list of individual banks. Global Payment Service Planning Guide December 2014 47

Chapter 6 Real-Time Bank Transfers Transaction Flow The following steps describe the transaction flow for a real-time bank transfer: 1 The customer is ready to checkout. 2 You display a payment page that is localized in the customer s language and that shows the payment options that are available in the customer s country. 3 The customer selects the real-time bank transfer payment method. In some cases, as explained previously, the customer must select his or her bank from a list. 4 You prompt the customer for personal and financial information such as account number, name, billing address, email address, phone number, and shipping address. 5 Using the information entered by the customer and information you already have, such as the payment amount, you form a request and send it to CyberSource using either banktransferrealtimeservice (Simple Order API) or ics_bank_transfer_ real_time (SCMP API). 6 CyberSource uses the information in the request to initiate a transaction with the bank. 7 CyberSource replies to you with the following: Reconciliation ID (Simple Order API) or transaction reference number (SCMP API) URL to direct the customer to a banking site 8 You use the URL that is sent by CyberSource to re-direct the customer s browser window to the bank s web site, accessing the transaction that was already initiated by CyberSource, so that the customer can complete the transaction. 9 After completing the transaction, the customer s browser is re-directed to your web site by means of a return URL. You either provide the return URL to CyberSource in the real-time bank transfer request, or it is stored in the CyberSource database. 10 Your web site displays a message to the customer. If the customer abandoned the payment process, he or she might return to your web site. For customers who return to your site, you can display a Thank You message and tell them to return in an hour to verify that. 11 When the customer returns to your web site to check the order status, use the on-demand query as described in "Payment Confirmation and Shipping Goods," page 50, to determine the payment status: If you have received payment, ship the goods to the customer If you have not received payment, tell the customer to return in 24 hours to verify that Global Payment Service Planning Guide December 2014 48

Chapter 6 Real-Time Bank Transfers Flow of Identifiers for Order Tracking The following figure shows the flow of identifiers that occurs for a real-time bank transfer. As you can see, the customer is not responsible for passing along any identifiers, which is one of the benefits of real-time bank transfers. Figure 14 Real-Time Bank Transfer Identifier Flow The solid lines (steps 1-3) indicate actions that happen during the purchase process. Dashed lines (steps 4-7) indicate actions that happen during payment and reconciliation. 1 The customer chooses to pay by real-time bank transfer, and you send a request to CyberSource with the merchant reference code. 2 CyberSource returns to you a transaction reference number, or reconciliation ID, and the payment reference number. CyberSource also returns a request ID, which is not shown in the figure. You must store the values of the request ID in case you need to request a bank transfer refund. 3 You display the payment reference number, the bank information, and payment instructions to the customer. Global Payment Service Planning Guide December 2014 49

Chapter 6 Real-Time Bank Transfers 4 The customer is re-directed to the bank s web site and initiates the bank transfer by completing forms at the site. 5 The processor processes the settlement transaction. 6 The processor notifies CyberSource of the payment. CyberSource updates the transaction status in the CyberSource system, and the payment reference number is used to match the payment to the original order. 7 You receive confirmation of the payment as described in "Payment Confirmation and Shipping Goods," page 50, and you update your corresponding pending orders. Payment Confirmation and Shipping Goods CyberSource receives information about payment success for real-time bank transfers through an out-of-channel communications method, usually no more than 5 minutes after the payment transfer is accepted by the customer s bank. You can use one or more of the following methods to obtain payment confirmation: Business Center you can log on to the CyberSource Business Center, search for the payment, and then view the payment details. The Payment Details page shows the payment status. On-demand Query you can send CyberSource a query by means of an HTTPS POST and CyberSource will return the status of the order. It is requested that you select a query interval of at least 10 minutes for repeat queries on a particular order. See the section about on-demand queries in the real-time bank transfers chapter in the Global Payment Service Developer Guide for more information. Payment Events Report you can view a transaction s status in the Payment Events Report, which is available every morning. See "Payment Events Report," page 31, for more information. Regardless of which method you use, you can ship the goods when the transaction s status is PAYMENT. Enrolling for the Service Each country requires a separate enrollment procedure. Please contact your CyberSource account representative to enroll in the real-time bank transfer service. Global Payment Service Planning Guide December 2014 50

Boleto Bancário Payments CHAPTER 7 Overview of Boleto Bancário Processing Boletos Bancários are offline bank transfers that are popular in Brazil. In some merchant vertical segments they account for up to 20% of online payment transactions in Brazil. Boletos Bancários have the following features: No upper limit, whereas Brazilian credit cards have low credit balances. You often receive funding from the Boleto Bancário payment system more quickly than from a credit card. You pay a fixed charge to the bank that issues the Boleto Bancário, whereas credit cards charge a percentage of the sale price. Boletos Bancários are similar to offline bank transfers worldwide but with these differences: They are payable through a customer s home banking application, which Brazilian banks offer with nearly all bank accounts. They are payable in person at any bank in Brazil, whether or not this is the customer s depository bank. Each Boleto Bancário has an expiration date set by you. Each Boleto Bancário has a bar code that minimizes processing errors when used for in-person payment. The Boleto Bancário system does not process refunds. Boletos Bancários expire at the close of the Brazilian banking day, which is between 7:00 pm and 9:00 pm in Brazilian local time. To receive prompt payment, CyberSource recommends that you set an expiration date that is five to seven business days after the date that the Boleto Bancário is initiated. Note If the Boleto Bancário expiration date falls on a non-banking day, the Boleto expiration date is extended until the end of the next banking day. The Boleto Bancário expiration date skips weekends and holidays. Global Payment Service Planning Guide December 2014 51

Chapter 7 Boleto Bancário Payments Figure 15 shows the flow of information that occurs during a Boleto Bancário transaction. The main steps for processing a Boleto Bancário payment are: 1 You host a customer checkout page on your web site with a selection of payment types that includes Boletos Bancários. 2 The customer chooses Boleto Bancário as the payment type and enters their customer information. 3 You forward the payment information to CyberSource as a Boleto Bancário payment request. 4 CyberSource sends you a reply message that includes the Boleto Bancário expiration date and a URL for the Boleto Bancário form to display to your customer. 5 On your Web site, you display the Boleto Bancário form or a URL that the customer can click to open a pop-up window that contains the Boleto Bancário form. 6 The customer pays using one of two methods: The customer logs into their home banking system and initiates a payment request. The customer prints the Boleto Bancário form and takes it to any bank branch in Brazil and pays cash or uses a bank debit card. (Check payment is not recommended due to the bank's holding period.) 7 The bank at which the customer paid the Boleto Bancário sends the Boleto Bancário funds to the Brazilian Clearing System. 8 The Brazilian Clearing System moves the funds to your depository institution. Boletos Bancários usually clear within two to three days. 9 The depository institution places the funds into your account and sends a daily file containing the paid Boleto Bancário to CyberSource Latin American Processing. 10 CyberSource Latin American Processing sends payment verification to CyberSource. 11 You monitor the progress of the transaction in CyberSource reports and on the Business Center. 12 When you see the payment event in the Payment Events Report, you ship the merchandise because this is verification of payment. For more information about these steps, see the Global Payment Service Developer Guide. Global Payment Service Planning Guide December 2014 52

Chapter 7 Boleto Bancário Payments Figure 15 Boleto Bancário Payment Information Flow Requirements Business Requirements To do business in Brazil, you must have: A license to do business in Brazil. A bank account at a Brazilian bank that can issue Boletos Bancários. Global Payment Service Planning Guide December 2014 53

Chapter 7 Boleto Bancário Payments Web Site Requirements You cannot use IFrame technology with Boletos Bancários. Note On your web site you must publish the Boleto Bancário confirmation form, unaltered in any way, exactly as you retrieved it from CyberSource Latin American Processing. You can publish it in one of the following ways: Display the contents of the Boleto Bancário confirmation form on your web site exactly as you retrieved it. Provide the customer with a link that launches a window or pop-up window that contains the Boleto Bancário confirmation form exactly as you retrieved it. Note Using a pop-up window can cause problems with browsers that block popup windows. Also, CyberSource Latin American Processing has not implemented any JavaScript that controls the size of the pop-up window. Technical Requirements You need to: Contact Customer Support to enable your CyberSource account for Boletos Bancários. You must provide your Boleto Bancário merchant ID, which you obtained while establishing your business relationship with your Boleto Bancário-issuing bank. Install a client SDK. If you have not integrated with CyberSource before, you will be using the Simple Order API, which is the newest of the CyberSource APIs. The older, legacy API is called the SCMP API. To select and install a Simple Order API client or to update your SCMP API client, see the information about clients in the Global Payment Service Developer Guide, which is available on the Support Center. Global Payment Service Planning Guide December 2014 54

Chapter 7 Boleto Bancário Payments Expiration Date Requirements When setting expiration dates, take the following information into consideration: The Boleto Bancário expires at close of business on the expiration date, unless it expires on a weekend or holiday, in which case it expires at the close of the next banking day. Instead of sending an expiration date for the Boleto Bancário in each Boleto Bancário request, you can arrange for CyberSource to use an interval to automatically calculate the expiration date for you. Contact Customer Support to set the value for this interval in your CyberSource account. CyberSource calculates the expiration date by adding the interval to the date that the Boleto Bancário payment is initiated. For example, if a Boleto Bancário payment is initiated on 19 March 2009 and your interval is five days, CyberSource calculates an expiration date of 24 March 2009. CyberSource recommends that you use an expiration interval of five days. Limitations The only service that can be called with the Boleto Bancário payment service is the Tax Calculation service. Information About Your Transactions You have several sources of information about your Boleto Bancário transactions: Reply messages that are sent in response to your service requests. Reports that you can view in and download from the Business Center. Results from the query for a single transaction. Transaction details that you can view on the Business Center. Reply Messages After you send a request message for the Boleto Bancário payment service, CyberSource responds with a reply message that contains information about the status of your request. If your request, contains any errors, this information is included in the reply message. Additional status information is specific to each service. Global Payment Service Planning Guide December 2014 55

Chapter 7 Boleto Bancário Payments Reports Note Boletos Bancários transactions are recorded only on XML-formatted reports. They are not recorded in CSV-formatted reports. Boleto Bancário transaction reports are available through the Business Center or for download in XML format. See the Reporting Developer Guide, which is available on the Support Center, for more information. The following daily CyberSource reports include information about your Boleto Bancário transactions: Payment Submission Detail Report lists your transactions that were sent to the processor during the previous processing day. The report includes transactions for all payment types that you process with CyberSource. To view this report, you must subscribe to it on the Business Center. Payment Events Report lists payment events that occur after a transaction is sent to the processor and that occur within the reporting period for the report. All Boleto Bancário payment transactions previously submitted to the processor, and therefore previously reported in the Payment Submission Detail Report, are reported in the Payment Events Report as updates to the status are received from CyberSource Latin American Processing. To view this report, you must subscribe to it on the Business Center. The following daily Boleto Bancário report provides information about unfulfilled transactions. This report is described in the Global Payment Service Developer Guide, which is available on the Support Center: Boleto Bancário Unfulfilled Report lists Boleto Bancário transactions that were initiated but that are not fulfilled yet. A transaction is included in the report starting the day after a Boleto Bancário is initiated until CyberSource Latin American Processing confirms that the Boleto Bancário is fulfilled. If a Boleto Bancário is not fulfilled by the expiration date, the transaction is removed from the report. To view this report, you must subscribe to it on the Business Center. Query for a Single Transaction Use version 1.4 of the Query for a Single Transaction is supported for Boleto Bancário transactions. The query is described in the Reporting Developer Guide, which is available on the Support Center. The query results show the status of a Boleto Bancário transaction within the transaction time frame. The query results include: Summary information about the transaction Boleto number For a query and response example, see the chapter about Boleto Bancário reports in the Global Payment Service Developer Guide, which is available on the Support Center. Global Payment Service Planning Guide December 2014 56

Chapter 7 Boleto Bancário Payments Transaction Details You can view the details of all your transactions, including your Boleto Bancário transactions, on the Business Center. You can search for transactions by date, application type, customer name, and other transaction identifiers. Abandoned Boletos Bancários CyberSource sends you a reply message that includes a URL for the Boleto Bancário form. After you display the form for the customer, the customer does one of the following: Uses the form to initiate a home banking transfer. Prints and delivers the Boleto Bancário form to the bank and pays the Boleto Bancário there. If the customer does not pay the Boleto Bancário, you do not get paid, and you must then contact the customer. Each Boleto Bancário that is not paid is included in the Boleto Bancário Unfulfilled Report, which indicates that the transaction has not been completed. If the customer does not pay a Boleto Bancário within three days of initiating the Boleto Bancário payment, CyberSource recommends that you send the customer a reminder that you have not received payment. Payment Discrepancies When a payment discrepancy makes it necessary for you to return funds to the customer, you will need a separate procedure for refunds because refunds are not available for Boletos Bancários. CyberSource recommends that you have a separate refund procedure in place, such as using checks or wire transfers, before you accept Boleto Bancário payments. If a customer overpays or underpays, this information appears in the Exception value in the Payment Events Report. See the Reporting Developer Guide, which is available on the Support Center, for information about the Payment Events Report. If the Boleto Bancário amount is greater than the order amount, CyberSource recommends that you ship the product and return the difference to the customer. If the Boleto Bancário amount is lower than the order amount, Cybersource recommends that you cancel the transaction and return the entire Boleto Bancário amount to the customer. Global Payment Service Planning Guide December 2014 57

Direct Debits and Direct Debit Refunds CHAPTER 8 Direct Debits Contact CyberSource Customer Support for a full list of supported countries. Note For direct debits, customers provide their bank account information and authorize you to transfer money out of their accounts. Because direct debits are used only for in-country fund transfers, CyberSource provides you with local country payment-receipt bank accounts. When the account receives payment, CyberSource funds your merchant bank account. Direct debits are similar to electronic checks used in the U.S. Note I is a general term that is used throughout the documentation for this payment type. Depending on the country, direct debits can be called by other names. For example, in Germany, one of the large direct debit systems is called ELV, which stands for Elektronisches Lastschrift Verfahren, and which means electronic debit method. When the customer s payment is received, CyberSource matches the payment to the customer s order and communicates the payment information to you in the Payment Events Report. Global Payment Service Planning Guide December 2014 58

Chapter 8 Direct Debits and Direct Debit Refunds Flow of Identifiers for Order Tracking for Direct Debits The following figure shows the flow of information and identifiers that occurs for a direct debit. Figure 16 Direct Debit Identifier Flow In the figure, solid lines (steps 1-3) indicate actions that happen during the purchase process. Dashed lines (steps 4-7) indicate actions that happen during payment and reconciliation. For definitions of identifiers, see "Order Tracking," page 21. 1 The customer chooses to pay by direct debit. You gather the bank information and send it with your merchant reference code in a request to CyberSource. 2 You send a confirmation to the customer along with the merchant reference code. 3 CyberSource generates a transaction reference number, or reconciliation ID, and sends it and the request to the payment processor. 4 Your local payment-receipt bank receives payment from the customer s bank. 5 The processor processes the settlement transaction. Global Payment Service Planning Guide December 2014 59

Chapter 8 Direct Debits and Direct Debit Refunds 6 The processor notifies CyberSource of the payment. CyberSource updates the transaction status in the CyberSource system as shown in Figure 17, and the payment is matched to its original order. 7 You receive confirmation of the payment in the Payment Events Report, and you update your corresponding pending orders based on the report s information. The report includes the transaction reference number, or reconciliation ID, and your merchant reference code for the payment. The following figure shows the possible transaction statuses for a direct debit. Figure 17 Direct Debit Transaction Statuses You can view a transaction s status in the Transaction Search Details screen. The status is listed as the Action in the small table in the top right corner of the screen. Payment Confirmation and Shipping Goods Use the Payment Events Report to determine when a direct debit payment has been received so that you can ship the goods. Look for an event type of Payment. For more information about the report, see "Fulfilling the Order," page 24. You can reconcile your orders with their corresponding payments by using either the CyberSource-generated transaction reference number, or reconciliation ID, or your own merchant reference code. If you plan to use the merchant reference code, make sure it is a unique value when you send it in the request. Global Payment Service Planning Guide December 2014 60

Chapter 8 Direct Debits and Direct Debit Refunds Direct Debit Reversals Customers can reverse direct debits if they believe the money was taken in error or without permission. A direct debit can also be reversed when there are insufficient funds in the customer s account. When a direct debit is reversed, you receive notice in the Payment Events Report. Look for events labeled Reversal. The Processor Message field provides information about why the direct debit was reversed. The funds are automatically removed from your account and the status of the direct debit changes to REVERSAL. Using Chargebacks and Banking Reversal Codes for Reconciliation You can use the daily Payment Events Report to reconcile your weekly or twice-weekly funding. The process is similar to reconciling a bank statement. Customer payments, such as credit card charges and direct debits, credit your account, and credit card chargebacks and direct debit reversals debit your account. When your account is debited you are not getting paid for the goods or services you provided. From an accounting perspective, credit card charges even when the payment is later reversed always credit your account, and chargebacks always debit the account. The sum of all credit card chargebacks is shown as a negative entry on the weekly or twiceweekly Remittance Report. See "Remittance Report," page 29. Direct debit reversals occur two ways: If a direct debit reversal is received by the processor in the same settlement period as the direct debit it reverses, funds are neither credited nor debited in the Remittance Report. Instead, the transactions are internally reversed and are displayed as a notational entry in the Payment Events Report with an X prepended to the banking reversal code. See the appendix about banking reversal codes in the Reporting Developer Guide, which is available on the Support Center. If a direct debit reversal is received by the processor after the settlement period for the direct debit it reverses, then funds are debited. All debited funds are added together and are displayed as a single debit entry in the Remittance Report. The individual reversal is displayed as a regular entry in the Payment Events Report. Figure 18, page 62, illustrates the two types of direct debit reversals. Global Payment Service Planning Guide December 2014 61

Chapter 8 Direct Debits and Direct Debit Refunds Figure 18 Direct Debit Reversals The reversal for direct debit #1 occurs in the same settlement period as the direct debit it reverses. These transactions do not affect the Remittance Report. The reversal is in the Payment Events Report with an X banking reversal code. Direct debit #2 is credited to your account in Settlement Period A. The reversal for direct debit #2 occurs in the following settlement period. The reversal is on the Remittance Report for Settlement Period B and is included in the sum of deductions. The reversal is in the Payment Events Report with a regular (no X) banking reversal code. Settlement Period A and Settlement Period B could be in the same or different funding cycles. Global Payment Service Planning Guide December 2014 62

Chapter 8 Direct Debits and Direct Debit Refunds Design Considerations Consider these factors when designing your system: With direct debits, you should not ship the goods until you receive confirmation of the customer s payment. Therefore, consider informing customers that shipment will not occur until you receive payment. For more information, see "Fulfilling the Order," page 24. Depending on the country in which the direct debit takes place, you might be required to obtain and store mandates. Contact CyberSource Customer Support for countryspecific requirements. Direct debits are subject to dispute rights. For example, a customer can claim that you did not have permission to remove funds from the account. Therefore, be prepared to handle disputes. You might be required to inform the customer before you collect a direct debit payment. Contact CyberSource Customer Support for country-specific requirements. To avoid providing a refund to customers who reverse a direct debit, CyberSource recommends that instead of issuing refunds for direct debits, you ask customers to reverse the direct debits. Web Site Modifications To accept direct debits, make the following modifications to your web site: Offer direct debit as a payment option if the customer resides in one of the supported countries. Provide the necessary procedure for obtaining a mandate. Contact CyberSource Customer Support for country-specific requirements. Display the appropriate bank information fields for the customer to complete. These fields and their local language labels depend on the country where the direct debit occurs. For guidelines on the bank account number structures used in various countries, see the Global Payment Service Developer Guide. Direct Debit Refunds You can submit a request to refund up to 100% of a direct debit. You can also request multiple partial refunds of a direct debit. The sum of the partial refunds cannot exceed 100% of the original direct debit. CyberSource recommends that before giving the refund, you confirm that you have already received the direct debit payment. When designing your system and your return policy for direct debit refunds, consider the fact that customers can reverse direct debits. The time window during which customers can do so varies by country. Contact CyberSource Customer Support for country-specific requirements. Global Payment Service Planning Guide December 2014 63

Chapter 8 Direct Debits and Direct Debit Refunds Types of Refunds There are two types of direct debit refunds: follow-on refunds and stand-alone refunds. A follow-on refund uses information from a previous direct debit. A stand-alone refund does not depend on a previous transaction. A follow-on refund must occur within a limited number of days after the request for the direct debit. If you are using the API to make these transactions, a follow-on refund must occur within 60 days of the direct debit request. If you are using the Business Center to make these transactions, a follow-on refund must occur within 180 days of the direct debit request. After the time limit for a follow-on refund has passed, the only kind of refund you can make is a stand-alone refund. Requesting a Follow-on Refund A request for a follow-on direct debit refund must include the Request ID that was returned in the reply for the direct debit. Flow of Identifiers for Order Tracking for Direct Debit Refunds To perform a direct debit refund, you must obtain the customer s bank account information and supply it as part of the request to CyberSource. You must also link the refund to the direct debit by providing particular information from the direct debit in your refund request. For more details about the API fields, see information about direct debit refunds in the Global Payment Service Developer Guide. CyberSource recommends that when you request a refund, you use the same merchant reference code that you used for the direct debit. using the same code makes it easier for you to link the refund to the original direct debit in your own system and in CyberSource reports and Transaction Search screens. Figure 19, page 65, shows the flow of information and identifiers that occurs for a direct debit refund. Global Payment Service Planning Guide December 2014 64

Chapter 8 Direct Debits and Direct Debit Refunds Figure 19 Direct Debit Refund Identifier Flow In the figure, solid lines (steps 1-3) indicate actions that happen during the refund initiation process. Dashed lines (steps 4-6) indicate actions that happen during payment and reconciliation. For definitions of the identifiers, see "Order Tracking," page 21. 1 You collect the customer s bank information and send it along with the merchant reference code from the original bank transfer in a request to CyberSource. To request a follow-on refund, send the following additional field (not shown in the figure): Request ID of the original direct debit. 2 CyberSource sends the refund request to the payment processor. 3 The payment processor sends the refund request to your local payment-receipt bank. 4 Your local payment-receipt bank transfers the money to the customer s bank and notifies the processor. 5 The payment processor notifies CyberSource that the refund is complete, and CyberSource updates the transaction status. Global Payment Service Planning Guide December 2014 65

Chapter 8 Direct Debits and Direct Debit Refunds 6 You download the Payment Events Report and update your system based on the report s information. The report contains the merchant reference code and the refund transaction reference number. Depending on which processor you are using, these numbers might not be the same as the direct debit number. Transaction Status Changes The following figure shows the different transaction statuses for a direct debit refund. Figure 20 Direct Debit Refund Transaction Status Changes You can view a transaction s status in the Transaction Search Details screen. The status is listed as the Action in the small table in the top right corner of the screen. You can confirm that a refund has been given to the customer by looking at the Payment Events Report. Look for a Refund event for the refund. Reconciling a Refund Reconciliation for a refund is the same as reconciliation for direct debits. Use the Payment Events Report to get the confirmation that the refund has been processed by the payment processor. See "Payment Events Report," page 31. The report contains the transaction reference number (reconciliation ID) and the merchant reference code (merchant reference number) for the refund. The transaction reference numbers that you receive for all of the refunds will be the same as the number for the direct debit. Global Payment Service Planning Guide December 2014 66

Bank Cards CHAPTER 9 Bank Card Types There are two general types of bank cards you can accept through the Global Payment Service: Global bank cards Regional or country-specific bank cards For more information, see "Bank Cards," page 11. The global bank cards include: American Express Diners Club JCB MasterCard Visa The regional or country-specific bank cards include the following: Carte Bleue (French bank card; note that for this card your capture requests must be 0.99 euros or more) Carta Si (Italian Visa or MasterCard bank card) Dankort (Danish Visa bank card) Delta (U.K. Visa debit card) Electron (European Visa debit card) Eurocard (Regional brand of MasterCard) Laser (Irish Visa bank card) Switch (U.K. bank card) Global Payment Service Planning Guide December 2014 67

Chapter 9 Bank Cards Online and Offline Processing Each Global Payment Service bank card is classified as online or offline. Online Bank Card Flow Online means that when you submit an authorization request to CyberSource, you receive an immediate confirmation from the customer s bank that the funds are available. For online bank cards, you typically start fulfilling the order when you receive confirmation. Figure 21 shows the flow of information and identifiers for an online bank card. Figure 21 Online Bank Card Identifier Flow Customer Customer's bank 4. Merchant Ref 6. Receive funds Merchant 3. Authorization Merchant's local payment-receipt bank 1. Merchant Ref 5. Merchant Ref 9. Reconciliation ID and Merchant Ref 7. Notification CyberSource 2. Reconciliation ID 8. Reconciliation ID Processor In the figure, solid lines (steps 1-4) indicate actions that happen during the purchase process. Dashed lines (steps 5-9) indicate actions that happen during payment and reconciliation. See "Order Tracking," page 21, for definitions of the identifiers. 1 The customer chooses to pay by online bank card, and you send a request for authorization to CyberSource with the merchant reference code. 2 CyberSource generates a transaction reference number (reconciliation ID) and sends it and the authorization request to the payment processor. Global Payment Service Planning Guide December 2014 68

Chapter 9 Bank Cards 3 The customer s bank authorizes the transaction in near real time, returning an authorization code. 4 You send confirmation to the customer with the merchant reference code. 5 When you are ready to bill the customer, you send a capture request to CyberSource with the same merchant reference code that you used in Step 4. For Carte Bleue, your capture request must be at least 0.99 euros. Note 6 The customer s bank settles the order with your local payment-receipt bank. 7 The processor processes the settlement transaction and matches it to the original order. 8 The processor notifies CyberSource of the payment. CyberSource updates the transaction status in the CyberSource system. 9 Download the Payment Events Report using the merchant reference code and the transaction reference number (reconciliation ID) for the payment, and you can update the pending orders based on the report s information. Offline Bank Card Flow For offline cards, you do not receive immediate authorization from the customer s bank indicating that the funds are available. You will not know that funds are available until you receive confirmation of payment. If you sell physical goods, you typically do not ship them until you receive payment confirmation. Offline bank cards typically require 5 more days to confirm payment than online cards do. Figure 22 shows the flow of information and identifiers for an offline bank card. Global Payment Service Planning Guide December 2014 69

Chapter 9 Bank Cards Figure 22 Offline Bank Card Identifier Flow Customer Customer's bank 5. Receive funds 3. Merchant Ref Merchant Merchant's local payment-receipt bank 1. Merchant Ref 4. Merchant Ref 6. Notification 8. Reconciliation ID and Merchant Ref CyberSource 2. Reconciliation ID 7. Reconciliation ID Processor In the figure, solid lines (steps 1-3) indicate actions that happen during the purchase process. Dashed lines (steps 4-8) indicate actions that happen during payment and reconciliation. See "Order Tracking," page 21, for definitions of identifiers. 1 The customer chooses to pay by offline bank card, and you send a request for authorization to CyberSource with the merchant reference code. 2 CyberSource generates a transaction reference number (a reconciliation ID) and sends it and the request to the payment processor. Because there is no online authorization, you receive an authorization code of Offline. 3 You send a confirmation to the customer with the merchant reference code. Funds availability cannot be predicted, however. 4 When you are ready to bill the customer, you send a capture request to CyberSource with the same merchant reference code that you used in Step 3. Note that an alternative is to eliminate this step and instead request both authorization and capture together in Step 1. 5 The customer s bank settles the order with your local payment-receipt bank. 6 The processor processes the settlement transaction and matches it to the original order. 7 The processor notifies CyberSource of the payment. CyberSource updates the transaction status in the CyberSource system. 8 Download the Payment Events Report using the merchant reference code and the transaction reference number (reconciliation ID) for the payment, and you can update the pending orders based on the report s information. Global Payment Service Planning Guide December 2014 70

Chapter 9 Bank Cards Reconciliation Reconciliation enables you to determine when the bank card payment is received. Use the Payment Events Report for confirmation of payments or refunds for all types of Global Payment Service bank cards. For more information about the report, see "Payment Events Report," page 31. You can reconcile your orders to their corresponding payments using either the CyberSource-generated transaction reference number (also known as the reconciliation ID) or your own merchant reference code. If you plan to use the merchant reference code to reconcile orders, make sure it is a unique value such as the merchant order number. Bank Card Refunds You can perform follow-on credits for bank cards. You can also perform multiple partial credits against an original charge. Note that for bank cards processed with the Global Payment Service, you can perform only one partial credit per day for a particular charge. Web Site Modifications You must modify your web site to offer your customers the option to pay using the bank cards appropriate for their country. API for Bank Card Implementation You use the same API for the Global Payment Service bank cards that you use for credit cards processed with CyberSource through other processors. You can find API information in Credit Card Services Using the Simple Order API or Credit Card Services Using the SCMP API. Global Payment Service Planning Guide December 2014 71

Reason Codes APPENDIX A Reason Codes for the Simple Order API These reason codes apply only to Simple Order API. The reason code appears in the reply that you receive immediately after you request the service. See Getting Started with CyberSource Advanced for the Simple Order API for a discussion of replies, decisions, and reason codes. Note CyberSource reserves the right to add new reason codes at any time. If your error handler receives a reason code that it does not recognize, it should use the decision field to obtain the result. Table 5 Reason Codes for the Simple Order API Reason Code Description 100 Successful transaction. 101 The request is missing one or more required fields. Optional action: See the reply fields missingfield_0...n. Resend the request with the complete information. See the information about missing and invalid fields in Getting Started with CyberSource Advanced for the Simple Order API. 102 One or more fields in the request contain invalid data. Optional action: See the reply fields invalidfield_0...n. Resend the request with the correct information. See the information about missing and invalid fields in Getting Started with CyberSource Advanced for the Simple Order API. 150 Error: General system failure. See the documentation for your CyberSource client for information on handling retries in the case of system errors. Global Payment Service Planning Guide December 2014 72

Appendix A Reason Codes Table 5 Reason Codes for the Simple Order API (Continued) Reason Code Description 151 Error: The request was received, but a server time-out occurred. This error does not include time-outs between the client and the server. Optional action: To avoid duplicating the transaction, do not resend the request until you review the transaction status in the Business Center. See the documentation for your CyberSource client for information about resending requests when errors occur. 152 Error: The request was received, but a service timed out. Possible action: To avoid duplicating the transaction, do not resend the request until you have reviewed the transaction status in the Business Center. See the documentation for your CyberSource client for information about resending requests when errors occur. 231 Invalid account number. Optional action: Request a different form of payment. 233 General decline by the processor. Possible action: Request a different form of payment. 234 A problem exists with your CyberSource merchant configuration. 236 Processor failure. Optional action: Do not resend the request. Contact Customer Support to correct the configuration problem. Optional action: Wait a few minutes and resend the request. 239 The requested transaction amount must match the previous transaction amount. Optional action: Correct the amount and resend the request. 241 The request ID is invalid. Optional action: Verify that the request ID is correct. 244 The bank account number failed the validation. Optional action: Verify with the customer that the account number is correct; if it is incorrect, request the service again with the corrected information. 250 Error: The request was received, but a time-out occurred with the payment processor. Optional action: To avoid duplicating the transaction, do not resend the request until you review the transaction status in the Business Center. 254 Your CyberSource account is prohibited from processing stand-alone refunds. Optional action: In the refund request, provide the requestid of the payment to create a follow-on refund. If you want to process stand-alone refunds, contact your CyberSource account representative. Global Payment Service Planning Guide December 2014 73

Appendix A Reason Codes Table 5 Reason Codes for the Simple Order API (Continued) Reason Code Description 255 Your CyberSource account is not configured to process the service in the country you specified. Optional action: If this is a bank transfer or bank transfer refund, verify that the billto_country value and bankinfo_country values are set to the correct country (for a direct debit, bankinfo_country). To process the service in a country for which you are not configured, contact your CyberSource account representative. Global Payment Service Planning Guide December 2014 74

Researching a Missing Bank Transfer Payment APPENDIX B This appendix explains how to submit an inquiry in the Business Center to research a missing bank transfer payment. Note You should wait at least five days after the funds are debited from the customer s account before initiating an inquiry because it can take that long for funds to appear in your account and in CyberSource s reports. CyberSource will not allow you to perform an inquiry within five days of submitting the initial bank transfer request. If your user permissions in the Enterprise Business Center are limited to read access for the Support Screens (SSR), you cannot research a missing payment. You must have additional access permissions. Contact your Enterprise Business Center administrator to change your access level. Before making the inquiry, you must obtain the following items: Information about the bank account that the customer used to make the payment, including the name of the bank, the name on the customer s account, and the account number The date the funds were debited from the customer s account A digital copy of a document that shows that the customer initiated the bank transfer (for example, a scanned bank statement or a screen shot of an online banking statement showing the payment) Global Payment Service Planning Guide December 2014 75

Appendix B Researching a Missing Bank Transfer Payment To research a missing payment: Step 1 Step 2 Log in to the Business Center and search for the bank transfer transaction. View the transaction details. If 3 or more days have passed since you sent the bank transfer request, Research Lost Payment appears as an available action on the right side of the page. Step 3 Click Research Lost Payment. The Research Lost Payment page appears. Part of the form is already completed with the original transaction information. Step 4 In the Merchant Information section at the top of the page, enter your contact information. CyberSource uses this information to contact you if more information is needed. Global Payment Service Planning Guide December 2014 76

Appendix B Researching a Missing Bank Transfer Payment Step 5 In the Customer s Bank Information section at the bottom of the page, enter the customers bank information and the payment date (the date that the funds were debited from the customer account). The required fields are in bold. Step 6 Step 7 Step 8 In the Attachment field, attach the scanned copy of the customer s bank statement or whatever proof the customer possesses to show that they made the payment. In the Other Information field, enter any other information that might help CyberSource research the missing payment. Click Submit. A confirmation page appears and the transaction details are updated to show that you made a payment inquiry. Customer Support receives the inquiry information and contact the processor to verify that the processor received the payment. One of two things happens within several business days: The processor uses the inquiry information to match the payment to the original bank transfer request. Confirmation of the bank transfer payment automatically appears in the Payment Events Report. The transaction details screen in the Enterprise Business Center (see the figure in Step 2) is updated to show that the bank transfer was paid. CyberSource will not contact you by email or phone to give you the results, so you should monitor the Payment Events Report or the transaction s details in the Enterprise Business Center. If the processor cannot find or match the funds to the original bank transfer request, CyberSource will contact you by email or phone. Global Payment Service Planning Guide December 2014 77

INDEX Index A B C D E F G H I J K L M N O P Q R S T U V W X Y Z A accounts 18 American Express 67 B bank cards country-specific 67 described 67 online and offline 68 reconciliation 71 worldwide 67 bank information, displaying 33 bank transfer refunds 42 bank transfers described 35 expected payment times 25 improving order reconciliation 46 increasing order conversion 46 payment reference numbers 23 unpaid 75 Web site modifications 39 Boleto Bancário Unfulfilled Report 56 Boletos Bancàrios confirmation forms 54 description of 51 expiration dates 55 expiration dates and times 51 unpaid 57 C Carta Si 67 Carte Bleue 67 Chargebacks 17 chargebacks 32 Collection Report 28 country-specific bank cards 67 currencies 16 customer support 26 D Dankort 67 Diners Club 67 direct debit refunds 63 direct debits described 10, 58 expected payment times 25 reconciliation 60 reversals 61 Web site modifications 63 E Electron 67 ELV 58 Eurocard 67 events 19 exceptions 26 F financial reports 28 follow-on refunds for direct debits 63 fulfillment policies 24 Global Payment Service Planning Guide December 2014 78

Index A B C D E F G H I J K L M N O P Q R S T U V W X Y Z I implementation 16, 19 J JCB 67 L Laser 67 M MasterCard 67 merchant agreements 17 merchant reference codes 21 O offline and online payment types 68 offline bank cards expected payment times 25 payment flow 69 online bank cards expected payment times 25 payment flow 68 order conversion for bank transfers 46 order reconciliation for bank transfers 46 order tracking for direct debit refunds 64 for direct debits 59 overview 21 P payment confirmation for real-time bank transfers 50 Payment Events Report described 31 direct debit refunds in 66 direct debit reversals in 61 direct debits in 60 exceptions in 26 for order reconciliation 30 for payment confirmation 24 real-time bank transfers in 49 refunds in 25 payment reference numbers 23 Payment Status Report for order reconciliation 30 Payment Submission Detail Report described 30 for order reconciliation 30 R real-time bank transfers 46 reason codes listed 72 reconciliation bank cards 71 for direct debit funding 61 for direct debit refunds 66 for direct debits 60 for real-time bank transfers 50 reconciliation IDs 21 refunds bank transfers 42 for direct debits 63 Remittance Report 28 reports and settlement periods 29 Collection Report 28 financial reports 28 Payment Events Report 31 Payment Submission Detail Report 30 Remittance Report 28 schedules for 29 request tokens 27 reserve accounts 18 reversals 61 Global Payment Service Planning Guide December 2014 79

Index A B C D E F G H I J K L M N O P Q R S T U V W X Y Z S settlement periods and direct debit reversals 61 and reports 29 shipping 24 stand-alone refunds for direct debits 63 Switch 67 T tracking orders 21 trans ref nos 21 Transaction Exception Detail Report for order reconciliation 30 transaction reference numbers 21 U underwriting assessments 17 V Visa 67 W worldwide bank cards 67 Global Payment Service Planning Guide December 2014 80