Comments on: All About Authorize.Net’s Silent Post

By: Johnny

Johnny — Wed, 01 Sep 2010 18:47:13 +0000

Authorize.Net says expired cards will not be sent to Silent Post. But I see plenty of these sent to Silent Post. I am not sure whether all expired cards are sent to Silent Post, or just the ones where the wrong expiration date was provided to Authorize.Net and they found out it was expired when processing the transaction. But you will see expired transactions sent to Silent Post so it’s best to be aware of them and handle them accordingly.

By: Joe

Joe — Wed, 01 Sep 2010 06:45:25 +0000

John, excellent website, you’ve made this ARB thing almost easy! Thank you so much for putting this information together! I have a question about expired credit cards…

In your document, you said:

However, if a credit card on file within an ARB subscription has expired a transaction will not process thus you will not receive a Silent Post response, as you only receive Silent Post responses to transactions that process through your account. In order to be notified about expired credit cards, you can enable the ARB email notifications from within the account control panel.

But later on, you also said:

If there was an error the card is expired x_response_code will contain a value of 3. Expired credit cards will have this response code and x_response_reason_code will contain a value of 8.

So what really happens when a credit card with a subscription expires?

By: Arif

Arif — Wed, 16 Jun 2010 08:05:32 +0000

I am using the ARB method for authorize.net, I have used your sample code in php to get silent post responses from authorize.net. But the issue is I am not getting the subscription Id from silent post url.

Please help

Thanks in advance

By: Kristi

Kristi — Tue, 04 May 2010 20:55:49 +0000

Thank you for this!

By: Bob

Bob — Fri, 12 Feb 2010 15:54:18 +0000

You are a true hero. Thank you.

By: Johnny

Johnny — Fri, 12 Feb 2010 01:42:12 +0000

Bob,

I’m glad you found this information helpful. That’s why I post it.

1. What’s interesting about the MD5 field is a value is returned from Authnet for AIM and ARB transactions. It would be cool if they would tell us how they create it so we could use it to verify the transaction.

Your options would be to either use the customer ID or invoice number to pull the customer information out of the database and verify it against what is submitted via silent post. Or, if you’re not using the description field for anything else, put in your own MD5 hash in there and use it just like it was a SIM transaction.

2. If a card is declined ARB will not go back and charge the payment. This means you’ll have to do it yourself. But that isn’t a big deal since, assuming you have a form your customers fill out to provide their updated credit card information, you can use AIM at the time they update their credit card info to process any back payments they owe.

By: Bob

Bob — Fri, 12 Feb 2010 01:00:56 +0000

First of all, you are awesome and a total lifesaver. You have saved me hours of frustration tonight.

I have two questions and I would love to hear your thoughts if you would be so kind:

1. I have silent posts coming in from both AIM and ARB transactions. Using the MD5 to verify that the ARB transactions are legitimate is easy. But, for AIM transactions I can’t find any info on using MD5 at all. In fact, Auth.net says that MD5 “is not necessary for use with AIM” (here: http://developer.authorize.net/faqs/#md5). Is there any info anywhere about using MD5 to verify that a silent post about an AIM transaction is indeed coming from Authorize.net?

2. Let’s say I have an ARB subscriber whose first payment works without issue, but then their card is declined when their second payment is attempted (and I cut off their access to my site). Two days later, they update their credit card info to a legitimate card and I update the ARB subscription and reactivate their access to my site. My question is this: does that missed payment ever actually get charged? Does ARB know to go back and try again for the missed payment after the card is updated, or did my customer just get a free month?

Thank you so much for any help you can provide. The lack of documentation on this stuff is extremely frustrating and you are a beacon of hope!

-Bob

By: Gary

Gary — Fri, 05 Feb 2010 18:54:37 +0000

Thanks for the detailed response.
we will be evaluating our requirements and the options we have before deciding which method (AIM/SIM ) to use.

By: Johnny

Johnny — Wed, 03 Feb 2010 16:58:35 +0000

If it is a subscription you should already know the card type since you had to have the credit card number to set up the subscription (at least you do through their ARB API). Naturally each payment will use the same card so all you have to do is retrieve the card type from your database when a silent post is made using their subscription ID (which is provided when their subscription is created and through silent post). AIM transactions require your system handling the credit card information at the time of payment so that also allows you to capture the card type for later retrieval as well.

Basically what it boils down to is if you didn’t or are unable to capture the card type at the time the payment is made or subscription is created there is no way to retrieve it through silent post later.

By: Gary

Gary — Wed, 03 Feb 2010 16:49:26 +0000

We are implementing direct Customer Payments and automated recurring billing payments.
For the customer paying directly AIM may be an option, but for the subscription type payment services, we DO NEED to rely on the Silent Post and hence the need for the card type.

Is there any work around that can be used to get the card type through silent post?
or can we use AIM and SIM interchangeably depending on the transaction (direct/subscription based) ?