​
SwitchFlow.mount(options)

OptionTypeRequiredDescription
containerstring | HTMLElementYesCSS selector or element the form renders into
sessionIdstringYesFrom your server’s session-create response
clientSecretstringYesFrom your server’s session-create response
apiBasestringYesSwitchFlow API origin (https://api.switchflows.net)
vaultVaultConfigYesThe vault block from the session-create response — pass it through unchanged
onSuccess(result: SuccessResult) => voidNoCalled when the payment is captured
onDeclined(result: DeclineResult) => voidNoCalled on a terminal decline
alternativeMethodLabelstringNoButton label shown if all gateways are down (default: "Pay with PayPal")

​
Result shapes

interface SuccessResult {
  capturedVia: 'STRIPE' | 'ADYEN';  // which of your gateways captured
  failoverUsed: boolean;            // true if capture happened on a fallback gateway
}

interface DeclineResult {
  declineCode: string;              // normalized code, e.g. 'do_not_honor'
}
Do not branch fulfillment logic on the widget callbacks alone — they run in the customer’s browser. Treat the signed webhook as the source of truth for order fulfillment, and the callbacks as UX signals.

​
The vault block

The session-create response includes a vault object that tells the widget how to tokenize. Pass it to mount() verbatim — its contents depend on your account’s vault mode and are not something you construct yourself: 
interface VaultConfig {
  mode: 'shim' | 'saas';
  vaultBase?: string;         // tokenization origin (shim mode)
  publishableKey?: string;    // vault SDK credentials (saas mode)
  profileId?: string;
  sdkAuthorization?: string;
  sdkUrl?: string;            // secure-fields SDK to load (saas mode)
}
In saas mode the widget loads the vault’s secure-fields SDK, so card input is fully isolated from your page’s JavaScript; the widget then submits an opaque pm_… payment-method token. In shim mode (sandbox) the widget renders its own fields and tokenizes to vaultBase. Your integration code is identical in both modes.

​
Degradation behavior

If the API responds with { "action": "RETRY_ALTERNATIVE_METHOD" } (all gateways down within the latency ceiling), the widget replaces the card form with a single button labeled alternativeMethodLabel. Clicking it is your page’s cue to present your fallback payment flow. If you configure no alternative method, the widget shows a retry-later message instead. See Failover behavior.