Skip to main content

Inttegro with Inertia

Inertia applications use the Inttegro adapter for their frontend renderer. There is no separate Inertia package: React applications use @inttegro/react, Vue applications use @inttegro/vue, and Svelte applications use @inttegro/svelte.

Developer preview

The web packages and hosted runtime are not yet available for live payments. Use this guide to plan the server-to-page boundary before release.

Prerequisites

  • An Inertia application using React, Vue, or Svelte
  • The corresponding Inttegro adapter installed with npm, Yarn, Bun, or Deno
  • A backend that creates and finalizes an Inttegro Order

Choose the renderer adapter

Inertia frontendInttegro packageInstallation and usage
React@inttegro/reactReact guide
Vue@inttegro/vueVue guide
Svelte@inttegro/svelteSvelte guide

The adapter already depends on @inttegro/js. Inttegro does not publish a separate Inertia package.

Pass the Order ID as a page prop

Create and finalize the Order in the server-side controller or action that prepares the Inertia response. Return only the client-safe Order ID needed by the page. Do not include your secret API key, payment method data, or unnecessary customer details in page props.

Whichever server adapter you use, expose the same small page-prop contract:

export interface CheckoutPageProps {
  orderId: string
}

Then pass orderId to the Checkout component for your renderer. A React page, for example, needs no Inertia-specific Inttegro API:

import { router } from '@inertiajs/react'
import { Checkout } from '@inttegro/react'

interface CheckoutPageProps {
  orderId: string
}

export default function CheckoutPage({ orderId }: CheckoutPageProps) {
  return (
    <Checkout
      orderId={orderId}
      onCompleted={() => router.visit('/payment-status')}
    />
  )
}

Vue and Svelte pages pass the same prop to Checkout using the conventions in their framework guides.

Handle navigation and payment state

When the page component unmounts during an Inertia visit, the framework adapter destroys its Checkout instance and removes its subscription. If Checkout lives inside a persistent layout, remove it when payment collection ends rather than leaving a completed instance mounted across unrelated pages.

Changing the orderId prop creates a fresh Checkout instance. Keep the Order ID in server-provided page props instead of preserving a stale value in local component state.

Use the completed callback to visit a payment-status route or update the interface. That callback does not authorize fulfillment. The status route should have your backend look up the Order and act on the current server-side state.