Files
Jason RhinelanderandClaude Opus 4.8 b6830f7e45 pro_backend: split get_pro_details into get_pro_status + get_payment_details (Delta #15)
The old combined get-details endpoint conflated a cheap entitlement check with a
heavy payment ledger; no client used the ledger beyond the latest item. Split it
into two endpoints (both a signed-request flip, new domains):

- get_pro_status (domain ProGetProStatus_; signed `master_pkey ‖ ts`) -- the hot
  "am I Pro?" path. Response: user_status, auto_renewing, expiry_ts,
  refund_requested_ts, grace_period_duration, error_report, and a single
  `latest_payment` (or none). No list, no pagination. C++ ProStatusResponse /
  parse_pro_status; C session_pro_backend_get_pro_status_response with a
  bool has_latest_payment + embedded latest_payment.
- get_payment_details (domain ProGetPayDetails; signed
  `master_pkey ‖ ts ‖ \0 ‖ limit ‖ \0 ‖ before`) -- paginated history. Request
  {limit, before}; response {payments_total, items, next_cursor}, no user_status.
  Keyset pagination: `before`/`next_cursor` is an opaque cursor (std::optional /
  const char* NULL at end-of-data), echoed verbatim, never parsed.

Payment-item parsing is factored into a shared parse_payment_item helper used by
both `latest_payment` and `items`. No "pro details" terminology survives
(identifiers, endpoints, domains, the error-report enum -> GET_PRO_STATUS_*).

C-API change (clients): get_pro_details_{request_build,response,response_parse,
response_free} and SESSION_PRO_BACKEND_GET_PRO_DETAILS_ENDPOINT are replaced by
get_pro_status_* and get_payment_details_* equivalents.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
2026-07-23 16:30:04 -03:00
..
2025-04-11 11:53:50 +10:00
2023-04-18 18:33:43 -03:00