Difference between revisions of "Configuring Authorize.NET"

From Opentaps Wiki
Jump to navigationJump to search
m (Protected "Configuring Authorize.NET": Sysop page [edit=sysop:move=sysop])
(→‎Testing Your Setup)
 
(14 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
== Testing Setup ==
+
== Testing Your Setup ==
  
−
Authorize.NET has two very different settings with regards to testing,
+
[http://reseller.authorize.net/application/?id=5553974 Authorize.NET] is a payment gateway for processing credit card and e-check payments. It has a live server and a testing server.  Both servers behave in exactly the same way with the exception that the testing server does not  perform any real financial transactions.  Hence, the testing server should be used to do development work and to trial run Opentaps features such as order fulfillment to see how they behave.
  
−
1.  Test using your actual credentials on the live Authorize.NET server.
+
The testing server requires a testing account, which is distinct from a real account.  A testing account can be obtained from,
−
2.  Test using credentials of a separate Authorize.NET testing account on the certification Authorize.NET server.
 
  
−
The first method can be used with your real credentials on the live site by passing a special flag. However, no actual transactions will be created by Authorize.NET in this mode.  That means it is unsuitable for testing authorizations, captures, refunds and voids. It should be treated only as a way to ensure that a connection with the live server is established.
+
http://developer.authorize.net/testaccount/
 +
 
 +
Next, you will need to configure payment.properties for testing.  The following setup is recommended,
 +
 
 +
<pre>
 +
payment.authorizedotnet.url=https://test.authorize.net/gateway/transact.dll
 +
payment.authorizedotnet.trankey=  Transaction key of the testing account
 +
payment.authorizedotnet.test=FALSE
 +
payment.authorizedotnet.logging=TRUE
 +
payment.authorizedotnet.login=    API Login key of the testing account
 +
</pre>
  
−
The second method creates test transactions that can be authorized, captured, voided and refunded.  This mode should be used for development purposes and for trial runs of the production system.  This mode must be used with a separate testing account distinct from the one you will be using for production.  You can obtain such an account at the following URL,
+
The test parameter should be set to FALSE except for testing special things that will be described below.  Setting it to true will turn on Test Mode, which is a special state that prevents transaction IDs from being generated and affects both the live and testing server.  This is generally not useful, except in specific cases as we'll come to in the next section.  If unsure, always set test to FALSE.
  
−
http://developer.authorize.net/testaccount/
+
Then you will need to add the certificate from https://secure.authorize.net/ if you use production setup or https://test.authorize.net for testing setup.
 +
 
 +
Go to that page with a navigator, then export the SSL certificate of the page.
 +
Then on the server add it to your JDK default keystore:
 +
 
 +
  cd $JAVA_HOME/jre/lib/security
 +
  keytool -import -trustcacerts -file secure.authorize.net.cert -alias AUTHORIZE_NET -keystore cacerts
 +
 
 +
=== Testing Specific Gateway Failures ===
 +
 
 +
Suppose you wish to see what happens when there is an AVS address verification failure (code 27) that results in an authorization being declined.  We can trigger the test server to return this by using a special VISA credit card number '''4222222222222''' and an authorization amount equal to the error code ($27.00).  Because the CC validation code will not let you create this number, you'll have to create a CreditCard record by hand and a PaymentMethod for it.
 +
 
 +
Make the following change to '''payment.properties''',
 +
 
 +
<pre>
 +
    payment.authorizedotnet.test=TRUE
 +
</pre>
 +
 
 +
Restart opentaps and create an order with an offline payment.  Cancel the payment and add a new payment for the amount you want to test, in this example $27.  Opentaps will automatically authorize the payment, which should trigger the desired transaction error code 27,
 +
 
 +
<pre>
 +
    (TESTMODE) The transaction resulted in an AVS mismatch. The address provided does not match billing address of cardholder.
 +
</pre>
 +
 
 +
When you're done, be sure to set '''payment.authorizedotnet.test''' back to '''FALSE'''.

Latest revision as of 18:21, 26 August 2010

Testing Your Setup

Authorize.NET is a payment gateway for processing credit card and e-check payments. It has a live server and a testing server. Both servers behave in exactly the same way with the exception that the testing server does not perform any real financial transactions. Hence, the testing server should be used to do development work and to trial run Opentaps features such as order fulfillment to see how they behave.

The testing server requires a testing account, which is distinct from a real account. A testing account can be obtained from,

http://developer.authorize.net/testaccount/

Next, you will need to configure payment.properties for testing. The following setup is recommended, 

payment.authorizedotnet.url=https://test.authorize.net/gateway/transact.dll
payment.authorizedotnet.trankey=   Transaction key of the testing account
payment.authorizedotnet.test=FALSE
payment.authorizedotnet.logging=TRUE
payment.authorizedotnet.login=     API Login key of the testing account

The test parameter should be set to FALSE except for testing special things that will be described below. Setting it to true will turn on Test Mode, which is a special state that prevents transaction IDs from being generated and affects both the live and testing server. This is generally not useful, except in specific cases as we'll come to in the next section. If unsure, always set test to FALSE.

Then you will need to add the certificate from https://secure.authorize.net/ if you use production setup or https://test.authorize.net for testing setup.

Go to that page with a navigator, then export the SSL certificate of the page. Then on the server add it to your JDK default keystore: 

  cd $JAVA_HOME/jre/lib/security
  keytool -import -trustcacerts -file secure.authorize.net.cert -alias AUTHORIZE_NET -keystore cacerts

Testing Specific Gateway Failures

Suppose you wish to see what happens when there is an AVS address verification failure (code 27) that results in an authorization being declined. We can trigger the test server to return this by using a special VISA credit card number 4222222222222 and an authorization amount equal to the error code ($27.00). Because the CC validation code will not let you create this number, you'll have to create a CreditCard record by hand and a PaymentMethod for it.

Make the following change to payment.properties, 

    payment.authorizedotnet.test=TRUE

Restart opentaps and create an order with an offline payment. Cancel the payment and add a new payment for the amount you want to test, in this example $27. Opentaps will automatically authorize the payment, which should trigger the desired transaction error code 27, 

    (TESTMODE) The transaction resulted in an AVS mismatch. The address provided does not match billing address of cardholder.

When you're done, be sure to set payment.authorizedotnet.test back to FALSE.

Retrieved from "https://docs.opentaps.org/docs/index.php?title=Configuring_Authorize.NET&oldid=6651"