Member membership and purchase history
Purpose and source contract
Extend the existing member_get with an explicit membershipHistory selection. A person can inspect the selected member's membership-history tab, choose a membership/product row, and read one purchase-history page. No financial action, member edit, CSV export or current entitlement decision is part of this read.
The active Members/Container route admits OWNER or MANAGE_MEMBERS delegates. MembershipUsers/Container mounts MembershipHistoryList and MembershipHistoryDetail; TabBar links the detail/history tabs. The membershipUsers sagas, reducers and types consume membershipHistories, or subscriptionProductPurchaseHistories together with subscriptionProductTitle and pagination.currentPage/limit/totalEntries. The generic repository return type incorrectly reuses the member-list DTO; the active reducers and rendered fields control this workflow instead.
| Screen | Source request | Exact console path after /channels/:channelCode |
|---|---|---|
| Selected profile anchor | GET /seller/api/v2/channel-management/user-profiles/:profileId | Existing member detail |
| Membership history | GET /seller/api/v1/profiles/:profileId/membership-histories | members/membership-users/:profileId/membership-history |
| Selected product purchases | GET /seller/api/v1/profiles/:profileId/membership-histories/:mid/subscription-products/:subscriptionProductId/purchase-histories | members/membership-users/:profileId/membership-history/:mid/:id?page=:page&limit=:limit |
Use channel bearer and x-publ-channel-id for these reads. History needs no PAY issuer or private payment-service configuration. Purchase history starts at page 1/limit 15; source sizes are 15, 30, 50 and 100, synced to URL by usePagination. Membership mid is distinct from its numeric row id; subscriptionProductId is the selected numeric product id represented as a canonical string. The history list is unpaginated in source; fail instead of silently truncating excessive results.
Planned interface and preservation
member_get retains its existing basic/include behavior. membershipHistory accepts {kind:"memberships"} or {kind:"purchases",membershipMid,subscriptionProductId,page,limit}. Do not combine it with contact/additionalInformation/membershipSummary include: this is a separate source tab and does not silently add sensitive sections. The workflow checks channel/actor credentials, profile identity, the parent membership and selected product, rereads the projected history/page and profile, and rejects changes. A purchase target absent from the same member's observed history is not fetched. No pApp purchase endpoint or arbitrary API path is exposed.
Return raw status, type, date and exact price strings from the rendered fields. Do not infer successful payment, active access, refundable amount or canceled state from an unfamiliar status. Omit unknown payload fields, user/contact data and credentials. Sequential read stability is not an atomic snapshot. Results contain one exact current console destination; demo results contain none.