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.