Design checkout before connecting payments

Ask the builder for a checkout and it creates a dedicated mock checkout instead of an enquiry form or calendar. Until a provider offer is selected, it shows an order summary and sample customer/card details. Unknown prices stay unpriced. Preview checkout simulates completion in the editor only; it takes no payment, places no order and grants no member access. On a published page, unconfigured checkout is disabled. Connect a provider and choose an offer in Commerce to replace the mock with the real checkout. Payment-triggered funnels still require configured, verified payments before publishing.

Connect your provider

Open Site Dashboard → Commerce. Owners and admins can connect or disconnect site-owned accounts. Products, prices, orders, refunds and fulfillment remain in your provider. Credentials are encrypted server-side and never returned. Select Connect and approve access on the provider’s hosted screen. Shopify first asks for your myshopify.com store domain; Whop may ask you to choose an authorized business. No merchant API keys are entered in the dashboard. If account connections are being set up, the platform administrator must configure the Client Ascension provider app. Publish Shopify products to the connected app’s storefront.

Pick and place an offer

Browse offers and select an existing Stripe price, Whop variant (plan_) or Shopify product variant. Choose a built page, a unique CSS selector for the mount or existing CTA, button label, and return page. Missing mounts create a purchase section at the end of main content. Save creates an immutable draft; publish separately. Normal websites and funnels both support placements. Checkout preview uses sample details and an optional simulated completion; it never creates payment sessions.

Stripe and Whop support hosted buttons or embedded checkout. Shopify uses its own hosted checkout and order confirmation; configure a return link in Shopify if needed. Catalog requests are bounded and paginated; Shopify lists up to 50 variants per product. Existing offer IDs can also be placed through the API.

Verify purchases

Hosted connections register Whop and Shopify webhooks automatically; the platform configures the shared Stripe Connect webhook. Stripe: checkout.session.completed and checkout.session.async_payment_succeeded. Whop: payment.succeeded. Shopify: orders/paid. The endpoint verifies the raw signed payload, provider account, signed site/placement reference and selected offer. Duplicate payment events are ignored. A page view or browser callback never counts as payment. Select a matching payment-trigger funnel step to include purchases in its conversion metrics. Embedded Stripe/Whop returns wait for recorded confirmation before advancing; delayed confirmation can require refreshing.

Provider app activation, domain approval for wallets and a provider test transaction must be completed before accepting payments. BuildASite does not create provider products or alter pricing. Commerce checkout is limited to 30 attempts per visitor per site per hour; ordinary traffic and other visitors are independent.

Use your agent

Read get_commerce. For hosted account connections, open the Commerce dashboard and let the user approve provider access. configure_commerce retains a legacy write-only credential path for explicitly authorized integrations; it cannot forge OAuth connections. Use list_commerce_offers with provider and optional cursor, then save_commerce with current revisionId and the complete placements array. Each placement includes id, provider, offerId, name, route, selector, mode, label, returnPath and optional stepId. Only Shopify button mode is supported. Keep a neutral data-commerce mount in generated source; the platform renders checkout. disconnect_commerce disables the connection. Publishing still requires explicit approval.