Customer Records and Access

Start with the customer context

Customer records are developer-scoped. Search/filter by the supported fields and date range, then review purchases, owned products, serials, activation devices, and verification state. Marketing permission is a separate property, not implied by the record existing.

Take care with ownership changes

A serial assigned to another customer cannot be claimed merely by knowing its text. Follow owner proof, verification, and the supported account path. Correcting an email address is not permission to transfer all product ownership.

For refund, dispute, or account-closure requests, follow the policy and support procedure. Never publish raw customer tables, last names, email addresses, serials, or tokens in public screenshots.

Support activity and deliberate grants

Permissioned customer tools also expose activity, plugin-connection events, and internal notes. Supported recovery actions can resend library/activation mail or reset activations. These are not a replacement for customer identity verification.

Manual product grants and suspend/restore/revoke operations require the relevant entitlement permissions and product scope. A grant of access is not authorization to start recurring billing. Keep the action, reason, and customer communication explicit.

Purchase refunds and documents

The Purchases table supports order references, filters, item detail, authorized invoice PDFs, exports, and permissioned refund previews. Refund an eligible full order or whole selected products within the initial 14-day window; do not substitute Remove Access for a payment refund. Review cumulative refunded items, payment state, original tax/fee amounts, and any recipient allocations.

A pending or needs-review refund is not complete. Use its operation reference and the current purchase state for support. Billing and finance summaries can lag the provider event until reconciliation; do not send the same refund again merely because one table has not refreshed.

Customer activation resets, when enabled

Developers can allow customer self-service resets for supported serial and entitlement licenses, with a configured cooldown. Only the signed-in owner of the license can request a reset. The confirmation clears the affected device activations and sessions together while preserving the license and product ownership.

A reset is not a refund, a new serial, or unlimited extra devices. Customers must reload the current state and wait for the next eligible reset when a cooldown applies.

Correct the identity without rewriting history

First and last names can be updated or cleared independently. Name and phone corrections can update the shared profile. Contact-only email correction is limited to an exclusive identity without a linked login and clears verification; linked email changes use the customer-verified account flow.

Verified customer email changes synchronize current contact records and queued deliveries, with billing-provider synchronization retried where needed. They do not rewrite issued invoices or already sent messages, and do not undo opt-outs. Last Login reflects recorded sign-in activity, not a support edit.

Current access and previous records

The customer account separates current licenses and plans from Previous licenses and Previous subscriptions. Ended or inactive records stay available in expandable history; a plan with remaining eligible paid-through access is not hidden merely because cancellation is scheduled.

A signed-in marketplace customer who already owns a product can open their library and downloads from its product page. This is an account-specific lookup, not a public ownership list. License-reset cooldowns show the next eligible date; resetting activations does not create another license.

Purchases and marketing preferences

Customer records and marketing contacts serve different purposes. Purchases and eligible account/serial activity can automatically enroll the associated developer contact; existing unsubscribes, complaints, and suppressions remain protected. Do not infer sending permission from the presence of a customer row.

Help a previous purchaser sign in

If a purchaser has never set a password, direct them to Reset password on your storefront with their purchase email. A blocked-storage message means their browser could not save the session; allowing required site data and retrying is different from changing product ownership. Do not issue another paid order or remove an entitlement to repair sign-in.

Purchase history also includes access records

The customer tables distinguish paid orders, subscription payments and access-only records. Access included with a subscription or another grant can appear without a new payment. These records have no invoice and do not add sales revenue. A subscription-earned product can display its original funding order and a $0 item amount; other access records use an ACCESS reference. Neither display is a new charge or refund permission.

A manual grant recorded for a customer who already owns the product retains the existing entitlement and serial. Hiding that manual history does not remove the original access. Use the appropriate original license or serial control for an intentional access change; no history action itself refunds money.

Login changes belong to the customer

Developer contact editing cannot replace a customer password or change a linked login email. The customer uses account settings and verifies an email change, or uses Reset password. A developer confirmation is not proof of control of a customer inbox.

Workspace-wide contact editing, deletion, customer import and verification resend require customers.manage and all-products scope. Product-assigned staff retain their permitted product-specific serial and purchase controls. Names and phone corrections can update a shared profile; they are not isolated storefront nicknames. An exclusive contact-only email correction clears verification and does not transfer purchases.

Permanent gifts and paid subscription ownership

A timed manual keep-products grant gives the customer permanent ownership of the products included when the developer makes that grant, without a payment. That original product snapshot remains owned after subscription cancellation, expiry or incomplete billing setup. Explicit developer access removal can revoke the grant. New products added later are not retroactively included.

A lifetime manual grant instead provides complimentary ongoing subscription access; it is not the timed-grant ownership model or evidence of a paid invoice. Ordinary access-only grants and unpaid checkout trials also do not create paid ownership.

Paid keep-products invoices establish their own product snapshots. Refunding or reversing a paid purchase affects that purchase, not an independent manual ownership grant. Future paid subscription benefits still require the separate billing setup, preview and customer confirmation; a gift is not permission to charge a card.