Learning Center
Plans & pricing Sign in
Sign Out

QBMS Credit Card Processing Guide.doc


									 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.
 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.
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.
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.
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.
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.
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
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.
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.
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.
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
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
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.
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.
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:
85       Merchant does not need to switch back and forth between the QBMS Merchant Services
86       Center and the application
88       Application is able to provide the full context on all customer transactions
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.
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:
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.
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 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.

120   Typical Integration Options
122   There are several dimensions to constructing requirements for credit card integration. This
123   section lists a few of them:
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
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.
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.
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.
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.
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.
168   Link to PCI DSS:
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:
176   management/cisp.html|Defining%20Your%20Merchant%20Level
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.
185   Link to PABP:
188   QBMS strives to make it easier for your application to comply with the standards.
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.
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.
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.

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.

To top