onSubmit fires when an element produces a submittable value. For inputs, it fires when you call element.submit() after validation passes. For wallet elements, it fires when the wallet sheet resolves with a cryptogram. value is non-null by construction.
Payload
Example
Merchant-driven vs. self-driven
card, bank, email, fullName, phone, companyName, address elements, and custom elements are merchant-driven: you call element.submit() (from a button click, a form submit, or an external CTA).
applePay and googlePay are self-driven: the wallet sheet triggers onSubmit directly when the shopper authorizes.
checkout composes both: card and bank submit through the internal button, wallets submit through their sheet.
submitButton is a relay: it fires onSubmit with value: undefined on every click. Use it to drive an external card.submit() or bank.submit() call.
Never call the payment gateway directly
For card and wallets, value is a tokenized payload. Forward it to your server, which calls the Overflow authorize endpoint. Calling the payment gateway directly from the browser bypasses risk evaluation and the SDK’s payment-settings layer.
Do not return a promise expecting the SDK to await it
The contract is fire-and-forget. If you need request-in-flight UI, manage it in your own state:
Checkout
Switch on value.method first; the per-method key is then non-null:
Wallets
The onSubmit.value for wallets is:
Contact and address keys appear only when the wallet sheet returned them. Set require.email, require.name, and so on in the wallet options to ask the sheet for them. Keys the sheet did not return are omitted, never null.
See also
Last modified on July 17, 2026