Silent Post being removed any time soon?

[cartpauj]

I recently had a client call me stating that they had contacted Authorize.net support and were told that Silent Post was no longer supported (in favor of Accept.js and Webhooks).

However, I cannot find any documentation online or in the forums about Silent Post being deprecated or removed.

Does anyone know if Silent Post is in-fact being deprected and if so, by when?

[Renaissance]

I'm thinking they're done for. I started on my first integration in 2017. Silent post was already marked for upcoming deprecation at that time. The webhooks documentation states that webhooks replace the silent post method. Doesn't say "will replace at XZY date" or "we recommend upgrading to this" like the other docs about deprecated services.  The fact you search and can't find anything whatsoever about silent post anywhere on the website suggests strongly that they are no longer supported, period.

I'm not an employee of this company, but if I were to give you advice I would say start using webhooks ASAP and drop silent post, no matter the current status. If it's not deprecated completely, I would say that it's on the chopping block and the axe is in midswing at this point.

[Anurag]

Hi @cartpauj

Yes silent post is deprecated  and for any new integration you should be using Webhooks integration . 

For more details on Webhooks please visit 

https://developer.authorize.net/api/reference/features/webhooks.html

https://github.com/AuthorizeNet/webhooks-sample-app

Thanks

Anurag

[shepfc3]

Hi @Anurag,

I am a developer on this project. Our plan is to migrate to webhooks in the very near future, but we have a hard deadline of the end of Jan to move from supporting the MD5 hash to the SHA2 hash for silent post data. We have thousands of clients currently using our plugin and need to allow for a transition. 

Here is where I have run into issues. I have followed the guide here: https://developer.authorize.net/support/hash_upgrade/. I have generated a signature key and am using that to hash the data string "^{API Login ID}^{transId}^{amount}^". However I cannot get the x_SHA2_Hash to match from the silent post. Is that the correct data and format for the silent post hash? Or does it hash the entire body like the webooks?

We will be moving to webhooks this month, but need to support silent posts until all clients have moved over. So we will also need to verify the silent posts via the SHA2_Hash until they have updated.

[h122762561]

Hi @shepfc3 

Did you find the way to macth the generated sha2 hash with x_SHA2_Hash?

Thanks a lot.

[shepfc3]

No we had to move to using the webhooks

[Renaissance]

@h122762561

I think webhooks are the way to go. They work very well. If you’re looking for a quick fix in the meantime, myself and others have posted working solutions to the sha512 validation for SIM.

[h122762561]

Hi @shepfc3,

Got it, thanks!

Hi @Renaissance,

Thanks! I finally found the problem and matched the sha2 hash.

The reason why we still use webhooks is its payload data. It only contains transaction id, so if we change to use webhooks, we need to call get transaction details API for those required data. And for each transaction data, we have to make a call. If we have a lot of transactions, we'll make a lot of connections to API server. Not good.

And another potential issue is the response time, when we get a webhook data, we need to establish the connection to API server first, then send request data to API server, and then wait server response for the transaction details data. These processes will depend on the internet health between our server and ANet API server.

I looked up to customize the payload data in webhook response, but I cannot find any useful information. If it is possible to achieve, please let me know.

Thanks again.

[Renaissance]

@h122762561 

I understand your concerns but I can tell you that webhooks will work very well for you. I have ran countless test transactions and my clients have ran real transactions.  They don't do business fast enough to compete with some of the rapid iteration testing I do.  I have exactly what you say.  The webhook comes to our server, only containing the transaction id.  Our server runs an API call to get the details. The API responds and our server processes record updates.

The entire process rarely takes more than 3 or 4 seconds per order. On the hosted payment form we use (AH) if I don't go to the admin page as fast as I can get there after placing the order, the webhooks + record updates will often beat me to it.  There is no way to customize the data you receive, but in my experience it is not needed. And again, I have ran orders very very fast testing my site. So I might have 25 orders in 45 seconds in some cases.  

[mockdumps]

Succeed! It could be one of the most useful post we have ever come across on the subject . Excellent info! I’m also an expert in this topic so I can understand your effort very well. Thanks for the huge help.