DomiDo moves money along four rails. Three of them are inbound — Stripe Checkout for Web and Progressive Web App, Apple In-App Purchase for iOS digital AI credits, and Google Play Billing for Android digital AI credits — and the fourth is outbound, Stripe Connect Express, which carries designer and listing-owner payouts when the entitlement gates clear. This page is the deep dive on how those rails work together: it walks through the customer-side state machines for interest reservations, no-capture pre-orders, immediate-capture purchases, and AI-credit subscriptions; the designer-side mechanics of Stripe Connect onboarding, payout scheduling, and tax handling; and the regulatory posture that ties everything together under UK VAT, PCI DSS, FCA, consumer-protection, and GDPR rules. The page is intentionally diagram-heavy. Fifteen Mermaid diagrams render natively in this wiki, and they are the canonical source of the payment-state contracts; the surrounding prose explains them rather than restating them.
Across all flows, the same posture holds. Phase A — the public-beta interest period — moves no money, creates no Stripe customer or payment object, and promises no shipment; it captures non-binding interest only. Phase A.5 may convert invited eligible reservations into no-capture pre-orders that verify the customer's card through Stripe SetupIntent without charging it. Phase B captures funds through PaymentIntent against the verified payment method and only then issues receipts, invoices, and the corresponding payout-release events. Designer payouts run through Stripe Connect Express on the same gated schedule: Phase A.5 can collect KYC, banking, and tax data so supply is ready, but no money lands in a connected account until Phase B captures the customer payment, delivery becomes eligible, and the reserve-and-dispute checks pass.
DomiDo Blocks operates a three-rail inbound commerce architecture plus a deferred marketplace payout stream. Phase A has no payment rail for physical-kit demand at all: public-beta demand is captured through non-binding interest reservations with no card, no charge, no pre-order, no order, and no shipment promise. Stream 1A (Web and PWA inbound) covers Stripe-web AI-credit purchases where active, Phase A.5 Stripe SetupIntent physical-kit no-capture pre-order verification for invited eligible reservations, and Phase B physical-kit payment capture. Stream 1B (iOS inbound) covers native iOS AI-credit purchases via Apple IAP. Stream 1C (Android inbound) covers native Android AI-credit purchases via Google Play Billing. Stream 2 (outbound marketplace payouts) covers DomiDo paying designers and listing owners through Stripe Connect Express only when Phase A.5 readiness and Phase B payout-release gates are met.
The architecture uses Stripe as the Web and PWA and physical-kit rail for Phase A.5 and Phase B, Apple IAP as the iOS digital AI-credit rail, Google Play Billing as the Android digital AI-credit rail, and Stripe Connect Express as the designer-payout readiness and release rail. Native digital AI credits do not route through Stripe-web checkout inside iOS or Android apps; the store rails are mandatory for that surface. To minimise the PCI burden once Phase A.5 opens, the Web and PWA implementation uses Stripe Checkout (hosted) rather than Stripe.js Elements where feasible. This reduces PCI scope from SAQ A-EP (191 requirements) to SAQ A (22 requirements). A payment service abstraction layer in the Go backend routes by product type and platform rail while preserving tax, entitlement, refund, and reconciliation evidence.
Phase A collects customer demand for physical block kits through non-binding InterestReservation records. Phase A does not collect card details, call Stripe, create a pre-order, create an order, raise an invoice or receipt, reserve production capacity, or promise shipment. This is the public-beta demand-learning model, and it sits before any payment provider is involved at all. The state machine below shows how a Phase A reservation moves through Phase A.5 invitation, Phase A.5 SetupIntent verification, and Phase B charge.
The lifecycle starts as a draft, becomes a saved_design, then a public_listing, then an active interest reservation. From interest_active, the user can cancel, or the back-end can promote the reservation to preorder_invited once Phase A.5 gates pass. The user then either declines (or lets the invite expire) or proceeds with fresh consent and SetupIntent, moving through preorder_pending and preorder_confirmed. From preorder_confirmed, Phase B gates promote the record to conversion_ready and finally build_ready on PaymentIntent success. The preorder_failed state captures SetupIntent failures and allows the user to retry.
Phase A.5 may convert selected eligible Phase A interest reservations into no-capture pre-orders. Conversion requires an explicit invitation, fresh buyer consent, listing-owner and designer terms, moderation and intellectual-property gates, regulatory and product gates, price and support readiness, and Stripe SetupIntent verification. It remains no-capture: no funds are moved, no invoice or receipt is issued, no shipment is promised, and no payout is released. The SetupIntent sequence below shows the conversation between the customer, the app, the backend, and Stripe. After the customer accepts the invite, the app creates a SetupIntent through the backend; Stripe issues a client secret; the customer enters card details through Stripe's hosted UI; Stripe verifies the card at zero amount; and Stripe fires a setup_intent.succeeded webhook that the backend uses to move the reservation to a no-capture pre-order.
Several properties of the Phase A.5 pre-order model are load-bearing. No charge is captured: the customer's card is verified as valid, but the zero amount means no funds move, which is legally distinct from a deposit or pre-authorisation. The payment method is stored: the verified PaymentMethod is attached to the Stripe Customer object and can be charged later in Phase B via a server-side PaymentIntent using off_session: true. When Phase A evidence, Phase A.5 pre-order evidence, and the Phase B safety, fulfilment, insurance, and capture gates are met, the platform transitions selected eligible commitments to Phase B; confirmed commitments are then converted to PaymentIntents and charged, with advance notice and any required fresh confirmation before charge. The customer promise is symmetric: in Phase A the user only registers non-binding interest, and in Phase A.5, if invited, the card can be verified but is never charged until the kit is ready for the Phase B charge path; cancellation is free where state permits. This model is non-negotiable for the Phase A.5 conversion strategy — any payment provider that cannot support zero-charge card verification with deferred charging is architecturally incompatible with the pre-order conversion path.
When Phase B activates, the stored PaymentMethod from a Phase A.5 pre-order may be used to charge the customer where consent and payment rules allow, and new customers in Phase B pay at checkout via a standard PaymentIntent flow with immediate capture. The diagram below shows the existing pre-order conversion path.
In the batch conversion, the backend creates an off-session PaymentIntent for each confirmed commitment. On success, the commitment moves to build_ready and the backend dispatches the order to the third-party logistics (3PL) partner, who returns an order confirmation and tracking reference. A dispatch notification then goes to the customer. The Phase B new-customer flow is symmetric but in-session: the customer adds a kit to cart, the backend creates a PaymentIntent with amount equal to the kit price plus the delivery estimate, the customer confirms payment, 3D Secure runs where required for Strong Customer Authentication, and a payment_intent.succeeded webhook drives the 3PL handoff and order confirmation email.
Kit pricing follows a deterministic structure. Kit price equals the sum of (block manufacturing cost × quantity) plus connector cost, packaging, platform margin, and the configured listing-owner markup or entitlement where active. The price is computed by the pipeline cost model after voxelisation completes. In Phase A the price is shown only as an estimate or price-unavailable state for interest reservations. In Phase A.5 the invited pre-order checkout may show an expected no-capture amount. In Phase B it becomes the charged amount after capture gates pass.
Alongside the physical-kit rail, DomiDo offers AI-credit subscription tiers for design generation. Credits are non-cumulative: they reset monthly at the billing cycle date, not at a calendar boundary. The tiers and credit allowances are configured product data and live in the data requirements; they are not encoded here. The subscription lifecycle sequence below shows the two paths the API takes when a customer changes tier. New subscribers are routed to Stripe Checkout in subscription mode, which handles SCA and card collection in one hosted experience, while existing subscribers go through the Subscriptions API directly because the card is already on file.
Plan switching follows the standard Stripe Billing rules. An upgrade applies proration: the customer is charged a prorated amount for the remainder of the current billing cycle at the new rate, less a credit for the unused portion of the old plan, and credits are immediately reset to the new tier's allocation. A downgrade takes effect at the start of the next billing cycle; Stripe creates a credit note for the prorated difference, credits continue at the current tier's level until the cycle ends, then reset to the new tier's allocation. A cancellation reverts the subscription to Free tier at the end of the current billing cycle, with remaining credits available until cycle end and a reset to the Free allocation thereafter. The monthly credit reset itself is enforced in application logic: at each billing cycle renewal (the invoice.paid webhook), the API resets aiCredits.balance to the tier's monthlyAllowance. Credits do not roll over — Stripe handles the recurring billing, and the platform handles the credit ledger.
Physical-kit delivery in Phase B uses a 3PL partner for fulfilment, and delivery cost is not a fixed line item; it depends on package dimensions (driven by block count and kit geometry), weight, and destination address. The sequence below shows the lookup performed at checkout.
The delivery estimate is shown at checkout alongside the kit price. A variability note informs the customer that the final delivery cost is confirmed at dispatch, since 3PL rates may fluctuate. The customer is not charged more than the estimate without notification; if the actual cost exceeds the estimate by more than 10%, the platform absorbs the difference. Phase A interest reservations show delivery estimates only as optional indicative context and collect no delivery choice or charge. Phase A.5 no-capture pre-orders may show expected delivery assumptions without capturing money. Phase B makes delivery part of the captured order flow.
Refund and cancellation obligations depend on the commitment stage and the nature of the product. In Phase A the customer may cancel a non-binding interest reservation where state permits, and in Phase A.5 the customer may cancel a no-capture pre-order before Phase B charge capture where state permits; no funds have been collected, so no refund is necessary. For Phase A.5 cancellation, the SetupIntent-linked PaymentMethod can be detached or marked unusable according to policy, the reservation or pre-order transitions to a cancelled state and remains auditable, and the customer promise explicitly states that no charge occurs before the later Phase B charge path. Post-charge cancellation in Phase B is governed by the Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 (SI 2013/3134), which grant a 14-day cooling-off period for distance selling contracts beginning the day after the customer receives the goods (Regulation 30); Regulation 28(1)(b) exempts goods "made to the consumer's specifications" or "clearly personalised", so kits derived from the customer's own uploaded 3D model or AI-generated design are custom-manufactured to their specification and the exemption applies, while kits purchased from the Gallery that use a designer's published design are arguably not custom-manufactured and are subject to the full 14-day cooling-off period. Refunds are processed via stripe.Refunds.New() against the original PaymentIntent; Stripe does not return processing fees on refunds. AI-credit subscription cancellation takes effect at end of billing cycle, with no mid-cycle refund for used time and no refund for credits already consumed; a pro-rata refund is available if requested within 14 days of subscription creation (the Consumer Contracts Regulations apply to digital subscriptions, though the consumer loses the right to cancel once digital content supply begins with their express consent under Regulation 37).
The current delivery strategy activates designer and listing-owner acquisition after Phase A and before real order fulfilment. Phase A can show attributed interest demand but does not create payable royalties or payout balances. Phase A.5 may activate listing-owner terms, projected entitlements, Stripe Connect and KYC readiness, payout settings, statement previews, and reserve and dispute modelling so supply can be acquired before Phase B. Actual payout release requires Phase B captured funds, delivery eligibility, KYC and Connect readiness, and any reserve or dispute checks. The requirements use configurable listing-owner markup and entitlement rules rather than a fixed hard-coded split: public prices, markup ranges, VAT inclusion, entitlement rates, payout fees, thresholds, reserve rules, and eligibility delays come from backend configuration and signed terms, not from static payment-analysis examples. The split is summarised as customer payment equal to the Phase B captured public kit price, listing-owner entitlement equal to the configured entitlement rule applied to the eligible captured and delivered order, and DomiDo platform share equal to the remainder after fulfilment cost, fees, taxes, reserves, and entitlement policy. The legal and tax characterisation of listing-owner entitlements remains advisor-owned, and the requirements baseline treats payout logic as configurable and evidence-driven rather than locking a single tax model or split.
When a customer purchases an eligible Gallery-listed kit in Phase B and the listing-owner terms are active, the listing-owner entitlement becomes payable only after delivery and payout-eligibility gates pass. The pipeline below shows how funds move from the customer, through Stripe, into the connected designer account, and finally out to the designer's bank.
Three payout triggers govern the pipeline. The immediate trigger initiates the transfer to the designer's connected account upon payment confirmation (the payment_intent.succeeded webhook), with a hold applied for standard Gallery kits subject to the cooling-off period. The payout schedule then takes over: funds accumulated in the designer's connected account are paid out to their bank account on a monthly schedule (1st of each month), subject to a minimum balance threshold defined in payout configuration. Below-threshold handling rolls funds forward — if the designer's balance is below the threshold at the monthly payout date, funds roll over to the next month, and the designer is notified of the current balance and projected payout date. Dispute handling closes the loop: if a customer disputes a charge (a chargeback) after the designer has been paid, Stripe reverses the transfer to the connected account; if the designer's balance is insufficient, the balance goes negative and is recovered from future earnings, and the platform may choose to hold a rolling reserve to mitigate this risk.
Designer onboarding for payouts is handled through Stripe Connect Express, which provides a Stripe-hosted onboarding flow. The full identity, banking, and tax decision tree is shown below.
Stripe handles all Know Your Customer (KYC) verification, identity checks, and sanctions screening with Connect Express. The platform does not collect or store designer banking details — Stripe owns that data and the associated PCI and data-protection obligations, which is a significant compliance advantage because the platform avoids becoming a data controller for sensitive financial information beyond what Stripe surfaces through the API. The account is created via:
stripe.Accounts.New({
Type: "express",
Country: "GB",
Email: [email protected],
Capabilities: {
CardPayments: {Requested: true},
Transfers: {Requested: true},
},
BusinessType: "individual",
Metadata: {domido_user_id: "usr_xxx"},
})
After account creation, a Stripe Account Link redirects the designer to the hosted onboarding:
stripe.AccountLinks.New({
Account: acct_xxx,
RefreshURL: "https://domido.com/designer/onboarding/refresh",
ReturnURL: "https://domido.com/designer/onboarding/complete",
Type: "account_onboarding",
})
Tax-reporting obligations for designer payouts vary by jurisdiction, and professional tax advice is obtained for designer payout structuring. For UK designers, the platform does not withhold income tax on royalty payments. Designers are self-employed or operate through their own limited companies and are responsible for their own Self Assessment tax returns. The platform maintains records of all payments made to each designer — including dates, amounts, and the designer's name and address — and issues an annual payment summary. For international designers, UK double-taxation agreements with most EU countries typically provide reduced or zero withholding rates on royalty payments, and these agreements remain in force post-Brexit; for US designers, Stripe Connect handles 1099-MISC and 1099-K form generation and filing, and if a US designer fails to provide a valid W-9, Stripe enforces backup withholding. A cross-border tax adviser is engaged before expanding designer payouts to non-UK jurisdictions. On VAT, designer royalties are payments from the platform to the designer — they are not a supply from the designer to the platform in the VAT sense; if the arrangement were structured as the designer supplying a licence, VAT-registered designers would need to charge VAT on their royalty invoices. The structure used is that the platform is the seller (merchant of record for the kit sale) and pays the designer a royalty, avoiding reverse-charge VAT complications.
The regulatory analysis here is based on publicly available guidance and is not legal or tax advice. The company obtains professional legal counsel for VAT registration, FCA assessment, and GDPR data-processing determinations before launch.
UK VAT is the first concern. The UK VAT registration threshold is GBP 90,000 in taxable turnover over any rolling 12-month period. Once taxable turnover exceeds this threshold (or is expected to exceed it in the next 30 days), the platform must register for VAT with HMRC. Phase A collects no revenue from kit sales and creates no SetupIntent for physical-kit demand; Phase A.5 SetupIntent pre-orders also collect no kit revenue; AI-credit subscription revenue is therefore the sole taxable turnover stream until Phase B kit capture is active. Once registered, the platform charges 20% VAT on all UK domestic sales (kit sales and AI-credit subscriptions), issues VAT invoices or simplified invoices, files quarterly VAT returns with HMRC, and pays collected VAT to HMRC. International expansion adds further obligations: EU B2C digital services require UK businesses to register for VAT in each EU member state where sales occur, or to use the non-Union scheme via a single EU member state, because post-Brexit UK businesses cannot use the EU One Stop Shop directly; EU B2C physical goods attract import VAT, with the Import One Stop Shop covering consignments up to the EU low-value consignment threshold of €150 and full customs import procedures applying above that; Stripe Tax automates VAT and sales-tax calculation in over 100 countries but does not file returns, and it has a known limitation with Northern Ireland (which remains in the EU VAT area for goods under the Windsor Framework) that may require manual configuration.
The Payment Card Industry Data Security Standard (PCI DSS) applies to any entity that stores, processes, or transmits cardholder data, and PCI scope depends on the payment integration architecture. SAQ A (22 requirements) applies when the platform uses Stripe's fully hosted Checkout page (stripe.checkout.Sessions.New()): the customer is redirected to a Stripe-hosted page to enter card details, the platform's servers and client-side code never touch cardholder data, and the simplest self-assessment questionnaire applies, primarily covering policy and procedural controls. SAQ A-EP (191 requirements) applies when the platform embeds Stripe.js Elements directly into its own checkout page: card data is entered on a page that the platform controls (even though the iframe is Stripe-hosted), and the 191 requirements cover network security, access controls, vulnerability management, encryption, logging, and testing, with an annual compliance burden roughly ten times that of SAQ A. The requirements baseline uses Stripe Checkout (hosted) for Web and PWA card payment surfaces, Apple IAP for native iOS digital AI credits, and Google Play Billing for native Android digital AI credits; the platform qualifies for SAQ A for Stripe-web card flows, and native purchase validation and app-store report ingestion are governed by the interface, data, and acceptance documents.
The Financial Conduct Authority (FCA) regulates payment services in the UK under the Payment Services Regulations 2017 (SI 2017/752) and the Electronic Money Regulations 2011 (SI 2011/99). When Phase B marketplace and listing-owner sales activate and the platform collects payments from customers before paying royalties to designers, this could constitute a regulated payment service (transmitting funds on behalf of a third party); using an FCA-authorised payment service provider for the payout pipeline avoids the platform needing its own FCA authorisation for that flow. Stripe Payments UK Ltd holds FCA authorisation as an Electronic Money Institution (EMI, licence number 900461). Subject to regulatory review and changes, when the platform uses Stripe Connect to handle the collection of customer payments and the onward transfer to designer connected accounts, the regulated payment activity is performed by Stripe, and the platform acts as the platform operator, not as a payment institution. Three conditions hold the FCA exemption together: the platform must not hold customer or designer funds in its own bank accounts (funds must flow through Stripe), the platform must not control the timing of payouts to designers' bank accounts in a way that constitutes money transmission (Stripe's payout scheduling, with Stripe holding funds in the connected account, satisfies this), and the platform must not offer financial products (loans, credit, insurance) to designers or customers without separate FCA authorisation. If the platform were to collect customer payments through a Merchant of Record and then separately pay designers via manual bank transfers, Wise, or PayPal, the platform itself could be performing a regulated payment service, requiring either FCA authorisation or reliance on the commercial-agent exclusion under Regulation 4 of the PSR 2017, which has narrow conditions and regulatory uncertainty.
Consumer-protection law applies on top of the payment-rail regulation. The Consumer Rights Act 2015 (CRA 2015) requires that goods be of satisfactory quality, fit for purpose, and as described (Sections 9–11); the 3D preview and BOM shown to the customer at checkout constitute a description, and the delivered kit must match, with remedies including the short-term right to reject (30 days), the right to repair or replacement, and the final right to reject or price reduction after one failed repair or replacement. The Consumer Contracts Regulations 2013 (CCR 2013) impose a 14-day cancellation period for distance selling (Regulation 29), starting the day after delivery for goods or the day after the contract is entered for digital content or services; custom-manufactured goods are exempt under Regulation 28(1)(b), so kits based on the customer's own 3D model or AI prompt are exempt, while standard Gallery kits (a designer's design, not customised by the buyer) are not exempt and are subject to the 14-day right. The CRA 2015 Part 1 Chapter 3 digital-content provisions apply to AI-credit subscriptions: they must be of satisfactory quality, fit for purpose, and as described, and once digital content is supplied (credits used), the right to cancel is lost if the consumer gave express consent and acknowledged loss of cancellation right (Regulation 37 of the CCR 2013).
GDPR obligations under the UK GDPR (Data Protection Act 2018) shape data handling end-to-end. The lawful basis for processing payment data is the necessity for the performance of a contract (Article 6(1)(b)), so no separate consent is needed for payment processing. Data minimisation is enforced because the platform stores Stripe Customer IDs, PaymentIntent IDs, and subscription IDs, not raw card numbers, CVVs, or full card details — Stripe handles cardholder data. Payment records are retained for 6 years for tax and accounting purposes (HMRC requirement), and after 6 years records are archived or deleted unless a legal hold applies. Erasure requests under Article 17 can be refused for payment records where retention is required for legal obligations or for the establishment, exercise, or defence of legal claims; the Stripe Customer object can be deleted, but anonymised transaction records are retained for accounting. Stripe processes data in the EU and US, and Stripe's Data Processing Agreement covers international transfers under Standard Contractual Clauses (SCCs); the platform's privacy policy discloses this. For designer financial data, with Stripe Connect Express, Stripe is the data controller for designer banking details and identity documents — the platform receives limited data (connected account ID, payout status) and does not store or process sensitive financial data.
The selected architecture binds the rails together through a single payment service abstraction. Web and PWA customers hit Stripe Checkout in setup, payment, or subscription mode depending on the flow; iOS customers buy AI credits through Apple IAP; Android customers buy through Google Play Billing; both store rails feed validated transactions back to the API. The API sits behind a PaymentProvider interface (plus rail-specific integrations for Apple and Google), which routes by product type and platform. Stripe Connect Express handles outbound payouts to designer bank accounts. The compliance row shows where Stripe Tax, app-store payout reports, PCI SAQ A coverage, and webhook handling fit. The supporting systems are MongoDB Atlas (orders, commitments, credits), the 3PL partner, and the email service.
To mitigate vendor lock-in and keep rail routing auditable, the Go backend implements a PaymentProvider interface and rail-specific integrations:
type PaymentProvider interface {
// Stream 1A: Web/PWA customer → DomiDo
CreateSetupSession(ctx context.Context, req SetupSessionRequest) (*SetupSessionResponse, error)
CreatePaymentSession(ctx context.Context, req PaymentSessionRequest) (*PaymentSessionResponse, error)
CreateSubscription(ctx context.Context, req SubscriptionRequest) (*SubscriptionResponse, error)
UpdateSubscription(ctx context.Context, req UpdateSubscriptionRequest) (*SubscriptionResponse, error)
CancelSubscription(ctx context.Context, req CancelSubscriptionRequest) error
ProcessRefund(ctx context.Context, req RefundRequest) (*RefundResponse, error)
// Stream 2: DomiDo → Designer
CreateConnectedAccount(ctx context.Context, req ConnectedAccountRequest) (*ConnectedAccountResponse, error)
CreateOnboardingLink(ctx context.Context, req OnboardingLinkRequest) (*OnboardingLinkResponse, error)
CreateTransfer(ctx context.Context, req TransferRequest) (*TransferResponse, error)
// Webhooks
VerifyWebhookSignature(payload []byte, signature string) error
ParseWebhookEvent(payload []byte) (*WebhookEvent, error)
}
type NativeStoreRail interface {
ValidatePurchase(ctx context.Context, req StorePurchaseValidationRequest) (*StorePurchaseValidationResponse, error)
ParseStoreNotification(ctx context.Context, payload []byte, headers map[string]string) (*StoreNotificationEvent, error)
IngestPayoutReport(ctx context.Context, req StorePayoutReportRequest) (*StorePayoutReportResult, error)
}
The StripePaymentProvider struct implements the web and physical-kit interface using the Stripe Go SDK. Apple and Google implementations own native transaction validation, server notifications, payout-report ingestion, entitlement updates, and audit events. Business logic in the API layer routes by product type and launch surface before calling the rail-specific implementation.
Several key implementation choices fall out of this architecture. Checkout integration uses Stripe Checkout (hosted) to keep PCI scope at SAQ A (22 requirements) versus SAQ A-EP (191 requirements), a 10× scope reduction. The Connect account type is Express, balancing platform control with compliance outsourcing while Stripe handles KYC. Stripe Tax is enabled for UK and countries are added as the platform expands, deferring international registration until revenue justifies it. The payout schedule is monthly, on the 1st of the month, with a configurable minimum threshold enforced in application logic. The royalty hold period is 14 days after delivery confirmation, aligned with the cooling-off period for standard Gallery kits. Idempotency keys are constructed from the business entity ID and an attempt counter, preventing duplicate charges on retry. Webhook processing is idempotent, signature-verified, and asynchronous via the Asynq job queue, preventing duplicate state transitions and decoupling webhook receipt from processing. Voluntary VAT registration occurs pre-launch to avoid threshold surprise and to support OSS and Stripe Tax configuration.
The Stripe integration for Phase A.5 invited pre-orders uses SetupIntent, a Stripe API object designed specifically for collecting and verifying payment-method details without creating a charge. Phase A interest reservations do not use Stripe at all. The key API integration points are listed below, followed by the webhook events that drive the SetupIntent lifecycle.
| Operation | Stripe API | Go SDK method | Key parameters |
|---|---|---|---|
| Create SetupIntent | POST /v1/setup_intents |
setupintent.New() |
PaymentMethodTypes, Customer, Usage: "off_session" |
| Confirm SetupIntent | Client-side (Stripe.js) | N/A | client_secret |
| Retrieve SetupIntent | GET /v1/setup_intents/:id |
setupintent.Get() |
SetupIntentID |
| List PaymentMethods | GET /v1/payment_methods |
paymentmethod.List() |
Customer, Type: "card" |
| Event | Trigger | Backend action |
|---|---|---|
setup_intent.succeeded |
Card verification successful | Update commitment to preorder_pending |
setup_intent.setup_failed |
Card verification failed | Notify customer, allow retry |
setup_intent.requires_action |
3D Secure / SCA challenge | App handles authentication challenge |
payment_method.attached |
PaymentMethod saved to Customer | Log for audit trail |
Rather than embedding Stripe Elements, the platform uses Stripe Checkout in setup mode, which redirects the customer to a Stripe-hosted page and reduces PCI scope to SAQ A. After completion the checkout.session.completed webhook fires with the SetupIntent ID and attached PaymentMethod:
stripe.checkout.Sessions.New({
Mode: "setup",
Customer: cus_xxx,
SuccessURL: "https://domido.com/preorder/success?session_id={CHECKOUT_SESSION_ID}",
CancelURL: "https://domido.com/preorder/cancel",
Metadata: {commitment_id: "cmt_xxx"},
})
The subscription flow follows the same hosted-checkout pattern, and its full lifecycle covers new subscribers, upgrades, downgrades, monthly renewal, and failed payments. Stripe Billing's Smart Retries (ML-optimised) handles dunning, retrying failed payments up to four times over three weeks before the subscription is cancelled.
Stripe Billing is configured for automatic proration on plan changes (create_prorations), automatic collection (charge_automatically, no manual invoicing for consumer subscriptions), default-incomplete payment behaviour (subscription created but inactive until first payment confirms), immediate charge with no net terms, Smart Retries dunning, and cancel-at-period-end for downgrades and cancellations so paid periods are honoured before tier changes.
Phase B introduces immediate-charge PaymentIntent flows for new customers and controlled conversion of eligible Phase A.5 no-capture pre-orders. The batch conversion flow handles 14-day advance notice, off-session capture with potential SCA challenge, retry handling, and final failure.
When charging a stored PaymentMethod off-session (no customer present), SCA may require 3D Secure. The PaymentIntent returns requires_action, and the backend sends the customer a notification with a link to complete authentication; the Stripe SDK handles this via stripe.PaymentIntents.New() with OffSession: true — if authentication is required, Stripe returns the appropriate error code and the webhook handler sends a push notification or email.
On the outbound side, Stripe Connect Express is the chosen account type for designer and listing-owner payout readiness and release. It remains inactive in Phase A. Phase A.5 may expose onboarding, KYC readiness, payout settings, projected entitlements, and statement previews where designer acquisition requires them; actual money movement remains blocked until Phase B captured funds and payout-eligibility gates pass. Express accounts balance platform control with compliance outsourcing: onboarding runs through a Stripe-hosted flow (KYC, identity, banking), designers get the simplified Express Dashboard, the platform's descriptor appears on customer statements, the platform manages disputes (Stripe debits the connected account), the platform sets the payout schedule (the designer cannot override), Stripe handles ongoing KYC updates and sanctions screening, and Stripe collects W-9 (US) and tax IDs (international).
The platform may use Stripe Connect destination charges or separate charges and transfers for eligible listing-owner payouts, depending on the final legal and tax model. The requirements do not hard-code a fixed split. The example below is illustrative; production values come from entitlement configuration, signed listing-owner terms, delivery eligibility, reserves, and dispute state:
stripe.PaymentIntents.New({
Amount: kit_price_minor_units,
Currency: "gbp",
Customer: cus_xxx,
TransferData: {
Destination: acct_designer_xxx,
Amount: configured_entitlement_amount,
},
Metadata: {
order_id: "ord_xxx",
kit_id: "kit_xxx",
designer_id: "usr_xxx",
entitlement_model: "configured_terms_version",
},
})
If a future feature allows bundled kits from multiple designers, the platform uses separate charges and transfers:
// Single charge to customer
pi := stripe.PaymentIntents.New({
Amount: total_minor_units,
Currency: "gbp",
Customer: cus_xxx,
TransferGroup: "order_ord_xxx",
})
// Separate transfers to each designer
stripe.Transfers.New({
Amount: designer_a_entitlement,
Currency: "gbp",
Destination: acct_designer_a,
TransferGroup: "order_ord_xxx",
})
stripe.Transfers.New({
Amount: designer_b_entitlement,
Currency: "gbp",
Destination: acct_designer_b,
TransferGroup: "order_ord_xxx",
})
The full onboarding sequence from the platform's perspective creates the Express account, redirects the designer to Stripe-hosted onboarding, polls account status on return, and listens for ongoing account.updated webhooks as Stripe re-verifies connected-account information.
When additional information is required, Stripe sends an account.updated webhook with requirements.currently_due populated; the platform notifies the designer and provides a link to the Stripe-hosted remediation flow. Payout scheduling itself runs monthly on the 1st of each month with a configurable minimum threshold, a 14-day hold period after kit delivery confirmation, GBP for UK designers and multi-currency for international designers, instant payout availability, and Bacs bank transfer (2–3 business days) as the standard payout method. Because Stripe Connect's native payout scheduling does not support minimum thresholds, the platform implements threshold logic in application code: at month-end it queries each designer's connected-account balance via balance.Get() with the Stripe-Account header; if the balance is at or above the configured threshold, the scheduled payout proceeds; if it is below the threshold, payouts are paused by updating the account's payout schedule to manual and suppressing the automatic payout, resuming on the next monthly check, with the designer notified of the current balance and projected next payout date.
The compliance posture follows the rail choice. PCI scope for Stripe-web card flows is SAQ A (22 requirements). Stripe Checkout supports custom branding, pre-filled customer details, automatic SCA and 3D Secure handling, Apple Pay and Google Pay, setup, payment, and subscription modes, and redirect back with session ID for confirmation. The UX trade-off is a redirect away from the app to a Stripe-hosted page; for a React Native web app this is a standard pattern and does not significantly degrade the user experience. On VAT, with Stripe as the direct payment service provider the platform is the merchant of record and is responsible for VAT registration when turnover exceeds the threshold, UK VAT calculation (20%, either in application logic or via Stripe Tax), quarterly UK VAT returns, international VAT registration and filing in each jurisdiction (with Stripe Tax calculating rates), VAT invoicing (Stripe generates invoices for subscription charges, the platform generates them for kit sales), and manual configuration for Northern Ireland under the Windsor Framework. On FCA, when Phase A.5 payout readiness and Phase B payout release activate, Stripe's FCA authorisation (EMI licence 900461) covers the Stripe Connect payout pipeline; the platform does not need to obtain FCA authorisation for that flow as long as all marketplace customer payments that generate designer or listing-owner entitlements flow through Stripe, all designer and listing-owner payouts are made via Stripe Connect transfers and payouts, and the platform does not hold funds outside of Stripe. Subject to professional legal counsel confirming the position before launch, no additional FCA assessment, application, or capital requirement is expected to apply.
The backend uses the Stripe Go SDK (github.com/stripe/stripe-go/v85). Client initialisation reads the secret key from environment variables. Error handling uses a type-switch on stripe.Error for CardError, InvalidRequestError, and APIError. Idempotency is enforced through Params.IdempotencyKey on all mutating requests (POST and PUT). Pagination uses the iterator pattern (iter := paymentintent.List(params); for iter.Next() { ... }). Webhook verification uses webhook.ConstructEvent(body, sig, webhookSecret). All Stripe objects carry a Metadata map that the platform uses to attach internal entity identifiers.
The webhook surface handles a defined set of events across both streams. Stream 1 events include setup_intent.succeeded (confirm pre-order commitment), setup_intent.setup_failed (log failure, notify customer), checkout.session.completed (process checkout completion), payment_intent.succeeded (confirm kit purchase, trigger 3PL), payment_intent.payment_failed (log failure, notify customer), customer.subscription.created (activate subscription tier), customer.subscription.updated (handle plan change), customer.subscription.deleted (revert to Free tier), invoice.paid (reset monthly credits), and invoice.payment_failed (notify customer of failed renewal). Stream 2 events include account.updated (update designer verification status), transfer.created (log royalty transfer), payout.paid (log designer payout), and payout.failed (alert operations, notify designer). The charge.dispute.created event applies to both streams and initiates the dispute response workflow. All webhook endpoints verify the Stripe-Signature header using webhook.ConstructEvent(). The endpoint is POST /api/v1/webhooks/stripe. The webhook secret is stored as an environment variable, not in code or configuration files. Events are processed idempotently; duplicate webhook deliveries (Stripe retries for up to 3 days) do not cause duplicate state transitions.
All mutating Stripe API calls include an idempotency key to prevent duplicate charges or transfers. Keys are constructed from the business entity ID (order, commitment, subscription) and an attempt counter. Stripe caches the response for 24 hours; retries within that window return the cached result without creating a new PaymentIntent:
params := &stripe.PaymentIntentParams{
Amount: stripe.Int64(kit_price_minor_units),
Currency: stripe.String("gbp"),
Customer: stripe.String("cus_xxx"),
}
params.IdempotencyKey = stripe.String(fmt.Sprintf("pi_%s_%d", orderID, attempt))
pi, err := paymentintent.New(params)
Several known operational trade-offs are tracked. Even with SAQ A, the platform completes the annual self-assessment questionnaire, maintains security policies, and ensures the hosting environment meets PCI requirements. VAT compliance is the platform's own responsibility as the merchant of record. Stripe's modular pricing means fees accumulate across products (payment processing, Billing, Tax, Connect), Stripe does not return processing fees on refunds, and the per-month per active Express account fee scales linearly with designer count, so "active" is defined narrowly to manage cost. SCA failure on off-session Phase B conversion is mitigated through notification with a deep link to complete authentication, with retry logic across email, push, and SMS. Stripe API changes or pricing increases are mitigated through the payment service abstraction layer wrapping Stripe-specific calls behind a generic PaymentProvider interface. Designer negative balances after payout are mitigated by the 14-day hold on royalty transfers after kit delivery and a rolling reserve on early-period earnings. Voluntary VAT registration pre-launch is a control against threshold surprise and supports OSS and Stripe Tax configuration. Webhook delivery failure is mitigated through Stripe's 3-day retry with exponential backoff, plus webhook replay and a daily reconciliation job comparing Stripe records against the platform database. PCI compliance gaps are addressed by strict logging filters that redact any field matching card number, CVV, or expiry patterns, by exclusive use of Hosted Checkout to maintain SAQ A eligibility, and by PCI scope review in quarterly security audits.
DomiDo handles its own merchant-of-record obligations and integrates directly with Stripe rather than routing through a third-party Merchant of Record. The reason is structural: the Phase A.5 no-capture pre-order conversion model — verify a card now, charge it later, with no funds moved at verification time — depends on a payment-provider primitive that only direct PSPs expose. Stripe's SetupIntent is that primitive. Third-party Merchant-of-Record platforms charge the customer at the point of sale and handle downstream tax and payment obligations on the platform's behalf; that is a strong fit for pure-digital catalogues, but it cannot host a zero-charge verification followed by a deferred capture, and DomiDo's pre-order conversion path is built around exactly that semantic. The diagram below maps the alternative workaround shapes that have been considered and the reasons each one fails to support the pre-order conversion model.
A deposit model would charge a small upfront amount and refund or credit it at Phase B, but that changes the customer promise, adds refund logistics, is not zero-charge, triggers CCR 2013 cancellation rights, and incurs Merchant-of-Record fees on the deposit. A full-charge-upfront model would collect the full kit price now and hold it until Phase B fulfilment, which forces the customer to pay months or years early, creates a cash-flow timing mismatch, brings cancellation refund obligations, raises a substantial trust barrier, and leaves the funds under a third-party MoR's control. A zero-value subscription workaround is not supported by major MoR platforms (no zero-priced subscriptions, no card verification on free tier, no stored payment method access). A split-rail hybrid (Stripe for SetupIntent, MoR for Phase B charges) creates two payment systems, a stored PaymentMethod in Stripe that cannot be used in the MoR's processor, customer-facing charges from two different entities, and a double compliance burden. None of these supports the conversion model, which is why DomiDo runs Stripe end-to-end for Web and PWA.
A second structural reason is physical-goods coverage. MoR platforms that are popular for SaaS and digital catalogues — including Paddle and LemonSqueezy — restrict their use to digital products, software, and digital subscriptions under their terms of service. Physical merchandise, physical fulfilment, and tangible goods are outside that permitted use. Since the core DomiDo business is selling physical block kits, the platform needs a payment provider that handles physical-goods transactions, variable delivery pricing with real-time shipping cost calculation, the specific UK consumer-protection rules for custom-manufactured goods, and returns and refunds with physical logistics. Stripe handles all of that natively. The same constraint applies to the subscription rail: an MoR can host AI-credit subscriptions in isolation, as the sequence below shows, but that only covers one of the three customer payment use cases — kit sales and designer payouts are not supported.
The third structural reason is the marketplace payout pipeline. Third-party MoRs do not, in general, provide native marketplace payout capability; popular MoR products either have no built-in mechanism for splitting payment between platform and seller at the point of charge, or have discontinued the feature, leaving no integrated path for onboarding sellers with KYC and banking details, scheduling payouts to sellers, or handling disputes and refund clawbacks on split payments. The diagram below maps the alternatives the platform would otherwise have to assemble.
Each alternative carries either an FCA-perimeter problem, a KYC burden the platform would have to absorb, or operational complexity that does not scale. If the platform collected customer payments through an MoR and then separately paid designers from its own bank account, the platform itself could be performing money transmission under the Payment Services Regulations 2017 (the commercial-agent exclusion under Regulation 4 has narrow conditions and uncertain enforcement). Without Stripe Connect, the platform would have to perform its own KYC and Anti-Money-Laundering checks: identity verification (passport, driving licence), address verification, sanctions screening against HM Treasury's financial sanctions list and international lists, ongoing monitoring, and record-keeping for 5 years after the business relationship ends (Money Laundering Regulations 2017, Regulation 40). Stripe Connect Express handles all of this. The combined effect of these three reasons — the SetupIntent primitive, physical-goods coverage, and the marketplace payout pipeline — is that DomiDo uses Stripe directly as the merchant of record, with Apple IAP and Google Play Billing as the native-store rails for iOS and Android digital AI credits.
LemonSqueezy is a Merchant of Record platform acquired by Stripe in July 2024 and being progressively integrated into Stripe's product suite. The same structural constraints apply: it has no deferred payment capability (charging at point of sale, with no SetupIntent equivalent), it does not support physical goods (restricted to digital products, software licences, and SaaS subscriptions), its fee structure (base fee plus a cross-border surcharge on non-US transactions) is prohibitive for UK transactions, its marketplace fee would consume the platform's base kit cost margin, and it has no Go SDK (a REST API exists but no official Go SDK; custom HTTP client wrapping would be required). LemonSqueezy's acquisition by Stripe may lead to deeper integration that combines MoR tax handling with full Stripe payment capabilities; no such integration is currently available, and the platform reviews the position in 12–18 months.
The compliance posture splits across four areas that interact in non-obvious ways: the VAT consequences of running three inbound rails in parallel; the Apple IAP commission, VAT treatment, and revenue recognition; the off-session capture failure modes that Stripe SetupIntent must handle in Phase B; and the FCA e-money perimeter analysis for AI credits.
The three inbound rails operate in parallel with distinct VAT consequences. For Stripe-web (UK consumer) sales, Avvyland is seller of record, collects 20% UK VAT at checkout, and retains records for 6 years (general VAT). For Stripe-web (EU consumer) sales, Avvyland is seller of record, collects destination member-state VAT (17–27%), remits via Non-Union OSS Ireland, and retains records for 10 years (Council Implementing Regulation 282/2011 Article 63c). For Apple IAP, Avvyland is supplier to Apple Distribution International (Cork, Ireland) as the default working position (advisor confirmation is required per material jurisdiction); Apple collects EU VAT and the platform's supply is outside UK VAT scope (Box 6), with 6-year records retention. For Google Play Billing, Avvyland is supplier to Google Commerce Ltd (Ireland) as the default working position (advisor confirmation required); Google collects EU VAT and the platform's supply is outside UK VAT scope (Box 6), with 6-year records retention. For inbound AI vendor services (OpenAI, Replicate, and similar), Avvyland is recipient and applies reverse charge under VATA 1994 s.8, self-accounting Box 1 plus Box 4, with 6-year records retention. The OSS rate engine (Stripe Tax or equivalent) determines the destination member state via two non-contradictory pieces of evidence per Council Implementing Regulation 282/2011 Article 24b: billing address, IP, BIN, bank country, or SIM.
Apple IAP commission, VAT, and revenue recognition follow the default Paid Apps Agreement Schedule 2 at launch: 30% standard commission on developer proceeds, 15% Small Business Program rate where developer worldwide proceeds are at or below the qualifying threshold in the prior and current calendar years, and 15% on subscriptions in year 2 and beyond. The EU Digital Markets Act Alternative Terms Addendum is an opt-in for EU storefront apps with a different commission structure (acquisition fee plus store-services fee plus a Core Technology Fee or Commission); Apple has signalled transition to a single Core Technology Commission from January 2026. Choice between default Schedule 2 and Alternative Terms is a commercial decision requiring advisor input if EU is a material revenue channel. The VAT treatment (default working position) is that the place of supply is Ireland under VATA 1994 s.7A B2B general rule, the supply is outside the scope of UK VAT, and it is reported in Box 6 of the UK VAT return. Variants — commissionnaire (PVD Article 28), tax-collection-only intermediary, or Merchant of Record — vary by territory and contract, and advisor confirmation is required per material jurisdiction. Apple's commission to the platform is a B2B service from Ireland into UK; place of supply is UK; reverse charge applies under VATA 1994 s.8, and the platform self-accounts Box 1 plus Box 4 net-neutral. Under FRS 102 s.23 principal-versus-agent (default), Apple is the principal seller to the consumer and the platform is the principal supplier to Apple; the platform recognises revenue at the net amount received (after VAT collected and Apple commission). Advisor confirmation is required to lock the revenue-recognition policy before the first set of statutory accounts.
Off-session capture in Phase B has four failure modes that the platform handles end-to-end. An off-session SCA challenge occurs when the issuing bank requests in-session SCA per PSD2 Article 97; Stripe returns requires_action, and the platform emails the customer the next_action URL for re-authentication. A soft decline (insufficient funds, expired card, lost or stolen, fraud suspected) triggers retry per backoff, customer notification, and a final-failure path. Mandate decay occurs when time elapsed since SetupIntent confirmation makes the mandate stale; the response is proactive customer re-engagement before the Phase B trigger, potentially via a fresh SetupIntent. Customer-not-present rules in some EU member states may require fresh consumer consent for long-deferred Merchant-Initiated Transactions, in which case member-state-specific re-confirmation is performed before capture. Four engineering requirements follow: the Phase B capture flow handles requires_action responses; a failed-payment retry policy applies delay and backoff; a final-failure flow exists; and every authentication and decline event is audit-logged (payment.setupintent_capture_requires_action, payment.setupintent_capture_failed).
The FCA e-money perimeter analysis runs in two steps. Step 1 asks whether the credit meets the e-money definition at all. EMR 2011 reg. 2 defines e-money as monetary value that is electronically stored, representing a claim on the issuer, issued on receipt of funds for the purpose of making payment transactions, and accepted by a person other than the electronic-money issuer. AI credits are purchasable only from the platform and redeemable only for AI outputs supplied by the platform — the fourth limb is not met. Credits are likely not e-money, and the EMR 2011 regime does not engage; Step 1 is the cleanest position. Step 2 is the fallback exclusion analysis. EMR 2011 reg. 3(1) excludes monetary value usable only (a) for purchases of goods and services from the issuer, (b) under a commercial agreement with the issuer in a limited network of providers, or (c) for a limited range of goods and services. Exclusion (a) applies at launch. No FCA authorisation is required under either Step 1 or Step 2 analysis at launch. Advisor confirmation is required to confirm the position in writing before terms and conditions go live. Several trigger events would change the position: if credits became redeemable for cash, Step 1 would fail and the e-money definition would be met; if credits became acceptable at a third party, Step 1 would fail; if credits became transferable between users, the analysis would depend on whether transfer changes the redeemer; if credits became usable on third-party services, Step 1 would fail and possibly Step 2(b) limited network would apply. If e-money status crystallises and outstanding e-money exceeds the EMR 2011 reg. 13(1) average-€5M threshold, full EMI authorisation (initial capital €350K) is required; below that threshold, SEMI registration is the simplified route. EMR 2011 reg. 21 safeguarding obligations (segregated client account or insurance or comparable guarantee) apply to either route.
The expansion path follows revenue justification rather than ambition. EU launch (Web and PWA AI credits) charges EU customers and calculates EU VAT through Stripe Tax (100+ countries), with registration in the EU VAT scheme via a single member state and Stripe Tax configured for the destination countries. Deferred EU physical-kit launch adds EU fulfilment, customs, and import VAT; Stripe handles payment, the 3PL is configured for EU shipping, and IOSS covers consignments under €150 — this is activated only after goods-expansion approval, and the complexity is 3PL and customs logistics, not payment complexity. Deferred US AI-credit launch charges US customers and calculates state sales tax through Stripe Tax (all US states), with registration for sales tax in nexus states. Deferred US physical-kit launch adds US fulfilment and state sales tax; Stripe handles payment, but a US 3PL partner is needed, making this a high-effort path due to separate US fulfilment infrastructure. International designers can be paid in local currencies through Stripe Connect (40+ countries), with per-country payout currencies configured and cross-border transfer fees applying. Multi-currency pricing supports 135+ Stripe currencies, with medium effort for price management across currencies and FX risk.
Stripe Tax has known limitations. Northern Ireland requires manual configuration due to the Windsor Framework. Not all countries have automatic tax-ID validation, and some jurisdictions require manual review. Stripe Tax calculates tax but does not file returns.
| Term | Definition |
|---|---|
| 3PL | Third-Party Logistics — external fulfilment partner for physical kit shipping |
| AML | Anti-Money Laundering — regulations requiring businesses to verify customer identity and monitor for suspicious activity |
| BOM | Bill of Materials — itemised list of components in a kit |
| CCR 2013 | Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 (SI 2013/3134) |
| CRA 2015 | Consumer Rights Act 2015 |
| Direct PSP | Direct Payment Service Provider — the platform integrates with the PSP API and is the merchant of record |
| EMI | Electronic Money Institution — FCA authorisation category for payment service providers |
| FCA | Financial Conduct Authority — UK financial services regulator |
| GDPR | General Data Protection Regulation (UK GDPR as retained EU law via Data Protection Act 2018) |
| HMRC | His Majesty's Revenue and Customs — UK tax authority |
| IOSS | Import One Stop Shop — EU scheme for collecting VAT on imported goods under €150 |
| KYC | Know Your Customer — identity verification and due diligence process |
| MoR | Merchant of Record — the entity that is the seller of record for tax, compliance, and liability purposes |
| PCI DSS | Payment Card Industry Data Security Standard |
| PSP | Payment Service Provider |
| SAQ | Self-Assessment Questionnaire — PCI DSS compliance self-assessment instrument |
| SAQ A | SAQ for merchants that outsource all cardholder data processing (22 requirements) |
| SAQ A-EP | SAQ for e-commerce merchants that partially outsource cardholder data processing (191 requirements) |
| SCA | Strong Customer Authentication — EU and UK requirement for two-factor authentication on electronic payments |
| SetupIntent | Stripe API object for collecting and verifying payment-method details without creating a charge |
| PaymentIntent | Stripe API object for creating and confirming a payment charge |
| API resource | Endpoint | Key parameters | Use |
|---|---|---|---|
| SetupIntent | POST /v1/setup_intents |
customer, payment_method_types, usage |
Phase A.5 no-capture card verification |
| PaymentIntent | POST /v1/payment_intents |
amount, currency, customer, payment_method, off_session |
Phase B kit charge |
| Checkout Session | POST /v1/checkout/sessions |
mode (setup, payment, subscription), line_items, success_url |
All checkout flows |
| Subscription | POST /v1/subscriptions |
customer, items, proration_behavior |
AI credit tiers |
| Customer | POST /v1/customers |
email, metadata |
Customer record |
| Account (Connect) | POST /v1/accounts |
type: express, country, capabilities |
Designer onboarding |
| Account Link | POST /v1/account_links |
account, type: account_onboarding, return_url |
KYC redirect |
| Transfer | POST /v1/transfers |
amount, destination, transfer_group |
Royalty payout |
| Refund | POST /v1/refunds |
payment_intent, amount |
Kit or subscription refund |
| Webhook Event | Received at configured endpoint | type, data.object |
All lifecycle events |
| Regulation | Citation | Relevance |
|---|---|---|
| Consumer Rights Act 2015 | c.15 | Quality, fitness, description for physical kits and digital content |
| Consumer Contracts Regulations 2013 | SI 2013/3134 | 14-day cooling-off, custom-goods exemption (Regulation 28(1)(b)) |
| Payment Services Regulations 2017 | SI 2017/752 | FCA authorisation for payment services, commercial-agent exclusion |
| Electronic Money Regulations 2011 | SI 2011/99 | EMI licensing (Stripe's authorisation basis) |
| Money Laundering Regulations 2017 | SI 2017/692 | KYC and AML obligations for businesses handling funds |
| Data Protection Act 2018 | c.12 | UK GDPR implementation, payment-data processing |
| Value Added Tax Act 1994 | c.23 | VAT registration, rates, returns |
| PCI DSS v4.0 | PCI SSC | Cardholder data security standard |
| PSD2 / UK retained law | SI 2017/752 (Part 7) | Strong Customer Authentication requirements |