DOCUMENTATION

PLANNED / PRODUCTPAY CONNECT

Continue with ProductPay.

A future permissioned sign-in standard that lets publisher software verify the correct buyer and product entitlement without receiving marketplace credentials or the buyer’s wider purchase history.

PLANNED — NOT AVAILABLE IN THE CURRENT MVP

Why it matters

The permanent Verified Help link puts ProductPay inside a product without requiring authentication changes. ProductPay Connect is the next layer: a publisher can place a recognizable button on its login or support page and request a narrowly scoped confirmation from ProductPay.

productpay

Continue with ProductPay

→

This changes ProductPay from a destination into permissioned infrastructure. Each publisher connection makes the buyer’s ownership account more useful, while every new buyer makes ProductPay more valuable to connected publishers.

Proposed authorization flow

  1. 01
    Publisher starts a request

    The verified publisher identifies its client, exact product, approved callback, state and PKCE challenge.

  2. 02
    ProductPay authenticates the buyer

    The buyer signs in or recovers the verified purchase inside ProductPay—not on the publisher page.

  3. 03
    Buyer sees the exact permission

    The consent screen names the publisher, product and entitlement facts requested.

  4. 04
    ProductPay returns a one-time code

    The publisher exchanges it server-to-server. The browser never receives a reusable platform secret.

  5. 05
    Publisher opens the correct experience

    The result can create or connect an account, admit the buyer to the product or prefill verified support.

  6. 06
    Lifecycle stays connected

    Signed refund, revocation and restoration events keep the publisher’s access decision synchronized.

Minimum product-scoped claims

Pairwise subject

A different stable ProductPay user reference for each publisher, preventing easy cross-publisher correlation.

Product identifier

Only the ProductPay product included in the authorization request.

Entitlement state

Active, scheduled, paused or revoked, plus authoritative start or expiry where available.

Verification class

Whether ownership comes from a connected authoritative purchase source.

Optional buyer field

A masked display address or other field only when the buyer explicitly approves it.

Never shared by default

Marketplace credentials

ProductPay never asks a publisher to receive or store a buyer’s marketplace password.

Real email

A ProductPay sign-in is not permission to acquire the buyer’s direct marketing identity.

Other products

The publisher cannot query the buyer’s library or discover unrelated purchases.

Raw receipt data

The default assertion is the minimum entitlement decision, not the complete transaction record.

Three delivery gates

GATE A · LIVEVerified Help links

Permanent product routes, recovery, self-service, verified support and funnel reporting.

GATE B · PILOTOne-time iGloo connection

Allowlisted clients and callbacks, signed one-time product connection and manual security review.

GATE C · STANDARDOAuth 2.1 / OIDC

Authorization code plus PKCE, discovery, rotating keys, client management, revocation and conformance testing.

Build gate

Do not rush the identity layer.

Proceed beyond Gate A only after buyers repeatedly use Verified Help, publishers keep the link installed, and ProductPay can operate recovery, session security and entitlement lifecycle updates reliably. ProductPay Connect creates a durable network effect, but it also makes ProductPay an identity provider.