Send the purchase event when an order is placed, not paid

I attach a patch with a possible solution to use just the commerce_order.place.post_transition event. This would also fix another issue I encountered 🐛 Drupal Commerce purchase event gets sent multiple times if someone refreshes the checkout success page Active as it would not send a purchase event based on the checkout step multiple times anymore. But as you mentioned, this alters the module's behavior when to send purchase events to the way how Commerce Google Tag Manager → worked.

Then this way, I encountered a strange error when PurchaseEvent::getData is called:

Error: Typed property Drupal\google_tag\Plugin\GoogleTag\Event\Commerce\PurchaseEvent::$transformer must not be accessed before initialization in Drupal\google_tag\Plugin\GoogleTag\Event\Commerce\PurchaseEvent->getData() (line 79 of modules/contrib/google_tag/src/Plugin/GoogleTag/Event/Commerce/PurchaseEvent.php).
google_tag_page_attachments(Array) (Line: 311)

I could not fix this with proper DI, so that's why I made those changes there.

Just stumbled over this as well. In my case I was confused why the purchased event is tiggered in this form_alter you removed. Was looking into a similar fix.

I wonder if we could use

CheckoutEvents::COMPLETION

as the subscribed event instead of `'commerce_order.place.post_transition'`?

opened a MR, addressing #4, as I fully agree that CheckoutEvents::COMPLETION is the event that should be used here

And I further have observed that DI is really not working when using a delayed event. I haven't chased this problem down, but I'm 99% sure that the problems derive from serialization and deserialization of the plugin. This is the main difference between the sync and the delayed events

We are using a custom event subscriber triggered by CheckoutEvents::COMPLETION and have been successfully in a production environment for 2 years. This adds a delayed custom purchase event.

So, this is certainly a workable solution, but we have encountered an issue following implementation of Stripe Payment Element.

The Stripe Payment Element implementation (commerce_stripe) uses a webhook that Stripe POSTs to with the payment status. If Stripe is faster responding than the Drupal checkout, the order is completed in the context of the Stripe webhook with token based authentication and as there is no user session or cookie attached to that and it is independent of the Drupal checkout flow, the GA4 event is never fired.

When Stripe wins the race to complete the order, the checkout page is refreshed in the context of the user and this redirects to the complete page but as the transition didn't happen in the context of the user's browser session, the GA4 event is never triggered and attributed to the user here either.

agree that this would be a better solution