Resolves an Adyen action — the object completePayment surfaced on
PaymentInfo.raw when it answered requires_action. Adyen Web unmounts the
Card and mounts the action in its node: a threeDS2 action runs INLINE and
resolves with a fresh clientToken carrying the additional details, which
the host completes the payment with exactly as it did the first token; a
redirect action navigates the page to Adyen, so this promise never settles
and the payment finishes on the return page (see adyenRedirectResultToken).
Adapter-specific: the unified contract has no action-handling method, since most PSPs resolve challenges inside confirm().
One challenge at a time per mounted handle: the returned promise settles
when Adyen reports the shopper's additional details, or failed when Adyen
Web reports an error through onError meanwhile or the fields are unmounted
first, so a second call while one is outstanding is refused rather than
replacing the pending resolver (which would strand the first caller's
promise forever). An error raised while the action runs is
authentication_required, unless Adyen Web names it a network or script
error, or its message reads as one (psp_unavailable). A host that wants a
deadline on an abandoned challenge races this promise against its own timer.
Loads Adyen Web's script and stylesheet once, from the CDN host of the
configured Adyen environment. Loaded from their default URLs, both files
carry the Subresource Integrity hash Adyen publishes for ADYEN_WEB_VERSION;
sdkVersion turns the check off for both, sdkUrl for the script and
stylesheetUrl for the stylesheet. With cspNonce both carry the nonce.
If the script fails to load, the next call fetches it again; a stylesheet
that failed stays on the page and is reused, as core's injectStylesheet
keeps every link it injects. If the script loaded without defining
window.AdyenWeb, the next call checks again instead of failing from a
cached result.
Renders Adyen's Card component into a generated child of container. The
fields live in Adyen-hosted iframes, so no card data touches the host page.
options.appearance becomes Adyen's styles object and
options.fieldOptions passes through untouched (the host wins), except the
two keys the adapter must own: showPayButton (the host's own button drives
submission) and onChange (the encrypted blob arrives on it).
Two Card defaults differ from Adyen Web's, and fieldOptions still wins
over both: the cardholder name is shown and required (hasHolderName,
holderNameRequired), since Adyen's native 3-D Secure 2 guide lists it as
required for Visa and JCB — hasHolderName: false alone hides it, and
Adyen Web then drops the requirement too — and onEnterKeyPressed does
nothing, since Adyen Web's default handler calls submit(), which has no
onSubmit to call here.
Tokenize-first shape: resolves requires_confirmation plus a JSON clientToken, / completionEndpoint wire
it automatically), which creates the Adyen payment.
{ paymentMethod, browserInfo?, origin?, billingAddress?, riskData? }— the encrypted card blob and the browser data Adyen's 3-D Secure 2 asks the page for, taken from Adyen Web's state. The host passes it to the server's completePayment (Incomplete fields resolve
failedafter asking the Card to show its own validation errors. Once handleAction ran on the handle the Card is gone — Adyen Web replaced it with the action — so confirm() resolvesfailedwith invalid_request rather than resubmit card data a payment already used; remount the fields to pay again.