New Ideas 💡
119Under consideration
Durable Metered Paywall Using Device-Based Identification
🔍 Problem Statement Pelcro's metered paywall relies on cookies, which means users can trivially bypass free-article limits by opening incognito windows, clearing cookies, or restarting the browser. This requires no technical skill and is regularly flagged by clients as a core weakness — undermining publisher confidence and estimated to cost 4–6 % of metered revenue. 💡 User Story As a publisher using Pelcro's metered paywall, I want free-article limits to persist across sessions using device-based identification, so that casual meter abuse via incognito mode or cookie clearing is significantly reduced — without requiring readers to log in for free articles or breaking SEO/crawler access. 🎯 Definition of Done (DoD) A feature is done when: ✔️ Given a reader on a metered site, when they exhaust their free-article limit and reopen the same browser in incognito mode or after clearing cookies, then the meter is not reset and the paywall continues to enforce the limit. ✔️ Crawler and bot access remains unaffected. ✔️ No login is required for free articles. ✔️ The feature does not claim cross-device or cross-browser enforcement (scope is same-browser, same-device only).
Add missing subscription fields to the API response
🔍 Problem Statement The Pelcro subscription API response is missing fields that clients need for integration and reporting (e.g. plan name, product name, custom fields). This forces developers to make additional API calls to assemble complete subscription data. 💡 User Story As a developer, I want all relevant subscription fields included in the API response, so that I can retrieve complete subscription data in a single call without additional lookups. 🎯 Definition of Done (DoD) A feature is done when: ✔️ Given a subscription API request (list or get), when the response is returned, then it includes all commonly needed fields (plan name, product name, custom fields, billing details) without requiring additional API calls.
Enable subscription changes for shipment-based plans
🔍 Problem Statement Pelcro currently does not allow subscription plan changes when either the current or target plan includes shipments. When a subscriber wants to upgrade, downgrade, or switch between shipment-based plans, customer service must manually cancel the existing subscription and create a new one — increasing operational overhead and preventing self-service for subscribers. 💡 User Story As a Pelcro admin, I want the platform and UI to support plan changes for shipment-based subscriptions, so that customer service teams and subscribers can switch plans without manual cancellation and re-creation. 🎯 Definition of Done (DoD) A feature is done when: ✔️ Given a subscriber on a shipment-based plan, when a plan change is initiated via the Pelcro admin UI or by the subscriber directly, then the change is processed successfully — applying existing plan-change rules (billing alignment, proration) — without requiring customer service to manually cancel and recreate the subscription.
Article gifting with metering
🔍 Problem Statement When a subscriber gifts an article behind a metered paywall, the recipient's meter is still decremented. There is no way to allow gifted articles to bypass the meter, which undermines the gifting experience and discourages sharing. 💡 User Story As a subscriber, I want to gift individual articles to non-subscribers without it counting against their meter, so that recipients can read the full article seamlessly and are encouraged to subscribe. 🎯 Definition of Done (DoD) A feature is done when: ✔️ Given a metered paywall, when a subscriber shares an article via the gifting feature, then the recipient can view the article in full without their own meter being decremented, and the gift link respects any configured expiry or usage limits.
Ability to impersonate a Customer Login using the OpenAPI
🔍 Problem Statement There is no way for admins to impersonate a customer login via the Core API. When troubleshooting customer-specific issues, support teams must ask the customer for screenshots or attempt to recreate their account state, which slows issue resolution and creates a poor support experience. 💡 User Story As a Pelcro admin, I want to impersonate a customer's login session via the Core API, so that I can see exactly what the customer sees and troubleshoot issues quickly without requiring their credentials or step-by-step screenshots. 🎯 Definition of Done (DoD) A feature is done when: ✔️ Given an admin with impersonation permissions, when they call the impersonation API endpoint with a customer ID, then a session token is returned that provides the same view and access as the target customer — and all impersonated actions are logged for audit purposes.
Standardize Field Naming Across Export Files
🔍Problem Statement Export files currently use inconsistent field names for the same data across different areas of the platform. For example, the subscription ID is labeled "ID" in Subscriptions exports, the customer ID is labeled "ID" in Customers exports, and "user_ID" in other exports. This inconsistency creates unnecessary complexity for customers building integrations and automations with tools such as Zapier and other external systems. 💡User Story As a Pelcro administrator integrating exported data with external systems, I want consistent field names across all exports so that I can build and maintain reliable automations without needing export-specific field mappings. 🎯Definition of Done ✔ Standardize field names for identical data across all export types (e.g., customer ID, subscription ID, invoice ID). ✔ Ensure existing and newly introduced exports follow the same naming convention. ✔ Update the export documentation to reflect the standardized field names.
Subscription Export Should Respect Selected Table Columns
Problem Statement Currently, subscription exports include all available columns regardless of the columns selected or displayed in the subscriptions table view. This creates unnecessary noise in exported files and makes it harder for users to export only the data relevant to their workflow. User Story As a platform user, I want subscription exports to include only the columns I selected in the subscriptions table, So that I can export cleaner, more relevant datasets without unnecessary fields. Definition of Done (DoD) Subscription exports only include columns currently selected/displayed in the table view. Hidden/unselected columns are excluded from the export. Column ordering in the export matches the table ordering where applicable. Existing filters and search criteria continue to apply correctly to exports. Export functionality remains supported for CSV and other existing export formats.
Introduce Pausing Subscriptions
Problem Statement Pelcro currently lacks a native “pause subscription” capability, forcing subscribers to cancel when they want a temporary break. This creates unnecessary churn, disrupts subscription lifecycle continuity, and negatively impacts retention metrics. Clients need a flexible, controlled way to allow subscribers to temporarily stop billing and access without terminating their subscription. Additionally, the absence of structured pause rules (e.g., duration limits, frequency caps) prevents consistent business logic across clients. User Story As a subscriber, I want to pause my subscription for up to 90 days once per year, So that I can temporarily stop billing and access without canceling my subscription, while retaining the ability to resume at any time. As an admin, I want the ability to override pause/resume states, So that I can assist users and resolve edge cases or support issues. Proposed Solution Introduce a Pause Subscription feature with controlled rules: Subscribers can pause their subscription once per calendar year Maximum pause duration: 90 days Billing is fully stopped during the pause Subscription automatically resumes at the end of the selected period Users can resume early at any time During pause, user access downgrades to free-tier entitlements Admins can override pause/resume states This feature must follow Pelcro’s API-first architecture, with full support across UI, API, SDK, and webhook layers. Scope & Components Affected UI (React Elements) Add “Pause Subscription” option in account settings Duration selector (up to 90 days) Display: Pause status Remaining pause time Resume button (early resume) Messaging for: “Once per year” restriction Access downgrade during pause API (Laravel Backend) New endpoints: POST /subscriptions/{id}/pause POST /subscriptions/{id}/resume Extend subscription resource: pause_start_at pause_end_at pause_used_this_year (boolean or counter) Logic for: Enforcing one pause per year Validating max 90-day duration Blocking billing during pause Automatic resume job (cron/queue) SDK (JS-SDK) Methods: pauseSubscription(subscriptionId, duration) resumeSubscription(subscriptionId) Expose pause metadata in subscription object Admin / Dashboard Admin controls to: Force pause Force resume Override annual limit (if needed) Visibility into pause history Webhooks / Integrations Events: subscription.paused subscription.resumed Include metadata: Pause duration Resume trigger (auto vs manual vs admin)
Ability to add metadata via dropdown
🔍 Problem Statement Admins need to attach structured metadata (e.g. department, campaign source, region) to customer or subscription records, but the current metadata input only supports free-text key-value pairs. This leads to inconsistent values, typos, and unreliable filtering or reporting. 💡 User Story As a Pelcro admin, I want to add metadata values via a dropdown of predefined options, so that metadata is consistent, typo-free, and reliably filterable across reports and segments. 🎯 Definition of Done (DoD) A feature is done when: ✔️ Given a metadata field configured with predefined dropdown options, when an admin adds metadata to a customer or subscription, then they can select from the predefined list and the saved value matches exactly — enabling reliable filtering and reporting.
Core API: Export Products and Plans
🔍 Problem Statement As a developer, the Core API lacks endpoints to retrieve the full catalogue of products and plans. Plans must be fetched product-by-product and there is no bulk products/plans export, which forces manual CSV downloads and prevents automated ingestion into data warehouses or analytics tools. 💡 User Story As a developer, I want to retrieve a full list of all products and all plans (across every product) via the Core API in a single paginated call, so that I can build integrations and automate data ingestion without manual exports or product-by-product lookups. 🎯 Definition of Done (DoD) ✔ Given a valid API token, when calling the list-all endpoints (e.g. GET /v2/products and GET /v2/plans), then all records are returned with full detail, paginated. ✔ The plans endpoint returns every plan across all products in one response (no product-by-product iteration required). ✔ This change will impact API — new products and plans list/export endpoints, documented and tested. ✔ Limitations: read-only in v1; write operations are out of scope.
Discovery
7Under consideration
Deferred & Recognized Revenue Report
🔍 Problem Statement Finance teams need to track how subscription revenue transitions from deferred to recognised over time. Without a Deferred & Recognised Revenue Report, reconciliation against accounting standards (ASC 606 / IFRS 15) requires manual spreadsheet work, increasing audit risk and operational overhead. 💡 User Story As a finance team member, I want a Deferred & Recognised Revenue Report in Pelcro, so that I can see the monthly breakdown of deferred vs. recognised revenue and produce audit-ready reports without manual calculations. 🎯 Definition of Done (DoD) A feature is done when: ✔️ Given a Pelcro organisation with active subscriptions, when a finance user opens the Deferred & Recognised Revenue Report, then it displays each subscription's total booked amount, the deferred balance, the monthly recognition schedule, and cumulative recognised-to-date — without requiring external exports or manual calculations.
Make first and last name optional fields for account creation when it's a company profile
🔍 Problem Statement When creating an account for a company or organisation, Pelcro still requires first and last name fields. This is unnecessary for corporate accounts and creates friction during onboarding — admins must enter placeholder values, which pollute customer data. 💡 User Story As a Pelcro admin, I want first and last name to be optional when the account is a company, so that corporate accounts can be created cleanly without placeholder name data. 🎯 Definition of Done (DoD) A feature is done when: ✔️ Given account creation for a company, when the admin omits first and last name, then the account is created successfully using only the company name — and the customer record displays correctly in the dashboard and API without placeholder values.
Improve collaborator on-boarding experience
🔍 Problem Statement The current process of adding collaborators in Pelcro is time-consuming and inefficient, particularly for clients like Crain that manage multiple Pelcro accounts. When a new employee needs access to multiple accounts, admins must invite them separately to each account, resulting in approximately 15–30 invitation emails. The collaborator must then accept each invitation individually to activate their access. Additionally, if an invitation expires or is not accepted, admins must delete the pending collaborator and add them again to generate a new invitation. This creates unnecessary administrative effort and complicates collaborator onboarding. 💡 User Story As a Pelcro admin managing multiple accounts, I want to invite and manage collaborators more efficiently across all my Pelcro accounts, so that employees can access their assigned accounts without receiving multiple invitation emails or having to complete repetitive activation steps. 🎯 Definition of Done (DoD) 1. Send Invitation Emails Only to New Users Given a collaborator has never registered with Pelcro, when an admin adds them to an account, then send an invitation email to complete their initial account setup. Given a collaborator already has an active Pelcro login, when an admin adds them to another Pelcro account, then grant access without requiring another registration or invitation acceptance. Ensure existing collaborators can access newly assigned accounts using their current login credentials. 2. Allow Admins to Resend Invitations Given a collaborator has not completed their initial account setup, then provide a Resend Invitation option. Given an admin clicks Resend Invitation, then generate and send a new invitation email without requiring the collaborator to be deleted and re-added. Ensure the latest invitation link allows the collaborator to complete their registration successfully. 3. Simplify Multi-Account Collaborator Access Given a collaborator already has an active Pelcro account, when they are added to additional Pelcro accounts, then their access should not remain in a Pending status awaiting individual acceptance. Given a collaborator is assigned to multiple Pelcro accounts, then they should be able to access all authorized accounts using a single login. Eliminate the need for collaborators to accept a separate invitation for every additional account. 4. Centralized Collaborator Management (Nice to Have) Provide a centralized interface where authorized admins can view collaborators across multiple Pelcro accounts. Allow admins to add an existing collaborator to multiple accounts from one interface. Allow admins to remove collaborator access from selected accounts without switching between accounts. Display the accounts each collaborator has access to, along with their corresponding roles and permissions. Ensure all actions respect existing account-level permissions and access controls. Feedback: The process for adding a collaborator in Pelcro is clunky and error-prone, especially for Pelcro clients with multiple accounts. When we hire a new employee, we often end up adding them as a collaborator on all of our Pelcro accounts. This results in them receiving 15 to 30 invite emails, and they must click a link in each email to confirm each account. Should they fail to do so, we must delete their collaborator record in each account, and re-add them to generate a new invite email. Here is what I would suggest: Pelcro should only send an invite email to the user if they have not yet se
Search function for collaborators
🔍 Problem Statement The lack of search functionality makes managing and finding existing collaborators time-consuming and inefficient. 💡 User Story As an admin, I want to search for existing collaborators by name or email address, so that I can quickly locate and manage collaborators without having to navigate through multiple pages. 🎯 Definition of Done (DoD) Given an admin accesses the Collaborators page, then display a search field above the collaborators list. Given an admin enters a collaborator's name or email address, then filter the collaborators list to display matching results. Given a search query is entered, then search across all existing collaborators, not just the 25 currently displayed on the page. Given an admin enters a partial name or email address, then return relevant matching collaborators. Given multiple collaborators match the search criteria, then display all matching results with pagination where applicable. Given no collaborators match the search query, then display an appropriate message indicating that no results were found. Given the search field is cleared, then restore the complete collaborators list with its existing pagination. Ensure the search functionality does not affect existing collaborator management actions or permissions. Feedback: Please add a search function to the collaborators view so I can easily find existing collaborators by name or email. Background: Our Pelcro accounts have over 100 collaborators. The collaborators page only displays 25 at a time, so finding an existing collaborator often requires clicking through several pages of results.
Sync Membership Address with Customer Default Shipping Address
🔍 Problem Statement Customers currently cannot update the address associated with their active memberships when they change their default shipping address, particularly when the custom UI does not expose the memberships view. This requires customers to contact Customer Service to make the change. 💡 User Story As a user, I want active memberships to automatically use the customer’s default shipping address when it is changed, so that customers can update their membership address without needing to contact Customer Service. 🎯 Definition of Done (DoD) ✔ ️When a customer changes their default shipping address, the new address is automatically assigned to their active membership(s). ✔ The behavior can be enabled/configured through the appropriate Pelcro setting.
Allow renewal of expired subscriptions
🔍 Problem Statement As a business owner of a print publication with non-auto-renew subscribers, I can't renew a subscription once it has expired, so I have to create a new one, which skews renewal and churn metrics and print fulfillment lists. This affects every publisher using the invoice-pay or check-pay renewal model, which is standard for regional magazines, trade publications, newsletters and journals. 💡 User Story As a business owner, I want expired subscriptions to be renewable, so that they're recorded as renewals of the same subscription rather than new subscriptions. 🎯 Definition of Done (DoD) ✔ Admins (from the dashboard) and subscribers (from their account) can renew an expired subscription. ✔ The renewal continues the same subscription record and is reported as a renewal, not a new subscription. ✔ This change will impact the Dashboard, UI and API, specifically the renew subscription action.
Send SMS and Facebook Messenger Messages via Automations
🔍 Problem Statement As a business user, I can only send campaigns to my segments over email, which limits reach to customers who don't engage by email. 💡 User Story As a business user, I want to send campaigns to my existing segments via SMS and Facebook Messenger, so that I can reach customers on their preferred channel. 🎯 Definition of Done (DoD) ✔ Given a segment in the automation tool, when a business user creates a campaign, then they can select email, SMS, or Facebook Messenger as the send channel and the message is delivered to that segment. ✔ This change will impact UI, API, and Integration, specifically the campaign/automation engine and the Integration Orchestrator (Twilio for SMS, Messenger Platform API for Facebook). ✔ This solution will include the following limitations: [clarify SMS provider]; sends to existing segments only; [clarify whether inbound replies are handled].
Tech Planning
3Committed and queued
Implement JWT Token Refresh Mechanism
Problem Statement When a user's auth token expires, and they relaunch the app, there is no way to silently restore their session. The current refresh endpoint only accepts a non-expired JWT, so once a token has expired, the app hits a dead end. Without a proper token recovery mechanism, users are forced to manually sign in again — creating unnecessary friction and drop-off at relaunch. Since the auth token is used in every request and is frequently exposed, extending the auth token’s TTL is not a secure resolution for this issue. User Story As a returning app user whose auth token has expired since their last session, I want the app to silently restore my session on launch without prompting me to sign in again, so that I can resume using the app immediately with my subscription state loaded, even if it has been last used long ago. Definition of Done A user object contains both a short-lived access token that cannot be refreshed and a long-lived refresh token. The refresh endpoint accepts a non-expired refresh JWT and returns a new short-lived access token along with a new refresh token. The authentication endpoint accepts a non-expired auth JWT and returns the requested information/performs the requested function. A refresh_ttl window is defined and enforced — tokens outside this window cannot be refreshed and require re-authentication. If the auth token is close to expiring, the app uses the stored refresh token to call the refresh endpoint on launch; if successful, the new refresh and auth tokens are stored and the session resumes silently. If the refresh fails (token outside refresh_ttl or invalid), the app falls back gracefully to the sign-in screen. Subscription state is successfully queried using the new auth token after a silent refresh. Changes are documented in the API reference.
Collaborator Roles, Permissions & Account Management
🔍 Problem Statement Pelcro's current collaborator permission model has two key issues: (1) any collaborator can delete other collaborators, which should be restricted to the Account Owner only; and (2) several roles lack capabilities they need — Sales cannot create/edit plans or export data for quoting and reporting, and Customer Service cannot void or cancel invoices, slowing issue resolution. 💡 User Story As a Pelcro Account Owner, I want collaborator deletion restricted to my role only, and I want the Sales and Customer Service roles to have the specific capabilities they need (plan management, data export, invoice voiding/cancellation), so that permissions match real operational responsibilities without over-granting destructive rights. 🎯 Definition of Done (DoD) A feature is done when: ✔️ Given the updated permission matrix, when a collaborator attempts to delete another collaborator, then only the Account Owner succeeds — all other roles receive a clear 'permission denied' error in both the UI and API. ✔️ When a Sales collaborator is logged in, then they can create/edit plans and export customers, subscriptions, and invoices — but cannot access access control, product settings, or delete any object. ✔️ When a support is logged in, then they can void and cancel invoices and update customer info — but cannot access plans, access controls, or delete any object. ✔️ As an Account Owner or Admin, I want to see the last login timestamp for each collaborator, so that I can identify dormant or inactive accounts during periodic security and compliance reviews. ✔️ Admins retain all existing delete permissions except collaborator deletion.
Fix the state name for the District of Columbia
Problem Statement When exporting data, the state District of Columbia is incorrectly exported as “District of Colombia.” This results in inaccurate state information in exported files. User Story As a user, I want District of Columbia to be spelled correctly in exports so that exported address data is accurate. Definition of Done Update the exported state value from “District of Colombia” to “District of Columbia.” Ensure the corrected spelling is used across applicable exports. No other state values or export functionality are affected. Feedback: when we do an export, the state is being exported as “District of Colombia” which is not the correct spelling. If this could be fixed ASAP that would be appreciated.
In Sprint
10Actively being built
Consumer Data Platform/CDP
🔍 Problem Statement As a publisher, I experience paywall targeting as a fixed attribute list set inside each individual paywall, which results in audiences I cannot express — anonymous readers with more than five page views in the last 30 days, for instance — receiving the same meter and gate as everyone else. 💡 User Story As a publisher, I want to define paywall targeting as a Pelcro segment rather than per-paywall attributes, so that an audience is described once and reused across paywalls. As a publisher, I want every attribute available in today's paywall targeting to also exist as a segment condition, so that deprecating paywall-level targeting costs me no capability I have now. As a publisher, I want to select a segment when I create a paywall, so that the paywall applies only to readers in that segment. [TBD: one segment per paywall, or several] As a publisher, I want to build segments over anonymous visitors from referral source and page-view frequency, so that I can target readers I know nothing else about. 🎯 Definition of Done (DoD) ✔ Given the segment builder, when a publisher creates a segment, then every attribute usable in paywall targeting today — country, platform, tag, URL, adblock — is available as a condition. ✔ Given a paywall, when a publisher configures targeting, then they select a segment, and the per-paywall attribute fields are deprecated in the UI. ✔ Given a reader in a targeted segment, when they load an article, then that paywall's frequency_limit and type_of_paywall apply instead of the untargeted paywall. ✔ Given each segment condition type, we should make sure the data will be available and can be evaluated client-side at paywall time. ✔ Given a paywall is displayed, when Paywall Displayed is logged, then the matched segment ID and applied meter limit are recorded. ✔ This solution will include the following limitations: anonymous identity is per-browser and resets on cookie clear; activity events are logged-in only and retained 3 months; geo is country-level at decision time; per-segment products, plans and campaigns out of scope.
Add first and last name to membership list export
Problem Statement The Membership List export does not currently include the customer's First Name and Last Name as separate columns, even though this information is already available on the customer record. User Story As a user exporting the Membership List, I want the customer's First Name and Last Name included as separate columns so that I can easily identify and work with member information in the exported file. Definition of Done Add First Name and Last Name as separate columns in the Membership List export. Pull both values from the associated customer record. Ensure the exported values match the names stored on the customer. Existing export columns and functionality remain unchanged. Feedback: We regularly export membership lists for group/corporate licenses and send them to customers so they can review and clean up the users on their license. The membership list export currently includes each member's email address but not their first and last name. Many members use email addresses in a first-initial-plus-last-name format (e.g. jsmith@company.com), which makes it hard for customers to tell who each user is. We'd like to request that first name and last name be added as separate columns in the membership list export. Current Behavior Customer search and customer export: First and last name appear for almost all of these users. Membership list export: Only the email address is included, with no first or last name. Why We Can't Use the Customer Export Instead We no longer delete customer records, so the customer export includes users who have been removed from a license but still exist as customers. The membership list is the only accurate source of who is currently on a license, which is why we need the names in that export specifically. Requested Change Add First Name and Last Name as separate columns in the membership list export, pulled from the customer record (where the names are already stored).
Support Stripe Link payment method on the platform
Problem Statement Stripe's Link payment method syncs correctly to Pelcro's DB, but it is not displayed on the platform (e.g., on the customer's payment methods list). Link is also not listed as supported in our docs (https://docs.pelcro.com/docs/stripe#supported-payment-methods), so the behavior is currently unofficial and inconsistent: the data exists, but admins can't see or work with it. User Story As an admin/client, I want Link payment methods saved through Stripe to appear on the customer record, so that I can see how a customer is paying and allow customers who have Link as the only payment method to pay invoices correctly Definition of Done - A Link payment method synced from Stripe is displayed on the platform wherever other payment methods appear (customer payment methods, subscription details), with a clear label. - Link is usable as the payment source for subscription renewals and invoice payments, or its limitations are explicitly documented. - Existing Link payment methods already synced to the DB display correctly with no re-sync or backfill needed (or a backfill is provided if required).
Allow auto renew gifts
🔍 Problem Statement As a publisher or operations admin using Pelcro, I experience that all gift subscriptions are treated as one-time purchases, regardless of the plan’s renewal configuration, which results in inability to offer auto-renewing gift subscriptions and inconsistent renewal behavior compared to standard subscriptions. 💡 User Story As a publisher or subscription admin, I want gift subscriptions to inherit their renewal behavior from the selected pricing plan, so that one-time and auto-renewing gift subscriptions are supported natively and behave predictably. 🎯 Definition of Done (DoD) A feature is done when: ✔ Given a pricing plan with renewal_type = self-renew, (NOTHING CHANGES) when a gift subscription is created using this plan, then the gift subscription remains one-time and does not auto-renew, matching current behavior. ✔ Given a pricing plan with renewal_type = auto-renew, when a gift subscription is created using this plan, then the gift subscription auto-renews according to the plan’s billing cycle using Pelcro’s standard renewal and dunning logic. ✔ This change will impact API, specifically subscription creation and renewal logic for gift subscriptions in the backend. ✔ This solution will include the following limitations: Existing one-time gift subscriptions are not retroactively converted to auto-renewing Renewal behavior is determined only at subscription creation time No UI changes are included as part of this feature No mixed renewal behavior within a single gift subscription is supported
Legal Consent Checked by Default in Checkout
🔍 Problem Statement As a publisher, I experience friction at checkout when a customer must input their checkmark, which results in lost revenue. 💡 User Story As a publisher, I want the option for enableLegalConsent checkmark to be enabled by default, so that I can streamline my checkout process. 🎯 Definition of Done (DoD) A feature is done when: ✔ ️ Given the enableLegalConsent setting is used, when a second setting is introduced to toggle on the check by default, then the checkmark is enabled in the checkout flow. ✔ This change will impact [UI / API / SDK / Integration], specifically [describe endpoint, component, or area affected]. ✔ ️ This solution will include the following limitations [list constraints, edge cases, or scenarios not supported].
AI usage dashboard: tokens and cost by service
🔍 Problem Statement As a business user, I have no visibility into the cost consumed by Pelcro's AI services, which prevents me from tracking and managing my AI spend. 💡 User Story As a business user, I want a dashboard showing token consumption and cost broken down by AI service, so that I can monitor and manage my AI usage. 🎯 Definition of Done (DoD) ✔ Given AI usage across services, when a business user opens the AI usage dashboard, then tokens consumed and associated cost are displayed per service (e.g. AI coding agent, AI customer service). ✔ This change will impact UI and API, specifically a new AI usage/metering endpoint and the dashboard. ✔ All AI projects use the centralized LangfuseTracer::trace() method, which detects and sets account_id, site_id and user_id as trace tags on every trace, at all times. ✔ An hourly cron job pulls the previous day's usage from Langfuse and saves only what is required (date, account, service, cost, input tokens, output tokens) in a local table. The dashboard reads from that table, not from Langfuse. ✔ The cron job stays within the Langfuse Metrics API rate limit (100 requests/hour on Core, shared org-wide) and handles 429 responses by waiting for Retry-After and retrying. ✔ This solution will include the following limitations: per-service aggregation only.
Ticketing: automated CSAT survey emails on ticket solved
🔍 Problem Statement As a support manager, I can't collect satisfaction feedback on solved tickets, which leaves us with no CSAT data after leaving Zendesk. 💡 User Story As a support admin, I want to enable an automatic CSAT survey email in the Email Center, so that customers are asked for feedback after their ticket is solved. As a support manager, I want CSAT responses visible on the platform, so that I can review satisfaction per ticket and per agent without leaving Pelcro. 🎯 Definition of Done (DoD) ✔ Given CSAT is enabled in the Email Center, when a ticket has been Solved for 24 hours, then a survey email is sent to the ticket's customer. ✔ Given a Solved ticket, when it is reopened before the 24 hours elapse, then the scheduled survey is cancelled. ✔ Given a survey email, when the customer selects Good or Bad and optionally adds a comment, then the rating and comment are saved on the ticket. ✔ Given a ticket with a CSAT response, when an agent opens Ticket Details, then the rating, comment, and response date are displayed. ✔ Given the Tickets list, when an agent views or filters it, then a CSAT column shows each ticket's rating and the list can be filtered by rating. ✔ Given a ticket that already received a survey, when it is reopened and solved again, then no second survey is sent. ✔ Given a ticket with no customer email, or CSAT disabled in the Email Center, when the ticket is solved, then no survey is sent. ✔ This change will impact UI / API, specifically the Email Center CSAT template and toggle, the ticket status-change scheduler, a public survey-response endpoint, CSAT fields on the ticket resource, Ticket Details, and the Tickets list. ✔ This solution will include the following limitations: single survey template; binary Good/Bad rating; fixed 24-hour delay (not configurable); no aggregate CSAT dashboard or score trends in v1; survey link expiry.
Ticketing: canned Tickets report under Reporting > Customer Service
🔍 Problem Statement As a support manager, I can't see a ticketing performance report in Pelcro like Zendesk's canned dashboards, which forces manual tracking of support performance. 💡 User Story As a support manager, I want a predefined Tickets report under Reporting, so that I can monitor ticket volume, satisfaction, and response times at a glance for a chosen timeframe. As a support manager, I want to see the CSAT responses customers submitted, so that I can understand the reasons behind the satisfaction score. As a support manager, I want to export the report, so that I can share it outside Pelcro. 🎯 Definition of Done (DoD) ✔ Given the Reporting page, when a manager opens it, then a new Customer Service section contains a canned Tickets report. ✔ Given the Tickets report, when it loads, then it displays fixed widgets for ticket volume, tickets per status, satisfaction score, CSAT responses, median first-reply time, and median resolution time. ✔ Given the Tickets report, when a manager selects a timeframe (last 7, 30, 90 days, or custom range), then all widgets reflect tickets created within that timeframe. ✔ Given a selected timeframe, when the report loads, then the volume widget shows the total number of tickets created in that timeframe. ✔ Given a selected timeframe, when the report loads, then the status widget shows the ticket count and percentage per status (Open, Pending, On-hold, Solved). ✔ Given CSAT responses in the timeframe, when the report loads, then the satisfaction widget shows the score as Good ÷ (Good + Bad), with Good and Bad counts. ✔ Given CSAT responses in the timeframe, when the report loads, then the CSAT responses widget lists each response with ticket ID, customer, assignee, rating, comment, and submission date, newest first. ✔ Given a CSAT response in the list, when a manager clicks its ticket ID, then the related ticket opens in Ticket Details. ✔ Given tickets in the timeframe, when the report loads, then it shows median first-reply time (created → first agent reply) and median resolution time (created → first Solved). ✔ Given the Tickets report, when a manager clicks Export, then a CSV with all widget figures and the CSAT responses list for the selected timeframe is downloaded. ✔ This change will impact UI / API, specifically a new Customer Service section on the Reporting page and a reporting endpoint returning the report figures and CSAT responses by timeframe.
Surface Organization Field as Part of Checkout
🔍 Problem Statement As an Pelcro user, organizations cannot self identify as an organization in checkout, which results in unnecessary labor for me and confusion for my customers. 💡 User Story As a Pelcro user, I want the organization system to be self serve, so that my clients are able to correctly purchase and establish organizations for themselves. As a membership owner buying a multi-seat plan, I want to enter my organization name at checkout, so that my membership is tied to that organization. As a publisher admin, I want members added to a membership linked to the owner's organization, so that support can find any seat by organization. As a publisher admin, I want to require the organization field on membership plans, so that institutional purchases never land without one. 🎯 Definition of Done (DoD) A feature is done when: ✔ Given a membership plan with organization capture enabled, when a customer chooses a multi-user plan, then a mandatory free-text organization input is shown at checkout. ✔ Given a membership plan is purchased by an organization owner, then the membership is registered as an organization and the purchaser is the organization's owner. ✔ Given an organization name is submitted, when the membership subscription is created, then a new organization record is created and linked to the owner and membership. ✔ Given the purchaser already has an organization on their profile, when the membership is created, then their profile organization is kept (only filled in when empty), and the new organization is still linked to the membership with the purchaser as owner. ✔ Given a member accepts an invite to that membership, when their seat activates, then the member is linked to the membership's organization. ✔ Given the member already has an organization on their profile, when their seat activates, then their profile organization is kept (only filled in when empty), and they are still linked to the membership's organization. ✔ Given an organization owner or member is logged in, when the customer views their subscription, then their current organization is displayed and named as part of their subscription. ✔ Given the organization input is shown, when the customer types, then no existing organization names are suggested or shown. ✔ Given the organization input is shown, when the customer types, Pelcro does not check the organization name against existing organizations or indicate that a matching organization already exists. ✔ Given the organization input is shown, when the customer types in an organization that already exists, Pelcro creates a new separated organization. Organization names are not unique; the organization record is the identifier.
Support Avatax with Ecommerce
Problem Statement Pelcro currently does not support AvaTax tax calculation for e-commerce transactions. E-commerce SKUs may require different AvaTax tax codes, and taxes must also be handled correctly when orders are refunded or items are returned. User Story As a merchant using AvaTax, I want Pelcro to calculate taxes for e-commerce purchases based on each SKU’s AvaTax tax code so that the correct taxes are applied to purchases, refunds, and returns. Definition of Done Support AvaTax tax calculation for e-commerce transactions. Allow an AvaTax tax code to be configured per SKU. Send the applicable SKU tax code to AvaTax when calculating tax. Support different tax codes for different SKUs within the same order. Calculate and display the applicable tax correctly during e-commerce checkout. Ensure AvaTax-calculated taxes are reflected correctly on the resulting order/invoice. Support full and partial refunds with the corresponding tax adjustment. Support item returns and correctly reverse/adjust the associated tax. Refund and return tax behavior should be consistent with Pelcro's existing tax behavior. Existing e-commerce flows that do not use AvaTax remain unaffected.
Done
6Recently shipped
Improve Coupon Management & Flexibility
🔍 Problem Statement Pelcro’s current coupon functionality has limitations that make it difficult to support more flexible promotional campaigns. Coupon activation is primarily controlled through dates, promotions cannot be scheduled at a specific time of day, and discounts on annual plans cannot repeat across multiple years before returning to the regular subscription price. Coupon functionality should be enhanced to provide publishers with greater control over activation, scheduling, and discount duration. 💡 User Story As a Pelcro admin, I want more flexibility when configuring and managing coupons, so that I can run different promotional strategies without manual workarounds. 🎯 Definition of Done (DoD) ✔️ Active / Inactive Toggle Add an Active/Inactive toggle for coupons. Deactivating a coupon immediately prevents it from being used. Reactivating it allows it to be used again, subject to its other conditions. Toggle is available from the coupon management UI. ✔️ Start & End Date/Time Allow admins to configure a specific start date/time and end date/time. Coupon automatically activates and expires at the configured times. Supports time-sensitive promotions such as flash sales. ✔️ Multi-Year / Repeating Annual Discounts Support repeating coupon discounts for annual plans across multiple years. Admin can specify how many annual billing cycles the discount applies to. Example: apply a discount for 4 annual renewals, then automatically renew at the plan’s regular price starting in year 5. Supports use cases such as student pricing and multi-year rate-lock campaigns. ✔️ Existing coupon functionality and previously configured coupons continue to work without disruption.
Reorder pricing plans
🔍 Problem Statement As a Pelcro admin, plans display in a fixed creation-order on both the Platform UI and the Plan Selection Modal (Elements UI), which gives customers an unintuitive sequence — especially when multiple tiers or region-specific plans exist. 💡 User Story As an admin, I want to drag-and-drop plans into a custom order from Products → Plans, so the order I set is exactly what customers see in every plan-selection surface. 🎯 Definition of Done (DoD) ✔ Given the Platform → Products → Plans page, when an admin drags a plan into a new position, then the new order is auto-saved (no Save button) and persisted at the plan level. ✔ Plan Modal, Change-Plan flow, and Checkout plan selector all respect sort_order from the API; no caching conflicts. ✔ This change will impact UI / API / SDK — specifically the Plans page (Platform UI), the plans Core API (new sort_order field), and the ReactJS Elements Plan Modal component. ✔ Limitations: plans without sort_order default to creation order (backward-compatible).
Make Shipping Address Optional on new checkout UI
🔍 Problem Statement The Shipping Address section on the new checkout UI displays by default and cannot be hidden, even for plans that don't require shipping information. 💡 User Story As a business owner, I want the Shipping Address field to show or hide dynamically based on the shipping requirement configured on the selected plan, so that customers aren't shown irrelevant fields at checkout. 🎯 Definition of Done (DoD) ✔ Given a plan configured without a shipping address requirement, when a subscriber reaches checkout, then the Shipping Address section is not displayed. ✔ Given a plan configured with a shipping address requirement, when a subscriber reaches checkout, then the Shipping Address section is displayed and required. ✔ This change will impact UI, specifically the checkout Shipping Address section.
Trigger Renewal/Expiration by Shipments Remaining for Print Subscriptions
🔍 Problem Statement As a publisher managing shipment-based print subscriptions, renewal and expiration are tied to end_date/renewal_date, which don't reflect actual shipments remaining. 💡 User Story As a publisher, I want auto-renewing (or scheduled-phase) shipment-based subscriptions to activate renewal automatically once shipments remaining hits 0, so subscribers aren't held to an unrelated date. As a publisher, I want non-auto-renewing shipment-based subscriptions to be marked expired once shipments remaining hits 0, so expiration reflects actual fulfillment status. 🎯 Definition of Done (DoD) Given a print subscription is auto-renewing or has a scheduled renewal phase, when shipments remaining reaches 0, then renewal activates regardless of end_date or renewal_date. Given a print subscription is non-auto-renewing with no scheduled renewal phase, when shipments remaining reaches 0, then the subscription is marked expired. Given an existing print subscription currently tracked by end_date/renewal_date, when this change ships, then it is migrated to shipment-count-based renewal/expiration logic. This change will impact API / SDK, specifically shipment-based subscription renewal and expiration logic. This solution will include the following limitations: applies only to pure print subscriptions (no print+digital combined pricing plans); end_date and renewal_date are not used as renewal/expiration triggers for shipment-based subscriptions; manual early-activation override is out of scope (superseded by automatic shipment-count trigger).
Support Tax Rates With Plan Bundling
🔍 Problem Statement As a publisher, I need to apply different tax rates to individual line items within a bundled plan based on the product type, customer billing country, and VAT ID status. For example, a publisher may create a bundled plan priced at $100, consisting of: Print: $50 — 7% tax Digital: $50 — 5% tax The applicable tax rate for each line item must be dynamically resolved based on the customer's billing country, VAT ID, and the line item's content code/product type. Certain tax scenarios also require specific legal text to be dynamically added to the invoice. The tax calculation mechanism may be implemented through AvaTax or Pelcro's AI Tax module. 💡 User Story As a publisher, I want each line item within a bundled plan to have its tax calculated independently so that Print, Digital, and other components can follow their applicable tax rules. As a publisher, I want tax rates to be dynamically determined based on the customer's billing country, VAT ID status, and the line item's content code so that the correct tax treatment is applied. As a publisher, I want the appropriate legal text to be dynamically added to invoices when a transaction qualifies for a tax exemption or reverse-charge treatment. As a subscriber, I want the correct tax to be calculated for each component of my subscription so that my checkout total and invoice reflect the applicable tax treatment. 🎯 Definition of Done (DoD) A feature is done when: Tax Calculation per Line Item ✔ Given a bundled plan contains multiple line items, tax is resolved independently for each line item. Example: Create a bundled plan for $100: $50 Print $50 Digital The Print and Digital components can receive different tax rates depending on the applicable tax rules. ✔ Tax resolution takes into consideration: vat_id billing_country content_code / product type ✔ The resolved tax is calculated against the amount of the corresponding line item rather than against the bundle as a single taxable amount. ✔ For bundled Digital & Print products, Print and Digital are evaluated independently whenever the applicable rules require different rates.
AI-Driven Code Customization & Deployment for UI
🔍 Problem Statement As a Pelcro client, I need engineering involvement for every UI customization (paywall, dashboard, member pages), which slows onboarding and blocks self-serve iteration. 💡 User Story As a Pelcro client, I want to describe my site in natural language and get a working, deployable UI, so that I launch and iterate without Pelcro engineers. 🎯 Definition of Done (DoD) ✔ Given a client prompt or uploaded template, when submitted, then the agent produces a working site in the workspace using JS-SDK for all billing actions and Elements where applicable. ✔ Given a workspace build, when the client views it, then a live preview reflects changes without a deploy step. ✔ Given client approval, when Publish is clicked, then the site is served on the client's domain with SSL, and any prior version is restorable in one click. ✔ This change will impact UI, SDK, and API, specifically an agent service, workspace/preview infrastructure, and publish/rollback endpoints. ✔ This solution will include the following limitations: UI only — no integrations or backend logic; billing flows only via JS-SDK; templates must pass validation before use; one production domain per client.
Available
244Closed or declined
Prevent duplicate subscriptions with subscription buckets
Problem Statement Pelcro currently allows a user to have multiple active subscriptions of the same type or within the same logical grouping, especially when subscriptions are created via the API. This creates problems for: In-app purchases (Apple App Store / Google Play), where platforms enforce one active subscription per group Web subscriptions, where users can accidentally subscribe twice Client apps, which must implement complex and fragile idempotency logic Apple and Google solve this with subscription groups that behave like radio buttons: one active subscription per group, while still allowing upgrades and downgrades. Pelcro lacks a native equivalent. User Story As a Pelcro merchant or integrator I want to define subscription groups that enforce one active subscription per user per group So that duplicate subscriptions are prevented and upgrades/downgrades are handled cleanly across web, API, and mobile platforms. Proposed Behavior (High Level) Plans may optionally belong to a Subscription Group A user may have only one active subscription per group Creating a subscription in the same group will: Trigger an upgrade/downgrade flow or Be rejected with a clear, deterministic API error (behavior TBD) Multiple Groups Are Supported A platform may define multiple independent subscription groups A user may have one active subscription per group Example: Group A: Content Access Group B: Add-on / Premium Tier → One active subscription per group is valid and supported Definition of Done (DoD) Subscription Groups can be created and managed Plans can be assigned to a group Pelcro enforces one active subscription per user per group Upgrade/downgrade within a group is supported Duplicate subscriptions in the same group are prevented at the platform level API behavior is documented and test-covered Backward compatible for plans not assigned to a group Impacted Components API – enforcement and upgrade/downgrade logic Admin UI – group and plan management JS-SDK – subscription creation flows Integrations – Apple App Store, Google Play Store, Web Checkout Business Impact Simplifies in-app purchase integrations Prevents double billing and duplicate entitlements Improves upgrade/downgrade UX Aligns Pelcro with Apple / Google subscription models
Subscription Start-Date Override (Platform + API)
Problem Statement Administrators need the ability to set or backdate the subscription start date directly from the platform. The current platform does not provide a controlled way to adjust start_date, creating gaps when aligning entitlement periods or correcting subscription timelines. The feature must also be supported through the Subscription Create API endpoint, ensuring API-first consistency. User Story As an admin or integrator, I want to explicitly set the subscription start date (including backdating) via the platform UI and the Subscription Create API, so that subscription timelines can be accurately initialized without relying on workarounds. Definition of Done (DoD) 1. Functional Requirements The platform allows administrators to set or backdate the subscription start_date. The Subscription Create API accepts an optional start_date parameter. Changing the start date does not modify: Invoice start date Invoice line-item periods Historical invoice data 2. Renewal Logic Renewal date is based on the subscription's start date, including backdated values. Example: Backdating to Aug 1 → next renewal occurs Aug 1 of the next cycle. 3. Guardrails Start-date modification (UI or API) allowed only when: The subscription is not set to auto-renew, and No renewal phase or future renewal event is scheduled. Operation must be blocked when renewal logic depends on the existing start date. 4. Scope Applies to all plan types (shipment-based and time-based). Implemented in: Platform UI (admin-level controls) Subscription Create API 5. UI Note Where applicable, the UI must clearly state: “Start date modifications do not affect invoice dates.”
Add Cancellation Reason in new UI
🔍 Problem Statement Currently, when end users cancel their subscriptions, we do not collect structured data on the reasons for cancellation. This limits our ability to understand customer churn, identify patterns, and implement improvements to retain subscribers. 💡 User Story As a business owner, I want a required exit survey that asks customers their reason for cancelling via a dropdown with predefined options, plus an open-text field if “Other” is selected, so that I can better understand why customers churn and use these insights to improve retention strategies. 🎯 Definition of Done (DoD) A feature is considered done when: A required field is presented to users when they attempt to cancel a subscription. The field is a dropdown containing a list of reasons configured through the platform. If “Other” is selected, an open-text input field appears, allowing the user to specify their reason. The open-text input field is required when other is selected. The validations happens only on the UI strictly and not on the Open API. This change needs to be backward compatible with custom UIs and older react elements versions. The selected reason (and optional free-text entry) is stored in the subscription object and is accessible in subscription exports.
Modernizing the Pelcro JavaScript SDK for Faster Performance
🔍 Problem Statement The Pelcro JavaScript SDK (pelcro package) can be further optimized to improve JavaScript loading performance and enhance the end-user experience of the Pelcro interface. The current build setup and testing framework work reliably, but they do not take full advantage of the latest improvements in the JavaScript ecosystem. This creates opportunities to reduce bundle size, improve loading speed, and streamline developer workflows. 💡 User Story As a Pelcro end user, I want the SDK to load quickly and render the user interface smoothly, so that my interaction with subscriptions, paywalls, and account features feels seamless. As a developer integrating Pelcro, I want the SDK to be built with modern tooling and testing frameworks, so that I can confidently deliver a fast, reliable, and secure experience to my customers. 🎯 Definition of Done (DoD) A feature is done when: ✔️ Modernize tooling Upgrade Node.js to the current Long Term Support (LTS) release. Switch from Yarn to pnpm for faster and more efficient dependency management. Update major dependencies (Babel, ESLint, etc.) to their latest stable versions. ✔️ Modernize build system Upgrade from Webpack 4 to Webpack 5 for better performance and compatibility. Migrate to webpack.config.mjs with ES modules and native import syntax. ✔️ Dependencies streamlined Remove any unused dependencies or devDependencies. Update remaining dependencies in package.json to their latest stable versions. Test Cases Added unit test coverage for all UI components listed in the coverage report. Verified rendering, props handling, and default states. Covered edge cases for conditional rendering and error handling. Ensured event handlers and callbacks are triggered correctly. Validated data formatting and helper utilities with both valid and invalid inputs. Increased overall branch and function coverage across the UI component library.
Subscription Health Report for Retention and Churn Insights
Problem Statement Pelcro clients are not able to project their subscriber behavior into the future because they don't understand historical numbers and current projected number. User Story As a Pelcro client, I want to understand how many subscriptions were retained and churned in a given period DoD Create a Subscription Health report on Pelcro platform. Pelcro client can select their required date range and interval. The output will be a table based on every interval valid in the selected date range: If user selects a date range of January 1, 2024 to December 31, 2024 with an interval of Monthly, then the table below will be January 1-January 31, February 1 - Feb 29, etc.. We generate a table with the variable below based on database queries Name Variable Description Opening Actives OA Subscriptions active at the start of period New Starts NS Subscriptions created during period Churned (Opening Cohort) CO Subscriptions that were active at the start but ended during the period and did not renew Churned (In-Period) CI Subscriptions that started and ended during the period (short-term churn) Closing Actives CA Subscriptions active at the end of period Closing Actives (Opening Cohort) CAO Subscriptions that started the period and are still active at end of period In order to audit this and verify it is true, verify that CA = OA + NS - CO - CI All variables in table above must be exportable 3. Generate retention and churn rate numbers based on the table above Subscription Retention Rate = (OA - CO)/OA Total Retention Rate = CA / (OA + NS) Subscription Churn Rate = CO / OA In-Period Churn Rate = CI / NS Total Churn Rate = (CO + CI) / (OA + NS) Here is a quick mockup: https://v0-subscription-health-report.vercel.app/
Pelcro AI Co-Pilot - Import tool
Problem Statement As a publisher admin, I have no way to quickly query my subscription data, analyze trends, or act on insights without manually running reports or contacting Pelcro support, which results in slow decision-making and dependency on external help for routine data questions. User Story As a publisher admin, I want an AI assistant embedded in my dashboard that understands my live Pelcro data and can analyze uploaded files, so that I can get instant answers, surface insights, and execute guided actions without leaving the dashboard. Definition of Done A feature is done when: Given I am on the publisher dashboard, when I open the AI Copilot panel and ask a question about my subscriptions or revenue, then the assistant responds in real-time by calling live Pelcro tools and streaming the answer token-by-token with tables, charts, or action buttons as appropriate. Given I upload a CSV, Excel, or PDF file, when the upload completes, then the copilot can reference that file in my next message and analyze its contents alongside my live account data. Previously uploaded files remain downloadable from past conversations. Given I navigate away and return to a past conversation, when I load it from the history sidebar, then all message content is fully restored including tool call steps, artifact tables and charts, file upload pills with download links, and action button states. This change will impact the UI (new Copilot panel, message partials, history sidebar), the API (new routes under /admin/copilot-ai/ for chat, conversation history, file upload, and file download), and the Database (new agent_conversations table). SDK and Integrations: no changes. This solution will include the following limitations: conversations are scoped per publisher account; file uploads support CSV, Excel, and PDF only; the agent performs up to 25 reasoning steps per message; S3 storage is required for file uploads and downloads; action buttons from past conversations are shown as completed badges and are not re-executable.
Ability to Edit Coupons and Re-Enable Codes
Problem Statement Currently, coupon fields such as maximum redemptions and expiration date cannot be edited once a coupon has been created. This limitation forces users to create new coupons whenever adjustments are needed — leading to operational inefficiencies, fragmented analytics, and increased risk of configuration errors. Additionally, coupon expiration only supports date-based UTC values, without the ability to specify a time component, making it difficult for publishers to manage time-sensitive promotions accurately. User Story As a subscription manager, I want to be able to edit coupon configuration fields such as maximum redemptions and expiration date/time so that I can manage promotions flexibly without creating duplicate coupons or disrupting active campaigns. Definition of Done (DoD) ✅ API Layer Add support for editable coupon fields via PATCH /coupons/:id endpoint. Allow updates to: max_redemptions expires_at (date + time support in ISO8601 format) Include validation logic to prevent retroactive invalid states (e.g., editing expired coupons to past dates). ✅ Platform (Dashboard UI) Update the coupon edit modal/form to allow modification of: Maximum redemptions (integer field with validation) Expiration date + time (datetime picker in local timezone) Ensure that audit logs capture all field changes (e.g., “Max redemptions updated from 100 → 150 by [user_email]”). ✅ Data & Audit Maintain versioning for coupon updates for traceability. Expose updated timestamps (updated_at) in API responses. Problem Statement Currently, coupon fields such as maximum redemptions and expiration date cannot be edited once a coupon has been created. This limitation forces users to create new coupons whenever adjustments are needed, Feedback: Would love to be able to edit coupon fields such as max redemption and expire date
Allow Payment Method Deletion When Currently Blocked (manual-renewal & only-method-on-file)
🔍 Problem Statement Customers and admins cannot delete a saved payment method in situations where keeping it provides no functional benefit and blocks legitimate requests: (a) when the method is tied only to manual-renewal subscriptions — which do not process recurring payments, so requiring a replacement is pointless — and (b) when it is the only payment method on file (including ACH), which blocks admins from honouring customer data-removal requests. 💡 User Story As a customer or Pelcro admin, I want to remove a saved payment method in these currently-blocked scenarios without being forced to add a replacement, so that I can clean up unused methods and fulfil data-removal requests. 🎯 Definition of Done (DoD) ✔ Allow deletion of a payment method tied only to manual-renewal subscription(s) without requiring a replacement. ✔ Allow admin removal of the only saved payment method on an account (including ACH); any linked subscriptions transition to manual/invoice billing. ✔ This change will impact UI / API — the payment-method management UI and the payment-method resource (Core API).
Subscription across multiple sites
🔍 Problem Statement As a subscriber purchasing a subscription across multiple sites under the same account, I experience access being limited to only the site where the subscription was purchased, despite the product being configured for availability on multiple sites. This results in confusing access behavior, fragmented content availability, and reduced perceived subscription value, often leading to support requests or duplicate subscriptions. 💡 User Story As a subscriber of a multi-site product, I want my subscription to grant access across all sites associated with that product, so that I can consume content seamlessly without needing multiple subscriptions. 🎯 Definition of Done (DoD) A feature is done when: ✔️Given a product configured to be available on multiple sites under the same Pelcro account, when a subscriber purchases a subscription using any pricing plan under that product on any site, then the subscriber is granted paywall access on all sites associated with that product. Acc multiple sites > if subscription attached to product, return all subscriptions related to that site. ✔️ This change will impact API and SDK/ JS part, specifically: Subscription entitlement resolution at the API level Paywall evaluation logic within the Pelcro SDK to recognize cross-site entitlements No change to purchase flows or checkout UI behavior ✔️ This solution will include the following limitations: Applies only to sites under the same Pelcro account Does not extend access across different Pelcro accounts Products configured for a single site will continue to behave as they do today Retroactive application to existing subscriptions is out of scope.
Introduce Activity logs in subscriptions details view
Problem Statement Currently, subscription-related events/logs are not visible in the subscription details view, making it difficult to understand changes, investigate issues, and answer questions about a subscription’s history. User Story As an admin I want to view activity logs in the subscription details page So that I can track all subscription events and changes in one place.