Currently FoxyShop just supports the legacy XML datafeed, which while that still works, we should add support for the Foxy JSON webhook to get access to the benefits that that provides (like auto-retrying, JSON payload etc)
We will need to maintain the XML datafeed still for backwards compatibility, but we could utilise the same route in FoxyShop, but based on the payload we receive, detect if it's the legacy datafeed, or the new webhook (based on the presence of the headers of the new webhooks). If we detect it's the legacy, then send on to the legacy file, but if it's the new JSON webhook, pass on to the new file.
The JSON webhook endpoint will be largely a duplication of the existing functionality that the datafeed supports, including handling inventory updates, SSO syncing, and supporting events for people to hook into. It should also be a file that people can duplicate into their theme folder to customise further.
The existing endpoint in FoxyShop has some helper logic which pulls in the values from the payload into variables in the scripts, and provides commented places for users to interact with that information. Let's duplicate that same logic for the webhook as well - grabbing the values from the respective elements in the payload.
We should ensure we handle the fact that a single transaction can trigger multiple webhooks as well, if it is an initially pending status transaction, and then becomes approved later, by checking that the status is either blank, approved, or authorized. Anything else we can ignore. (Or alternatively, just skipping if the status is either declined, pending, or rejected).
The legacy datafeed also has a subscription datafeed which sends information about failing or cancelling subscriptions - this isn't a part of the new webhooks, so we can skip most of this functionality with the new endpoint (all the reminder functionality is handled natively now). We do have the subscription/cancelled event though, which sends a payload when the subscription is actually ended - we should pick up that event (if the user subscribes to it for the webhook) and set the subscription as inactive within FoxyShop like we do with the existing datafeed handling.
We don't need to support sending the payload on to external datafeeds like the legacy approach does - as multiple endpoints can be defined in Foxy for the JSON webhooks.
Tasks:
Detect the new webhooks in the existing datafeed route in FoxyShop
Add a new optional setting for users to be able to specify the JSON webhook encryption key, below the existing datafeed route in the settings. Add a note for "If using the JSON webhook, optionally set the webhook encryption key here to validate the webhooks being received".
Create a new webhooks endpoint themefile mirroring the existing functionality
Support both encrypted and raw payloads (depending if it's HTTPS or not) as documented on the Foxy wiki
Support only the transaction/created and subscription/cancelled events (detected via the Foxy-Webhook-Event header)
Validate the payload using the Foxy-Webhook-Signature header, if the webhook encryption key is set.
Ensure we only handle completed transactions, not pending or declined
Currently FoxyShop just supports the legacy XML datafeed, which while that still works, we should add support for the Foxy JSON webhook to get access to the benefits that that provides (like auto-retrying, JSON payload etc)
We will need to maintain the XML datafeed still for backwards compatibility, but we could utilise the same route in FoxyShop, but based on the payload we receive, detect if it's the legacy datafeed, or the new webhook (based on the presence of the headers of the new webhooks). If we detect it's the legacy, then send on to the legacy file, but if it's the new JSON webhook, pass on to the new file.
The JSON webhook endpoint will be largely a duplication of the existing functionality that the datafeed supports, including handling inventory updates, SSO syncing, and supporting events for people to hook into. It should also be a file that people can duplicate into their theme folder to customise further.
The existing endpoint in FoxyShop has some helper logic which pulls in the values from the payload into variables in the scripts, and provides commented places for users to interact with that information. Let's duplicate that same logic for the webhook as well - grabbing the values from the respective elements in the payload.
We should ensure we handle the fact that a single transaction can trigger multiple webhooks as well, if it is an initially pending status transaction, and then becomes approved later, by checking that the status is either blank,
approved, orauthorized. Anything else we can ignore. (Or alternatively, just skipping if the status is eitherdeclined,pending, orrejected).The legacy datafeed also has a subscription datafeed which sends information about failing or cancelling subscriptions - this isn't a part of the new webhooks, so we can skip most of this functionality with the new endpoint (all the reminder functionality is handled natively now). We do have the
subscription/cancelledevent though, which sends a payload when the subscription is actually ended - we should pick up that event (if the user subscribes to it for the webhook) and set the subscription as inactive within FoxyShop like we do with the existing datafeed handling.We don't need to support sending the payload on to external datafeeds like the legacy approach does - as multiple endpoints can be defined in Foxy for the JSON webhooks.
Tasks:
transaction/createdandsubscription/cancelledevents (detected via theFoxy-Webhook-Eventheader)Foxy-Webhook-Signatureheader, if the webhook encryption key is set.