Hello,
We are trying to get up to speed using Authorize.net Webhooks to connect to our Salesforce external site. Our Salesforce endpoint seems to be working OK, because I can call it using curl from the command line and pass a JSON structure that gets successfully saved to our database. This much works fine.
However when I enter the URL of our Webhook into the "Endpoint URL:" field in Authorize.net and click the "Test Webhook" button, I get the error message:
"Error: Error occured in connecting to the endpoint: https://<my.server.com>/site/services/apexrest/PYMT_AuthnetHook"
I am sure that I am calling the correct URL because I have copied and pasted it from the command line into the Endpoint URL field. But I need to know why I'm getting this error. Is there a debug log for Webhooks? Or how can I get a more detailed error message from Authorize.net?
Thanks and Best Regards!
Solved! Go to Solution.
04-25-2017 06:15 PM
Hi @BSYFDev1,
Thanks for your help and patience in all of this. This did get pushed up to a higher priority, and we've now made some changes in production regarding Webhooks notifications that we believe will fix this issue.
I can now do a test to that URL successfully. Can you tell me if things are now working right from your perspective?
07-25-2017 05:14 PM
Hello @BSYFDev1
It sounds like we're unable to make a connection. Have you tried sniffing the connection using wireshark or similar to see the https traffic?
Richard
04-25-2017 06:49 PM
Hi @RichardH,
Thanks for your reply. I'm just seeing it now. The thing is, I can't get between Authorize.net and Salesforce to do any sniffing. Salesforce is a SaaS platform, so their servers are hosted on their farm, and Authorize.net's are hosted where they are, so if there is a way of getting in between I don't know what it is.
The only thing I can do so far is simulate an incoming Auth.net webhook call from the command line. I have used the requestb.in site to retrieve the Auth.net payload and can send the exact same using cURL, but that goes through just fine and comes back from Salesforce with an HTTP 200 response code. It's only when I try the Test Webhook button in Auth.net's interface that I get the error, and I can't see what the response code is there. I have asked for logs from Auth.net but couldn't make headway.
Thanks and Best Regards,
Josh
06-29-2017 09:15 AM - edited 06-29-2017 09:16 AM
Hi @BSYFDev1,
Any chance that there's some access restriction only allowing connection from your network and not ours? What happens if you try to post to your listener URL from a different network?
You can use a service like https://www.hurl.it/ to simulate the connection from our side. If that works but the connection from our side doesn't, we need to troubleshoot things at that connection level. If coming from hurl.it doesn't work, then the problem's on the side of your (Salesforce's) server.
07-11-2017 01:29 PM
Hi Aaron,
Thanks, we'll try hurl.it. We have tried this using cURL from the command line and it goes through fine. We got the JSON payload below from the Webhook instructions regarding requestb.in. There are no IP access restrictions in place on our side.
curl -i -X POST -H "Content-Type: application/json" -d '{"notificationId":"fe40a66c-1d1c-44d5-bd56-ae8d4ec06383","eventType":"net.authorize.payment.authcapture.created","eventDate":"2017-04-26T21:25:51.7675262Z","webhookId":"7b287bed-d7c1-47b7-ae09-c9252909754c","payload":{"responseCode":21,"authCode":"572","avsResponse":"M","authAmount":12.5,"entityName":"transaction","id":"245"}}' https://jphsb-mjy.cs21.force.com/jyotish/services/apexrest/PYMT_AuthnetHook
If I plug the same URL into the Webhook interface on the Auth.net server, I get an error when testing it. But the error message doesn't say what specifically is wrong.
Best Regards,
Josh
07-11-2017 04:12 PM - edited 07-11-2017 04:14 PM
Hi Aaron,
I used Hurl.it to post a request as follows:
POST: https://jphsb-mjy.cs21.force.com/jyotish/services/apexrest/PYMT_AuthnetHook
Headers: Content-Type -> application/json
I didn't post the JSON payload, but this endpoint doesn't parse anything anyway, it just responds.
I received a 200 OK response:
POST https://jphsb-mjy.cs21.force.com/jyotish/services/apexrest/PYMT_AuthnetHook
200 OK 2 bytes 107 ms
Here are the headers from the response, in case they are useful:
Cache-Control: s-maxage=0
Content-Encoding: gzip
Content-Security-Policy: referrer origin-when-cross-origin
Content-Type: application/json;charset=UTF-8
Date: Wed, 12 Jul 2017 01:08:53 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: BrowserId=_prkM-YXQ5-fefeTzsK9bw;Path=/;Domain=.force.com;Expires=Sun, 10-Sep-2017 01:08:53 GMT
Transfer-Encoding: chunked
Vary: Accept-Encoding
X-Xss-Protection: 1; mode=block
With Best Regards,
Josh
07-11-2017 06:16 PM
Shoot, that's no good. Someone will need to analyze logs on our side to determine what our notifier service is encountering when it's trying to connect to that server, whether it's a failure to find the server, a failure to negotiate a secure connection, or something else.
At this point, to get it escalated to the right people the best bet would be to open a ticket with our support department. Do you already have a production Authorize.Net account? If so, please call our support team and open a ticket and they can escalate it from there.
07-12-2017 08:47 AM
Sorry, one more piece of info I noticed from my side. If you test the Webhooks through the Webhooks API...
POST https://apitest.authorize.net/rest/v1/webhooks/{{webhookId}}/pings
...you get a 500 response from the API, with the following payload:
{ "status": 500, "reason": "PING_FAILED", "message": "The ping operation failed with the status code 400", "correlationId": "2dd4462d-8595-49da-89c4-befb3f42b281", "details": [ { "message": "Error occured in connecting to the endpoint:https://jphsb-mjy.cs21.force.com/jyotish/services/apexrest/PYMT_AuthnetHook " } ] }
Unless we're really bad at reporting errors, this appears to say we got a 400 from the force.com server when we tried to post the notification. So, it doesn't appear to be connection negotiation that's the problem, but rather something that URL doesn't like about our request.
07-12-2017 09:00 AM
Hi @Aaron,
Yes, we had a case open, and got the reply that the situation was under investigation but that was over 6 weeks ago. The eTicket number for that case was: 1-411891741 and it was escalated. The last comment says that it the issue was now being investigated under Case Number 04120232, but I'm not able to access that case from within the Auth.net interface.
Thanks for providing the information about the ping request. This appears to be the same message that is received when the Test Button is clicked in the Auth.net interface ("Error occured in connecting to the endpoint: ...").
So the 400 Status Code is defined this way (https://tools.ietf.org/html/rfc7231#section-6.5.1):
400 Bad Request - The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
I'm wondering actually if the routing is somehow an issue...?
This response is something that is generated by Salesforce itself and is not a result of our custom code to parse the payload. The test URL that I provided doesn't do anything to process the request, although we have tested it with the simulated Auth.net payload using cURL and were able to successful parse that request. But the code has now been reverted to do no parsing.
So, we're really stuck. We are using the Silent Post URL for now, but when that gets deprecated, we'll be out of luck, and will have to evaluate our options at that point. Salesforce is a big company, and I'm sure we are not their only customers who use Auth.net. Is there anything I can do to somehow get this pushed up to a high priority?
With Best Regards,
Josh
07-17-2017 08:01 AM
Hi @BSYFDev1,
Thanks for your help and patience in all of this. This did get pushed up to a higher priority, and we've now made some changes in production regarding Webhooks notifications that we believe will fix this issue.
I can now do a test to that URL successfully. Can you tell me if things are now working right from your perspective?
07-25-2017 05:14 PM