I am testing some webhooks code and am having issues around Test A Webhook and Notification History. This is using a developer account.
Solved! Go to Solution.
03-14-2017 03:52 PM
Hi John,
For development and testing, we recommend using an external URL as the target (like requestb.in) when there's any question at all of whether your own server is reacting to or accepting the notification.
Have you tested the Webhook (with either a real event or the 'pings' command) using a target URL that's external to your environment?
Assuming that works to another URL, you'd look to see what's happening on your server when the notification comes in. If the notification shows up in your history on our side as successful, that means we must have got the 200 status response back from you. If we didn't get that 200 status response, we would have queued up the notification for retries instead.
Try doing your own post to your URL using something like Postman or similar. Post with the application/json content-type and then see what your server does. Does it register it when you post, but not when it's coming from us? Do you have any logging that would show TCP connections at the server level so you can even see when the incoming connection happens?
Here's roughly what the HTTP session for a notification post from our server to your Webhooks URL would look like if you want to use this as a basis for testing in Postman or similar.
POST /authorizenet/webhooks/listener.php HTTP/1.1 Host: example.com Accept-Encoding: gzip Content-Length: 209 X-Anet-Signature: sha512=38546842C5CE9A54DAB16B66FE7F501E45A0CB9144E5BB568017643901BD71205B44484B4C26E739FD5A87C28E5E5A483D0929FD461A3AAC4F84879AB388CE4E Content-Type: application/json Cache-Control: no-cache {"notificationId":"1947e7d0-4fb6-403d-913c-5ee33c4ab10f","eventDate":"2017-03-14T15:41:01.9004341Z","webhookId":"ce6d9f1f-16ea-43b0-b212-52238af7986a","payload":["net.authorize.customer.subscription.created"]}
03-17-2017 08:48 AM
1) For ping , a sample notification payload should get posted on the webhook endpoint .
2) Test of webhook do not generate a notification history .
Try and switch the webhook to active and do a create transaction .
This will generate a notification and it can be retrieved later from notificationHistory API .
03-14-2017 09:19 PM
Setting up a webhook and making a payment did populate my notification history as expected. However, I did not receive a notification at my specified webhook URL.
Is it possible to receive a notification at my specified URL in a development environment? If so, what am I missing?
03-16-2017 04:46 PM
Hi John,
For development and testing, we recommend using an external URL as the target (like requestb.in) when there's any question at all of whether your own server is reacting to or accepting the notification.
Have you tested the Webhook (with either a real event or the 'pings' command) using a target URL that's external to your environment?
Assuming that works to another URL, you'd look to see what's happening on your server when the notification comes in. If the notification shows up in your history on our side as successful, that means we must have got the 200 status response back from you. If we didn't get that 200 status response, we would have queued up the notification for retries instead.
Try doing your own post to your URL using something like Postman or similar. Post with the application/json content-type and then see what your server does. Does it register it when you post, but not when it's coming from us? Do you have any logging that would show TCP connections at the server level so you can even see when the incoming connection happens?
Here's roughly what the HTTP session for a notification post from our server to your Webhooks URL would look like if you want to use this as a basis for testing in Postman or similar.
POST /authorizenet/webhooks/listener.php HTTP/1.1 Host: example.com Accept-Encoding: gzip Content-Length: 209 X-Anet-Signature: sha512=38546842C5CE9A54DAB16B66FE7F501E45A0CB9144E5BB568017643901BD71205B44484B4C26E739FD5A87C28E5E5A483D0929FD461A3AAC4F84879AB388CE4E Content-Type: application/json Cache-Control: no-cache {"notificationId":"1947e7d0-4fb6-403d-913c-5ee33c4ab10f","eventDate":"2017-03-14T15:41:01.9004341Z","webhookId":"ce6d9f1f-16ea-43b0-b212-52238af7986a","payload":["net.authorize.customer.subscription.created"]}
03-17-2017 08:48 AM
For development and testing, we recommend using an external URL as the target (like requestb.in) when there's any question at all of whether your own server is reacting to or accepting the notification.
The requestb.in tool worked well for my purposes. I'm only looking to test my code to verify it works as well as gather data so I can blog about Webhooks in general. Fortunately I have no plans to ever accept payment through my website. :)
Have you tested the Webhook (with either a real event or the 'pings' command) using a target URL that's external to your environment?
I haven't. What's interesting is the ping did reach my endpoint even if it didn't send any data.
It looks like Silent Post and the Reporting API both offer more information than a webhook notification. Are there plans to change this? Or if someone wanted more information about a transaction would they use the webhook as a cue to hit the Reporting API to get the desired data?
03-17-2017 03:18 PM
@stymiee wrote:It looks like Silent Post and the Reporting API both offer more information than a webhook notification. Are there plans to change this? Or if someone wanted more information about a transaction would they use the webhook as a cue to hit the Reporting API to get the desired data?
As designed and implemented currently, a Webhook notification is just a notification that a particular event has occurred. It's not attempting to transfer all relevant information about that event. In some cases, you may already know all you need to know about an event, and are just waiting for the confirmation on our side that it happened. In other cases, receiving that Webhook notification is the signal that you should retrieve more information from our site.
We're definitely looking at ways to expand the functionality to perhaps include more relevant information in the notification itself.
03-20-2017 08:43 AM
Cool. Just wanted to make sure I understood its intended uses so if I write about this, and I think I will, I explain it properly.
Thanks for all of your help.
03-21-2017 05:36 PM