Allow correlation/reference tokens and transaction status in webhooks

Status: Accepted
by passenger19 on ‎08-03-2017 09:59 AM

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.

Status: Accepted
Comments
by Administrator Administrator
on ‎02-05-2018 01:17 AM
Status changed to: Under Review
 
by Administrator Administrator
on ‎04-10-2018 12:03 AM
Status changed to: Accepted
 
by schammy
on ‎08-06-2018 12:06 AM

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.