Question:

 

I purchased the source code to your Smith Registration module and have modified it for my needs. 

 

I have a question regarding the silent postback mechanism for Authorize.Net.

 

Your documentation says that if a scheduled transaction fails, the postback mechanism will result in the role that was assigned on sign up being removed from the user. I can clearly see in the code where you have coded for that. 

 

BUT… Looking at the Authorize.Net documentation, it seems pretty clear that no postback will be generated in the event of a failed transaction. 

 

“ARB subscriptions only generate Silent Post responses if and when a transaction

processes. If a transaction does not process, for example, if the credit card has expired, a

Silent Post does not occur (see "General Errors for Individual Payments in a Subscription

," page 28 for more information). It is recommended that you configure the ARB specific

email notifications within your account as well as using Silent Post for the purposes of

identifying ARB subscription activity.”

 

I have been monitoring the SilentPost.log file and the AuthorizeNetLog table in the database, and have seen no failure posts from transaction that have failed to bill and thus should have posted failure entries to both.

 

From this, I have concluded that the auth.net silent postback does not happen on declines or failures. One needs to either manually or automatically monitor for expected transactions and handle them if they do NOT in fact occur. Please correct me if I am wrong. 

 

 

Answer:

 

I just finished reading the Auth.net ARB guide and on page 22 of the ARB guide http://www.authorize.net/support/ARB_guide.pdf

 

They state that the silent postback will return a response for a declined transaction but not for general failures.  See the following excerpt:

 

The Silent Post feature only returns responses for scheduled ARB transactions 

that are approved or declined. The payment gateway will not return a response 

to the specified Silent Post URL if the scheduled transaction results in a general 

error due to expired or invalid payment information. For more information see 

the “General Errors for Individual Payments in a Subscription” section of this 

guide.

 

Regarding the following point you made:

 

“Your documentation says that if a scheduled transaction fails, the postback mechanism will result in the role that was assigned on sign up being removed from the user.”

 

I looked in our Registration Pro manual in section G. Silent Post URL Feature on page 64-65 and it describes the type of messages the RegPro module receives from the auth.net silent postback as “declines” and not "failures".  Please see the following excerpt from the Smith RegPro manual:

 

If an ARB credit card transaction for one of your portal members declines for any reason 

(NSF, card expired, etc.) a silent post message will be sent from Authorize.Net to your 

portal and received by the registration module.  The transaction details regarding the 

declined transaction will be stored to the database and the user will be removed from the 

DNN role they were added to when they registered.  

 

In reading the auth.net ARB manual there is a difference in what Auth.net considers a "declined" and a "failed" transaction.  Auth.Net describes it as follows:

 

Authorize.net will submit a silent postback to the Smith Registration module on declines but not failures.

 

The following are some of the common decline types that should do a silent postback:

 

There are about 5 pages of different types of declines that you can receive.  See page 44 of the AIM guide or using this link http://www.authorize.net/support/merchant/Transaction_Response/Response_Reason_Codes_and_Response_Reason_Text.htm

 

Based on your feedback I did find one error in the RegPro manual on page 65 it states that “expired card” is included as a decline and after researching the Auth.net considers an expired card as a failure and not a decline.  It would be nice if auth.net also did a silent post on expired card failures also, but in the meantime I will remove the expired card reference from the silent postback section of the RegPro manual.

 

Thanks for your feedback!