Proposal: Membership plans with shielded renewal reminders

[paulbrigner]

Summary

I wanted to share a feature idea for discussion, not as an expectation.

It seems like CipherPay could be a good fit for recurring memberships if it had a first-class membership layer on top of the existing subscription/invoice model, plus optional renewal reminders sent as tiny shielded memo payments to a member-provided address.

The actual membership payment would still happen through CipherPay’s normal renewal invoice / checkout flow. The outbound memo payment would only be used as a private reminder channel.

Why this might be useful

CipherPay already has recurring prices and subscription lifecycle logic, but it doesn’t seem to have a dedicated concept of a membership / entitlement yet.

This could be useful for:

• Clubs or communities with ongoing access
• Supporter memberships
• Subscriber-only services or content
• Merchant systems that need a simple “is this member currently active?” check

Proposed direction

Membership layer

Add a membership domain on top of recurring prices / subscriptions, with concepts like:

• membership_plans
• memberships
• renewal_tokens
• reminder_addresses

A merchant could create a membership plan backed by a recurring price, and a buyer could enroll by paying for the first period.

Renewal reminder flow

• Member completes initial payment
• CipherPay creates or links a membership record
• Member optionally provides a shielded address for renewal reminders
• As renewal approaches, CipherPay creates a renewal invoice or checkout session
• CipherPay generates a one-click renewal URL
• CipherPay sends a tiny shielded payment with a memo containing the reminder + link
• If the member pays, the membership advances normally
• If not, the membership can move to past_due and later expired

Outbound reminder wallet

This would require a dedicated low-balance hot-wallet used only for reminder payments.

At a high level, it would need:

• A strict balance cap
• Queue-based sending
• Retry / failure tracking
• Audit logging
• Automatic pause if balance gets too low

Why it seems compatible with CipherPay

This feels like it could reuse a lot of what CipherPay already has:

• Recurring prices
• Subscription lifecycle logic
• Invoice generation
• Checkout flows
• Webhooks
• Background scheduling

So most of the new work would be around:

• Membership state
• Reminder address capture
• Renewal token links
• Outbound memo reminder delivery

Possible API surface

Possible endpoints might look something like:

• POST /api/membership-plans
• GET /api/membership-plans
• POST /api/memberships/enroll
• GET /api/memberships
• GET /api/memberships/{id}
• POST /api/memberships/{id}/reminder-address
• POST /api/memberships/{id}/cancel
• POST /api/memberships/{id}/send-reminder
• POST /api/memberships/verify
• GET /renew/{token}

Scope boundary

I’m not suggesting automatic wallet charging or storing member spending keys.

The idea would be:

• CipherPay still collects membership payments through its normal inbound flow
• The outbound wallet is only used to send tiny reminder memos

Open questions

• Does a membership layer fit the intended direction of CipherPay?
• Should reminder addresses be optional or required?
• Would membership verification justify the added API surface?
• Is an outbound memo wallet too far outside the project’s trust model?
• Would this be better as a lightweight extension of subscriptions rather than a new membership domain?

Closing

Thanks for considering this proposal. If it feels out of scope, no worries at all.