Shift4 Checkout FAQs

Note: This feature is currently in pilot. Availability may be limited.

What is Shift4 Checkout?

Shift4 Checkout is a suite of online payment integration options. It gives merchants two ways to accept card payments: a fully hosted checkout page they redirect customers to, or secure card fields they embed directly into their own checkout form. Both are backed by the same integration foundation, so merchants can start with one and switch to the other without rebuilding their back-end.

Who is Shift4 Checkout for?

Any merchant accepting card payments online. Checkout Redirect suits teams that want to launch quickly without building a payment UI. Custom Components suit merchants who want full control over their checkout design but need Shift4 to handle PCI-safe card data capture.

What are the two integration paths?

Checkout Redirect: Your customer is redirected to a secure, Shift4-hosted payment page. You create a checkout session on your server and send the customer to the URL in the response. Shift4 handles the UI, authentication, card processing, and payment confirmation.
Custom Components: You build your own checkout form and embed Shift4's card input fields (card number, expiry, CVV) inside it. Your design, your layout — Shift4 secures the card data and processes the payment. To initiate a payment process, you create a checkout session and use it to power your form.

Do I need to rebuild my integration if I switch from Checkout Redirect to Custom Components, or vice versa?

No. Both integration paths use the same back-end call to create a checkout session. Switching is a front-end change only — your server-side code stays the same.

Which payment methods are supported?

Shift4 Checkout supports cards and digital wallets (Apple Pay, Google Pay). Alternative and local methods, such as BLIK in Poland, iDEAL in the Netherlands, and others, may be considered based on business needs. Checkout will automatically surface the most relevant options based on the customer's location and configuration.

I know I have full control over branding in Custom Components, but can I also brand Checkout Redirect?

Yes. In the Customer Hub, you can customize several settings for the hosted payment page: logo, page title and subtitle, background color, button color, font, wallet visibility (enable/disable), and your business's terms and conditions. No redeployment necessary.

What's the difference between integrating via Checkout Session API and using Payment Links?

They serve different use cases. Checkout Redirect and Custom Components are used as elements of the payment flow embedded on your own website — the session is short-lived, and the customer is expected to move directly from your cart into it and complete payment immediately. Payment Links, by contrast, are designed to live independently of any on-site payment flow: a single link can be reused multiple times, and can remain active indefinitely. Payment Links can also be shared directly with customers via email, SMS, or QR code.

How does Shift4 Checkout handle 3D Secure and strong customer authentication?

Automatically. Shift4 Checkout analyzes each transaction and handles any required authentication challenge inline — the 3DS step is presented to the customer directly within the checkout flow without any additional developer logic. SCA and PSD2 compliance requirements are built in.

Does Shift4 Checkout offer any anti-fraud protections?

Yes. As part of the broader Platform4 initiative, Shift4 is building Shift4 Defense — a unified, gateway-agnostic fraud and decisioning service. Shift4 Defense and Shift4 Checkout are two of several components within Platform4, and Shift4 Defense will be fully integrated into Shift4 Checkout, providing merchants with centralized, real-time scoring, dynamic 3DS orchestration, and self-service rule authoring through Customer Hub. While Shift4 Defense is still under development, every merchant is protected by a default set of fraud rules — so protection is in place from day one, but merchants can't yet fine-tune these rules themselves and will need to reach out to support for any adjustments. This will change once Shift4 Defense is ready for merchant-facing use.

What does Shift4 Checkout take off my PCI compliance plate?

Shift4 Checkout is SAQ-A compliant by design. Card numbers, CVV, and expiry data never pass through your servers or code. For Checkout Redirect, Shift4 handles the entire payment page. For Custom Components, the card inputs are isolated components that capture data securely within Shift4's environment — not yours.

Can I add, enable, or disable wallets without redeploying my code?

For Checkout Redirect, yes — enabling a wallet is a configuration change within Customer Hub, and it appears automatically on the checkout page with no code changes or redeployment required. For Custom Components, enabling a wallet requires a small amount of frontend code. Additionally, enabling Apple Pay requires registering your domain. In both integration paths, you can enable both wallets or only one, depending on your preference.

Are there other integration options coming for Shift4 Checkout?

Yes. Shift4 Checkout is expanding to include additional integration paths. These will give merchants more flexibility in how they present the payment experience without requiring a full page redirect. These integration paths are on the roadmap and are not yet available for release. Contact your Shift4 representative for the latest on timing.

Internal Only:

Internal-Facing FAQs

Who stands behind it?

Shift4 Checkout is currently developed by the Digital Experience team (led by Marcin Jancewicz under Tim Goodwin). The core engine was originally built by the Matterhorn team and has proven to be a reliable solution for years. Whichever integration a merchant chooses today, they are plugging into that same reliable foundation.

The payment form for Checkout and Payment Links looks identical, yet they're presented as two separate products. Is there actually a difference between them?

Not really — under the hood, they're the same product. Payment Links is built as a layer on top of Checkout, reusing the same underlying engine and payment form rather than duplicating it. So when a merchant uses Payment Links, they're effectively using Checkout under a different name and workflow. The distinction lies in how each is meant to be used: Checkout is designed to be embedded into a merchant's broader purchase flow on their own website, while Payment Links offers additional standalone functionality on top — clean, shareable URLs, scheduling, expiration, and delivery via e-mail, SMS, or QR code.

Who is the target customer for this release?

eCommerce and digitally-active merchants processing online payments through Shift4 — specifically those currently on legacy checkout tooling (i4go, HPP) and those building net-new online integrations on the Shift4 REST API. The two integration paths serve distinct profiles: Checkout Redirect for teams optimizing for speed to market with minimal development overhead; Custom Components for teams that need design control with low PCI scope and a path to migrate off legacy products.

What is in scope for this release?

Launching the shift4.js library as the standard REST API-based browser payment component suite
Checkout Redirect: redirect-based integration backed by the CheckoutSession API
Custom Components: individual card inputs (card number, expiry, CVV) embeddable in any merchant-built form
Integration and Developer experience via a new documentation on docs.shift4.com (Work in Progress)

What are the key integration components?

Component	Role
CheckoutSession API (POST https://api.shift4.com/api/rest/v1/checkoutsessions/create)	Unified backend — single call that initializes all frontend integration paths
shift4.js (https://js.shift4.com/v1/shift4.js)	Frontend SDK — delivers Custom Components and other embedded components
Checkout Redirect	Shift4-hosted payment page; redirect-based; no JS SDK required on the merchant side
Custom Components	Individual PCI-safe card input fields (card number, expiry, CVV) embedded into the merchant's own form via shift4.js

What is out of scope for this release?

Payment Links and Invoice products (separate integration paths within the broader Checkout suite; not in scope here)
Checkout Component (the full embedded drop-in form, including order summary and pay button)
Checkout Modal (payment page that covers the merchant’s website without redirection)
Payment Component (Seamless integration into custom checkout flows where the merchant wants control over the layout but offloads the complexity of payment logic (card + APMs)
InstantPay Component (wallet-first fast-track)
Server-to-server raw API integrations (merchants handling raw card data directly — high PCI compliance requirement; treated as a separate use case)
Gateway routing decisions below the Checkout layer (handled by Platform4)
In-person and POS payment flows

How does Shift4 Checkout relate to Platform4?

The Shift4 Checkout Charter is explicitly scoped as part of Platform4. The Checkout Session API is the eCommerce entry point to Platform4's routing layer. Transactions initiated via Checkout route through Platform4 to the appropriate gateway — GW2 is the preferred path, with links to GW1 for US processing, GW3 for EU, and TPII for APAC.

What are the key success metrics?

Metric	Description
Sale/Authorization approval rate	% of payment attempts that result in a successful authorization, benchmarked against the legacy product baseline for the same merchant segments and regions.
Adoption Rate (30 / 60 / 90 Days Post GA)	% of merchants in supported regions using the new Checkout (shift4.js + Checkout Session API) as their active integration, measured against the total addressable merchant base in those same regions who are currently live on legacy products.
Time to First Live Payment (TTFLP)	Elapsed time from a merchant's first API credential issuance (AccessToken creation) to their first successful live transaction through the new Checkout.

Are there other integration paths planned beyond Checkout Redirect and Hosted Fields?

Yes. The broader Shift4 Checkout suite includes additional integration paths on the roadmap — Checkout Component (a full embedded drop-in form), InstantPay Component (a super easy wallet integration), and Checkout Modal. These are under development and not yet ready for release. Commercial teams should set merchant expectations accordingly and direct timeline questions to the product team.

What's the status of Invoices going forward?

Invoices were paused in Customer Hub due to low adoption. It's worth noting that Invoices was never a standalone product — like Payment Links, it was surfaced from the underlying Shift4 Checkout engine. The capability itself hasn't gone away: it's still available and surfaced through Matterhorn, where it was recently enabled for a pilot merchant: SpaceX Events. We'll revisit the go-to-market approach for Invoices once we have a better understanding of merchant needs and use cases.

Is integration documentation publicly available, and what support is available for early integrators?

Documentation is currently in development and is not yet publicly available. It will follow the same goal-oriented approach as the official Payment Links documentation — with extensive examples and tutorials: Payment Links. Merchants integrating during this early phase should expect a white glove experience — the Shift4 team will work directly with them to guide the integration. Commercial teams should flag early adoption opportunities to the product team to ensure appropriate support is in place. For questions, contact the Payments Product team.

What else is on the roadmap for Shift4 Checkout?

Selected Roadmap items:

PayPal support (Q3). Checkout redirect and Payment Link support through the GW2 connector.
Checkout Component (drop-in) (Q3). A full-featured checkout experience inside the merchant's site with minimal code.
MC & Visa Click to Pay (Q3).
Payment Component (drop-in). Seamless integration into custom checkout flows where the merchant wants control over the layout but offloads the complexity of payment logic (card + APMs)
InstantPay Component (drop-in). Reducing friction at the top of the funnel by prioritizing digital wallets
Redirect APM support
Checkout Custom Domains. Merchants can use their domain for Payment Links, e.g., pay.nike.com instead of pay.shift4.com

What Can We Help You With?