Authorize.net
BluSynergy supports are two modes of operation using Authorize.net:
Using Authorize.net's Customer Information Manager (CIM) - This option enables tokenization and replicates all customer information (i.e., billing contact information between BluBilling and Authorize.net)
Without using Customer Information Manager (CIM)
Depending on your preference/requirements, select the appropriate payment processor using the listbox.
The following parameters are required:
API Login ID - This is obtained from your Authorize.net system under [Home > Account > Settings > Security Settings > General Settings > API Login ID and Transaction Key]. (Click the link to go to authorize.net's support page)
Transaction Key - This is obtained from your Authorize.net system under [Home > Account > Settings > Security Settings > General Settings > API Login ID and Transaction Key].
Primary URL: For testing set this to 'SANDBOX' (maps to 'https://apitest.authorize.net/xml/v1/request.api'). For production use, set this to 'PRODUCTION' (maps to 'https://api.authorize.net/xml/v1/request.api'). The possible values are one of [SANDBOX, SANDBOX_TESTMODE, PRODUCTION, PRODUCTION_TESTMODE, CUSTOM]. See the authorize.net documentation for the meaning of these options.
If ACH processing is enabled, then these Custom Settings are applicable (default values show are used if not provided)
eCheckType = WEB.
eCheckRecurringBilling = true
The following eCheckType vales are supported by Authorize.net
Accounts Receivable Conversion (ARC)
This transaction type is a one-time charge 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.
Back Office Conversion (BOC)
This transaction type is a one-time charge 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.
Cash Concentration or Disbursement (CCD)
This transaction type is a one-time or recurring charge or refund against a business checking
account. CCD transactions are fund transfers to or from a corporate entity.
Internet-Initiated Entry (WEB)
This transaction type is a one-time or recurring charge against a consumer checking or savings
account and for which payment authorization was obtained from the customer via the Internet.
Prearranged Payment and Deposit Entry (PPD)
This transaction type is a one-time or recurring charge or refund against a consumer checking or
savings account. PPD transactions may only be originated when payment and deposit terms between the merchant and the customer are prearranged.
Telephone-Initiated Entry (TEL)
This transaction type is a one-time charge against a consumer checking or savings account that was
originated via the telephone. TEL transactions may only be originated when an existing relationship between the merchant and the customer exists; or if no relationship exists, the customer must initiate the telephone call to the merchant.
For WEB transactions, eCheckRecurringBilling must be set to eaither "true" or "false"
Click here for Authorize.net error codes
Notes:
Please ensure that inside your Authorize.net portal (on their website) the "test mode" setting is set appropriately.
https://support.authorize.net/authkb/index?page=content&id=A400&actp=LISTTo sign up for a production Authorize.net account, please visit the Authorize.net signup page
You can sign up for a test account at https://developer.authorize.net/testaccount/
If you have trouble with credit cards declining in the test environment (or in the production environment with "Test Mode" turned on in your authorize.net account) then please check these helpful links:
Refunds are processed first as a "CREDIT" and failing that, as a "UNLINKED CREDIT". This is done automatically by BluBilling, so you may see a single Refund transaction in BluBilling show up as two separate "CREDIT" and "UNLINKED CREDIT" transactions on the Authorize.net portal. See this note from Authorize.net:
"The ability to submit unlinked credits (refunds) is not a standard feature of a merchant’s
payment gateway account. To be enabled for expanded credit capability (ECC), the merchant
must submit an application. For more information about the ECC application, see
http://www.authorize.net/files/ecc.pdf "