Reply
Highlighted
Contributor
Posts: 22
Registered: ‎07-08-2018

webhook fields

On a post in May you said that the next release should have webhooks returning refId directly so that we don't have to go find it with another API call for the transaction details.

Any idea when this might happen?

Highlighted
All Star
Posts: 733
Registered: ‎11-05-2018

Re: webhook fields

Just curious what you’re using the refId for in your application and your process. Are you using it for db updates? What issues are you having? Do you have webhooks with failed delivery? I’ve been configuring webhooks for my application and it seems to work a little too well. I’m trying to see how often things mess up. Thus far I’ve ran well over 100 samples and I don’t think one has missed yet.

Highlighted
Member
Posts: 7
Registered: ‎09-19-2018

Re: webhook fields

I'm using the Accept Hosted Payment page, and need a way, once the payment page is closed, to have my application "watch for" the webhook and update some tables.

 

I wanted to use the refId to store something about the payment transaction that would be returned i the webhook, so I could link a particular webhook response to a given payment, but the refId isn't included in the webhook payload. There is another post on this topic (see https://community.developer.authorize.net/t5/Integration-and-Testing/RefID-not-being-returned-in-get...) that explains the situation.

 

For now, I'm using the workaround suggested in that thread - when create the auth-capture transaction, I include some identifying info in the invoiceNumber and Description for the order. Then, when I get a webhook, I make a getTransactionDetails call, where I can access that info and use it in my application.

 

Highlighted
All Star
Posts: 733
Registered: ‎11-05-2018

Re: webhook fields

Yes, that makes perfect sense. I was thinking exactly that thing. I am not sure of another process with the accept hosted form redirect to link information from ids tracked internally by your business to transaction ids. When you say "watch for", I think you mean your current process is doing manually, and you would prefer an  automated process. Is that where you're coming from?  I have solved this same problem myself. My app is for a retail business with no internal technical or web employee(s), and a manual process wouldn't be anything they would be interested in doing. 

 

For what I am doing it doesn't matter to me whether it is a ref id or an invoice number. I just need some field called anything to attach our internal order number to the request so that I can tie the transaction details to the relevant order.

 

Basically what you want to do is capture the payload and hashed header, verify before your application executes anything, and then extract the transaction number to use in your transaction details method call. The json payload can be ripped apart and values extracted in a number of ways. Then you just include in your script that if we have success in retrieving the invoice number, prepare and execute the db update.