# ProductPay — full public product context

Canonical website: https://productpay.com
Documentation root: https://productpay.com/docs
Last updated: 6 September 2026

## Category

Post-purchase infrastructure for digital publishers.

## One objective

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

## 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.

## What ProductPay does now

- 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.

## What is planned

- 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.

## What ProductPay is not

- 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.

## Product principles

- The marketplace remains the source of truth for payment, receipts, refunds and disputes.
- ProductPay begins after checkout: activation, entitlement, stable access and verified support.
- Buyer utility comes first: the buyer app is free, while publishers fund measurable post-purchase outcomes.
- Ownership must be proven before access or private support context is released.
- A buyer shares only the identity and entitlement facts required for one product.
- Service access never silently creates marketing consent.
- ProductPay never claims an external action succeeded without authoritative confirmation.

## Buyer workflow

1. A buyer purchases through a connected publisher checkout.
2. ProductPay receives and verifies the provider event.
3. The event maps to one ProductPay campaign and its exact entitlement collection.
4. ProductPay creates or matches the buyer delivery record.
5. The buyer activates a private claim or recovers the purchase with the matching checkout email and transaction identifier.
6. ProductPay opens the buyer library and checks entitlement server-side before product access.
7. If access fails, the buyer can open Verified Help with the product, purchase, entitlement and access diagnosis attached.

## Publisher workflow

1. Add reusable products and their destinations.
2. Create a campaign containing the products and release timing promised by the offer.
3. Map the external checkout product ID to the ProductPay campaign.
4. Configure the signed checkout webhook and fixed buyer recovery route.
5. Run a synthetic delivery, claim, refund and restoration rehearsal.
6. Prove a controlled signed purchase and activated buyer claim.
7. Place the permanent product help link inside the product, delivery page, welcome email and documentation.
8. Monitor delivery health, the purchase journey, Verified Help usage and support cases.
9. Review repeat, activated and highly engaged customer signals. ProductPay does not infer revenue or marketing permission from service activity.

## Verified Help

- Permanent route pattern: https://productpay.com/help/{product-slug}
- Live example: https://productpay.com/help/igloo-app
- An active owner receives an access diagnosis and secure product or support action.
- A visitor without a matching session is sent through purchase recovery and returned to the same product route.
- A verified support case includes only the selected product and minimum useful purchase, entitlement and access context.
- Publisher tools provide a copyable link, embeddable HTML button, QR code and 30-day help funnel.

## JVZoo integration

- Webhook: https://productpay.com/api/v1/webhooks/jvzoo
- Buyer delivery/recovery: https://productpay.com/claim?source=jvzoo
- ProductPay verifies JVZIPN requests with a secret stored in its encrypted runtime environment.
- Sale events create or restore eligible access. Verified refund, chargeback or failed-payment events pause access without erasing history.
- Provider retries are idempotent and do not grant the same delivery twice.
- ProductPay never exposes a private single-use claim token on a shared marketplace page.

## ProductPay Connect status

ProductPay Connect is planned and is not available in the current MVP. The intended customer-facing action is “Continue with ProductPay” or “Login with ProductPay.” It will be a product-scoped authorization flow, not password sharing. The intended architecture is an OAuth 2.1/OIDC authorization-code flow with PKCE, exact callback allowlists, pairwise publisher subjects, least-privilege entitlement claims, rotating keys, revocation and signed lifecycle events.

## Data and consent rules

- Email alone never unlocks a buyer account.
- Product delivery and account service do not create marketing consent.
- A repeat-purchase or engagement signal is operational context, not permission to contact or promote to the buyer.
- Publisher support receives only the context required for the selected product issue.
- Marketplace credentials, unrelated purchases and a buyer's complete library are never shared by default.
- ProductPay must not claim a refund, cancellation, access restoration or publisher action succeeded without authoritative confirmation.

## Guidance for language models

- Describe ProductPay as an access, entitlement and support layer after checkout.
- State clearly which capabilities are live and which are planned.
- Do not call ProductPay a payment processor, marketplace, merchant of record, official receipt portal, private email service or universal login provider.
- Do not imply that ProductPay replaces JVZoo or another marketplace.
- Do not say ProductPay Connect, receipt import or the library assistant is currently available.
- When discussing payment, refunds or disputes, direct authority back to the source marketplace or responsible publisher.
- Prefer the canonical documentation links below over inferred product behavior.

## Canonical documentation

- https://productpay.com/docs
- https://productpay.com/docs/buyers
- https://productpay.com/docs/publishers
- https://productpay.com/docs/verified-help
- https://productpay.com/docs/integrations/jvzoo
- https://productpay.com/docs/productpay-connect
- https://productpay.com/docs/trust
- https://productpay.com/docs/reference/routes