eCommerce & Payments: Subscriptions, Marketplaces, Tax, Platforms, Checkout, and Agentic Commerce¶
Part 3 of 4 of the eCommerce and Payments Development reference (plugin
ecommerce-development), covering §9–§14. Sibling skills:ecommerce-payments-architecture-and-integration(§0–§4),ecommerce-payment-methods-sca-fraud-and-pci(§5–§8),ecommerce-reference(§15–§20). Section numbers are shared across the set; a reference written as §N →skillpoints into that sibling skill.Currency: Verified August 2026. See §17 →
ecommerce-referencefor the currency snapshot and what goes stale first.How to read this. Reference, not tutorial. Sections are independent. Three markers: - [DURABLE] — accounting reality, distributed-systems truth, or a lesson every payments team learns the hard way. Does not expire. - [VERSIONED] — API versions, regulatory deadlines, platform behaviour, market state. Verify before relying on it. - [CONTESTED] — practitioners genuinely disagree.
⚠️ GOTCHA boxes mark the mistakes that double-charge customers, lose orders, fail an audit, or quietly leak revenue for months before anyone notices.
Scope note: this is an engineering document. It covers how these systems are built, integrated, and operated. It is not legal, tax, or financial advice — the regulatory material in §8 →
ecommerce-payment-methods-sca-fraud-and-pciand §11 tells you what to ask your counsel and your acquirer, not what your obligations are.The three framings that organize everything below: 1. Money is not data. It is data with an audit trail, a counterparty, and a regulator. A dropped message in most systems is an inconvenience; here it's a customer charged twice, or an order shipped for free. Every design decision follows from that asymmetry. 2. The network will fail mid-transaction, and you must be correct anyway. This is a distributed-systems problem wearing a business costume. Idempotency and reconciliation (§3 →
ecommerce-payments-architecture-and-integration) are not best practices — they are the load-bearing walls. 3. Your job is mostly to touch card data as little as possible. PCI scope is a function of architecture, and the difference between the easy compliance path and the expensive one is decided in week one (§8 →ecommerce-payment-methods-sca-fraud-and-pci).
§9. Subscriptions and Billing¶
[DURABLE] Billing is where the interesting bugs live, because it is a state machine running unattended for years.
The model: customer → subscription → plan/price → invoice → payment attempt → (success | dunning). Proration on mid-cycle changes is the classic source of disagreement between your invoice and the customer's expectations — decide the policy, document it, and show the math on the invoice.
Dunning — the retry sequence on failed payments — is directly revenue-relevant. Smart retry timing (aligned with paydays and issuer behaviour) recovers materially more than fixed daily retries. Combine with card account updater, pre-dunning notices before expiry, and a clear in-product update path.
⚠️ Involuntary churn — failed payments, not cancellations — is often the largest single churn component, and it is the most tractable. Teams obsess over the cancel flow and ignore the retry logic.
Also handle: trials (and the conversion charge), upgrade/downgrade proration, pausing, usage-based and metered billing (with idempotent usage records — double-counted usage is a support nightmare), tax on recurring charges as the customer moves jurisdiction, and revenue recognition (ASC 606 / IFRS 15 — cash received ≠ revenue recognized, and your finance team needs the deferred-revenue schedule).
⚠️ Make cancellation as easy as signup. Beyond being decent, "negative option" and click-to-cancel rules in several jurisdictions increasingly require it, and dark-pattern cancellation flows are a regulatory and chargeback risk.
§10. Marketplaces and Multi-Party Payments¶
[DURABLE] The moment money flows to someone other than you, the compliance surface changes dramatically. You may be handling funds on behalf of third parties, which in many jurisdictions is a regulated activity.
The standard answer: use a PSP's multi-party product (Stripe Connect, PayPal for Marketplaces, Adyen for Platforms) so they carry the licensing, KYC/KYB, and payout infrastructure. Building this yourself means money-transmitter licensing in the US (state by state) or a payment institution licence in the EU — a multi-year, multi-million undertaking that is almost never the right call.
What you still own: onboarding and KYC/KYB verification flows, the split logic (platform fee, seller net, tax), payout scheduling and reserves, negative balances (a seller refunds after you've paid them out — who eats it?), and 1099-K / DAC7 reporting.
⚠️ Chargeback liability in a marketplace is a contract question with a technical implementation. Decide explicitly whether the platform or the seller bears it, and build the ledger to reflect that decision.
§11. Tax and Cross-Border¶
[DURABLE] Sales tax is far harder than engineers expect, and it is a genuine liability rather than a rounding concern.
US sales tax post-Wayfair is economic nexus: you may owe in a state where you have no physical presence, based on revenue or transaction thresholds that vary by state. Roughly 11,000+ taxing jurisdictions, product-level taxability rules (is a digital download taxable? is a candy bar food?), and origin- vs. destination-based sourcing. EU VAT: destination-based for B2C digital services, with OSS/IOSS simplifying registration; reverse charge for B2B with a valid VAT number (validate it — VIES). Plus GST regimes in dozens of other countries with their own thresholds.
[DURABLE] Use a tax engine — Avalara, Vertex, Stripe Tax, TaxJar, Anrok. Hardcoded tax
rates are a liability, not a shortcut. Or use a merchant of record (§4.1 → ecommerce-payments-architecture-and-integration) and make it
their problem — which for small teams selling digital goods internationally is often the
correct engineering decision dressed as a commercial one.
Cross-border also means: customs and duties (DDP vs. DDU — surprise duty bills at delivery are a top cause of refused deliveries and chargebacks), restricted and sanctioned parties screening, local consumer-protection and returns law (the EU's 14-day withdrawal right), data residency, and currency: present prices in local currency, decide who bears FX risk, and note that dynamic currency conversion is generally bad for the customer and a conversion killer.
[VERSIONED] The European Accessibility Act's requirements for e-commerce services became enforceable on 28 June 2025 — for services in scope, accessibility is now a legal obligation in the EU, not a nice-to-have. Verify scope and exemptions for your business.
§12. The Platform Layer¶
12.1 Build vs. buy¶
[DURABLE] The honest default for most businesses is a SaaS platform, and teams routinely underestimate what they're rebuilding: catalog, variants, pricing rules, promotions, cart, checkout, payments, tax, shipping rate calculation, order management, returns, admin tooling, and the reporting the business will ask for in month three.
| Option | Fits |
|---|---|
| Shopify (+ Plus) | Most DTC and mid-market. Enormous app ecosystem; Shopify Payments' rates and the fee for using an external gateway are a real cost input |
| BigCommerce, Wix, Squarespace | SMB to mid-market, varying by catalog complexity |
| Adobe Commerce / Magento | Large, complex catalogs and B2B; heavy to run |
| Salesforce Commerce Cloud, SAP, Oracle | Enterprise, deep ERP integration |
| WooCommerce | WordPress-native, cheap to start, yours to operate |
| Commercetools, Elastic Path, Medusa, Saleor | Headless/composable — API-first, you build the front end |
| Custom | Genuinely unusual models. Rarely justified by "our business is special" |
12.2 Headless and composable¶
[CONTESTED] For: front-end freedom, multi-channel (web, app, kiosk, agent), best-of- breed components, better performance ceiling. Against: you now own the integration layer, which is a permanent team cost; more services to operate; and you lose the monolith's out-of-the-box admin. The honest test: are you actually constrained by the templating layer, or do you just want a nicer stack? Composable makes sense at scale and with a platform team; it is frequently a costly aesthetic choice below that.
[DURABLE] Whatever you choose, the storefront's job is speed. Core Web Vitals affect
both ranking and conversion, and the highest-leverage work is usually image optimization,
reducing third-party scripts (which is also §8.3 → ecommerce-payment-methods-sca-fraud-and-pci's security advice), and caching strategy.
§13. Catalog, Cart, and Checkout¶
13.1 The data model¶
Products vs. variants is the modelling decision everything else hangs off. A "product" with options (size, colour) has variants as the actual sellable units with their own SKU, price, and inventory. ⚠️ Getting this wrong forces a painful migration, because carts, orders, and inventory all reference the wrong grain.
Inventory: track available-to-promise, not just on-hand. Decide when you reserve — at cart (protects the customer, risks hoarding), at checkout start (a reasonable middle), or at order (risks overselling). Multi-location inventory and backorders turn this into a real allocation problem.
Pricing and promotions get complicated faster than any other area: price lists,
customer-group pricing, quantity breaks, currency-specific prices, and stacking rules for
discounts (order of application changes the total — decide and document it). ⚠️ Test
promotion logic adversarially; discount stacking is a business-logic vulnerability and
promo abuse is a real fraud category (§7.1 → ecommerce-payment-methods-sca-fraud-and-pci).
13.2 Checkout¶
[DURABLE] Checkout conversion is where the money is, and the levers are well-established: guest checkout (forced account creation is among the most reliably damaging choices you can make), minimal fields with sensible autofill and address autocomplete, wallets surfaced early (Apple/Google Pay skip the form entirely), all costs shown before the final step — surprise shipping and tax at the last screen is the top cited abandonment reason — a visible progress indicator, inline validation, trust signals, and a mobile experience designed first rather than adapted.
Accessibility is a conversion feature and, increasingly, a legal requirement (§11) — keyboard navigation, labelled inputs, sufficient contrast, and screen-reader-usable error messages.
⚠️ The webhook, not the redirect, confirms the order (§3.2 → ecommerce-payments-architecture-and-integration). Design the post-payment
experience so a customer who closes the tab still gets their order.
§14. Agentic Commerce¶
[VERSIONED — the newest layer here, moving fast, and full of premature certainty.]
14.1 What it is¶
AI agents completing purchases on a user's behalf, which breaks the classic model where a human clicks buy on a trusted page. That assumption underpins fraud liability, SCA, and dispute rights, so the protocols exist mainly to answer: how does the merchant know this agent is authorized, and who is accountable when it goes wrong?
14.2 The standards contest¶
| Protocol | Origin | Layer |
|---|---|---|
| ACP (Agentic Commerce Protocol) | OpenAI + Stripe, Sept 2025, Apache 2.0 | Agent-to-merchant checkout; shared payment tokens |
| UCP (Universal Commerce Protocol) | Google + Shopify, announced at NRF Jan 2026 | Full journey — discovery through post-purchase |
| AP2 (Agent Payments Protocol) | Google, 60+ partners; donated to the FIDO Alliance 28 April 2026 with v0.2 | Authorization and accountability — cryptographically signed mandates / verifiable credentials |
| x402 | Coinbase | HTTP 402 revival for stablecoin machine-to-machine micropayments |
| MPP (Machine Payments Protocol) | Stripe + Tempo, 18 March 2026 | Agent pre-authorizes a spending limit, streams micropayments |
| Visa Trusted Agent Protocol / Mastercard Agent Pay | The networks | Agent-scoped tokenization on existing rails |
⚠️ These are not interchangeable and they sit at different layers. A plausible reading of where it settles: UCP-style discovery and cart standards, AP2-style verifiable authorization underneath, and execution layers each major AI surface adopts its own way.
14.3 The reality check¶
⚠️ The obvious narrative is wrong in an instructive way. OpenAI's Instant Checkout — the launch product for ACP, which put ChatGPT purchasing in front of the largest consumer AI audience — was retired on 5 March 2026, after roughly thirty Shopify merchants integrated, with OpenAI pivoting to retailer-operated ChatGPT Apps. And Forrester's data shows US consumer adoption of Instant Checkout remained low and stagnant from debut to discontinuation; interest in AI agents making purchases is growing but described as lukewarm.
[CONTESTED] So: is this real? For building now: the infrastructure investment from Stripe, Google, Shopify, Visa, Mastercard and PayPal is enormous, the standards are consolidating rather than proliferating, and being invisible to agent-mediated discovery is a genuine risk if it lands. Against: consumer demand has not yet materialized, the flagship implementation was withdrawn within six months, and the protocols are still churning — ACP's own spec history shows five revisions between September 2025 and April 2026.
[DURABLE] The advice that holds either way is not really about agents: the thing that makes you legible to an AI agent is clean, accurate, machine-readable product data — precise titles, real-time stock and pricing, clear specs, standards-based schema, and a catalog API that doesn't require executing your JavaScript. That work pays off in search, in marketplaces, in feeds, and in agent surfaces alike, which makes it the rare hedge with no downside. Adopt a payment standard rather than building your own agent-payment flow — rolling your own means inheriting all the fraud liability yourself.
Plugin: ecommerce-development · View SKILL.md on GitHub