1 QuickBooks Merchant Service Credit Card Processing Guide 2 This guide seeks to explain the common use cases for QuickBooks Merchant Service (QBMS) 3 credit card transactions and provides recommendations on the optimal method for writing to 4 QBMS. Please refer to QBMS Developers Guide for more detail. Also refer to QuickBooks 5 Merchant Service SDK specification for the details of mandatory and optional fields in each 6 of these transaction types. 7 8 QuickBooks Merchant Service (QBMS) Software Development Kit (SDK) supports the 9 following transactions:- 10 Authorization: This transaction authorizes requested amount on a credit card. It 11 creates a hold on funds in cardholder account for a certain number of days that varies by 12 the issuer, often up to 30 days. However, no money changes hands. 13 14 Capture: This transaction follows a previous authorization. It indicates completion of a 15 transaction e.g., with the delivery of promised goods or services. It also initiates 16 movement of money from cardholder account into the merchant account. Capture 17 reflects the value of goods/services actually transacted. Ideally, it is for the amount of 18 the authorization. Different amounts are also permitted but they may cause transaction 19 downgrades unless industry specific criteria are met. 20 21 Sale/Charge: Often also called a charge, this transaction validates that adequate funds 22 exist in cardholder account to cover the charge as well as initiates the settling of funds. 23 Another way of thinking about this transaction as one step to perform both 24 authorization and capture together. It is usually performed for transactions where the 25 goods or services are provided at the same time as the payment. 26 27 Refund: This transaction refunds the money to the cardholder as a result of conditions 28 such as return of goods or incomplete/unsatisfactory/terminated service. 29 30 VoidOrRefund: Introduced in 2.1, this smart refund transaction refers to a previous 31 Sale, Capture or Voice Auth Capture. If possible, it will first try to void the transaction 32 else it will issue a refund to the card holder for the specified amount. The credit card 33 information does not need to be provided. See below for conditions under which a void 34 will be performed. 35 36 Voice Authorization Capture: Occasionally, the merchant may need to call the issuer for 37 authorization and obtain an auth code. This auth code is then sent in a voice 38 authorization request to QBMS to capture the funds 39 40 Void: If a credit card transaction has not been settled yet, the transaction may be 41 voided by supplying the original transaction id. The following transactions can be voided 42 – Auth, Sale, Capture and Refund. A typical reason for void is to reverse an 43 unintentional error e.g., customer gave a different credit card from the one she intended 44 to charge. Void would cancel the previous transaction for a much lower cost than a 45 refund. Void of an authorization merely prevents a capture from being performed on 46 that authorization code. The hold on funds is not released immediately. It will expire in 47 10 to 30 days, depending on the issuer, on its own. 48 49 Merchant Account Query: This query returns card types supported for the specified 50 merchant account. It also returns another field called convenience fee. It will return zero 51 in almost all cases since only some special accounts are eligible to be set with 52 convenience fees. 53 Supported Market Segment Features 54 The following features and segments are supported 55 eCommerce: ECI (eCommerce indicator) is supported for auth, charge, refund and voice 56 auth transactions. If the credit card information is entered by the cardholder over the 57 web, the transaction is considered to be an eCommerce transaction. 58 59 Recurring: Recurring charge indicator is supported for auth, and charge transactions. 60 Applications may use this to build recurring billing functionality. Typically, prior 61 written authorization from cardholder must be obtained to set up recurring charges on 62 her credit card. Recurring charges apply only till the expiration date on the card. 63 64 Mail Order/ Telephone Order (MOTO): QBMS may be used for card not present 65 situations such as MOTO transactions for credit cards that are called in over the phone 66 or mailed in 67 68 Retail (Card Present): Credit cards may be swiped using a magnetic stripe reader and 69 track2 data submitted for retail and card present applications 70 71 Commercial Card Code: for applications that take purchase, corporate and business 72 credit cards, this code is sent for auth, charge, refund and voice auth transactions 73 Use of Merchant Services Center 74 QBMS comes with an online reporting and transacting tool called Merchant Services Center. 75 This includes reports on all transactions for a given merchant account. Its account 76 management features are used to set fraud preferences and processing options. 77 78 Merchant Services Center also allows processing of transactions. A typical use of this 79 capability is for transaction such as a Void or Refund of a Sale or Capture of an 80 Authorization carried out within QBMS integrated software. 81 82 While QBMS does provide this ability to transact via the online Merchant Services Center, 83 processing all transactions via QBMS integrated software provides the following benefits: 84 85 Merchant does not need to switch back and forth between the QBMS Merchant Services 86 Center and the application 87 88 Application is able to provide the full context on all customer transactions 89 90 Application is able to provide data to QuickBooks via the QuickBooks SDK for 91 reconciliation. At this point, the transactions performed via Merchant Services Center 92 are not available for download into QuickBooks. 93 94 Fraud settings 95 QBMS provides for automated fraud checks. These settings are managed on Merchant 96 Services Center and are set to the default values shown in QBMS Developer Guide. By 97 default, all QBMS users are set up with the following fraud settings. Please note that these 98 settings apply only when processing through 3rd party software and not when processing 99 through QuickBooks or related products: 100 101 AVS refers to address verification service that validates the billing address on a credit card. 102 CSC refers to card security code, which is a 3 digit number found on the back of Visa, 103 MasterCard and Discover cards or 4 digits found in front of the American Express cards. 104 Mismatch of AVS or CSC data does not necessarily imply that the card is bad however, it is a 105 very good indication of fraud and use of these codes is highly recommended for credit card 106 acceptance. Your customers that use QBMS can go to Merchant Services Center to change 107 these settings. If you also do AVS or CSC related fraud checking inside your software, 108 Merchant Service Center settings will be applied first and may potentially conflict with 109 settings in your software. Please ensure that your customers that use QBMS are educated 110 about the fraud options and on how to change them in Merchant Services Center. 111 112 It is also possible to have your customers be set to a different default. Under that setting, 113 QBMS will conduct no checks unless those checks are explicitly configured on the Merchant 114 Services Center. If you need your application set to this default, please email 115 firstname.lastname@example.org with your application id with your request. In such a case, we will 116 assume that your application will interpret the return fraud codes for address verification 117 and card security code checks. If your customer configures the settings on the Merchant 118 Services Center, those will take precedence over any checks inside your application. 119 120 Typical Integration Options 121 122 There are several dimensions to constructing requirements for credit card integration. This 123 section lists a few of them: 124 125 Input method – key entered vs. card swiped: When the cardholder is present in person with 126 his/her credit card, data may be read via a magnetic stripe reader. QBMS supports a 127 standard USB card reader that may be ordered off QBMS site 128 http://quickbooks.intuit.com/commerce/catalog/product.jhtml?prodId=prod0000000000008044 129 443 . However, when the cardholder is not present, application needs to provide fields for 130 key-entry of data. Key entered integration options are typically used in MOTO and 131 eCommerce scenarios while swipe option is typically used in retail scenarios. 132 133 Fulfillment method – instantaneous or delayed: When the goods or services have been 134 delivered at the time of payment, a Sale transaction should ideally be used to authorize and 135 capture the data in one step. However, if goods or services will be delivered at a later time, 136 credit card may be authorized in advance to hold the funds. Upon fulfillment, the data can be 137 captured via a Capture transaction for payment to be completed. Retail sales are an example 138 of the former while eCommerce or MOTO sale of goods are an example of the latter. On the 139 other hand, soft goods such as music or software downloaded instantaneously from 140 eCommerce sites would qualify as instantaneous fulfillment. 141 142 Handling returns/ cancellations – refunds or voids: A customer may want to charge a 143 different credit card, cancel the order or return items after a payment has been made. If an 144 authorization only (Auth) had been carried out, there is nothing to do. The capture amount 145 may need to be adjusted. However, if a Sale, Capture or Voice Auth Capture had been done, 146 the transaction must be voided or refunded. A void may be carried out for a transaction 147 before batch close (at 3pm Pacific time) else a refund would need to be submitted. Check out 148 the Void, Refund and VoidOrRefund transactions. 149 150 Dealing with exceptions – voice authorizations: Usually when software is out of service and 151 there is no access to processing services, a voice authorization may be received by calling 152 authorization phone numbers. To complete the payment, a Voice Auth Capture must be 153 carried out later using the auth code received at the time of voice authorizations. A voice 154 auth may also be requested for large dollar amounts or other special circumstances. 155 156 Handling merchant service response codes: Plan to handle the merchant service responses 157 especially the error codes gracefully. A transaction may be declined for multiple reasons and 158 it is important that you display the appropriate response to the user for the situation. As a 159 best practice the errors should be logged for potential future review. Refer to the developer’s 160 guide for further information on error handling. 161 Security 162 Credit card number, also known as Primary Account Number (PAN) and any data related to 163 PAN must be handled and stored securely. Please review the Payment Card Industry Data 164 Security Standard (PCI DSS) available online at the following location. Merchants and 165 software used by merchants must comply with these standards in order to minimize risks 166 and avoid penalties in the event of a security breach. 167 168 Link to PCI DSS: https://www.pcisecuritystandards.org/tech/download_the_pci_dss.htm 169 170 Practical operating requirements for merchants that are imposed by the PCI Data Security 171 Standards will vary depending upon the transaction volume. Merchants processing vary 172 large transaction volumes have a stricter set of requirements than smaller merchants that 173 process fewer transactions. For more information, please see: 174 175 http://usa.visa.com/merchants/risk_management/cisp_merchants.html?it=c|/merchants/risk_ 176 management/cisp.html|Defining%20Your%20Merchant%20Level 177 178 Also, refer to PCI Payment Application Best Practices (PABP) guide from Visa to assist 179 software vendors create secure payment applications that help ensure merchant compliance 180 with PCI DSS. Note that these best practices form a subset of the larger PCI Data Security 181 Standard; software for merchants must comply or facilitate compliance with both the 182 Payment Application Best Practices as well as the broader PCI Data Security Standards. 183 184 185 Link to PABP: 186 http://usa.visa.com/merchants/risk_management/cisp_payment_applications.html 187 188 QBMS strives to make it easier for your application to comply with the standards. 189 190 For any of the follow-on transactions – refunds (when VoidOrRefund transaction is 191 used), voids or captures – credit card number is not required. This means that you 192 neither have to store the credit card number nor request it from the cardholder to 193 carry out a refund, void or capture. This provides a better user experience while 194 reducing the security burden for your application. 195 196 The credit card reconciliation data downloaded to QuickBooks does not need any 197 more than last 4 digits of the credit card number. This implies that you do not need 198 to store any more than the last 4 digits of a credit card number. 199 200 You must also advise your customers using your application on the best practices related to 201 your credit card implementation so they can handle the data in a secure manner. For 202 example, if you design password protection and encryption features in order to protect 203 sensitive information, advise your customers on how best to leverage those features to 204 safeguard sensitive data against hackers, employee theft, etc. 205 206 Batch close 207 Batch close is an event that triggers the settlement and funding of previously processed 208 credit card transactions. QBMS supports an automatic daily host initiated batch close. The 209 open batches for all merchants are closed at 3PM Pacific time.