BillMax Billing Solutions The ispark Group, Inc. PO Box 1947 Colleyville, TX, 76034 USA 877.245.5629 817.446.7776 Fax 817.446.7773 BillMax Documentation Copyright 1994-2014 The ispark Group, Inc. Documentation for BillMax 2014 All rights reserved. No part of this documentation may be reproduced or transmitted in any fashion without written permission by The ispark Group, Inc. This documentation is for use of evaluating the BillMax billing software created by The ispark Group, Inc or for the use of licensees of the BillMax billing software created by The ispark Group, Inc. Any other use of this documentation without written permission of The ispark Group, Inc. is a violation of the use of this documentation. While precautions have been taken in the preparation of this documentation, The ispark Group, Inc. assumes neither liability nor responsibility for errors or omissions, or for damages resulting from the use of the information contained herein. All terms mentioned that are known to be trademarks have been appropriately capitalized. Use of the a trademark does not affect the validity of any trademark or service mark. Links to third-party Web sites are provided for convenience. The ispark Group, Inc. is not responsible for any content contained in the third-party Web sites. Comments about this documentation may be sent to <doc@billmax.com>. Table of Contents General Overview... 3 Processing Modes... 3 Data Model... 4 Transaction Types... 4 Refund Processing... 5 Configuration and Multi-Merchant Issues... 5 1
PCI Compliance and Security Issues... 6 Implementing Tokenization... 7 Electronic Check Compliance Issues and Input... 7 Troubleshooting... 7 2
General Overview This document describes electronic fund processing in BillMax. This includes features, data structures and concepts, PCI compliance, and configuration. Electronic fund processing refers to any payment, credit (refund), authorization or other financial transaction performed by BillMax with external entities. Presently there are two payment methods within BillMax for this activity: Credit Card and Electronic Check. Credit Card processing of course involves debit or credit of a customer's credit account whereas Electronic Check achieves the same with a customer's bank account. The latter is generally achieved through the Automated Clearing House network (ACH). A successful Credit Card payment transaction (barring a charge back) guarantees the receipt of funds at the time of the transaction. Electronic Check processing on the other hand does not. This is due to the asynchronous nature of ACH. With ACH, it may take several days before a merchant knows whether or not a payment or refund was actually successful. To perform electronic fund processing, BillMax utilizes Internet payment gateways. Presently BillMax supports Authorize.Net and IPPay payment gateways. Other gateways and international support are also possible. Contact <support@billmax.com> for further details. Processing Modes BillMax processes electronic transactions either on a demand basis within the web interface or automatically as part of the nightly batch when it determines money should be collected or refunded. For on demand transactions, a Customer Service Representative (CSR) can specify: The payment or refund amount (subject to restrictions) Which payment account to use Which invoices to pay On demand electronic fund processing may be made regardless of how the customer normally pays their bill. During batch processing, BillMax determines on a per customer basis if auto payment or refund should be performed. The criteria for this determination is: The customer account's payment method must be either 'Credit Card' or 'Electronic Check' The customer must have at least one payment account on file with a 'May be used in Batch' setting set to YES The customer balance must be positive (or negative if auto refunds) are enabled The electronic payment date on any outstanding charges must be reached (either the current day or in the past) The next processing date must be reached or not set and the maximum number of attempts must not have been reached The amount to collect or refund must not exceed the account profile maximum and minimums The customer account's 'Disable Automatic Payment' setting is not set to YES During batch processing, the amount to collect or refund is determined by BillMax. If an account is skipped (not processed) during the nightly batch, the reasons for why the account was not processed will be shown in the nightly electronic processing logs. This information is also available via the NOTICE table. Whenever processing fails (for instance a "Decline") BillMax sets the next try date on the failed 3
account's payment account and advances the attempt counter as well. The frequency and maximum number of attempts is specified in the Account Profiles. Automatic electronic refund processing may be disabled on a per account basis or all electronic processing (both charges and refunds) may be disabled in a similar manner. Additionally refund processing may be disabled across all accounts by removing the '-r' setting on the efpbatch program (see System Administration -> Operations -> Batch Processing). The batch processing is done in two separate executions of efpbatch; once for 'Credit Card' and once for 'Electronic Check'. Data Model Aside from the ACCOUNT and PAYHIST tables (which are updated upon successful electronic fund processing), there are two tables involved in electronic fund processing. These are: EFPDATA EFPSTATE EFPDATA holds the account's payment account information. Accounts may have zero or more of these records. Each specific record holds information for a customer's Credit or Bank account. If an account has more than one record on file, the records marked 'May be used in Batch' are used for automatic batch processing. Only one Credit record and Bank record can be marked in this way. The records hold all the information necessary for making transactions; no other data source is used. The records have a payment type. If 'Credit Card', credit card specific fields are populated and used. If 'Electronic Check' bank account fields are populated and used. Address information is common to both methods. To process any electronic transaction on an account there must be a EFPDATA record for that account. EFPSTATE holds the data and results for every electronic processing transaction. During actual processing, this data is used to keep track of the progress of the transactions. Afterward this information may also be needed (depends on the gateway) for handling refunds and other transaction types. In addition, some transactions (like Authorize Only) may not have an associated ACCOUNT or BillMax financial transaction (PAYHIST). In these cases, this table contains the only reference to these transactions. Transaction Types BillMax supports both payments and refunds for both 'Credit Card' and 'Electronic Check' payment methods. In addition, the following transactions types are supported by BillMax provided the utilized gateway supports these as well: Authorize Only Capture Only Void Tokenize 'Authorize Only' and 'Capture Only' are valid only for 'Credit Card'. 'Authorize Only' authorizes a particular amount, but does not complete the transaction. To complete the transaction, a separate 'Capture Only' transaction is executed. At present the only places where BillMax utilizes Authorize Only transactions is when a new payment record is entered or during certain customer portal actions. In both cases, this use is optional. If an amount is authorized, but not captured, the amount may show on a customer's Credit account temporarily, but this amount is not owed and will eventually be removed. However, this amount while present, is included in any credit limit calculations. 4
'Capture Only' "captures" or completes a previously authorized amount. With the exception of certain remote applications (some customer portals), these transactions aren't used anywhere in BillMax. 'Void' is generally available only for 'Credit Card' transactions. It can be used to void a transaction before the daily settlement process take place. So it's use is limited to one day from the time of the original transaction. Using Voids is a good way to fix mistakes before the transactions "hit" the customer's Credit account. After settlement, incorrect charges can only be corrected via refunds. If a transaction is eligible for voiding, BillMax will show an button labeled 'PROCESSOR VOID' on the page for that transaction. 'Tokenize' transactions submit sensitive information (Credit or Bank account number) to the gateway for storage and subsequent use. After an account's payment sensitive information is tokenized, BillMax no longer holds the sensitive information in it database. Instead, in its place a token which identifies this data at the gateway is submitted instead. Utilizing tokens virtually eliminates any exposure a merchant has for handling this information and greatly helps a merchant be PCI compliant. Refund Processing Amounts can only be refunded in BillMax if the amount was actually paid to you. Store credit amounts can not be refunded. Furthermore for a payment to be refunded it must not be allocated to any charges. For example, assume a customer is billed $100 for Internet service and the customers subsequently pays this bill via their credit card. In this case, the sale for Internet access must first be "returned" (voided) before the payment can be refunded. In addition, some gateways impose additional requirements. These include a time limit where transactions older than a set number of days can't be refunded and a requirement that refunds are possible only if the original payment was made at the same gateway as the gateway used for refunding. Configuration and Multi-Merchant Issues Before BillMax electronic fund processing can be performed, it must be configured. Configuration is done via BillMax lists (see Billing -> Lists). A list is a collection of related settings. For each supported gateway or processor there will be one or more lists. The number depends on the payments types involved (Credit Card or Electronic Check) and whether or not you use multiple gateway accounts. In BillMax, each Virtual company may be configured separately to use a particular gateway. This ability is what is known as "Multi-Merchant" as it refers to the ability to use multiple merchant accounts. To process Credit Cards, one or more merchant accounts are required (one for VISA/MasterCard, and one each for Discover, American Express, etc.). IPPay provides both gateway services and a VISA/ MasterCard merchant account. Authorize.Net provides gateway services only so a separately obtained Visa/MasterCard merchant account is required. Contact BillMax sales for further details on your choices and for special offers through our merchant services partners. If a single gateway/processor is used for all your virtual companies, you must edit two lists (assuming you accept both Credit Card and Electronic Check payments). The available configurations are: IPPay IPPay-echeck Authorize.Net Authorize.Net-echeck FirstData 5
LoopBack LoopBack-echeck LoopBack is a special test processor. If used the transactions are processed by a dummy processor. The transactions aren't real and no actual money is involved. It is useful for pre-production testing. Assuming the IPPay gateway is used for both payment types, at a minimum the following list items must be set: State - Change from 'Not Active' to 'Active' Username - Set to the terminal ID associated with your IPPay account Test - Set to 0 The above changes should be made to both the IPPay and IPPay-echeck lists. If using Authorize.Net, the same changes must be made to their lists. Authorize.Net also requires a password (list item Password ) or transaction key (list item UserPass.TransactionKey). If tokenization is supported by the gateway, there will be a 'Tokenization' list item. Set to '1' to enable tokenization. If you wish to use multi-merchant, you will need to configure a list (two if also accepting Electronic Checks) for each virtual company in BillMax. To facilitate this configuration, a utility script named copylists.pl can be used to replicate additional lists. See instructions in script. Note that the actual list name is not significant, though it is recommended that the list be named appropriately to facilitate look ups and edits. Contact BillMax support for further assistance with multi-merchant configurations. BillMax can be configured to perform a small 'Authorization Only' transaction at the time of data entry if desired. This is useful to ensure that the Credit Card account is valid and in good standing prior to it's actual use. To enable these transactions, edit the 'Authorize' list item. Set it to a low amount; a value of 1.00 is typical and means authorize one dollar. Some gateways support a value of 0.00 as well. If available, this amount is preferable. To disable 'Authorization Only', a value of 'No' should be used. This setting has no meaning for Electronic Check. There are numerous other electronic fund processing configuration settings. Please consult BillMax support before making changes to any setting not mentioned in this document. PCI Compliance and Security Issues BillMax has undergone significant improvements concerning overall security and support for features needed to help BillMax users adhere to the Payment Card Industry's security requirements. The requirements are quite extensive and address software as well as a myriad of operating and environment issues as well as required practices. Wherever possible BillMax has implemented security features per their PA-DSS specifications. See their web site [http://https://www.pcisecuritystandards.org/] for details. There are several security settings which control the level of security and level of compliance in BillMax. If the PCI Mode setting is set to YES (see System Administration -> Security -> Security Settings), BillMax will ensure that the appropriate settings are used. One PCI compliance issue in particular concerns the storage and visibility of credit card numbers. Once entered, BillMax limits viewing of Credit Card numbers to the last 4 digits. Viewing the entire card number is not allowed in any circumstance. In addition, the numbers are masked in all log files. Assuming that tokenization is not in use, the only place card numbers are stored (available) is in the EFPDATA and EFPSTATE tables (see Data Model section above). When in PCI compliance Mode, these card numbers are encrypted using AES encryption. While not part of PCI compliance, BillMax also handles Bank account information in the same manner. 6
If tokenization (see Transaction Type section above) is fully utilized, no Credit Card or Bank account numbers are stored in the BillMax database or any of it's files. In fact, BillMax is designed to tokenize this information upon the initial data entry. In this way, no sensitive information is ever written to disk. If tokens are utilized, the tokens themselves are also AES encrypted. Implementing Tokenization Only certain gateways support tokenization. Please check with BillMax support before attempting to tokenize your sensitive Credit Card and Bank account numbers. To enable tokenization, The 'Tokenization' setting in the appropriate configuration lists should be set to 1. Once done, all new or modified sensitive data entered into BillMax (efpdata table) will be tokenized upon entry. In addition, any non tokenized sensitive data will be tokenized as part of any normal transaction the first time that information is referenced. Over time, this practice will eventually tokenize all active accounts. To ensure that all information held in BillMax is tokenized, BillMax provides a utility program that will convert all the existing sensitive information. Please contact BillMax support for instructions on using this program. Electronic Check Compliance Issues and Input As mentioned previously, Electronic Checks processing is handled ultimately through the Automated Clearing House (ACH) network. Rules and regulations that govern the ACH network are established by NACHA (formerly the National Automated Clearing House Association) and the Federal Reserve. See their website> [https://www.nacha.org/achrules] for details. To help a merchant comply with these regulations, Billmax collects specific details on a customer's bank account as well as how the authorization for access to that account was obtained from the customer. With the exception of the SEC code, most of the fields are self explanatory. The SEC code identifies how the authorization was obtained. Here are the possible values and their meaning. ARC - Accounts Receivable Check. Converted checks received via the US mail or at a drop box location. BOC - Back Office Conversion. Converted checks received by merchant at the point of purchase or at manned bill payment locations, and processed during back office operations. CCD - Corporate Credit or Debit. Transfer of funds between business accounts or to consolidate funds from several accounts of the same business. PPD - Prearranged Payment and Deposit Entry. Recurring entry for direct deposit of payroll, pension, etc., or for direct payment of recurring bills such as utilities, loans, insurance, etc. TEL - Telephone Authorized Entry. Single or recurring entry submitted pursuant to an oral authorization obtained solely via the telephone. WEB - Internet Authorized Entry. Entry submitted pursuant to an authorization obtained solely via the Internet or a wireless network. The most common type is PPD. Please note that the gateway impose restrictions on which values may be used. Troubleshooting Every transaction is recorded in log files and in the database. For the latter see the discussion on the data model above. For on demand transactions from a web interface (staff or customer), there will be a log file per transaction. For nightly batch processing, one or more transactions may be within a single log file 7
and the number of log files generated is dependent on the payments methods processed (Credit Card or Electronic Check) and whether or not multiple merchant accounts are utilized. Log files can be found in directories named /usr/local/billmax/efp/module-type where MODULE is the name of the gateway processor and TYPE is the payment type. These files normally contain processing summaries. To see detailed logs, set the applicable 'Verbose' list configuration item to 1. The EFPSTATE table contain a record for every transaction. This information includes account, time, transaction ids, gateway output, and result codes. Some key fields in this table: efpid - Internal BillMax transaction id. account - The customer account number in BillMax. payhist - The associated payment number. Present only if payment was successful. efpdata - The associated payment account number. efptype - The type of transaction. 1 = Authorize+Capture, 2 = Authorize, 3 = Capture, 4 = Void, 5 = Tokenize trantype - Transaction type. 1 = Payment or Other, 2 = Refund state - Transaction progress code. 4 = Complete. transid - Gateway transaction id. accepted - Overall result. 1 = success. processorcode - Gateway result code. reason - Gateway reason text. commcode - Communication error code. 0 = No communication error. processorbuf - Gateway output text (log). The NOTICE table also contains abbreviated status information on transactions and potential transactions (those that were skipped for some reason). The following query be used to show recent electronic fund processing: select entdate,enttime,account,summary from notice where class >= 39 and class <= 44 order by entdate, enttime 8