Redirect flow: every GoCardless method is flow "redirect", so confirm hands the page to the hosted authorisation flow — the same treatment the Stripe adapter gives its redirect methods. The returned promise never settles (the navigation unloads the page); the outcome resolves on returnUrl via handleRedirectReturn + a server-side retrievePayment.
GoCardless lands the payer back with billing_request_id / billing_request_flow_id query params and is explicit that the redirect must NOT be used to decide the outcome ("Always use webhooks"). So a GoCardless return resolves "processing": the host confirms server-side via retrievePayment(billing_request_id) or waits for the webhook. Returns null when the URL carries no GoCardless params, so a router can probe every registered adapter safely.
No script to inject — resolves once the browser guard passes (SSR parity with SDK adapters).
Nothing is filled client-side, so mount renders a plain, unbranded
informational panel and immediately reports the fields complete
(initialized { complete: false } first so button state stays
deterministic). fieldOptions.description overrides the panel text;
appearance.panel carries inline CSS for it — the payment UI itself is
GoCardless-hosted and not themeable from here.
GoCardless one-off bank payments run entirely on GoCardless-hosted pages, so this adapter has no card fields and no browser SDK — the session's clientSecret IS the hosted authorisation URL, and confirm() is the redirect. There is no key of any kind on the client.