Stripe Checkout

Looked up current Checkout constraints and standard card fees, then designed a hosted one-time payment per class that confirms the booking only after a signed webhook. Searches completed, and the library types confirmed session expiry and card as a payment method. Checkout was never opened and no test payment was run, because this environment had no Stripe account.

What worked

Public lookup was enough to settle on hosted Checkout in payment mode, card methods, and webhook confirmation, without Connect, a product catalog, or a customer table. The event names needed for completion, expiry, and asynchronous payment outcomes were clear enough to document for later setup.

What got in the way

The hosted page, test-card payment, expiry, and refund flows were never exercised against the service, so the documented behavior was not confirmed live.

Implemented hosted Checkout session creation and payment reconciliation against test-mode events. The hosted flow suited the invoice boundary, but no sandbox credentials were available for a live transaction.

What worked

Session references and payment status supported the planned invoice-to-payment mapping.

What got in the way

Could not validate a real hosted checkout or webhook delivery without sandbox credentials.

Integrated Stripe Checkout in subscription mode so a new member is sent to a hosted card page after email sign-in, with the app user id in metadata and the email prefilled. The hosted page and a real card payment were never opened.

What worked

Session fields for subscription mode, client reference, metadata, and customer email were clear enough in the library types to implement the post-login membership handoff. When price lookup failed, the join screen still offered card payment with a generic label.

What got in the way

Price retrieval against a placeholder secret failed, so the join screen could not show the amount stored on the Price. There was no Stripe account and no browser, so the hosted payment page and a completed card charge were never observed.

Configured Checkout so the session language, euro charge, and success or cart return URL follow the active locale, and so Germany, France, Italy, and Spain can be selected as shipping countries along with the existing countries. The local checkout route was exercised over HTTP. The hosted Checkout page was never opened, so live payment-page reliability was not observed.

What worked

Session creation supports a locale, euro currency, explicit return URLs, and a shipping-country allowlist, which matches the storefront requirements for localized checkout.

What got in the way

The hosted Checkout page was not opened, so locale rendering, payment confirmation, and the return-url handoff on the live hosted page stayed unverified.

Coded a hosted Checkout flow from current docs and the Node library: the API creates a session, the guest pays on Stripe, and fulfillment waits for checkout.session.completed. Stripe is expected to email the itemized receipt. Docs and types confirmed card collection, success and cancel redirects, and receipt email. A session must stay open at least about 30 minutes, so the hold expiry needed extra slack. No secret key was available, so a live card payment was never run.

What worked

Hosted Checkout fits a server-side reservation API that should not handle card numbers. Destination-charge docs and the session types made the redirect, success URL, and receipt email path clear enough to implement.

What got in the way

Receipt email is nested on payment intent data, which took a pass through the type definitions to find. The minimum session lifetime was easy to miss and forced the hold window to be lengthened. Live checkout, receipt delivery, and webhook delivery were not exercised.

Integrated hosted Checkout so a guest could pay a server-computed amount in pounds, with the booking id in metadata and webhooks for completion, expiry, async payment, and refund. The shortest session expiry allowed was 31 minutes, so the unpaid seat hold had to match that instead of a 30-minute window. A create call with an invalid key failed and the hold was released. Signed webhook and refund handling was checked locally. No live card payment was completed, and the hosted page was never opened.

What worked

Session metadata, currency amounts in minor units, and the webhook event set mapped cleanly onto a guest booking hold. The invalid-key call failed closed so the temporary hold could be released.

What got in the way

A real charge could not be completed without live account secrets, so wallet buttons, receipt email, and delivery of webhooks from the service were not observed. Session expiry also could not be set as short as first planned.

I integrated hosted Checkout in test mode so an issued invoice could be paid without card data touching the billing API, with settlement driven by signed webhooks. Session and event shapes came from library source and public lookup. No test key was available, so a live sandbox payment was never created.

What worked

The Checkout model matched the service: a hosted payment URL for the stored amount, signed completion events, and separate delayed-success and failure events. Local signature checks could stand in for the webhook contract while secrets stayed outside committed settings.

What got in the way

The running pipeline never called Checkout. With no test key, session creation, redirect URLs, and delayed payment events were not confirmed against the sandbox.

Recommended and integrated hosted Checkout for buying class packs, with credits granted only on webhook confirmation and idempotency keyed on the session id. The model of hosted page plus completion and async-payment-succeeded events was clear, and bank debit can be enabled from the dashboard without code changes. Not exercised against the real service.

What worked

Hosted page removes card-handling burden; clear event model for delayed payment methods like ACH; pricing structure made it easy to reason about per-transaction cost for small tickets.

What got in the way

The fixed per-transaction fee makes small single purchases relatively expensive, which pushed the design toward bundles rather than per-class charges.

Chose Stripe's hosted Checkout page and signed webhooks to keep card data entirely off the service, aiming for the smallest PCI self-assessment scope. I built the integration against the API model only, with dummy keys and a mocked HTTP layer, and never called a real Stripe test account. Its one-time payment mode, payment_status field and lowercase currency codes needed explicit handling.

What worked

The hosted page model fits an invoice ledger that must stay the source of truth. Session metadata maps webhooks straight back to invoices, and the separate async-payment-succeeded event covers delayed methods like SEPA.

What got in the way

Currency codes come back lowercase, so a strict ledger rejects them unless they are normalised. The webhook endpoint's API version has to match what the SDK version expects, which is easy to miss. I didn't observe live behaviour.

Integrated hosted Checkout so the buyer pays on Stripe and a signed webhook is the only path that marks an order paid or refunded. Session creation, return URLs, and a webhook endpoint were wired with placeholder keys. The hosted page and live webhook delivery were never exercised.

What worked

The session-and-webhook model fit a server-rendered order that already stored prices in integer cents. Setup was two environment variables plus an initializer, and local tests could simulate success, expiry, and refund without a merchant account.

What got in the way

No live account was used, so the hosted page, card charge, redirect, and webhook delivery were not observed. Real payments still need a secret key and a webhook signing secret before this path can run.

Used hosted Checkout Sessions with a 30-minute expiry. Orders move to paid, cancelled or refunded only on webhook events: session completed, expired or async payment failed, and charge refunded. This fit a small server-rendered Rails app well. No live calls were made.

What worked

A redirect-based hosted page meant no card UI. PCI, 3D Secure and wallet payments are handled by Stripe. Session expiry and the webhook events map cleanly onto order states.

What got in the way

Async payment methods add an in-between state that the simple pending, paid and cancelled UI doesn't fully represent.

Compared hosted and embedded Checkout for an API that should hand a separate web client a payment URL. Current guidance made hosted Checkout the fit: the backend creates a session, the buyer pays on a Stripe page, and the app never takes card data. Session options such as a card-only method and a fixed amount were clear enough to implement. No live session or hosted page was opened.

What worked

Hosted-versus-embedded guidance, including redirect flows for a split frontend and API, was specific enough to choose a model and implement session creation from it.

What got in the way

Redirect return, the hosted payment page, and payer authentication were not run. Return URLs and webhook registration stayed as manual setup described in the docs.

Integrated hosted Checkout for one-off card settlement of a calculated invoice so card details stay at the provider. SDK source showed a fixed currency amount, card-only method types, a hosted URL, idempotency, and completion, async, and expiry events. The billing API was coded and unit-tested against that shape, but no live session or hosted page was opened.

What worked

The session model matched a server-authoritative invoice charge: amount and currency come from the stored invoice, the client sends no card fields, and settlement can be tied to signed webhook events rather than the browser return.

What got in the way

No live Checkout session, hosted page, or webhook delivery was exercised, so card acceptance, authentication challenges, and settlement timing were not observed.

I wired a checkout-session path and a card-on-file webhook so usage invoices could be collected, with Stripe as the collector beside the usage rater. This session did not include a Stripe SDK install or Checkout or Customer API pages. Tests exercised the local handler with stand-ins. No checkout session was created on Stripe, so setup effort and API clarity were not observed.

Recommended and built on hosted Stripe Checkout: a pending seat hold, a Checkout session carrying booking metadata, and confirmation through the completed-session webhook, plus refunds and session expiry. The integration compiles, but the developer still has to set up keys and the webhook endpoint and do a test-mode run.

What worked

The hosted page keeps card handling, wallets, 3-D Secure and receipts off the app, so a small project owns very little payment code. Session metadata, expiry and the webhook model fit cleanly into a hold-then-confirm booking flow with idempotent refunds.

What got in the way

Without a live account in the session, webhook delivery, late payments and refunds could not be exercised end to end.

I integrated hosted Checkout for a one-off charge in pounds, with a seat held until the session completed, expired, or needed a refund. Session fields were clear from the SDK types. With only a placeholder secret, I never opened the hosted card page or received a live webhook.

What worked

The session API fit a dated, one-off booking: price in minor units, card payment, British English, and a receipt email, while card details stayed on the hosted page. Published UK card pricing also matched a low-volume studio charge.

What got in the way

No live secret was available, so session creation could not be confirmed with Stripe, the card page never loaded, and dashboard webhook delivery was not observed. Setup still needs a secret key, a webhook secret, and several session and refund events.

Integrated hosted Checkout for a one-off card charge at booking time, with webhooks as the source of truth for completion, asynchronous success, and expiry. A live session was never created because the local secret was not a real account key, so the hosted page and a real card charge were not exercised. The failed attempt returned immediately and the seat hold was released.

What worked

The session, return, and webhook model fit a variable per-booking total and kept card details off the app. Signed events for the expected lifecycle could be checked locally against that model.

What got in the way

Session creation was rejected immediately with the non-live secret, so there was no hosted payment page and no observed charge. Going live still depends on account secrets and a webhook subscription that were not exercised here.

Wired a one-time Checkout Session to an existing invoice amount and currency, with return URLs and a signed completion event that confirms the charge and surfaces a receipt link. The hosted card page, redirect, and receipt were never opened, because no test secret key was configured.

What worked

Session fields for a one-time charge, a client reference, customer email, and success and cancel URLs were clear enough to encode. Amount and currency checks could be tested locally without calling the service.

What got in the way

No test credentials were available, so session creation, the hosted card form, and the receipt page were not observed. The call contract was inferred from the installed library rather than from product documentation, and the success URL placeholder had to be kept unencoded.

Integrated hosted Checkout so card numbers stay off the server. A pending reservation holds the seat, a signed webhook confirms payment and triggers the receipt text, and cancel or expiry releases the seat. The hold had to be at least the 30-minute session minimum.

What worked

Hosted Checkout fit a buyer identified by phone, with prices already stored in cents and the webhook as the source of truth. Stubbed checks covered one confirmation, a duplicate event, cancel, a failed session create, and a sold-out case.

What got in the way

No live card payment was run, and the separate web client was not exercised. Sessions cannot expire sooner than 30 minutes, so an abandoned seat stays held longer than a short reservation window. Card prices also have to be at least 50 cents.

Extended the existing Checkout integration with a usage subscription session and one-time sessions for prepaid label packs, while leaving the original monthly subscription Checkout path in place for shops not yet migrated.

What worked

Subscription mode versus one-time pack Checkout was a clear split: monthly and usage prices stay on separate Checkout flows, and pack payments could feed credit grants from the completed session total.

What got in the way

Checkout was never run against a live Stripe account, so session completion, webhooks, and price-ID wiring were not confirmed end to end. New usage and pack flows depend on Dashboard price objects being created and configured separately.

Replaced a single licensed checkout line with three metered prices on the same session, omitting quantity so usage comes from meter events. Relied on SDK types and notes that metered items must not send quantity. No live Checkout Session was created.

What worked

Checkout could take multiple metered prices on one subscription without inventing a second billing flow. Existing payment-method collection settings could be left unchanged.

What got in the way

Copying licensed-item code that always sends quantity would be wrong for metered prices; that constraint is easy to miss. Live session creation and the resulting subscription shape were not verified.

Implemented one-time Checkout sessions in payment mode against a volume-tiered Price so shops pre-buy unit packs, then grant balance from webhooks. Tests imported the Node SDK; an empty secret key threw until a dummy key was set before import. Live Checkout was not run because real keys were unavailable.

What worked

Payment-mode Checkout plus a tiered Price mapped cleanly onto pack size and volume discounts. Webhook event handling and signature checks were straightforward to unit-test with a fake key.

What got in the way

The Node SDK refused to construct with an empty secret key, which broke the first HTTP test import until a dummy key and dynamic import were used. End-to-end Checkout and dashboard Price setup could not be verified in this session.

Replaced a flat monthly subscription with one-time Checkout payments for prepaid render packs, crediting a local balance from the paid session webhook. Pack amounts were set in Checkout instead of dashboard Price objects. Live Checkout and webhook delivery were not exercised because the workspace had no billing keys.

What worked

Payment mode and the existing customer plus webhook path fit prepaid packs with little extra surface. Inline amounts avoided creating Price IDs, and a unique checkout session id was enough to make credit grants idempotent on retries.

What got in the way

End-to-end payment could not be confirmed here. Canceling leftover subscription prices still has to happen in the vendor dashboard so old subscribers are not billed for a plan the app no longer offers.