echeck.net Compliance An Education Guide for Merchants

Transcription

1 echeck.net Compliance An Education Guide for Merchants

2 Table of Contents Introduction... 3 WEB - Internet-Initiated/Mobile Entry... 3 WEB Authorization Requirements... 3 WEB Example... 4 PPD (Prearranged Payment and Deposit Entry) & CCD (Cash Concentration or Disbursement)... 4 PPD and CCD Authorization Requirements... 4 PPD and CCD Example... 5 TEL - Telephone-Initiated Entry... 5 TEL Authorization Requirements... 6 TEL Example... 6 ARC - Accounts Receivable Conversion... 7 ARC Restrictions... 7 ARC Check Requirements... 7 ARC Notice Requirements... 8 ARC Storage Requirements... 8 ARC Authorization Requirements... 8 BOC - Back Office Conversion... 9 BOC Restrictions... 9 BOC Check Requirements... 9 BOC Notice Requirements...10 BOC Storage Requirements...10 BOC Authorization Requirements...10 Example of Auxiliary On-US Field Authorize.Net Page 2 of 11

3 Introduction Authorize.Net is dedicated to supporting your business needs and works hard to deliver the highest quality products and services. To minimize your losses, you must maintain compliance to prevent potential returns. Staying in compliance will help you save time and money when the depository bank requests proof of authorization. In this guide, we have provided you some examples on how to stay in compliance based on how you are processing. First, check your account s status in the Merchant Interface to determine which transaction types you are are approved for: 1. Log into the Merchant Interface at 2. Click Account from the main toolbar. 3. Click Merchant Profile from the main menu on the left. 4. Under the Payment Methods section, next to echeck.net, you will see one or more of the following echeck.net transactions types in the Status column: WEB, PPD, CCD, TEL, ARC or BOC. Please review the examples in this guide for each transaction type to make sure you are in compliance with your processing type. Feel free to contact us with any questions or concerns at option 2. You can also find more information by reading our echeck.net Operating Procedures and User Guide found at WEB - Internet-Initiated/Mobile Entry WEB is a charge transaction against a customer s personal checking or savings account. One-time or recurring WEB transactions may be originated via the Internet or a mobile device on a wireless network. WEB Authorization Requirements For a WEB entry, authorization is obtained from the customer via the Internet or mobile device on a wireless network during the payment or checkout process by capturing a screen shot and retaining the information in a template for two years. Implementation of payment authorization language is up to the merchant, as long as it complies with the authorization requirements stated below. It is also recommended that payment authorization language appear on the same page that collects the customer s bank account information. The customer s payment authorization must: 1. Be capable of displaying on a computer screen or other visual display that permits the customer to read and/or print it 2. Be readily identifiable as an authorization 2014 Authorize.Net Page 3 of 11

4 3. Clearly and conspicuously state its terms including the dollar amount, the effective date of the transfer and whether the authorization is for a one-time purchase or a recurring transaction 4. For recurring WEB transactions, the merchant must also provide a notice that the customer may revoke the standing payment authorization by notifying the merchant as specified in the payment authorization (i.e. calling a specific number or writing a specific address) WEB Example Merchant s payment form includes the following customer payment information as provided by the customer. Customer s Name (as it appears on bank account): Bank Name: Customer s Bank s ABA Routing Number: Bank Account Type: (savings, personal checking) Bank Account Number: By clicking the button below, I authorize [merchant s name] to charge my bank account starting on [month, day, year] and on the [day of the month] of each month following through [month, date year] for the amount of [$XX.XX] for [description of the transaction]. Authorize Payment Note: Portions of the second paragraph are for recurring payments only and are optional if you are only authorizing a one-time charge. PPD (Prearranged Payment and Deposit Entry) & CCD (Cash Concentration or Disbursement) PPD is a charge or credit transaction initiated by a merchant against a customer s personal checking or savings account. CCD is a charge or credit transaction against a customer s business checking account. PPD and CCD Authorization Requirements A written paper authorization/agreement filled out by the customer is required for onetime transactions and recurring charges. For recurring transactions the agreement must clearly state the terms of the recurring transaction and how to cancel the recurring payments. Payments cannot be processed until a filled out copy of the agreement is received from the customer. Copies of the written authorizations/agreements should be retained for two years. In addition, a PPD transaction cannot be used for telephone-initiated or Internet-initiated transactions, or for converting a paper check into an electronic payment Authorize.Net Page 4 of 11

5 PPD and CCD Example The below sample form can be modified with your company information and then copied and pasted onto your Company Letterhead. Date: (Option 1- for One-Time) I,, authorize [MERCHANT NAME] to charge my banking account listed below on [month, day, year] for the amount of $ for. [Description of the transaction] (Option 2- for Recurring) I,, authorize [MERCHANT NAME] to charge my banking account listed below, starting on the [month, day, year] and on the [day of the month] for each month following through [month, day, year] for the amount of $ for. [Description of the transaction] My account information is as follows: Customer s Name (as it appears on Bank account): Bank Name: Bank Account Type: Checking Savings Business Checking Bank ABA Routing Number: Bank Account Number: This payment authorization is valid and to remain in effect unless I, notify [MERCHANT NAME] of its cancellation by sending written notice to (Merchant: Please insert your mail to/ fax to/ to, etc., Or list your other preferred method). Customer Name Printed Customer Signature Date Note: The third paragraph is for recurring charges only and is optional if you are only authorizing a one-time charge. Also, you do not need to require the customer to attach a voided check. TEL - Telephone-Initiated Entry TEL is a one-time or recurring charge transaction against a customer s personal checking or savings account. TEL transactions may only be submitted against personal checking and savings accounts. The Originator/Merchant must either make an audio 2014 Authorize.Net Page 5 of 11

6 recording of the oral authorization or provide the Receiver with written notice confirming the oral authorization prior to the Settlement Date of the Entry. TEL transactions may only be originated when a business relationship between the merchant and the customer already exists, or, if no relationship exists, only when the customer initiates the telephone call to the merchant. TEL Authorization Requirements A telephone call must be recorded and retained for a minimum of two years. The authorization must include: 1. A clear statement that the customer is authorizing a charge to his or her bank account 2. The terms of the authorization in a clear manner, including: TEL Example the customer s name the date the authorization is given the bank routing and account number the date on or after which the customer s bank account will be charged (If recurring, the timing (including the start date), number of recurring charges, and/or frequency of the electronic fund transfers (weekly, monthly, etc.) and an end date.) the amount of the transaction to be charged (If recurring, state the recurring amount also.) a telephone number that is available to the customer and that is answered during normal business hours for customer inquiries and/or to cancel future recurring charges. To confirm your order, I understand that you, [customer s name] authorize [merchant s name] to charge your [bank account type] on [month, day, year] for the amount of [$X.XX] for [description of the transaction]. The account information you ve provided me is as follows: Bank Name: [name of the customer s bank] Bank ABA Routing Number: [customer s bank s ABA routing number] Bank Account Type: [checking, business checking, savings] Bank Account Number: [the customer s bank account number] Is this information correct? As of today s date, [month, day, year], this payment authorization is valid and to remain in effect until you, [customer name], notify [merchant s name] of its cancellation by calling [merchant s customer service number] 2014 Authorize.Net Page 6 of 11

7 Note: For an authorization relating to a single TEL Entry, the Originator/Merchant must either make an audio recording of the oral authorization or provide the Receiver/Customer with written notice confirming the oral authorization prior to the Settlement Date of the Entry. For an authorization relating to recurring TEL Entries, the Originator/Merchant must comply with the requirements of Regulation E for the authorization of preauthorized transfers, including the requirement to send a copy of the authorization to the Receiver. ARC - Accounts Receivable Conversion ARC is a single-entry debit against a customer s checking account. ARC allows merchants to collect payments received in the mail or left in a drop-box, and convert them to an electronic payment later. Merchants do not return the check to the customer or present it to the bank for payment. ARC Restrictions Merchants must use a check reading device to capture the MICR line (routing number, account number and check serial number), but may key in the transaction amount manually. (MagTek provides a variety of check reading devices. For more information, please visit ARC transactions may only be submitted to the payment gateway through a batch upload transaction or through an Application Programming Interface (API). Note: Server Integration Method (SIM) merchants must use the batch upload feature of the Merchant Interface, while Advanced Integration Method (AIM) merchants may use an API to submit the required transaction information. ARC Check Requirements To submit an ARC entry, the check must: 1. Contain a pre-printed serial number 2. Not contain an Auxiliary On-Us Field in the MICR line (positioned to the left of the routing number or the external processing code) 3. Be in the amount of $25,000 or less 4. Be completed and signed by the customer Checks that may not be used for ARC entries include: Checks that contain an Auxiliary On-Us Field in the MICR line (see below for an example of a check that contains an Auxiliary On-Us Field) Checks in an amount greater than $25,000 Third-party checks Demand drafts and third-party drafts that do not contain the signature of the customer 2014 Authorize.Net Page 7 of 11

8 Checks provided by a credit card issuer for purposes of accessing a credit account or checks drawn on home equity lines of credit Checks drawn on an investment company as defined in the Investment Company Act of 1940 Obligations of a financial institution (e.g. travelers checks, cashier s checks, official checks, money orders, etc.) Checks drawn on the U.S. Treasury, a Federal Reserve Bank, or Federal Home Loan Bank Checks drawn on a state or local government that are not payable through, or at, a participating Depository Financial Institution Checks payable in a medium other than U.S. currency ARC Notice Requirements Before accepting checks that will be used for ARC entries, merchants must provide their customers with a clear and readily understandable notice that includes the following, or substantially similar, language: "When you provide a check as payment, you authorize us either to use information from your check to make a one-time electronic fund transfer from your account or to process the payment as a check transaction." The notice must be provided in a clear and conspicuous manner, meaning it must be easily accessible to customers. The following language, or substantially similar language, must also be included to ensure that customers understand that their checks are being converted to an electronic payment that will clear their account faster than standard electronic check processing. "When we use information from your check to make an electronic fund transfer, funds may be withdrawn from your account as soon as the same day you make your payment, and you will not receive your check back from your financial institution." ARC Storage Requirements Once the payment information is captured from the check, merchants must retain an image or copy of the face of the check for at least two years from the settlement date (the date the ARC entry posts to the customer s account) and destroy the original check. The face of the copy must state that it is a copy. Upon written request from the RDFI, merchants must provide a copy of the check, with Copy written on its face, at no charge and within 10 business days of receiving the request. The physical check may not be re-presented for payment. ARC Authorization Requirements If a merchant receives a customer s signed check after the merchant has posted the appropriate notices in a conspicuous location, they have the customer s authorization to process an ARC entry Authorize.Net Page 8 of 11

9 BOC - Back Office Conversion BOC is a one-time charge transaction against a customer s checking account. BOC allows merchants to collect a check written at a point of sale (checkout counter, manned bill payment location, service call location) and convert it to an ACH debit during back office processing. Merchants do not return the check to the customer or present it to the bank for payment. BOC Restrictions The merchant must use a check reading device to capture the MICR line (routing number, account number and check serial number), but may key in the transaction amount manually. (MagTek provides a variety of check reading devices. For more information, please visit BOC transactions may only be submitted to the payment gateway through a batch upload transaction or through an Application Programming Interface (API). Note: Server Integration Method (SIM) merchants must use the batch upload feature of the Merchant Interface, while Advanced Integration Method (AIM) merchants may use an API to submit the required transaction information. BOC Check Requirements To submit a BOC entry, the check must: 1. Contain a pre-printed serial number 2. Not contain an Auxiliary On-Us Field in the MICR line (positioned to the left of the routing number) 3. Be in an amount of $25,000 or less 4. Be completed and signed by the customer Checks that may not be used for BOC entries include: Checks that have not been encoded in magnetic ink Checks that contain an Auxiliary On-Us Field in the MICR line (see below for an example of a check that contains an Auxiliary On-Us Field) Checks in an amount greater than $25,000 Third-party checks Demand drafts and third-party drafts that do not contain the signature of the customer Checks provided by a credit card issuer for purposes of accessing a credit account or checks drawn on home equity lines of credit Checks drawn on an investment company as defined in the Investment Company Act of 1940 Obligations of a financial institution (e.g., traveler's checks, cashier's checks, official checks, money orders, etc.) 2014 Authorize.Net Page 9 of 11

10 Checks drawn on the Treasury of the United States, a Federal Reserve Bank or a Federal Home Loan Bank Checks drawn on a state or local government that are not payable through or at a participating DFI Checks payable in a medium other than U.S. currency BOC Notice Requirements Before accepting a check that will be used for a BOC entry, merchants must provide the customer with a clear and readily understandable notice that includes the following, or substantially similar, language: "When you provide a check as payment, you authorize us either to use information from your check to make a one-time electronic fund transfer from your account or to process the payment as a check transaction. For inquiries, please call <customer service number>." The notice must be posted in a prominent and conspicuous location at the point of purchase or manned bill payment location. A copy of the notice, or similar language, must also be provided to the customer on their receipt or other takeaway at the time of the transaction. The following language, or substantially similar language, must also be included to ensure that customers understand their checks are being converted to an electronic payment that will clear their account faster than standard electronic check processing. "When we use information from your check to make an electronic fund transfer, funds may be withdrawn from your account as soon as the same day you make your payment, and you will not receive your check back from your financial institution." The above language does not have to be included on the receipt or takeaway given to the customer. Both notices must include a working customer service telephone number that is answered during normal business hours for customer inquiries. BOC Storage Requirements Once the payment information is captured from the check, merchants must retain an image or copy of the face of the check for at least two years from the settlement date (the date the BOC entry posts to the customer s account) and destroy the original check. The face of the copy must state that it is a copy. Upon written request from the RDFI, merchants must provide a copy of the check, with Copy written on its face, at no charge and within 10 business days of receiving the request. The physical check may not be re-presented for payment. BOC Authorization Requirements If a merchant receives a customer s signed check after the merchant has posted the appropriate notices in a conspicuous location at the point of sale and on the customer s receipt or other takeaway, they have the customer s authorization to process a BOC entry Authorize.Net Page 10 of 11

11 Example of Auxiliary On-US Field The following is a comparison of a regular check with a check that contains an Auxiliary On-Us Field: 2014 Authorize.Net Page 11 of 11