Checkout gives merchants multiple pathways to accept online payments, serving vastly different integration needs while running on the exact same foundation. Hosted checkout is a low-code solution that sends customers to a secure, Shift4-hosted payment page optimised for conversion with streamlined but robust customisation. Alternatively, Payment components allow a merchant to embed secure card input fields directly into their own forms, maintaining full control over the UI.
With both paths, card data is captured by Shift4 rather than by your site, so neither one brings card numbers into your systems. See PCI compliance below.
Underneath both sits a single building block: the Checkout Session, which your backend creates for each payment and then checks to confirm the payment went through. Only the middle step differs — whether the customer pays on Shift4's page or on yours. That makes the choice a front-end one, and it's why you can use each path for different flows, or change your approach later, without starting over.
Hosted checkout
Send customers to a secure, Shift4-hosted payment page built for conversion. The fastest way to start accepting payments, with streamlined customization and no payment experience to build or maintain yourself.
Best for: Getting live quickly, teams that want Shift4 to handle the checkout experience
Payment components
Bring payment directly into your own pages and keep full control of the look, feel, and flow — customers never leave your site. Card fields are rendered by Shift4, so card data never reaches your page.
Best for: E-commerce checkouts, keeping your own branding end to end, a fully tailored payment experience
Both paths run on the same foundation, so you can start with one and move to the other later without rebuilding. Not sure which fits? Walk through the common scenarios.
| Aspect | Hosted checkout | Payment components |
|---|---|---|
| Where customers pay | On a secure Shift4-hosted page | Right on your own site |
| Effort to launch | Fastest — little to build | More to build, fully tailored |
| Look and feel | Shift4-designed, lightly customizable | Fully your brand, end to end |
| Who maintains the payment experience | Shift4 | Yours to build — card entry stays secured by Shift4 |
| Apple Pay / Google Pay | Included — enable in the Customer Hub | Included — buttons render on your page |
| Where card data is entered | On Shift4's payment page | In Shift4-hosted card fields embedded in your page |
| Typical PCI SAQ | SAQ A | SAQ A |
| Best suited to | Getting live quickly, one-off and ad-hoc payments | E-commerce, seamless on-brand checkout |
- Bring payment into your own experience — accept payments on your product, cart, or checkout pages; with Payment components, customers stay on your brand from start to finish.
- Take payments on your own terms — create a checkout for each order and start it whenever your flow is ready.
- Confirm a card without charging — save a card for later or verify a payment method before you fulfil an order.
If you just need a shareable link with nothing to build, use Payment Links instead.
Both integration paths are designed to keep cardholder data out of your environment, so both typically qualify a merchant for SAQ A — the shortest PCI DSS self-assessment questionnaire.
What that means for each path:
- Hosted checkout — the customer is redirected to a Shift4-hosted payment page. Card entry happens entirely on Shift4's page, on Shift4's domain. Your site never renders a card field and never receives card data.
- Payment components — the card number, expiry, and CVC inputs are rendered by shift4.js as Shift4-hosted iframes mounted inside your layout. Because those fields are served from a Shift4 origin, they are isolated from your page's own scripts; you style the surrounding page and choose when to submit, but card data goes directly from the iframe to Shift4.
In both cases your servers receive only a token or a Checkout Session reference — never a card number — which is what keeps your PCI burden to a minimum.
Your page still counts. Under PCI DSS v4, SAQ A eligibility also requires you to confirm that the page embedding the components — or initiating the redirect — is not susceptible to script-based attacks that could compromise the payment fields, such as a swapped iframe or an overlaid fake form. Keep your site's scripts and dependencies secure. Your acquirer makes the final determination of which SAQ applies to you.
Apple Pay and Google Pay are included on both integration paths, and the buttons appear automatically on devices and browsers that support the wallet — customers authorise with a touch instead of typing card details.
- Hosted checkout — nothing to build: enable the wallets in the Customer Hub and Shift4 renders the buttons on the hosted page. See Apple Pay & Google Pay.
- Payment components — the wallet buttons render right on your own page, so the whole flow stays on your brand. Each wallet is a component you mount like any other. See Apple Pay and Google Pay.