Opentaps CreditCard Setup

Credit Card Processing with Opentaps

To set up credit card processing is very simple. First, find a processor that is already supported by looking in applications/accounting/servicedef/ for a services file. If one of these processors is supported, then just obtain the credentials for those processors and enter it into applications/accounting/config/payment.properties.

Then, for each product store in the Catalog > Stores >> Payments tab, configure the service in the services_XXX.xml file for the payment method type of Credit Card. Typically, you will need to configure the services for authorize, capture, release, and refund. Here is an example of a setup for using Authorize.NET:

Beware that each processor has its own quirks.

Authorize.net Setup

After you receive your "Welcome to Authorize.net" email and get your payment gateway ID, you will have to login to their site and activate your account. At the end of that process you will be presented with your transaction key and login. Both those fields will appear to be random letters and numbers.

Configuring opentaps for Authorize.NET

Edit your applications/accounting/config/payment.properties file and look near the bottom of the file, below the following text:

############################################
# Authorize.Net Configuration
############################################

Change the settings and put in your transaction key and transaction login that you got when you activated your account.

• payment.authorizedotnet.trankey=INSERT_YOUR_KEY_HERE
• payment.authorizedotnet.login=INSERT_YOUR_LOGIN_HERE

Note: the above login is not the same as your login to authorize.net's website

VERY IMPORTANT SECURITY NOTICE

Before going into production with real credit cards, set this flag from the default true:

  payment.authorizedotnet.test=TRUE

to false:

  payment.authorizedotnet.test=FALSE

Otherwise opentaps will log the credit card numbers in your log files.

Authorize.net Modes

What is Test Mode?

Test Mode allows you to test your connection to the payment gateway. Transactions submitted while your account is in Test Mode are NOT actually authorized or charged to any account numbers provided for the transactions.

Note: Test transactions are not stored by the payment gateway and will not be viewable in search results or reports.

For more details on the different methods for submitting test transactions, please review the Integration Guide for your connection method.

Changing Modes

After initial setup, your payment gateway account will be in Test Mode by default. This allows you to immediately test your connection to the payment gateway before you submit real transactions. However, you may turn Test Mode ON or OFF anytime you need to test changes to your payment gateway connection or to restore live transaction processing.

Turn Test Mode Off

To turn Test Mode off:

Step 1: Login to your Merchant Interface at https://secure.authorize.net

Step 2: Click Settings in the main left side menu.

Step 3: Click Test Mode.

Step 4: Click Turn Test OFF. A confirmation message indicates that the setting has been successfully applied.

Turn Test Mode On

To turn Test Mode on:

Step 1: Click Settings in the main left side menu.

Step 2: Click Test Mode.

Step 3: Click Turn Test ON. A confirmation message indicates that the setting has been successfully applied

Note: Please be sure to verify that Test Mode is OFF anytime you need to submit real transactions.

Authorize.net Test Mode Card Numbers

Any of the following card numbers can be used to run tests on your Authorize.Net account. It must be noted that these are not real card accounts, and will not generate an approval if your account is in live mode. They will return a decline in live mode, and an approval in test mode.

Sample numbers to use

Use any expiration date after today.

370000000000002 American Express Test Card
6011000000000012 Discover Test Card
5424000000000015 MasterCard Test Card
4007000000027 Visa Test Card
4012888818888 second Visa Test Card
3088000000000017 JCB 
38000000000006 Diners Club/ Carte Blanche 
4222222222222 Visa Error Test

The last testing card number is used to generate errors. THIS CARD IS INTENDED TO PRODUCE ERRORS, and should only be used if that is your intent--for example, if you are testing your site to see how it will respond to Authorize.Net errors. To cause the system to generate a specific error, send a transaction with the card number 4222222222222, and an amount equal to the number of the error you want the system to return.

For example, if a transaction is sent to the system in test mode with a credit card number of 4222222222222, and an amount of 12 dollars, the system will respond with error 12, "Authorization Code is required but is not present"

Authorize.NET Quirks

Authorize.NET will not be able to refund captures which are more than 60 days old. It will also not be able to refund captures which have not yet settled. The problem is that it does not have an API that tells you which captures have settled and which have not, so the service tries to refund, then release. This may not always work, but that does not appear to be a better solution.

Configuring eCheck.NET Processing

eCheck.NET is a service offered by Authorize.NET which allows one to accept check payments over the internet via payment gateway.

If you have already configured Authorize.NET, there is no additional configuration necessary for opentaps to use echeck.NET--the same configuration file for Authorize.NET (payment.properties) should work for eCheck.NET. You would just have to configure the eCheckNetAuthCapture as the Authorize service for EftAccount payment method type of your store and the eCheckNetRefund service as the Refund service for EftAccounts. (Note that there is no separate authorize and capture for checks: the payment is captured at the time when the order is authorized.)

Configuring Paypal

Paypal is not handled as a traditional payment gateway but as a request/response in the ecommerce store application. You can configure your paypal account settings (really just your paypal email account and the URL of your opentaps store) in payment.properties. Then, during checkout in ecommerce, if the user selects Paypal (“EXT_PAYPAL”) as the payment method, they are redirected to a Paypal screen with information about the item they have just purchased, as well as store information from payment.properties. After they have paid, Paypal sends a re-direct string which the ecommerce store handles. A Payment is created in the system, and, if a GL account is configured for the EXT_PAYPAL method as it is in the default chart of accounts, it will also be booked to the right ledger account.

This option currently does not work in the internal order entry system.

If you receive a Paypal payment from your customer outside of the ecommerce store, go to [Financials] > [Receivables] >> [Receive a Payment] and receive a payment of the type “Paypal”. You can then apply it to invoices outstanding. When you mark it as “Received”, it will be applied to the correct account.

Configuring Offline Credit Card Processing

If your store uses a separate terminal to process credit card sales, you can turn off the integrated credit card processing. Go to Catalog Manager > Stores >> Payments and remove all the credit card processing services defined for the "Credit Card" payment method. Then, add your credit card payment method type with Service Type of "External Payment (No Service)":

Writing your Own Payment Gateway Interface

To write an additional payment gateway, implement one of the credit card processor or payment processor interfaces defined in the accounting application's services definition file. The easiest way to do this is to start with one of the existing payment processor implementations and use its services XML definition file and Java source code as your starting point. You do not need to modify the services XML definition file in except to change the name of the services. In the Java source code, modify each service and replace the code, which calls the original payment gateway with your new payment gateway's interface code. Finally, you will need to have a properties file to define the connection URL and authentication setting such as username, password, etc. You can actually create your own .properties file in your own application component.

Then, load your service as a ProductStorePaymentSetting for the different payment types you wish to support, and the shopping cart/order entry system should automatically use them. Be sure to point to the .properties file that you have defined.

A few important tips:

1. Do not return error from your payment gateway service. The OFBiz shopping cart will think that an error means that the system was unavailable and will thus proceed with creating an order. If an authorization call failed, return an authResult of Boolean.FALSE so that the cart will know that the authorization actually did not succceed. In that case, the order will be created as “Rejected”, and the customer will be asked to enter a new form of payment.
2. If a capture fails, reauth and capture is automatically tried, but if it fails, the shipment will still be created. An invoice for the shipment is also created and posted to the general ledger, but no payments will be applied to the invoice.
3. Your payment gateway processor must return a captureAmount of 0.0 if the capture is unsuccessful. Make sure it does so, even if the payment gateway processor returns an amount to you.
4. You can use captureOrderPayments service to try again later manually.

Section pages >> Opentaps Address Validation Setup