cancel
Showing results for 
Search instead for 
Did you mean: 
passenger19
Member
Status: Accepted

When a webhook notification is recieved there is no way to trace it back to a customer/event/action.

 

In the case of hosted forms (i.e. Accept Hosted), none of the values (e.g. invoice number) submitted in the request for a form validation token appear in the webhook notification, so there is no way to immediately know what the webhook notification is in regards to.

 

This forces us to always query authorize.net for the transaction details to see what the transaction applies to (e.g. invoice number) and confirm the transaction is completed.

 

I imagine that a webhook notification alone is not especially useful unless it provides access to a correlation token and status. Because these values are small in size and almost definitely required by any merchant software, I feel the very small increase in payload could greatly reduce the need for subsequent queries - saving merchants as well as Authorize.net a lot of extra processing and network traffic.

3 Comments
Status changed to: Under Review
Anurag
Moderator Moderator
Moderator
 
Status changed to: Accepted
Anurag
Moderator Moderator
Moderator
 
schammy
Member

The identifying information that's included in Silent Posts should always be in webhook transactions (x_cust_id, x_subscription_id, etc). At the very least.

This is making my migration to Webhooks difficult. Your support staff has obviously been instructed to push everyone to webhooks if they're using Silent Post right now but the glaring omissions of functionality in webhooks is just absurd.

The only solution is to query the Authnet API for information on the transaction ("getTransactionDetailsRequest"). The response that comes back from that query is very detailed. That detailed response should just be webhook. Why the heck not? Come on now.