Webhook tests send wrong event

[inLeague]

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.

net.authorize.customer.subscription.suspended) 

, 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?

[Renaissance]

@inLeague

The test button as well as the POST request tests while on inactive mode serve one purpose- for you to know that the connection to your endpoint is working. Once you get a successful ping consistently, the next step is to place it on active and run test transactions. The test transactions you run will generate webhooks based on the type of transaction. It will work the way you want your tests to work

[inLeague]

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:

https://www.ssllabs.com/ssltest/analyze.html?d=orbit.inleague.io&hideResults=on

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?

[Renaissance · Accepted solution]

@inLeague

This sounds like a possible DNS resolution error. Auth.net can have slow DNS resolution at times. I would type the url in your browser to make sure you are getting a 200 response. The ping failed message is also triggered by 500 responses. The ping does send an http request and you can dump the request in a log when pings are successful. The pings can also be used to test your sha512 validation.

[inLeague]

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 developer@authorize.net 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. 

[Renaissance]

@inLeague

What you are describing sounds like DNS resolution issues. The on and off working and not working is exactly what happens. If you give it another 2 or 3 days you will probably get better results. Another option is to move your site to a long established domain name. Idk why auth.net tends to be slower at resolving.

If you want to move away from auth.net that is your choice, but I can tell you that what you have now is just a very temporary hurdle. Once you have the webhooks set up they work very well. I’ve ran over 1,000 test transactions with no confirmed failure from auth.net and very few failures (much less than 1%) period.

[Renaissance]

Just ran a few quick tests on some sites and it looks like you are not resolving consistently.

https://www.whatsmydns.net/#A/Orbit.inleague.io

[inLeague]

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.

[Renaissance]

@inLeague

Sure, I understand. And I wasn’t making any statement that there was something wrong with your domain or DNS record. I was pointing out that auth.net is slow to resolve sometimes and that if you moved to a well established domain you wouldn’t have this problem. I thought it was a good indicator that you had some endpoints online that were not resolving, including a few in the U.S. The idea was that since auth.net can be slow to resolve you are probably spinning your wheels until you can validate zero resolution issues with online tools.

I wish you the best of luck wherever you move to. I understand the grievance with the documentation. They do leave a good bit of the work up to you. Little to no production ready code anywhere on the website. What they do have has thus far been plenty enough for me and I will be sticking around for a long time.

[fawzytat]

Having the same issue!! any updates?