DOCUMENTATION

PRODUCTPAY / PRODUCT DOCUMENTATION · UPDATED 6 SEPTEMBER 2026

Post-purchase infrastructure for digital publishers.

VISION

A world where buyers can move from any digital-product checkout to working access and accountable support through one portable, permissioned ProductPay relationship—while marketplaces retain payment authority and publishers retain responsibility for their products.

01

THE ONE OBJECTIVE

Make every verified digital purchase immediately useful to the buyer and measurably valuable to the publisher.

This is the test for every feature. It must create real buyer utility and a measurable publisher outcome—activation, successful access, better support or an earned repeat relationship.

02

CURRENT RELEASE

What ProductPay does now.

LIVEVerified delivery

A connected purchase can create the buyer account and unlock the correct iGloo collection.

LIVEVerified help

Product access is checked before a support case opens with ownership context attached.

12 CAPABILITIESMeasurable relationships

Publishers can see activation, access, support and repeat-customer signals without treating service activity as marketing permission.

03

DOCUMENTATION MAP

Follow the part you own.

BUYERSPurchase to access

Activation, the library, account recovery, access states and notifications.

Read guide PUBLISHERSConnect a product

Catalog, campaigns, checkout mapping, delivery testing and operational health.

Read guide VERIFIED HELPSupport with context

Permanent links, ownership-aware routing, self-service and publisher tools.

Read guide TRUSTClear boundaries

Authority, privacy, consent, security controls and product limitations.

Read guide
04

CAPABILITY STATUS

Live, planned and deliberately excluded.

LIVE

Current MVP

  • Receive signed JVZoo purchase lifecycle events and map offers to ProductPay campaigns.
  • Create or match a private buyer account from a verified delivery.
  • Unlock one product or a complete launch collection from a single purchase.
  • Keep a stable ProductPay access doorway while a publisher destination changes.
  • Pause and restore entitlements when verified refund or restoration events arrive.
  • Recover a purchase with the matching checkout email and transaction identifier.
  • Provide a permanent product-specific verified-help URL.
  • Diagnose access before opening support and attach verified purchase context to the case.
  • Give publishers delivery health, purchase journey, help-funnel and verified-support views.
  • Identify repeat, activated and highly engaged customers from verified purchase and product-use signals without inventing revenue.
  • Generate publisher help links, embeddable buttons and downloadable QR codes.
  • Notify buyers inside ProductPay and support browser push where enabled.
PLANNED

After proof

  • ProductPay Connect: product-scoped sign-in and entitlement confirmation for publisher software.
  • Additional checkout and marketplace adapters chosen from observed buyer and launch demand.
  • Receipt forwarding/import for purchases not delivered through a connected publisher.
  • A source-backed assistant that answers only from owned products and approved material.
  • Buyer-controlled purchase address and carefully tested communication relay.
BOUNDARY

Not ProductPay today

  • Processing or holding customer payments.
  • Replacing marketplace receipts, refund rules or dispute processes.
  • Acting as merchant of record or refund arbitrator.
  • Sharing marketplace passwords or a buyer’s unrelated purchase history.
  • Automatically sending AI-written support replies or promising unconfirmed outcomes.
  • Using product delivery as permission for promotional email.
05

OPERATING PRINCIPLES

The rules behind the product.

  1. 01

    The marketplace remains the source of truth for payment, receipts, refunds and disputes.

  2. 02

    ProductPay begins after checkout: activation, entitlement, stable access and verified support.

  3. 03

    Buyer utility comes first: the buyer app is free, while publishers fund measurable post-purchase outcomes.

  4. 04

    Ownership must be proven before access or private support context is released.

  5. 05

    A buyer shares only the identity and entitlement facts required for one product.

  6. 06

    Service access never silently creates marketing consent.

  7. 07

    ProductPay never claims an external action succeeded without authoritative confirmation.