The component catalogue for your checkout
Drop in the all-in-one payment element, or assemble the payment step field by field. Every component is headless, validated and themeable — you own the markup, the layout and the copy, while Naturpay tokenizes the sensitive parts behind the scenes.
How the catalogue works
Wrap once with <Elements>, then mount what you need
Every component lives inside an Elements provider that holds the intent and shared appearance. From there you choose your altitude: the all-in-one element for speed, or individual field components for a fully bespoke form. The sensitive inputs are isolated and tokenized by Naturpay, so raw card data never reaches your code.
Headless by default
Components ship structure and behavior, not a fixed look. You place them in your own nodes, wrap them in your own labels, and style them through the appearance object or raw CSS.
your markupSensitive fields isolated
Card number, expiry and CVC are served and tokenized by Naturpay, so digits never touch your DOM or your servers. Your PCI scope stays at SAQ A while the fields still look like yours.
SAQ A · tokenizedValidation built in
Each field validates, formats and surfaces errors through events you can read. You decide where the message renders and how it looks — the component just tells you what is wrong.
events · stateAll-in-one elements
Drop in the whole payment step
When you want the fastest path, mount a single component that renders wallets, cards and local methods, adapts to the buyer, and handles authentication inline. One node, the complete flow.
Payment element
The complete payment step in one mountable component. It shows the right methods for the buyer's region and device, validates everything, and runs 3-D Secure when the issuer asks for it.
Express checkout
A row of wallet buttons that renders only the ones the current device supports, for one-tap confirmation at the top of your form. It disappears cleanly when nothing qualifies.
Method selector
A standalone picker that lists the methods enabled on the intent and lets the buyer switch between card, wallet and local options while the rest of your form stays put.
Granular field components
Or place every field exactly where you want it
For a fully custom form, mount the inputs one at a time. Each is an isolated, tokenized field you can position, label and validate inside your own layout — split the card across columns, reorder freely, wrap each one however your design system says.
Card number
An isolated number field that detects the card brand as the buyer types, formats the digits, and emits validity events without the value ever entering your page.
Card expiry
A month-and-year field with masking and validation, ready to sit beside the number and CVC in whatever column layout your form uses.
Card CVC
The security-code field, length-aware per brand, with an optional hint affordance. Like its siblings, the value is tokenized and never readable from your code.
Address element
Billing or shipping capture with country-aware fields and type-ahead completion. Return a structured address you can reuse for tax, shipping and fraud signals.
Wallet button
A single wallet button you can place on its own — on a product page or in a cart drawer — to start a one-tap payment before the buyer ever reaches a full form.
Pay button
A submit control wired to confirmation that knows the form's validity and shows its own busy and disabled states — or skip it and confirm from your own button.
Express and returning customers
Make the second purchase a single tap
For buyers you already know, skip the form. Recognize a returning customer, show their saved methods, and confirm with one tap — all from components that read from the vault you already populated.
Saved methods
Render a customer's vaulted cards and wallets as a selectable list, with add and remove built in. Tokens are network tokens, so a saved card keeps working after it is reissued.
Link authentication
Recognize a returning buyer by email and pull their saved details into the form after a quick verification, turning a full checkout into a confirm.
Save for later
A consent toggle that vaults the method on success so the next purchase is one tap. It carries the right mandate text per region, ready for off-session reuse.
Composing a custom form
Snap the pieces into your own layout
Wrap the fields in one provider, lay them out with your own grid, and read a single validity state for the submit button. The express row and the granular card fields coexist in the same form — nothing forces you to pick one shape.
- Place the number on its own row and split expiry and CVC into two columns — it is just your markup.
- Subscribe to each field's change event, or read one aggregate complete flag for the whole form.
- Confirm from your own button — the components never impose a layout or a submit control.
import { Elements, ExpressCheckout, CardNumber, CardExpiry, CardCvc, AddressElement, usePayment, } from 'naturpay/react'; function Form({ secret }) { const { confirm, ready } = usePayment(); return ( <Elements intent={secret} appearance={theme}> <ExpressCheckout /> <CardNumber label={'Card'} /> <div className='grid-2'> <CardExpiry /> <CardCvc /> </div> <AddressElement mode={'billing'} /> <button disabled={!ready} onClick={confirm}> Pay </button> </Elements> ); }
// React package import { Elements, PaymentElement } from 'naturpay/react'; <Elements intent={secret}> <PaymentElement /> </Elements>
// Vue package <script setup> import { Elements, PaymentElement } from 'naturpay/vue'; </script> <Elements :intent="secret"> <PaymentElement /> </Elements>
// framework-free Web Components <script type="module" src="https://js.natur-pay.com/v3"></script> <wv-elements intent="pi_3Q…"> <wv-payment-element></wv-payment-element> </wv-elements>
Framework support
The same catalogue, in your stack
Every component exists as a first-party React and Vue binding, a set of framework-free Web Components, and a vanilla JS SDK that mounts into any node. The names, props and events line up across all four, so the mental model carries over wherever you build.
- React and Vue packages ship typed props, hooks and composables for state and confirmation.
- Web Components work in Svelte, Angular, plain HTML or anything that renders custom elements.
- The vanilla SDK exposes mount, on and confirm so you can wire components by hand.
The catalogue in numbers
Enough pieces to build any flow
Before you ask
Questions about the components
Can I mix the all-in-one element with individual fields?
Yes. A common pattern is an ExpressCheckout row at the top for wallets, then granular CardNumber, CardExpiry and CardCvc fields below for buyers who pay by card. They share one Elements provider and one intent, so the validity and confirmation logic stays unified no matter how you arrange them.
If the fields are isolated, how do I style them?
Through the appearance object on the Elements provider, which drives type, color, spacing, radius and per-state rules inside each field. The wrapper, labels, layout and error placement are ordinary elements in your own DOM, so everything around the isolated input is fully yours to style.
How do I know when the form is ready to submit?
Each field emits change events with a validity flag, and the provider exposes one aggregate ready state across all mounted fields. Bind your submit button's disabled attribute to that flag, or listen per field if you want to show inline messages as the buyer types.
Do the Web Components really need no framework?
None. Add the script tag and use the custom elements directly in plain HTML, or inside Svelte, Angular, Astro or anything that renders the DOM. They expose the same attributes and events as the React and Vue bindings, so you are not learning a second API to use them.
What do the saved-method components read from?
From the customer vault you populate when a buyer opts to save a method. SavedMethods renders those vaulted tokens as a selectable list, and because they are stored as network tokens, a card keeps working after the bank reissues it — so returning-customer success rates hold up over time.
Are the components versioned independently of the API?
The component packages follow semantic versioning and pin to a stable API version, so an upgrade never silently changes payment behavior. Breaking changes land behind a major version with a migration guide, and the Web Components script is served from a versioned URL you control.
Build your form from Naturpay components
Install the package for your framework, wrap your form in Elements, and mount the pieces you need. Start with the all-in-one element and break it apart whenever your design calls for it.