This page describes how money moves through the DomiDo platform: which provider does what, which flows the platform uses at each phase, how taxes are handled, how fraud is prevented, how payouts to designers work, and how reconciliation closes the loop. DomiDo is built by Avvyland Limited (UK) and sells universal blocks and fasteners only; every construction shown on the platform is a user-generated design. The payment design is shaped by the phased rollout — non-binding interest reservations in Phase A, no-capture pre-orders in Phase A.5, captured payments and fulfilment in Phase B, and a marketplace with designer payouts in the later phases — and the choice of provider, the shape of every flow, and the webhook-driven state machine all follow from that gating model. Two flows are at the heart of the design: the Phase A.5 SetupIntent verification that stores a card without taking money, and the Phase B PaymentIntent capture that converts a verified pre-order into a paid order when the manufacturing batch is cleared to build.
The flow shows how the Phase A.5 pre-order verifies a customer's card without taking funds. The DomiDo backend creates a Stripe SetupIntent (rather than a PaymentIntent), the customer confirms it through Stripe.js, and the asynchronous webhook handler updates the pre-order state. No money moves; the customer's card is stored against their pre-order for the eventual Phase B capture.
The second flow shows the conversion from pre-order to fully captured order. When the manufacturing batch is queued, customers receive a notification with a grace window before their card is charged. The PaymentIntent then captures funds from the previously verified card, and the order transitions to build-ready in the production queue.
Stripe is the single payment processor across every flow because Stripe is the only provider that supports the four DomiDo requirements simultaneously: SetupIntent for zero-charge card verification in Phase A.5, PaymentIntent for physical goods in Phase B, Billing for subscriptions used by AI design credits, and Connect Express for marketplace payouts. Hosted Stripe Checkout reduces Payment Card Industry (PCI) scope to Self-Assessment Questionnaire A (SAQ A), which is the lightest compliance burden available, and the architecture keeps the door open to switch providers through a thin payment-abstraction layer even though the entire launch path runs on Stripe. PayPal and Braintree, Adyen, Square, Mollie, and GoCardless were all evaluated; none offered the same combination of SetupIntent, PaymentIntent, Billing, and Connect with PCI delegation. The same selection logic applies to the subscription side: the subscription provider comparison evaluated Stripe Billing, Recurly, Chargebee, and Paddle, and Stripe Billing remains the chosen option because of the SetupIntent and Connect alignment, the strong webhook ecosystem, and the established team familiarity.
The state diagram traces the four-stage progression. Phase A holds non-binding interest reservations — no card, no charge, no order, the buyer simply expresses interest. Phase A.5 opens gated no-capture pre-orders using Stripe SetupIntent, with a card verified but never charged, and fresh buyer consent required to enter this state. Phase B captures payments using Stripe PaymentIntent against the stored SetupIntent payment method and only then does fulfilment, invoice, and shipment begin. The marketplace stage that follows pays designer royalties through Stripe Connect Express after eligible delivery events and dispute-free periods. Cancellation paths are explicit on every stage: an interest reservation can be cancelled by the user, a pre-order can be cancelled by the buyer before capture, and a captured payment can be refunded through a return or refund.
A SetupIntent verifies a card and stores the payment method without taking any money. An administrator invites a qualified interest reservation to convert into a no-capture pre-order, the buyer reconfirms intent in a fresh consent screen, the platform creates a SetupIntent through Stripe and returns the client secret, and the buyer enters card details through Stripe's hosted Checkout in setup mode. Stripe runs strong customer authentication (SCA) and three-domain-secure (3DS) where required, then returns success and a payment method identifier; the platform persists the no-capture pre-order with the SetupIntent reference, the gate versions, and the cancellation state, and webhook handling records the SetupIntent state durably and idempotently. The flow never creates an order, an invoice, a receipt, a shipment, or a payout, a duplicate webhook cannot duplicate the pre-order, and the buyer can cancel before Phase B conversion.
When Phase B opens for an eligible pre-order, the platform creates a PaymentIntent using the stored payment method. The PaymentIntent is configured for off-session capture against the saved payment method, with three-domain-secure on the original SetupIntent satisfying the strong-customer-authentication requirement, and the capture creates the order, the invoice, the receipt, and the shipment event while the buyer's payment method is charged for the captured amount. Webhook handling records the PaymentIntent state idempotently, duplicate provider events cannot create duplicate orders, failed payments enter the failure-recovery flow, and refunds reverse the capture and update the order state accordingly.
AI design credits are sold as monthly subscriptions through Stripe Billing using hosted Checkout in subscription mode. Tiers, included monthly credit allotments, overage rules, and proration are managed in the platform code rather than in pricing metadata so that the platform can evolve product pricing without a Stripe migration, and the credit-token system stores per-user balances and per-generation deductions while metered billing for AI generations is implemented on top of the credit balance. Free-tier-to-paid conversion uses transparent overage cues and explicit upgrade prompts, and the subscription lifecycle — trial start, trial end, renewal, dunning, cancellation, plan change — is entirely webhook-driven. Trial periods are configurable, renewal handling is webhook-driven, plan change uses Stripe proration with platform overrides for clarity, and dunning (failed-payment recovery) follows a clear retry schedule with email and in-app notifications and an automatic downgrade when retries exhaust.
Designer payouts use Stripe Connect Express. Designers complete a Stripe-hosted onboarding flow that handles identity verification, bank-account capture, and tax residency, so the platform stays in control of pricing, splits, and entitlement while Stripe Connect handles the regulated parts of moving money to the designer. A designer royalty share is applied to each Phase B capture: the platform retains the marketplace commission share and the kit cost share, the designer receives a royalty share aligned with the designer terms, and splits are computed at the time of capture so that refunds and returns can reverse the split cleanly. For physical-goods sales, the designer share is held by the platform until eligible delivery events occur and a dispute-free window passes; this escrow pattern protects both buyer and designer because the designer is paid once the buyer has the working kit, and the platform is not on the hook for goods that never arrive.
Payouts are scheduled in line with the Stripe Connect default schedule for the designer's jurisdiction, and the platform exposes payout history, expected next payout, and per-order entitlement detail to the designer. Tax withholding on royalties depends on the designer's residency and the local rules, with Stripe Connect surfacing the relevant tax forms, using Stripe Connect's tax tools where available and an explicit designer-tax-information process where not; where withholding is required by local tax law, the platform applies the relevant rate and reports it to the designer. Returns and refunds reverse the split symmetrically: the buyer's refund returns the kit-cost share, the platform writes back its commission share, and the designer's royalty share is reversed in line with the designer terms.
The launch market is the United Kingdom and prices are quoted in pounds sterling. As the platform expands to the European Union and the United States, the pricing strategy moves to local-currency pricing using purchasing-power-parity-style adjustments; Stripe's automatic currency conversion is available as a fallback, but local pricing yields a better buyer experience. Beyond cards, local payment methods matter in some markets — bank-debit-style methods in Europe, wallet-based methods in some jurisdictions, and country-specific methods elsewhere — and the architecture is open to enabling local payment methods through Stripe as expansion proceeds. Cross-border optimisation reduces foreign-exchange leakage and dispute rates: the platform routes payments through Stripe's local processors where it can, and uses dynamic three-domain-secure thresholds tuned to local risk profiles.
UK value-added tax (VAT) at the standard rate is applied to digital services and physical goods sold to UK consumers. Avvyland Limited registers for VAT once the threshold is crossed or earlier if optional registration is advantageous, VAT returns are filed quarterly, and Postponed VAT Accounting is used for European Union goods imports to keep the cash-flow effect neutral. Different rules apply to digital services and physical goods — AI design credits and platform subscriptions are digital services while kits are physical goods — so the platform tracks the tax treatment per product line and applies the right rate. Stripe Tax automates the tax calculation across multiple jurisdictions: the platform calls Stripe Tax to compute the rate at the point of checkout, captures the tax amount in the order record, and includes the correct tax breakdown on receipts and invoices.
For European Union consumer sales, the value-added-tax One Stop Shop (OSS) scheme provides a single registration for cross-border digital services and distance sales, and the platform uses OSS once European Union sales begin. For United States sales, state sales tax is calculated at checkout per state nexus rules with Stripe Tax handling the heavy lifting; the platform tracks nexus, registers in states where the threshold is exceeded, and remits accordingly. Tax invoices are generated automatically with the required fields per jurisdiction — invoice number, date, supplier identification, buyer identification where required for business-to-business, the breakdown of net, tax, and gross, and the tax-registration number. The reverse-charge mechanism applies to business-to-business cross-border supplies in the European Union, and the platform identifies business buyers via VAT registration numbers and applies the reverse charge where required.
Three-domain-secure 2 (3DS2) is the second-generation strong customer authentication standard, and Stripe routes the buyer through 3DS2 when the payment risk warrants it; the platform configures 3DS2 to satisfy strong customer authentication for European Economic Area cards. Stripe Radar provides machine-learning-based fraud detection, and the platform configures Radar rules that fit the DomiDo profile — thresholds on velocity, geography, and average order value — with Radar decisions logged so that disputes can be traced. Chargebacks are handled through Stripe's dispute workflow: the platform collects the evidence that supports the captured payment (buyer consent records, fulfilment proof, support history) and submits it through Stripe within the required window. Address verification supports the fraud-prevention model where the issuer supports it, with mismatches surfacing as Radar signals rather than as hard declines, and risk-based authentication keeps friction low for low-risk transactions and applies stronger checks (3DS2, Radar review) for higher-risk transactions.
The platform never handles raw card data. Stripe Elements and hosted Checkout process all card input directly with Stripe, which reduces PCI scope to SAQ A — twenty-two requirements rather than the larger SAQ A-EP set — and the annual SAQ A is completed and retained. The platform stores only Stripe references such as customer identifiers, payment-method identifiers, and intent identifiers; card numbers, expiry dates, and security codes never touch the platform, and tokens are used for any required reference.
Every payment state change is driven by a Stripe webhook event. The platform exposes a webhook endpoint that verifies signatures, deduplicates events, persists the raw event, and triggers the platform state transition; the lifecycle covers SetupIntent created, requires-action, succeeded, and failed, PaymentIntent created, succeeded, payment_failed, and canceled, and Connect events for payout, transfer, and reversal. Every payment-creation call uses an idempotency key derived from the platform's internal action identifier, so a retry never creates a duplicate intent, and the order-payment state machine has explicit states — pre-order pending, pre-order active, pre-order cancelled, pre-order expired, order pending, order paid, order shipped, order delivered, order refunded, order disputed — with transitions driven only by validated webhook events.
Payment failures are surfaced clearly to the buyer with a safe failure code, a retryable flag, and a clear next-step; where the failure is retryable, the buyer can retry without re-entering card details. Stripe retries webhook delivery on failure, and the platform's webhook handler is idempotent so that retries are safe. The database schema persists customers, payment methods, intents, payments, orders, invoices, refunds, disputes, and Connect transfers; foreign keys preserve the relationships and indexes support the reconciliation queries.
Stripe reporting and exports drive end-to-end reconciliation. Revenue recognition for subscriptions follows the appropriate accounting standard, marketplace payout reconciliation matches each captured payment to the resulting designer royalty, and accounting integration pushes the reconciled records to the accounting system on a regular schedule. Payment-processing fees vary by transaction type, by region, and by payment method, and the cost profile differentiates kit purchases, subscription renewals, and designer payouts; monthly platform fees apply for Stripe Billing and for value-added services such as Stripe Tax, and the total payment cost as a share of revenue is monitored and benchmarked against the cost-optimisation levers available at scale.
The payment systems ship in four waves aligned with the platform-wide phase model. The UK launch wave puts Stripe basic configuration in place, opens the SetupIntent flow for no-capture pre-orders, sets up Stripe Billing for AI design credits, routes everything that takes a card through hosted Checkout, completes PCI SAQ A, makes the webhook handler idempotent, and establishes the reconciliation flow. The European-Union expansion wave that follows adds European-Union local payment methods, VAT One Stop Shop registration, multi-currency pricing in euros, Stripe Tax across the European Union, and Connect Express for non-UK designers. The United-States expansion wave adds United-States state sales tax via Stripe Tax, multi-currency pricing in United-States dollars, United-States-specific Radar rules, and Stripe Connect Express for United-States designers. The optimisation wave focuses on foreign-exchange optimisation, dynamic three-domain-secure thresholds, Radar rule tuning, payout-fee renegotiation, and reconciliation automation.