Store
Sell eligible digital and future physical products.
One commercial layer for many kinds of value.
Products and services flow through catalog, offer, checkout, order, delivery and support without pretending an unavailable payment rail exists.
MOJPLAYWIN / CURATED
Service Orders
Turn productized services into trackable orders.
Subscriptions
Recurring plans only when billing and cancellation flows are operational.
Building checkout that survives retries
A robust checkout moves through explicit states such as draft, pending payment, confirmed, fulfilled, expired and refunded. An order number and a payment event identifier are not interchangeable. Use idempotency keys so resending a payment callback does not fulfil an item twice. Keep a durable ledger of state transitions with timestamps and clearly defined permitted changes.
Never grant a download merely because a browser says payment succeeded. Verify independently with the trusted processor or network and reconcile the amount, currency, merchant destination and order reference. Build a way to investigate underpayments, late payments and failed delivery without losing customer records. Include accessible forms, unambiguous prices, transparent terms, and a safe fallback when a third-party service is unavailable.
Apply this in three steps
- Draw the states and permitted transitions.
- Simulate duplicate notifications, wrong amounts and interrupted callbacks.
- Run a complete test order with receipt and entitlement verification before public launch.
Key takeaway: Reliable commerce is the consistent agreement of payment, order and fulfilment records.
Explore more free field notes →An order state machine for dependable digital sales
Digital checkout should be modeled as a set of permitted transitions, not a collection of unrelated status flags. A typical lifecycle includes created, awaiting payment, verified, fulfilled, cancelled and refunded. The system needs to explain which event moves an order from one state to another.
Working method
Make payment callbacks idempotent, reconcile amount and currency against the invoice, and preserve an immutable record of verification. A customer refreshing a page or a provider repeating a callback must not grant extra licenses or duplicate charges. Download entitlements should be associated with a specific paid order.
Worked example
Suppose a user submits the same gateway callback three times. A robust handler checks the unique transaction identifier and existing order state before updating the ledger. The first valid confirmation can grant the download; subsequent identical notifications should leave entitlements unchanged and remain visible in the audit trail.
Common mistake
A green payment icon in the browser is not proof of money received or a file delivered.
Action checklist
- Diagram permitted states and transitions.
- Simulate duplicate, late and incorrect payments.
- Test fulfillment, refund and interrupted-session recovery.
Designing returns and customer support for downloads
Customer support begins before a transaction. Buyers should understand the product's format, compatibility, license, price, delivery method and applicable cancellation terms. Clear information reduces disputes and sets expectations for digital goods that cannot be physically returned.
Working method
Design a support workflow that records the order reference, reported problem, device or app version, reproducible steps and resolution. Offer sensible categories for failed download, wrong file, corrupted archive, compatibility problems, billing questions and refund requests. Restrict staff access to necessary information and never ask customers to disclose wallet seed phrases.
Worked example
For an ebook that downloads but does not open, the first response can provide verified checksums, a supported reader list and a replacement download link if allowed. If the product was misdescribed, follow the published terms and relevant consumer law rather than forcing the customer into repeated troubleshooting.
Common mistake
Never promise unlimited lifetime support unless the organization can actually provide it.
Action checklist
- Write a plain-language delivery and refund policy.
- Test common support cases without exposing payment secrets.
- Track resolution and recurring defects for product improvement.
Building privacy-aware product funnels that reveal friction
A conversion funnel tracks the steps visitors choose to complete, not just page-view counts. Relevant questions include whether people understand a product, whether pricing feels clear and whether payment or delivery fails after intent is established. Event definitions must be consistent before dashboards become useful.
Implementation method
Map the journey from landing page to product view, initiated checkout, verified payment and successful entitlement delivery. Instrument only the minimum data needed; avoid collecting full payment credentials, wallet secrets or unnecessary identifying details. Deduplicate events with stable identifiers and separate technical errors from user decisions.
Applied example
In a hypothetical sample, 1,000 visitors see a digital product, 100 start checkout, 40 reach a verified payment state and 38 successfully download it. The funnel is 10% checkout initiation, 4% confirmed orders and 3.8% successful delivery relative to product views. The two failed deliveries deserve investigation; treating them as ordinary buyer abandonment hides a service defect.
Important limitation
A conversion rate without traffic source, reporting interval and denominator can be misleading.
Action checklist
- Define a versioned event glossary.
- Track confirmed payment and fulfilled delivery separately.
- Review errors, privacy limits and cohort differences.