Configure your store
Create the products, payment setup and website connection before wiring the frontend.
Add the explicit integration
Place the stylesheets and runtime in your framework’s document/application shell using the supported HTML or script mechanism. Adapt syntax for JSX.
<link rel="stylesheet" id="pc-cloak" href="https://embed.pennicart.io/v1/cloak.css">
<link rel="stylesheet" href="https://embed.pennicart.io/v1/sdk.css">
<script src="https://embed.pennicart.io/v1/runtime.js" data-store="YOUR_STORE_ID" async></script>Verify route behavior
Use the current documentation for lifecycle handling. Check direct visits and client-side navigation without duplicate scripts.
Separate the website from commerce configuration
Your Next.js app controls the presentation and navigation. Penni Cart supplies the connected commerce runtime and store configuration. Start with a single complete purchase flow rather than trying to replace your entire application at once. This is an embedded-commerce integration, not a claim that every component or router behavior is automatically handled.
Use the explicit runtime setup
The plain HTML loader uses document.write, so it is not the correct choice for framework-managed rendering. Use the explicit cloak stylesheet, SDK stylesheet and async runtime script shown below. Include the configuration once in your application shell and keep YOUR_STORE_ID consistent with the store you are testing.
Treat navigation as part of the integration
Client-side route changes can introduce new product elements without a full document reload. Follow the current integration documentation for runtime lifecycle behavior instead of repeatedly injecting scripts. Test entering a product page directly, navigating to it from another route and returning after checkout. Avoid guessing initialization APIs or duplicating the runtime.
Keep payment and secret handling safe
The runtime runs in the browser. Your store identifier belongs in the install configuration; payment-provider secret keys do not. Never place server credentials in a public environment variable or bundled client component.
Use the supported provider payment interface rather than collecting card numbers in your own inputs. Validate a payment failure, a successful order and a route transition on your deployed staging site.