Digital delivery
A paid digital product can activate only after a successful payment event maps idempotently to a protected entitlement or delivery record.
Prepared · inactiveO030 · direct commerce foundation
Built to sell. Not pretending to sell yet.
ICU now has a direct-commerce contract for digital products, print-on-demand goods and supplier-fulfilled products. Checkout stays unavailable until payment confirmation, product pricing, fulfillment, shipping, returns, tax treatment and provider connections are actually verified.
0 sellable SKUs0 active checkout destinations0 live fulfillment integrationsPrint on demand
POD adds provider variant mapping, order submission, signed webhook handling, shipment state, shipping regions and returns/reprint policy.
Prepared · inactiveSupplier fulfillment
Supplier goods additionally require a verified supplier relationship, SKU/inventory truth, order submission and tracking path.
Prepared · inactiveThe payment-to-fulfillment boundary
- A sellable SKU must have a verified price, currency, fulfillment class and policy set.
- The server creates checkout only when a live payment configuration is active.
- A verified payment event, not a browser success redirect, advances the order to paid.
- An idempotent ICU order/entitlement record queues fulfillment exactly once.
- The correct adapter submits digital access, POD production or supplier fulfillment.
- Provider events update shipment/delivery/refund state without leaking customer data into the static site.
Current activation matrix
| Capability | Current state | What blocks activation |
|---|---|---|
| Checkout & payment | Inactive | No live Stripe configuration, price IDs or verified webhook endpoint. |
| Paid digital delivery | Inactive | No payment-confirmed entitlement path or approved sale price. |
| POD fulfillment | Inactive | No approved ICU provider SKU/variant mapping, credentials, shipping or returns configuration. |
| Supplier fulfillment | Inactive | No verified supplier agreement, inventory feed, order adapter or tracking path. |
| Tax / returns / shipping | Not configured | Product- and region-specific commercial decisions remain pending. |
Safety and trust rules
Provider tokens, webhook secrets, customer names, addresses, order payloads and payment details never belong in PUBLIC. Fulfillment handlers must verify provider events and be safe to run more than once. A redirect back to ICU is not proof that a payment succeeded.
Prepared pilot paths
The existing Premium Venture Kit is mapped as a real source asset for a future paid-digital path, but remains not sellable because payment, price, protected entitlement, refund and tax decisions are not active. POD and supplier records are contract fixtures only, not public product claims.
The O031 unified Shop uses these gates and merchandising experience on top of these contracts. It must not bypass these activation gates.
Provider documentation used for this contract
- Stripe Checkout fulfillment — server-side fulfillment and payment-event handling.
- Printful API documentation — order lifecycle, fulfillment and webhooks.
- Printify API reference — order and webhook integration contract.
Direct-commerce infrastructure remains inactive: zero sellable SKUs and no live payments or checkout. M019 treats these as hard activation blockers. See readiness gates →