We've created webhooks for each of several types of events we want to track.
When we go to test them, no matter which webhook we test (e.g.
, the event that is sent is "net.authorize.payment.authcapture.created".
What is the point of a webhook test if it doesn't actually simulate the webhook?
Solved! Go to Solution.
Alright, so it's not an actual webhook test, it's just a connectivity test.
We set up a public-facing test endpoint, but are receiving this message:
The ping operation failed. This could be due to connectivity issues, invalid url or server downtime. Check the url details for the webhook and try again.
We've verified that the endpoitn we supplied is working and even put it through SSL labs:
We're not using a nonstandard port, we've got TLS 1.2, and I can submit test transactions via Postman from outside my local network.
Is there some reason the webhook ping can't dump the actual HTTP request it's making so that it might supply useful information rather than just 'the ping request failed' -- leaving aside that it's not really correct to call it a 'ping request' in the first place, since 'ping' has a specific meaning that isn't an HTTP request?
The URL works fine in my browser both within our company network and outside of it, and obviously SSL labs has no problem reaching the server.
The request is not even hitting our server, so it isn't getting a 500; it's not connecting at all. The strange thing is that it was connecting for a few minutes yesterday and then it stopped.
I searched this forum and saw a couple cases of people reporting this error on the sandbox testing interface, but then the webhooks would actually fire. I guess we'll find out.
I contacted authorize.net support via firstname.lastname@example.org and they said that the only thing they can do is password resets.
If we have no way to test these endpoints, we're not about to bet our company and our clients on this solution. The documentation is also quite disorganized, and there are a few 'gotchas', like 'all webhook tests fire the same event,' which doesn't add up even if everybody here is used to it.
Let's be precise, here: this is not a problem with my domain. There is no problem with the DNS record, which is more than several days old with a TTL of 3600.
OpenDNS, Cloudflare, Google DNS - every major provider has no problem with it. Why would Authorize.net not be using a first tier DNS solution?
Even so, if it were just DNS issues, OK, that kind of thing happens. I did try our production endpoints and those are working. But DNS resolution problems are rookie mistakes, not something one expects from a huge payment provider.
If it were just that, I could see our way through here, but the documentation isn't written to any kind of standards; trying to get our transformers written correctly is an exercise in 'follow the dots and guess what is ACTUALLY required versus conditional, because the description of the API endpoint won't agree with the request fields.' If only there were standards for things like API documentation...
We had to guess our way through to the request structure for a refund against a payment profile, because the documentation is both incomplete and incorrect.
I appreciate that Authorize.net has been around forever, and indeed that's part of why we elected to migrate to them from FirstData. But these sorts of issues smack of somebody going through and checking boxes rather than seriously evaluating the process against competing products in 2019. I don't need your webhook testing to work exactly the way that I would design it, but if it's going to be idioscynratic in some way, say so in the documentation and replace your 'test webhook' button with a 'test connectivity' button.
It isn't that any one of these things hasn't got an explanation - it's that running into this sort of thing when migrating a system that has to process millions of dollars a year that makes it look a bit slapdash, and that's not an attribute we want to associate with our payment gateway.