Hosted checkout

Hosted checkout is what most merchants use, because it's the path that takes the least integration work. You create a payment session from your server, redirect the customer to session.checkoutUrl, and Strimz handles everything from there: wallet connect, signature collection, on-chain broadcast, redirect-on-success.

You don't write any front-end code. You don't think about wagmi configs or which wallet supports EIP-3009 or what to do if the user's wallet is on the wrong chain. The page is updated when we update; you get the improvements automatically.

What the customer sees

They click your "Pay" link and land on https://checkout.strimz.finance/pay/cmq4wck6a0002je6lfmb5bgjp. The page renders:

• Your logo and business name (from your merchant profile).
• The amount, prominently. 10.00 USDC, not 10000000.
• The session description.
• A Connect wallet button.

They tap Connect wallet and our Reown AppKit modal shows the wallet options. Once connected, they enter an email for the receipt and pay. The wallet shows two signature prompts: an EIP-3009 ReceiveWithAuthorization for the token, with the recipient, amount and deadline, and the Strimz PayIntent. Neither is a transaction, and the payer pays no gas.

After they sign, the page shows a confirming state and watches the session status. As soon as the indexer records the on-chain settlement, the page shows a confirmation and, if you set a successUrl, sends the payer there after a few seconds.

What you can customize

The customizations live on your merchant profile, not on the session. Configure them once and they apply to every session.

Business name in Settings → Business. Shows next to the logo. Maximum 120 characters.

Logo in Settings → Business. Upload a square image. Without one, checkout shows a blockie of your wallet address or the first letter of your name.

Brand colour and whitelabel are not available today. See Branding.

Per session, you set:

description is the line under the amount. Keep it short: "Pro plan. Monthly", "Invoice #4012", "Annual subscription".

customer.email records the customer's email on the session if you already have it (most invoice flows do). Checkout still asks the payer for a receipt email.

metadata is opaque key-value pairs. We store it, we return it on the session, we include it in webhook events. We never display it to the payer.

What you can't customize

The Strimz contract address. The payer sees it in the typed-data prompt; it's part of the EIP-712 domain. Changing it would invalidate the signature.

The signing prompt itself. Different wallets render EIP-712 differently. MetaMask shows it one way, Phantom another, Rabby with its custom security review pane. Strimz has no control over that surface; it's wallet software's job. The fields in the prompt are what we put in the signed envelope, but the layout is the wallet's.

The page layout. The form factor is fixed. Header, description, amount, action button, footer. We don't expose a layout configuration because letting people move pieces around invariably leads to "where's the amount" support tickets.

If you need full control of the layout, you want embedded checkout instead. That gives you the SDK + the typed-data builder; you write the UI. The trade-off is you maintain it yourself.

One wallet per checkout

The first wallet that connects and gives an email owns the session. The same wallet can come back to it as often as it likes; another wallet gets 409 payer_already_bound, and the page tells the payer to reconnect the first wallet or ask you for a new link. A session that is confirmed, cancelled, or past its expiry answers 409 session_not_open, and an archived plan answers 409 plan_not_active on its subscription page.

The email on a customer you already know is never replaced from checkout. A payer can add an email to a customer that has none; changing a known one goes through Strimz support for now.

When hosted vs embedded

Hosted is the right default for almost every flow. You ship faster; the page improves without you doing anything; you don't own the surface that's most likely to break.

Embedded makes sense when:

• The checkout lives inside a multi-step flow you don't want to break with a redirect.
• Your app uses Privy embedded wallets and you want the payer to use those (Privy's embedded wallet works with Strimz, but hosted checkout doesn't know about it because it's per-merchant authentication).

For most B2B SaaS, hosted is what you ship first and stay on.