Difference between revisions of "Configuring Authorize.NET"

From Opentaps Wiki
Jump to navigationJump to search
(Test Mode using Test Account)
Line 1: Line 1:
== Testing Setup ==
+
== Testing Your Setup ==
  
Authorize.NET has two very different settings with regards to testing,
+
Authorize.NET 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.
  
=== Test Mode using Live Credentials ===
+
The testing server requires a testing account, which is distinct from a real account.  A testing account can be obtained from,
 
 
This mode is where you use your actual credentials on the live Authorize.NET server.  It is activated by passing a special flag. 
 
 
 
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.
 
 
 
=== Test Mode using Test Account ===
 
 
 
This mode is where you use a separate Authorize.NET testing account on a special test Authorize.NET server.
 
 
 
Unlike the previous mode, this one 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.  It can be used only with a separate testing account distinct from the one used for production.  A testing account can be obtained from the following URL,
 
  
 
http://developer.authorize.net/testaccount/
 
http://developer.authorize.net/testaccount/
  
To properly configure this mode, you need to log into your Authorize.NET test account with the login name and password provided by Authorize.NET and turn test mode off.   
+
Next, you will need to configure payment.properties for testingThe following setup is recommended,
  
It might seem odd that the test server has a test mode. That is because the test server behaves exactly like the live server except that it does not actually send any information to financial institutions. Transaction IDs are generated only when test mode is off in either server.
+
<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>
  
Finally, you will need to change the gateway URL in payment.properties to the following,
+
The test parameter should always be set to FALSE except for testing special things that will be described below.
  
payment.authorizedotnet.url=https://test.authorize.net/gateway/transact.dll
+
=== Testing Specific Gateway Failures ===
  
Note that the value of payment.authorizedotnet.test does not affect the generation of transaction IDs.  We recommend setting it to TRUE so you can see the information sent and received to Authorize.NET.
+
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 of the validation code, you'll have to create this CreditCard record by hand and a PaymentMethod for it.

Revision as of 00:30, 13 December 2007

Testing Your Setup

Authorize.NET 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 always be set to FALSE except for testing special things that will be described below.

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 of the validation code, you'll have to create this CreditCard record by hand and a PaymentMethod for it.