Webhook gets disabled frequently

[Shubhada]

Hi all,

I have configured Webhook in Sandox account. After few transactions it gets disabled automatically in sandbox.I can't find the root cause behind it. We have have handled exception but not did not log any error realaed to webhook failure. Is there any extra setting required for webhook in Sandbox account except adding endpoints? or is it happening because we are using Sandbox Account.

Do we need to activate webhook programatically before transaction?

Below is code we have used in notification URL for  handling Webhook response.

StreamReader reader = new StreamReader(HttpContext.Current.Request.InputStream);
string requestFromPost = reader.ReadToEnd();

if (obj != null && obj.payload != null && obj.payload.id != null)
{
string transId = Convert.ToString(obj.payload.id);
if (transId != null && transId != string.Empty)
{

//Code for processing request

}

}

[Renaissance]

@Shubhada

Using a sandbox is exactly the same as using a production account. You can replicate a production environment 100%. There is one difference on the side of authorize.net. When you run sandbox transactions no transaction data or other evidence of the order is reflected on auth.net end. So you cannot call the people on the phone to see why xyz transaction didn’t update when you ran an API call.

You in practice should never have a need to do that. You can set up webhooks programmatically but it is not a requirement. I find it easier to set them up in the interface. In any event, if you set them up you only have to set them up once. Once you have activated webhooks they will come to your endpoint for every transaction.

When you say “disabled”, what do you mean? Do you mean that you go to the interface and they are on inactive? If you set them on active and then after receiving a webhook it goes to inactive you have an issue I have never seen.

If what you mean is that you receive a webhook for one transaction and then a subsequent transaction doesn’t receive one, the top suspects are dns issues and something causing a fatal error on your endpoint.

Verify the following to make sure they are not the issue:
-you have generated a signature key in your interface. I assume this is a yes.

-your endpoint url is not parameterized

-your endpoint url is affixed to a domain name and not an IP address

-your endpoint is on a remote server or on some set up other than the local environment on your machine. There are services that will allow you to use your local environment. I have never used them.

-your endpoint is set to active for all transactions. The inactive status is only for dry run tests. Any real or simulated transactions from your production or development environment will not receive anything when the endpoint is set to inactive

- you are enrolled in the events you need to receive. For testing you can just enroll in everything to eliminate this as a possibility. Then once you have it consistently working you can fine tune your enrolled events

Once you have done this, when you run test transactions check your server logs to see if auth.nets IP address is hitting it. You can also temporarily break my guidance to set on active and set on inactive. Once on inactive hit the test endpoint button in your interface. You will get instant results that let you know if you are getting a successful connection. Then turn it to active and run test transactions.

[Shubhada]

Hi,

We have configured Webhook from Sandbox interface ->Business Settings-> Webhook and not programatically.it get disabled automatically.We have verified all points given by you as below.

• you have generated a signature key in your interface- yes.
• your endpoint url is not parameterized -yes,it is not parameterized.
• your endpoint url is affixed to a domain name and not an IP address - yes, it is a domain name.
• your endpoint is on a remote server or on some set up other than the local environment on your machine - yes,it is on remote server.
• your endpoint is set to active for all transactions.-Yes it is active for all transactions.The inactive status is only for dry run tests - please elaborate this.
• you are enrolled in the events you need to receive. For testing you can just enroll in everything to eliminate this as a possibility.- yes we have enrolled all events.

Please revert back asap, as it is hampering production environment.

Thanks,

Shubhada

[Renaissance]

@Shubhada

Dry run means you are testing the webhook with no actual transaction. This is either through a post request or through the test button on your interface.

What specifically are you experiencing? The webhooks are delivered on one transaction and then on some subsequent transaction they are not? How do you know which webhooks you receive and which you do not ? Do you look at server logs? Do you go by the results of the order updates that are supposed to happen, meaning if the update doesn’t happen you assume no webhook was delivered? Also, how long has the domain name your endpoint is hosted on been pointed to the IP address it is currently on?

Please note that I do not work for auth.net. I just help on the forum when I have time to kill.

[Shubhada]

Hi,

For few transaction it works and automatically get deactivated in sandbox.We are placing order in handler code,Order not get placed and its status automatically set to Inactive.

Now we are programatically handling it for activating webhook if it is aready Inactive.

We will let you know our result.

Thanks

[Renaissance]

@Shubhada

That is a very, very strange issue. You shouldn’t have to manually call a webhook on each transaction.

[mikemurphy]

It gets turned off if it can't connect to your server after 10 tries.  They have been working on an email alert for 2 years.  https://community.developer.authorize.net/t5/Integration-and-Testing/Webhook-automatically-disabled/...

[Renaissance]

@mikemurphy

What is the use case for this email? Do you have recurring issues where connection to your webserver fails after 10 tries? Are you the web developer or the merchant? If auth.net is missing you 10 times, you need to look at your server and server side code. Servers from any decent hosting company will have uptimes greater than 99%. There is unfortunately only so much auth.net can do to help merchants with issues arising from incorrectly written source code.

To give a comparison, I have several integrations that use webhooks, and the test transactions ran for them total in the 1,000s. I have had about 3 occasions where we even get to notification 5. With the exception of a period of about 6 hours on one testing day, every single webhook we have not received was due to issues on our end.