Skip to main content
View as Markdown

Web Checkout

Embed Inttegro Checkout in a website or web application without building a payment form. Start with the JavaScript loader, or use the adapter designed for your frontend framework.

Choose your web integration

Use the JavaScript loader directly or choose the component that matches your frontend framework. Every adapter loads the same Inttegro-hosted checkout experience.

Inttegro with Inertia

Pass a client-safe Order ID through page props and use the adapter for your React, Vue, or Svelte frontend.

Choose an integration

Use @inttegro/js in a browser application without a supported framework. For React, Vue, Svelte, or Angular, use the corresponding adapter: it follows that framework's component lifecycle while preserving the same Checkout API and customer experience.

Inertia does not need a separate Inttegro package. Choose the React, Vue, or Svelte adapter that matches your Inertia frontend.

Choose the Checkout reference

Checkout starts from exactly one client-safe reference.

For a normal purchase, your backend owns credentials, pricing, and every authoritative change to the Order. It should:

  1. Create an order with the amount and commercial details your application has approved.
  2. Finalize the order before showing Checkout.
  3. Return only the client-safe Order ID needed to start payment collection.

Treat the Order ID as a payment capability. It cannot be used to change the Order through Checkout, but anyone who obtains it can attempt to pay. Avoid placing it in analytics, error reports, or public logs.

If you already have a Purchase Intent, do not create an Order first. Pass its public sale_... ID to Checkout as purchaseIntentId. Checkout renders the full Buy experience for that offer. It collects any required customer details, quantity, variant, or customer-selected amount, then creates the finalized Order when the buyer continues.

Choose a presentation

Every integration renders the same Inttegro-hosted payment experience. The presentation choice changes the space around Checkout—not the Order, payment flow, feature flags, or lifecycle events.

Use embedded Checkout when payment is a visible part of the page: a checkout step, invoice sidebar, or dedicated payment route. Your application provides a container, controls its placement and width, and keeps it mounted while payment or provider confirmation is in progress.

With @inttegro/js, pass that container to checkout.mount(target). Framework adapters mount their Checkout component in the same way. Start with the JavaScript integration or choose the React, Vue, Svelte, or Angular guide below for complete code.

Framework adapters do not recreate the form or bundle another payment runtime. They manage loading, supported updates, lifecycle events, and cleanup using the conventions of their framework.

See both presentations

The Express live demo uses @inttegro/js directly. Framework-native examples pair Next.js with React, Nuxt with Vue, NestJS with Svelte, and FastAPI with Angular. The demos use finalized Orders and offer embedded, modal, and hosted-page presentation. An existing Purchase Intent uses the same components with purchaseIntentId instead of orderId. Each modal is an application-owned dialog containing the official Checkout component or controller.

Express desktop embedded Checkout
Afterglow Sessions Express ticket page with Inttegro Checkout embedded beside the reservation details. Shown without a previously attached payment method.
Embedded. The checkout is mounted within Express’s server-rendered ticket experience. Shown without a previously attached payment method.
Express desktop modal Checkout
Afterglow Sessions Express ticket page dimmed behind an Inttegro Checkout modal. Shown with an attached payment method.
Modal. Checkout opens above the event page and can close without a full-page navigation. Shown with an attached payment method.

Select any image to view it full screen.

Keep the host application informed

Privacy-safe lifecycle events report when Checkout is ready, customer input changes, a payment attempt begins, more customer action is required, an attempt fails, or the flow completes. Forward these signals to your existing telemetry so navigation and route changes do not hide what happened inside Checkout.

The completed event is a customer-interface signal, not fulfillment authority. Before releasing goods, granting access, or marking a local record as paid, have your backend look up the order. For an in-progress payment, use a short bounded polling window and show a pending state if the Order has not reached a terminal state.