Stop the Drop-in reloading on every order update

[acasazza]

The bug

An Adyen gift card covering only part of the order left the Drop-in reloading repeatedly ("as if the Adyen component kept reloading"), and a Place Order click could take the page — and the Playwright run — down with:

unhandledRejection: Error: No active payment method.
  at handleSubmit (AdyenPayment.tsx)
  at ref.current.onsubmit
  at handleClick (PlaceOrderButton.tsx)

Root cause

Both parents implement their loader by replacing the subtree rather than overlaying it:

// PaymentMethod.tsx
const content = !loading ? <>{components}</> : getLoaderComponent(loader)
// PaymentGateway.tsx
if (loading) return loaderComponent

To React those are different trees in the same position, so every flip of loading unmounts every gateway below. For a stateless gateway that costs nothing. The Adyen Drop-in, though, owns imperative state — the shopper's selected method and typed-in card details — so it was destroyed and fully re-initialized (fresh AdyenCheckout(), new Dropin().mount(), translations and analytics again) on each flip.

Guarding the individual flips cannot close this: payment_source.payment_response.status and order.payment_status are populated by two different API calls (the gift-card balance check refetches the order; the authorization flips the payment status), so there is a window where a flip looks legitimate.

Dropin.submit() then threw because mount() had reset activePaymentMethod while the patched ref.current.onsubmit survived, leaving <PlaceOrderButton> believing it could submit.

The fix

File	Change
PaymentGateway.tsx	the adyen_payments branch is no longer swapped out for the loader; isPartiallyAuthorized guards on the loader flips and on recreating the payment source
PaymentMethod.tsx	once the methods have rendered they are never swapped back out for the loader
AdyenPayment.tsx	one intentional refresh via Core.update(); checkoutRef + latch; remove() on unmount; try/catch around submit(); submit wiring disarmed on refresh

The intentional refresh is kept — refreshing once when the order becomes partially authorized is correct, since the shopper now owes less — but it happens once:

checkoutRef.current?.update({ amount: remainingAmount }, { shouldReinitializeCheckout: true })

Verified against the shipped adyen-web@6.41.0: with true, Core does setOptions(amount) → initialize() → update() on each mounted component, and BaseElement.update() is state = {} plus unmount().mount(this._node) — a real refresh in place, with the payment method list consistent with what is left to pay. It replaces dropinRef.current.mount("#adyen-dropin"), which re-rendered the Drop-in with the old amount: same lost selection, none of the benefit.

The remaining amount is not gift_card_amount_cents

That field is "the sum of all the gift_cards applied to the order" — Commerce Layer gift_card resources. An Adyen gift card authorized through _authorization_amount_cents is a payment-source authorization and never creates one, so the field stays 0 and total_amount_with_taxes_cents - gift_card_amount_cents silently evaluates to the full total. Adyen's own payment_response.order.remainingAmount is preferred, falling back to total - currentBalance. Reported as { currency, value } and only when the currency is known: triggerAmountUpdate() gates on isAmountValid, which rejects an empty currency with nothing but a console.warn.

Behaviour changes to validate

• showLoader now means "while first fetching the payment methods", matching its documented description. It no longer re-enters the loading state after the first render.
• Place Order goes back to disabled right after the gift card is applied, until the shopper picks a method again. This is the logical consequence of a refresh resetting activePaymentMethod, and it prevents the crash at the source rather than only reporting it.

Both touch PaymentMethod/PaymentGateway, which every gateway shares, so the other payments-*.spec.ts suites are worth a run.

Testing

specs/payment_source/AdyenPayment.spec.tsx — 13 tests, mocking @adyen/adyen-web/auto and driving the real onSubmit handler the component installs. The important one renders the real chain — PaymentMethod → PaymentSource → PaymentGateway → AdyenGateway → AdyenPayment — and pushes through the order updates a partial authorization actually produces, in order, asserting one mount() and no remove().

Each fix was confirmed load-bearing by reverting the source line and watching the test fail:

Reverted	Failure
PaymentMethod latch	expected 1 times, but got 2 times
PaymentGateway adyen branch	expected "remove" to not be called, but was called 1 times
refresh latch	expected 1 times, but got 4 times
whole AdyenPayment change	reproduces Unhandled Rejection: Error: No active payment method.

• vitest run — 75 files, 794 tests green
• biome lint ./src --max-diagnostics=300 — 97 warnings, 0 errors, identical to the baseline on v5.0.0
• tsc --noEmit — no errors in the changed files (35 pre-existing elsewhere)
• husky pre-commit hook green (workspace build + lint + suite)
• payments-adyen-givex.spec.ts passes locally against a linked build

Still open

The loader-replaces-subtree pattern remains for the other gateways, and docs/adr/0001-payment-source-effect-invariants.md should probably gain an invariant for it — happy to add that here or in a follow-up.

🤖 Generated with Claude Code

[pkg-pr-new]

npm i https://pkg.pr.new/commercelayer/commercelayer-react-components/@commercelayer/core-components@807

npm i https://pkg.pr.new/commercelayer/commercelayer-react-components/@commercelayer/react-components@807

npm i https://pkg.pr.new/commercelayer/commercelayer-react-components/@commercelayer/react-hooks-components@807

commit: a7f94d6