Customers and support notes

A customer detail brings together App User IDs, current access, store subscription lifecycle, transactions, and immutable event history. It is an investigation surface, not an arbitrary grant/refund editor.

Locate the customer

Select the correct project/app, open Customers, and search by the app identity or other supported list filters. Open the result and confirm the App User IDs listed on the profile against the stable identity your application backend authenticates.

A customer token is not itself a purchase. If a user has never produced qualifying receipt evidence, they may not yet have a customer alias/subscriber record. A missing record is different from an existing customer with inactive access.

Read the profile

The summary shows spend information, subscription lifecycle count, current access, and the first recorded customer date. Spend is store-derived and currency-aware; missing accounting data is not proof of a zero-value purchase. Subscription records are renewal lineages, not a count of every transaction.

The profile tabs separate overview/lifecycle, history, and transactions. Use them to answer different questions:

• What can this user access now? Inspect the resolved access map and expiry.
• What did the store report? Inspect lifecycle status/phase and the event history.
• What was purchased or refunded? Open the transaction detail and its store identifiers.
• Why did ownership change? Inspect the receipt/restore observations and App User IDs around the change.

Interpret access correctly

Access is a union of mapped product grants across stores. An inactive subscription does not necessarily remove a lifetime or other-store grant. Cancellation can leave a paid period active until expiry. Expiry is evaluated at read time rather than waiting for a scheduled mutation.

Check the product's access mapping, grant mode, expiry, revocation, and the current owner of the purchase. A refunded transaction may affect one grant while another still grants pro. Access levels · Customer identity.

Add and maintain support notes

Owners and admins can add, edit, and delete notes from the customer profile. Notes are project-owned investigation context and do not alter store state, identity, purchases, access, or ledger events.

Use notes for a concise support case reference and the resolution. The current limit is 20 notes per customer and 1000 UTF-8 bytes per note. The form's character count can differ for non-ASCII text because backend limits are byte-based.

Do not paste API keys, customer tokens, store private keys, raw credentials, or unnecessary personal data into a note. Delete an obsolete note through its confirmation flow; this deletes the note, not the customer's history. Viewers can inspect the profile but cannot enter note write flows.

A repeatable support investigation

1. Confirm app, platform, and customer identity.
2. Locate the purchase/renewal transaction and note its product and store transaction ID.
3. Compare the verified expiry/revocation to the expected paid period.
4. Inspect the product access mapping and other grants contributing to the same level.
5. Review events for duplicate, late, refund, or restore observations.
6. Compare your application's broker subject and cached UI state to the current subscriber response.
7. Record the finding in a support note without credential material.

CherrySub currently does not offer a general customer-merge UI, manual premium override, store refund-issuance action, or self-service customer deletion. Use the migration and release-status guidance rather than assuming those operations exist.