DOCUMENTATION

REFERENCE / TRUST

Trust comes from clear boundaries.

ProductPay should say exactly what it knows, why it knows it and which party remains responsible. A useful access layer must never pretend to be the payment authority.

Authority model

Marketplace or checkout

Owns payment processing, the official receipt, transaction rules, refunds and disputes.

Publisher

Owns the product, access destination, fulfillment, product claims, support response and policy compliance.

ProductPay

Owns the verified handoff: activation, entitlement state, stable access route, organized support context and its audit history.

Buyer

Controls account access, product-scoped sharing, notification permission and future publisher connections.

Identity and purchase matching

The live purchase-recovery flow requires the matching checkout email and transaction identifier. Email alone is insufficient. Single-use claim links are private, expire and cannot be safely placed on a shared thank-you page.

ProductPay uses a server-side session cookie for the current buyer application. Publisher access uses an individual publisher session created from a work email and private publisher key. Publisher keys and integration secrets must never be placed in URLs or source code.

Data minimization

Masked operational views

Delivery and publisher views use masked buyer addresses. The database stores an email hash and masked display value for the current delivery workflow.

Scoped records

Access, support and entitlement reads are filtered to the authenticated buyer or publisher workflow that owns them.

Separate consent

Transactional delivery, account service, publisher communication and ProductPay marketing are different permissions.

Core consent rule

A ProductPay account, claim, imported receipt or support request must never silently subscribe the buyer to promotional email.

Support privacy

A verified case shares only the context needed to resolve the selected product issue. Private publisher notes use a separate message type and are excluded from buyer reads. Unrelated products, the buyer’s full library and marketplace credentials are not support context.

ProductPay can provide deterministic triage and suggested replies to a publisher, but the current system does not automatically send an AI-authored reply. Refund or cancellation outcomes must come from the responsible payment or publisher system.

Current security controls

  • Signed JVZoo notification verification and signed JSON adapter support.
  • Idempotent purchase events to prevent duplicate delivery on retries.
  • Same-origin requirements for browser mutations.
  • Request-body size caps and server-side field validation.
  • HTTP-only buyer and publisher session cookies.
  • Rate-limited purchase recovery and publisher login attempts.
  • Server-side entitlement checks before product access.
  • Restricted same-site return destinations after claim and recovery.
  • Immutable support workflow audit events and persistent purchase lifecycle records.

Non-negotiable product principles

  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.

Honest current limitations

  • JVZoo is the only live marketplace adapter in the current MVP.
  • Receipt forwarding and mailbox import are planned, not shipped.
  • ProductPay Connect sign-in is a planned identity layer, not a current login method.
  • The source-backed library assistant is not part of the current public release.
  • Browser push depends on production configuration, browser support and explicit device permission.
  • Scheduled-release push requires a later scheduled delivery worker.
  • ProductPay cannot guarantee the continued operation of an independent publisher or marketplace.