Failed payments 2.0.20

Hi,
we run Payment Plugins for PayPal WooCommerce and want to report what looks like a capture regression in 2.0.20.
Timeline (CEST, live mode):
• Jul 4, ~10:16 — last successful PayPal order on 2.0.19 (captured normally, transaction ID recorded)
• Jul 4, evening — updated to 2.0.20
• Jul 5, 00:01 / 10:19 / 12:06 — every PayPal attempt failed identically: order created as Pending payment, customer went through the PayPal popup (one retried and triggered two order-confirmation emails), but no capture ever registered — no transaction ID, no status change — until the unpaid-order timeout cancelled the orders. Stripe (your Stripe plugin) worked normally throughout.
• Jul 5, ~16:20 — rolled back to 2.0.19. The very next PayPal order captured immediately.
So: 4 consecutive failures on 2.0.20, instant recovery on 2.0.19.
Environment: WordPress 7.0 · WooCommerce 10.9.3 (HPOS on) · PHP 8.2.31 · live mode, Smart Buttons on classic (shortcode) checkout · German store, EUR · behind Cloudflare · SiteGround.
Settings: server_side_shipping_callback = no (the new 2.0.20 shipping-callback feature was not active). reCAPTCHA integration not enabled.
Suspicion 1: the changelog’s “deprecated ApplicationContext replaced with the new ExperienceContext object in the checkout flow” — the only unconditional change in the create/approve/capture path, and the symptom fits a create-order/return-flow payload issue. Possibly specific to German buyer accounts/funding sources.
Suspicion 2: we’re behind Cloudflare, which blocks some non-browser requests. Your 2.0.20 notes say the new callback endpoint (/wp-json/wc-ppcp/v1/cart/order-update-callback) should be whitelisted behind security layers. Our callback setting is “no” — but does 2.0.20 make any other server-to-server or REST callback calls in the standard Smart Buttons flow even with that setting disabled? If so, Cloudflare interference would explain why the regression hit our store while 2.0.19 works perfectly.
Caveat: WooCommerce logging was unfortunately disabled during the affected window, so we don’t have your plugin’s API logs from the failures. Logging is re-enabled; we can reproduce on request (small live test order on 2.0.20 with debug logging on) and send you the log.
One affected buyer may have completed payment on the PayPal side while the Woo orders auto-cancelled — we’re reconciling via the PayPal dashboard.
Happy to provide order IDs, timestamps, or a debug-log repro. We’ll stay on 2.0.19 until a fix is confirmed. The plugin has otherwise been rock-solid for us — which is why this stood out.