[Bug] Invoice generation broken since May 5, tickets purchased with invoice request not generating or sending invoices

[ciudadanoB]

Summary

Since Tuesday, May 5, invoices are no longer being generated or sent for ticket purchases where the attendee requested an invoice. The billing data is being saved correctly, but the generation and delivery steps appear to be silently failing.

This has been confirmed across at least two events:

• WordCamp Portugal
• WordCamp Europe

---

Steps to reproduce

1. Purchase a ticket on a WordCamp event site.
2. Check the "I need an invoice" option and fill in the billing details.
3. Complete the purchase.
4. Expected: Invoice is generated and sent to the attendee.
5. Actual: Billing data is saved, but no invoice is generated or sent.

---

Example ticket

The following order has billing details filled in but no invoice was generated:

https://portugal.wordcamp.org/2026/wp-admin/post.php?post=2659&action=edit
(also IDs 2660, 2689, 2690, 2692, 2693, 2727, 2728, 2735, 2745, 2772, 2775, 2776, 2780, 2819, 2821, 2822, 2823, 2838)

List of invoices generated and sent: https://portugal.wordcamp.org/2026/wp-admin/edit.php?post_type=tix_invoice

---

Impact

• Affects all ticket purchases with invoice requests from May 5 onwards.
• Dozens of pending invoices across at minimum WordCamp Portugal and WordCamp Europe.
• Attendees have not received invoices they are legally/fiscally entitled to.

---

Priority

High / Urgent — This affects fiscal compliance for attendees. Manual resolution of dozens of invoices is not scalable.

---

Questions / Requests

1. @dd32 Was there a deployment or code change on May 5 that touched the invoice generation logic or the ticketing/payment flow?

2. Is there a way to retroactively trigger invoice generation for all affected orders? A manual fix order-by-order would be… entertaining.

3. If a bulk fix isn't available, could one be added as part of the fix?

Huge thanks for looking into it!

Props to Alvaro Gois do Santos for finding the bug and informing about it!

[wputasic]

Here's what I think happened

Root cause: a race that #1708 silently decided

There are now two callers of CampTix_Plugin::payment_result() for the same payment token:

1. Interactive return path — buyer redirects back to e.g. portugal.wordcamp.org/...&tix_action=payment_return, runs on the event site, calls payment_result( …, $interactive = true ).
2. Centralized Stripe webhook ([Codex] Add centralized Stripe webhook for CampTix #1705) — Stripe POSTs to /wp-json/camptix/v1/stripe-webhook on the central site, the handler switch_to_blog( $site_id )s into the event site, calls payment_result( …, $interactive = false ).

payment_result() only fires do_action( 'camptix_payment_result', … ) when $status_changed === true (camptix.php:6694-6712). Whichever caller runs first flips the attendee draft → publish; the second sees $status_changed === false and returns without firing the action.

CampTix_Addon_Invoices::maybe_create_invoice() is the only listener on camptix_payment_result (class-camptix-addon-invoices.php:29). It only gets a chance to run on whichever of the two contexts wins the race.

Why it broke on May 5 specifically

Pre-#1708, the centralized webhook relied on add_action( 'switch_blog', [ $this, 'reload_options' ] ) (CampTix core, priority 10) and a second handler at priority 11 in the Stripe addon to refresh $camptix->options and $stripe->options for the switched-to site. Both handlers had a doing_filter( 'camptix_options' ) reentrancy guard. If anything in the request had camptix_options filters running when the webhook hit switch_to_blog(), the Stripe addon's options refresh short-circuited, get_api_credentials() returned stale/empty keys, the Stripe API call returned WP_Error, the webhook returned 5xx before reaching process_payment_return_session(), and Stripe retried until it gave up. The webhook never moved attendees to publish. The interactive return on the event site was the only path that actually flipped status, so it fired the action and minted the invoice.

#1708 replaced the global switch_blog listener with explicit, unconditional $camptix->load_options(); $this->load_options(); calls right after switch_to_blog( $site_id ) in the webhook handler (payment-stripe-webhook.php:146-165). No reentrancy guard, no priority race. The webhook now reliably loads the event site's Stripe credentials, the Stripe API call succeeds, payment_result() runs to completion, and the attendee flips to publish before the buyer's browser redirects back. The interactive return then hits the ! $status_changed early-exit and never fires the action. Net result: zero invoices.

So #1708 is not a bug per se — it correctly fixed the webhook. Its side effect was deciding the race in favor of a context that doesn't successfully produce a tix_invoice post.

[carmoreira]

Is there a way to retroactively trigger invoice generation for all affected orders?

[dd32]

@carmoreira Yes it's possible to find the affected users, but it's not possible to trigger them at present.

That's because of some server/system safeties we have in place.

#1555 and/or an organiser UI to edit/send/resend invoices would be needed to allow us to trigger sending the missing invoices. I guess it depends on how many people were affected, I'll have to follow up on that tomorrow.

[wputasic]

@dd32 Out of curiosity, would a WP-CLI command be a viable path here rather than triggering it via a web request? Asking for a few different use cases it wouldn't necessarily need to be run by organisers either, which could speed things up for statuses like "coupon generation", "attendee attended", batch process of invoice, visas etc.

Alternatively, could we leverage something similar to the Profile Badge Management approach where you can enter a list of IDs to be batch processed? That way organisers or admins (or whoever has access) could just paste in a list of IDs and trigger the action in bulk.