Purchase event is triggered when order is cancelled

[jansentjeu]

It is checked whether the order has the status "canceled" in Observer/TriggerPurchaseDataLayerEvent.php on line 29. However, this observer is called immediately after the payment button is clicked in the checkout, so this check is too early. The orders are only cancelled in the payment environment if the payment process is not completed there. At this moment, the purchase event is triggered too early while a customer can still cancel the order during the payment process.

Take Adyen as an example. When the payment button is clicked in the checkout, the status of the order is "pending_payment". This triggers the purchase event while the customer can still cancel the order in the Adyen environment.

Reproduction steps:

1. Go to checkout
2. Click on the payment button that redirects you to a PSP => purchase event is triggered
3. Click on "Cancel" in the PSP environment
4. You will be redirected to the shopping cart page in Magento

Conclusion: Order is canceled but the purchase event is still triggered

[jissereitsma]

Thanks for addressing this. There is indeed a discrepancy here. I read the issue, but I don't see a simple solution yet. To bring a discussion in motion, I've added a new configuration option order_states_for_purchase_event that allows you to configure which states should be used to trigger a purchase event. This will fix the direct issue that you were posting - that the purchase event should not be triggered when the status of the order is pending_payment.

Note that this module supports both an event is lazily triggered when it is picked up on the PHP side (that's the TriggerPurchaseDataLayerEvent observer that you referred to) AND there is the triggering of the event on the success page. With the new configuration option I just introduced, theoretically your specific scenario would be fixed. For instance, if an order is placed with state pending_payment while you have configured this module to skip the purchase event for that order state, then the observer would not do anything, but the success page would be reached whenever the state is actually processing or complete. Am I correct?

However, this brings in another question: When would the purchase event be fired then in other cases? With bank transfers, delayed PSP payments and payment-on-delivery options, the payment will only occur later offline as well. In other words, if this is used, it fixes the direct issue you are addressing. But it removes the possibility of triggering a purchase event.

This could potentially be solved with server-side analytics, but that's not part of this module. What kind of solution did you have in mind?

Note that if a payment is made, the purchase event is fired to GTM and then the order is refunded, a refund event should also be fired to GTM. But that refund event will be part of your Magento Admin Panel or part of an automated process of the PSP, never with JS in the frontend. Hence, this extension does not pick it up (because it is a client-side implementation, not a server-side implementation). This is yet another problem.

In general, if people do bookkeeping via GTM, then indeed, the numbers need to add up. However, some people suggest (and I've followed along with them) that once the checkout is completed, the intention for a purchase is made, and that's the actual thing that you're tracking with GTM - not the financial balance of the bank account.