All About Authorize.Net’s Silent Post
One very common topic at the Authorize.Net developer forums is their Silent Post feature and how it works. In fact, how it works seems to be the most common question by far. For better or worse, Authorize.Net’s documentation seems to be limited concerning silent post so I decided to make this blog post summarizing the information that has been shared in the community concerning this feature.
When a transaction is completed (via SIM, AIM, ARB, or CIM), Authorize.Net’s servers will literally POST the details of the transaction to a URL you specify. In the server-side code for the page that the URL points to, you can read all of the transaction details as if they were fields on a form. The end user never sees any of this, it is all done server-to-server, thus the “Silent” part.
Silent post will be incurred for successful SIM, AIM, ARB, and CIM transactions (this includes declines) as well as virtual terminal transactions. 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.
Silent Post responses are returned in real-time, meaning as soon as the transaction processes the Silent Post is sent to your specified URL.
To add or edit a Silent Post URL to your production environment account:
- Login to your Merchant Interface at https://account.authorize.net
- Click Settings in the main left side menu
- Click Silent Post URL
- In the URL text field, enter the URL to which the payment gateway should copy the transaction relay response. This URL must start with either “http://” or “https://”
- Click Submit. A confirmation message indicates that the URL has been added
Processing A Silent Post
To receive and process Silent Post data all you really need to know is what fields to expect. Basically it reports the same information as an AIM transaction response but also includes the subscription ID and subscription transaction number for ARB subscriptions and CIM Profile ID for CIM transactions. See the AIM integration guide for details about the response codes.
Sample Silent Post
Below is a dump of the fields and sample data that can be sent from Silent Post:
[x_response_code] => 2
[x_response_subcode] => 1
[x_response_reason_code] => 2
[x_response_reason_text] => This transaction has been declined.
[x_auth_code] =>
[x_avs_code] => P
[x_trans_id] => 2692521494
[x_invoice_num] =>
[x_description] =>
[x_amount] => 5.99
[x_method] => CC
[x_type] => auth_capture
[x_cust_id] => 17234
[x_first_name] => Johnny
[x_last_name] => Fakeuser
[x_company] =>
[x_address] =>
[x_city] =>
[x_state] =>
[x_zip] =>
[x_country] =>
[x_phone] =>
[x_fax] =>
[x_email] =>
[x_ship_to_first_name] =>
[x_ship_to_last_name] =>
[x_ship_to_company] =>
[x_ship_to_address] =>
[x_ship_to_city] =>
[x_ship_to_state] =>
[x_ship_to_zip] =>
[x_ship_to_country] =>
[x_tax] => 0.0000
[x_duty] => 0.0000
[x_freight] => 0.0000
[x_tax_exempt] => FALSE
[x_po_num] =>
[x_MD5_Hash] => 35BB06A9F9349854922A13EE67AE5115
[x_cavv_response] =>
[x_test_request] => false
[x_subscription_id] => 4991817
[x_subscription_paynum] => 2
[x_cim_profile_id] => 12354
* x_subscription_paynum starts at 1 for the first payment
Reading The Data
If a transaction is approved x_response_code will contain a value of 1.
If the card is declined x_response_code will contain a value of 2.
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.
If the transaction is held for review x_response_code will contain a value of 4.
Testing A Silent Post Script
Testing a Silent Post script is easy to do as it is no different then handling a submitted form. All you need is sample data to work with. The form below submits a sample ARB transaction to a Silent Post processing script (that you will write):
<form action="http://www.yourdomain.com/silent-post.php" method="post">
<input type="hidden" name="x_response_code" value="1"/>
<input type="hidden" name="x_response_subcode" value="1"/>
<input type="hidden" name="x_response_reason_code" value="1"/>
<input type="hidden" name="x_response_reason_text" value="This transaction has been approved."/>
<input type="hidden" name="x_auth_code" value=""/>
<input type="hidden" name="x_avs_code" value="P"/>
<input type="hidden" name="x_trans_id" value="1821199455"/>
<input type="hidden" name="x_invoice_num" value=""/>
<input type="hidden" name="x_description" value=""/>
<input type="hidden" name="x_amount" value="9.95"/>
<input type="hidden" name="x_method" value="CC"/>
<input type="hidden" name="x_type" value="auth_capture"/>
<input type="hidden" name="x_cust_id" value="1"/>
<input type="hidden" name="x_first_name" value="John"/>
<input type="hidden" name="x_last_name" value="Smith"/>
<input type="hidden" name="x_company" value=""/>
<input type="hidden" name="x_address" value=""/>
<input type="hidden" name="x_city" value=""/>
<input type="hidden" name="x_state" value=""/>
<input type="hidden" name="x_zip" value=""/>
<input type="hidden" name="x_country" value=""/>
<input type="hidden" name="x_phone" value=""/>
<input type="hidden" name="x_fax" value=""/>
<input type="hidden" name="x_email" value=""/>
<input type="hidden" name="x_ship_to_first_name" value=""/>
<input type="hidden" name="x_ship_to_last_name" value=""/>
<input type="hidden" name="x_ship_to_company" value=""/>
<input type="hidden" name="x_ship_to_address" value=""/>
<input type="hidden" name="x_ship_to_city" value=""/>
<input type="hidden" name="x_ship_to_state" value=""/>
<input type="hidden" name="x_ship_to_zip" value=""/>
<input type="hidden" name="x_ship_to_country" value=""/>
<input type="hidden" name="x_tax" value="0.0000"/>
<input type="hidden" name="x_duty" value="0.0000"/>
<input type="hidden" name="x_freight" value="0.0000"/>
<input type="hidden" name="x_tax_exempt" value="FALSE"/>
<input type="hidden" name="x_po_num" value=""/>
<input type="hidden" name="x_MD5_Hash" value="A375D35004547A91EE3B7AFA40B1E727"/>
<input type="hidden" name="x_cavv_response" value=""/>
<input type="hidden" name="x_test_request" value="false"/>
<input type="hidden" name="x_subscription_id" value="365314"/>
<input type="hidden" name="x_subscription_paynum" value="1"/>
<input type="submit"/>
</form>
If you’re looking for PHP code for processing a Silent Post check out Handling Authorize.Net ARB Subscription Failures at my Merchant Account Services blog.
Related Posts:
Tags: Authorize.Net, Silent Post
January 13th, 2010 at 11:05 am | Posted in Programming
Back to the top
January 15th, 2010 at 11:35 am
[...] more on Silent Post see All About Authorize.Net’s Silent Post and Handling Authorize.Net Silent Post with [...]
February 3rd, 2010 at 11:41 am
thanks for providing a 101 on silentPost .
We are working on a large PCI Compliance project in house. In our systems, in order to reconcile our credit card transactions, we need to get the card type returned in the Silent Post. From the AIM guide and the site documentaion, I see that Crad type is not being returned in the silentPost.
There are no automted reports that we can dopwnlod from authorize.net that would give us this information.
Can you throw some light on why the card type is not included in the Silent Post and whether or not there are plans to include it in a upcoming release.
Thanks for your help.
February 3rd, 2010 at 11:53 am
Gary, it is probably not included because it can be, and should be, recorded at the time the credit card is accepted by a website/software. It also doesn’t really have anything to do with individual transactions being processed so reporting it through silent post would be out of silent post’s scope. I haven’t heard if they plan on including it in silent post but I doubt it is in Authorize.Net’s plans.
February 3rd, 2010 at 12:29 pm
thanks for your quick repsonse.
If we are using Authorize.net’s Payment submission form then we dont have control of what card type the customer chooses while making the payment.
so the Card type that the customer chooses while making the payment might be different from what was recorded in our systems.
makes sense?
February 3rd, 2010 at 12:31 pm
Ah, if you’re using SIM you lose a lot of control over the checkout process. Maybe this is a good reason to switch to AIM?
February 3rd, 2010 at 12:49 pm
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) ?
February 3rd, 2010 at 12:58 pm
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.
February 5th, 2010 at 2:54 pm
Thanks for the detailed response.
we will be evaluating our requirements and the options we have before deciding which method (AIM/SIM ) to use.
February 11th, 2010 at 9:00 pm
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
February 11th, 2010 at 9:42 pm
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.
February 12th, 2010 at 11:54 am
You are a true hero. Thank you.