topic Re: Webhook payload (invoice number) in Integration and Testing

Webhook payload (invoice number)

mikeyudin — Wed, 22 Mar 2017 18:48:03 GMT

Hello,

While testing the webhooks for authcapture created, I noticed that the original invoice number sent does not get sent back in the webhook POST -- only the new transaction ID.

Is this by design? Is there a way to include the merchant invoice number in the payload? Without the invoice number, we have to do another API call back to authorize.net's servers to retrieve the transaction data to find our invoice number in order to validate the transaction against our database. This seems easily resolved by just including the invoice # in the payload, no?

Thanks!

Re: Webhook payload (invoice number)

mediaworksmt — Thu, 23 Mar 2017 23:29:50 GMT

I too am having this same frustrating issue. :-(

Earlier today I spoke with an Authorize.net chat support rep, who after some research on her end, informed me that including the invoiceNumber field (located at getHostedPaymentPageRequest > transactionRequest > order > invoiceNumber) with the token request would cause the net.authorize.payment.authcapture.created Webhook to return invoiceNumber as part of the payload.

It does not!

Without that, there is no easy way to associate Accept Hosted transactions with the transaction result from the Webhook. There's simply not enough information in the Payment Event payload delivered by Webhook!

The only way I can think of to possibly connect an Accept Hosted transaction to a Webhook result is to run yet another API query, getTransactionDetailsResponse , using the ID number from the Webhook payload – Although I really don't even know if that ID number is the transaction ID.

Anyone else find a way around this?

Re: Webhook payload (invoice number)

mikeyudin — Thu, 23 Mar 2017 23:38:33 GMT

According to their docs on Webhooks, the ID returned is indeed the Transaction ID, so doing another call back to authorize using that ID would be what you're looking for.

Just would be nice to avoid that extra trip for a simple verification that the transaction is legit.