Webhook Payload duplicate key

[biomedware]

After subscribing to the E-Junkie webhook, it appears a duplicate key is being submitted in the Form Data.

Duplicate Key: mailing_list_status

Is this a known issue? Or?

[E-junkie_Guru]

Yours is the first report we've had about that. I'll refer that to our Devs for correction; thanks for reporting it.

[biomedware]

While you're talking to the dev team about the webhooks, could you please request a failed webhook is resubmitted at least 2-3 times, which would be more along industry standards?

I get that a failure email is sent, but there are times when the endpoint may be down for a minute and a retry would pick it up.

I suspect the retry is not being performed b/c some webhook configurations will be responding with a body which is used during the final check-out process. In other words, the user is stuck on the check-out page until the webhook replies. But for the vast majority of the use cases, I suspect we're only consumers; never replying back with anything other than an OK response.

Thanks for listening

[E-junkie_Guru]

Thanks for the suggestion about retries; I'll refer that to Development.

BTW, Webhook transmissions never process any return output from the endpoint, aside from catching error response codes and timeouts. If we're expected to receive return output and provide that to the buyer, that would use our Send Generated Keys feature instead:

Selling Generated Codes

[biomedware]

Thanks for the reply. Please pass along to the dev team that for webhooks (non Send Generated Keys) should not be waiting on the webhook to reply.

For example, while debugging I was on a break point for several minutes and the e-junkie payment was in the wait-spin mode until I continued execution.

In other words, I'd recommend the webhook be submitted asynchronously if a response is not required to fullfil the order. This would help when an endpoint is processing the webhook, but may be frozen for a time before the response is sent back.

[E-junkie_Guru]

Dev reports they have fixed the duplicated mailing_list_status variable; thanks for reporting it.

They will also add your suggestion to their to-do list, about retrying Webhook submissions 2-3 times. Right now they don't have any ready way to implement that, as we currently don't retain any record of the submission that we could retry; it just gets generated and sent on-the-fly when we process the order.

Webhook submissions to non-keygen endpoints should not wait on any response back from the endpoint, as the submission was already POSTed to the endpoint in order for there to be any response to that in the first place.

[biomedware]

Webhook submissions to non-keygen endpoints should not wait on any response back from the endpoint, as the submission was already POSTed to the endpoint in order for there to be any response to that in the first place.

I just re-tested and the post to the webhook absolutely prevents the checkout from proceeding to the thank you page. I threw a breakpoint in my webhook handler, just prior to returning the ok response back, and the check-out hung until I continued past the break point.

I'm happy to start up a screen share and demo if needed.