One-Step Checkout

Paid pluginsize Mplanned, not built

Indicative price, not an offer: EUR 150-250/year or EUR 350 one-off

Generated from docs/plan/paid/one-step-checkout/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

One-Step Checkout consolidates shipping, billing, payment, and review into a single optimized page with progressive disclosure and client-side validation, reducing abandonment and increasing conversion rates.

The problem

Cart abandonment spikes when checkout requires three pages of form-filling. Merchants lose sales to friction. Competitors offer single-page checkout; AstroBaaS checkout is functional but multi-step.

What it does

• Consolidates shipping address, billing address, payment method, and order review into a single checkout page
• Client-side form validation with real-time error feedback and field-level hints
• Progressive disclosure: show only relevant fields based on shipping method selection
• Same-as-shipping checkbox to hide billing fields until explicitly unchecked
• Guest checkout option with optional account creation post-purchase
• Address autocomplete integration (via merchant-provided Google Places or Smarty key)
• Coupon code application in-page with immediate discount calculation and total update
• Order summary sidebar with real-time totals as items, shipping, or coupons change
• Stored payment method display for returning customers; new card option always present
• Mobile-optimized single-column layout; desktop 2-column (form + sidebar)
• Express payment button hooks (Apple Pay, Google Pay) with conditional rendering
• Estimated shipping time display based on selected method
• Pre-checkout inventory check to prevent stock-out during payment processing

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Address validation service (merchants must provide their own Google Places or Smarty key; feature has the integration hook, not the vendor contract). Reason: Address validation is geography-specific; no single service covers all regions.
• Shipping rate calculation (core shipping engine already exists; paid feature only reflows the form). Reason: Shipping logic is merchant-configured; feature applies it, does not create it.
• Payment processing or PCI liability (core tokenization adapter handles card capture; paid feature only optimizes the form flow). Reason: Payment liability cannot move into a paid pack; core owns the boundary.
• Tax calculation (feature applies core tax engine; does not add new tax logic). Reason: Tax is a compliance obligation, not an optimization.
• Multi-currency switching at checkout (core freezes currency at checkout start; paid feature respects that). Reason: Per-item currency switching breaks accounting; not supported.
• Subscription or recurring order checkout (separate scope; one-step is for standard one-time orders only). Reason: Subscriptions have billing cycle and prorating logic; belongs in a dedicated feature.
• Installment payment plans (no ‘buy now, pay later’ integration). Reason: Installments add liability and require per-country compliance; belongs in a separate paid feature.

Data model

None. The core order schema, cart state, and checkout flow already exist. This feature is pure frontend state choreography and UX reflow. No schema migration needed.

API

• POST /api/checkout/validate-address — client-side address validation (calls merchant’s geocoder service)
• POST /api/checkout/estimate-shipping — returns available methods, costs, and ETA for cart + address
• POST /api/checkout/apply-coupon — applies coupon in-page, returns new order totals
• POST /api/checkout/init-payment — begins payment flow with method selection
• POST /api/checkout/confirm-order — atomic order creation + payment capture
• GET /api/checkout/methods — returns available shipping and payment methods for current cart

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

New ‘One-Step Checkout’ settings card in storefront configuration. Merchant can: toggle feature on/off with fallback to multi-page, reorder address/payment/review blocks via drag-drop, set progressive disclosure rules (e.g., ‘show express shipping only if cart > EUR 50’), toggle express payment buttons (Apple Pay, Google Pay), paste address autocomplete API key or toggle off, set coupon visibility threshold, and preview the mobile/desktop layout. A/B test toggle to compare single-page vs multi-page conversion (metrics stored in audit log for reference, not automated decision-making).

The seam — why this is paid

Core owns: order creation atomicity, payment tokenization, PCI compliance, shipping/tax/coupon calculation logic, and the existing POST /checkout endpoint. Paid pack owns: the single-page UI/UX, address autocomplete integration hook, progressive disclosure rules, express payment styling, client-side state choreography, and re-sequencing of existing API calls. The boundary is clean: core’s endpoints are not modified; paid feature is a pure frontend wrapper that calls core’s existing endpoints in a different order and with a different presentation.

Paid conversion feature, not compliance. Core checkout is functional; single-page optimization is a business model choice that increases AOV.

Dependencies

• Core checkout flow (must already exist)
• Core shipping rate engine (must already exist)
• Core coupon/discount logic (must already exist)
• Core payment adapter + tokenization (must already exist)
• Assumption: merchants provide own address geocoder credentials (Google Places, Smarty, SmartyStreets, or similar)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• A guest user can complete an order in a single checkout page without creating an account
• Same-as-shipping checkbox hides all billing address fields; unchecking it shows them again
• Coupon code application in-page updates order total and removes tax/shipping recalculation from server round-trip
• Address autocomplete suggestions appear when typing into address field; selecting one pre-fills city/state/zip without page reload
• Out-of-stock product added to cart before checkout is flagged on page load; checkout is blocked with an error message
• Express payment button (Apple Pay) appears only on Safari/iOS and only if merchant has enabled and configured it
• Order confirmation email is sent with identical data whether order was placed via one-step or multi-page fallback checkout
• Shipping method selection updates estimated time and cost in the sidebar in real-time without server call
• Mobile viewport (< 768px) renders single-column layout; desktop (> 1024px) renders two-column (form left, summary sidebar right)
• Disabling the feature in settings reverts all new users to multi-page checkout; existing in-progress checkouts are not affected

Risks

Address autocomplete service outage (Google Places down) breaks checkout flow unless graceful fallback to manual entry exists. Double-submission: user clicks ‘confirm’ twice in quick succession, creating two orders; must disable button on first click and make order endpoint idempotent. Stock race condition: inventory shown in stock at page load but sold out by confirmation time; must re-check inventory on final POST /checkout/confirm-order before order creation. PCI scope drift: adding form fields that capture unencrypted card data outside the tokenization iframe; every field must be validated to NOT contain PAN/CVV in frontend state. Coupon validity changes between application and order creation (code expires, limits reached, code stolen); must revalidate on final POST and reject with reason.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.