OptionalappearanceOptionalchildrenLayout slots for split-field PSPs (Paysafe): render your own structure with elements carrying data-payfanout-field="cardNumber|expiryDate|cvv" and the hosted fields mount INTO them — your grid, your spacing, your labels. Single-element PSPs (Stripe) ignore slots; layout goes via fieldOptions.
OptionalclassPaymentSession.clientSecret from the server's createPaymentSession.
OptionalfieldPSP-vocabulary UI options passed through to the SDK (Stripe: Payment
Element layout/paymentMethodOrder/fields/terms/…; Paysafe:
per-field placeholders under fields, locale, …).
OptionallocaleBCP-47 locale for the PSP's own field texts, where supported.
OptionalonLive field validity — fires { complete: false } on mount, then on every change. The canonical "disable Pay until complete" hook, PSP-agnostic.
OptionalonOptionalonOptionalpspDefaults to the provider's active PSP.
OptionalsaveRenders an accessible "save my card" consent checkbox after the hosted
fields — unchecked by default, never auto-saved. The checkbox only
REPORTS consent via onChange: the host forwards it to its own server,
which sets savePaymentMethod: true on createPaymentSession when (and
only when) the customer checked it. Style it via
[data-payfanout-save-consent].
Optionalstyle
Visual theme for the hosted fields. The adapters that render themeable hosted card fields — today Stripe and Paysafe — translate a small cross-PSP common token set (
colorPrimary,colorText,colorDanger,colorBackground,fontFamily,fontSize) to their native format, so oneappearancestyles either of them. PSP-native shapes still pass through for power users (Stripe's Appearance API{ variables, theme, rules }; Paysafe'sstyleselector map like{ input: { … } }): Stripe ignores unrecognized keys, and Paysafe warns (console) about entries it cannot apply. Other PSPs take their own nativeappearanceshape (PayPal buttonstyle, GoCardlesspanel, PayZen); the common tokens do not apply to them.