New Ideas 💡

Discovery

Tech Planning

In Sprint

Done

Available

Pelcro Roadmap

🔍 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)
<ul>
 <li>✔ Allow deletion of a payment method tied only to manual-renewal subscription(s) without requiring a replacement.</li>
 <li>✔ Allow admin removal of the only saved payment method on an account (including ACH); any linked subscriptions transition to manual/invoice billing.</li>
 <li>✔ This change will impact UI / API — the payment-method management UI and the payment-method resource (Core API).</li>
</ul>

Backlog

Allow Payment Method Deletion When Currently Blocked (manual-renewal & only-method-on-file)

Nada Shoukry

Problem StatementWhen 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 StoryAs 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<ul><li>A user object contains both a short-lived access token that cannot be refreshed and a long-lived refresh token.</li><li>The refresh endpoint accepts a non-expired refresh JWT and returns a new short-lived access token along with a new refresh token.</li><li>The authentication endpoint accepts a non-expired auth JWT and returns the requested information/performs the requested function.</li><li>A refresh_ttl window is defined and enforced — tokens outside this window cannot be refreshed and require re-authentication.</li><li>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.</li><li>If the refresh fails (token outside refresh_ttl or invalid), the app falls back gracefully to the sign-in screen.</li><li>Subscription state is successfully queried using the new auth token after a silent refresh.</li><li>Changes are documented in the API reference.</li></ul>

Implement JWT Token Refresh Mechanism

Rana Haleem

🔍 Problem StatementThe 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.<hr>💡 User StoryAs 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.<hr>🎯 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.

Add missing subscription fields to the API response

Francesco Carusi

🔍 Problem StatementWhen 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.<hr>💡 User StoryAs 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.<hr>🎯 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.

Product Board

User/Growth Ideas

Discovery Board

Make first and last name optional fields for account creation when it's a company profile

An Anonymous User

🔍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.

Standardize Field Naming Across Export Files

<h2>Problem Statement</h2>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.<div data-type="horizontalRule"><hr></div><h2>User Story</h2>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.<div data-type="horizontalRule"><hr></div><h2>Definition of Done (DoD)</h2><ul><li>Subscription exports only include columns currently selected/displayed in the table view.</li><li>Hidden/unselected columns are excluded from the export.</li><li>Column ordering in the export matches the table ordering where applicable.</li><li>Existing filters and search criteria continue to apply correctly to exports.</li><li>Export functionality remains supported for CSV and other existing export formats.</li></ul>

Subscription Export Should Respect Selected Table Columns

<h2>🔍 Problem Statement</h2>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.<h2>💡 User Story</h2>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.<h2>🎯 Definition of Done (DoD)</h2>A feature is done when:✔ Given a pricing plan with <code>renewal_type = self-renew</code>, (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 <code>renewal_type = auto-renew</code>,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:<ol><li>Existing one-time gift subscriptions are not retroactively converted to auto-renewing</li><li>Renewal behavior is determined only at subscription creation time</li><li>No UI changes are included as part of this feature</li><li>No mixed renewal behavior within a single gift subscription is supported</li></ol>

Allow auto renew gifts

🔍 Problem StatementAdmins 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.<hr>💡 User StoryAs 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.<hr>🎯 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.

Ability to add metadata via dropdown

[Deleted User]

🔍 Problem StatementPelcro 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.<hr>💡 User StoryAs 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.<hr>🎯 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.

Enable subscription changes for shipment-based plans

🔍 Problem StatementPelcro's paywall is static — it shows the same content gate to every visitor regardless of engagement level, referral source, or user behaviour. Publishers cannot tailor the paywall experience dynamically to maximise conversions and reduce reader friction.<hr>💡 User StoryAs a publisher, I want a dynamic paywall that adjusts its behaviour based on reader engagement, referral source, or other signals, so that I can optimise the balance between content access and subscription conversion.<hr>🎯 Definition of Done (DoD)A feature is done when:✔️ Given a configurable rule set, when a reader encounters the paywall, then the paywall behaviour (e.g. number of free articles, gate type, messaging) adapts based on the defined rules — and the admin can create, edit, and prioritise these rules from the dashboard.

Dynamic wall

🔍 Problem StatementPelcro'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.<div data-type="horizontalRule"><hr></div>💡 User StoryAs 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.<div data-type="horizontalRule"><hr></div>🎯 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.

Planned

Collaborator Roles, Permissions & Account Management

🔍 Problem StatementThe membership list displays customer email addresses but not customer names. For members without email addresses or when names are more recognisable, this makes it difficult to identify members at a glance.<hr>💡 User StoryAs a Pelcro admin, I want the membership list to display customer names (alongside or instead of email), so that I can identify members quickly regardless of whether they have an email on file.<hr>🎯 Definition of Done (DoD)A feature is done when:✔️ Given the membership list view, when an admin views it, then each row displays the customer name — and if no name exists, the email is shown as fallback.

When looking at the membership list, we would like to see the customers name instead of the email field

Martha Lynn Crawford

<h2>Problem Statement</h2>Managing vendor assignments at scale is currently a manual and time-consuming process. When delivery areas change or operational adjustments are needed, users must reassign addresses individually from one vendor to another. This becomes inefficient for large numbers of addresses and increases the risk of errors.Providing bulk vendor reassignment through the AI Agent will enable users to update vendor assignments quickly using natural language commands, improving operational efficiency and reducing manual effort.<h2>User Story</h2>As an Operations Manager,I want to bulk reassign addresses from one vendor to another using the AI Agent,so that I can efficiently update vendor assignments without manually editing each address.<h2>Definition of Done</h2><h3>AI Agent</h3><ol><li>The AI Agent understands bulk vendor reassignment requests using natural language (e.g., "Move all addresses assigned to Vendor A to Vendor B.").</li><li>The AI Agent identifies:</li><li>Source vendor.</li><li>Destination vendor.</li><li>Scope of addresses to be reassigned (all or based on provided criteria).</li><li>Before executing the change, the AI Agent presents a summary including:</li><li>Source vendor.</li><li>Destination vendor.</li><li>Number of affected addresses.</li><li>The AI Agent requires user confirmation before applying the changes.</li></ol><h3>Vendor Assignment</h3><ol><li>Upon confirmation, all matching addresses are reassigned from the source vendor to the destination vendor.</li><li>Only the vendor assignment is updated; all other address data remains unchanged.</li><li>Existing validation and permission checks continue to apply.</li><li>If the destination vendor does not exist, the AI Agent informs the user and no changes are made.</li><li>If no matching addresses are found, the AI Agent informs the user and no changes are made.</li></ol>

Support Bulk Changes for Vendors assignment through AI agent

<h2>Problem Statement</h2>The platform currently does not support a clear notion of redelivery for missed, failed, or damaged shipments.When a shipment needs to be sent again, there is no standardized way to:<ol><li>Mark the original fulfillment as requiring redelivery.</li><li>Identify all subscriptions that need a replacement shipment.</li><li>Generate a fulfillment list specifically for redeliveries.</li><li>Track whether the redelivery was completed.</li><li>Distinguish the replacement shipment from the original fulfillment.</li></ol>As a result, redeliveries must be managed manually outside the normal fulfillment workflow, increasing the risk of missed requests, duplicate shipments, and inaccurate reporting.<h2>User Story</h2>As an operations administrator,I want to mark a shipment as requiring redelivery on the subscription details and generate a fulfillment list containing all pending redeliveries,so that replacement shipments can be processed, tracked, and completed through the standard fulfillment workflow.<h1>Definition of Done</h1><h2>Redelivery Status</h2><ol><li>A fulfillment or shipment associated with a subscription can be marked as requiring redelivery.</li><li>The redelivery indicator includes a clear status, such as:</li><li>Redelivery Required</li><li>Redelivered</li><li>Redelivery Cancelled</li><li>SIMILAR TO SHIPMENTS &amp; RETURNS FLOW &gt; SIMILAR TO RETURNS </li><li>Redelivery reason.</li><li>Notes.</li><li>Quantity to redeliver.</li><li>Original fulfillment reference.</li></ol><h2></h2><h2>Fulfillment List Filtering</h2><ol><li>Lists can be filtered to show subscriptions/ shipments with a pending redelivery.</li><li>Administrators can generate a dedicated fulfillment list for all eligible redeliveries.</li><li>The original fulfillment record remains unchanged for historical accuracy.</li><li>Approving the replacement fulfillment updates the redelivery request to Redelivered.</li><li>Should be logged under the sub details the redelivery changes.</li><li></li></ol><h2>Duplicate Prevention</h2><ol><li>Administrators receive a warning or validation message when a replacement fulfillment already exists.</li></ol>

Introduce redelivery management

<h2>Problem statement</h2>Carriers deliver bundles of papers along a route, in a specific walk (delivery) sequence. Today Pelcro's "Bundle Top" is a generic label sheet — customer name, address, product, date, quantity — with no route grouping, no delivery-sequence ordering, and no carrier context. <h2>User story</h2><blockquote>As a circulation/fulfillment operator,I want to export a Bundle Top per fulfillment that is grouped by carrier route and ordered by delivery sequence, with each subscriber's delivery details and per-route totals,so that each carrier receives an accurate, walk-ordered manifest of exactly what to deliver and how many bundles to prepare.</blockquote>Supporting: As a carrier, I want my route's stops listed in the order I drive them, with copy counts and delivery instructions, so I can deliver without re-sorting.<h2>DOD:</h2><h2>Part 1 — Available now (just add to the report)</h2>Pelcro already captures this information — the first version of the report simply organizes and presents it. No new setup or development beyond the report itself.What the PDF shows<ol><li>Carrier name &amp; phone</li><li>Total draws</li><li>Carrier route</li><li>Delivery sequence (the order the carrier drives the route)</li><li>Delivery instructions</li><li>Delivery date</li><li>Subscriber name</li><li>Subscriber delivery address</li><li>Subscriber phone</li><li>Product / publication</li><li>Number of copies</li></ol>How the report behaves<ol><li>One file per fulfillment, covering all routes.</li><li>Each route shows a subtotal (total copies); the file ends with an overall total.</li><li>The report only includes the carriers already selected for that fulfillment.</li><li>Each subscriber should appear in one separate page pdf (see example attached)</li></ol>

Enhance bundle tops report

🔍 Problem StatementPelcro'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.<hr>💡 User StoryAs 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.<hr>🎯 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).

In Progress

Durable Metered Paywall Using Device-Based Identification

Michael Ghattas

We extensively use Memberships in our organizations.Our membership sales team reports that it is difficult to find specific members underneath a membership subscription. This makes it difficult to remove members when requested by the owner of the subscription (like when an employee leaves the company or the employee no longer needs the subscription entitlements due to a role change).For example, if a given subscription has more than 25 members, one must scroll through the members one page at a time until the member can be located. That is very cumbersome.A couple of improvements we would like to see:<ul><li>Add a search function to the subscription members view.</li></ul><a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.pelcro.com/admin/5118/subscription/2303764/members">https://www.pelcro.com/admin/5118/subscription/2303764/members</a><ul><li>Allow members to be deleted from the global memberships view.</li></ul><a target="_blank" rel="noopener noreferrer nofollow" class="link" href="https://www.pelcro.com/admin/5118/memberships">https://www.pelcro.com/admin/5118/memberships</a>Removing Members from the memberships view should not delete the Customer Record as it is required for other purposes Happy to provide additional context if needed.

Improve Searching for Members in the Membership View

Manish Patel

<h3>Problem Statement</h3>Currently, Pelcro does not support SEPA Direct Debit for the EU for the UK as payment methods. This prevents businesses from accepting bank account payments in these regions, limiting payment flexibility and reducing the ability to serve customers who prefer or require direct debit over card payments.User Story As a business, I want to be able to support SEPA in the EU and BACS in the UK so that I can accept bank accounts as a source of payment method<h3>Definition of Done</h3><ul><li>Pelcro supports SEPA Direct Debit as a payment method on pelcro.</li><li>Admins can enable or disable SEPA from payment settings.</li><li>SEPA payment method details are securely stored and displayed on the customer profile.</li><li>Payment statuses are handled correctly, including pending, succeeded, failed, and refunded.</li></ul>

Support SEPA payment method on the platform

🔍 Problem StatementWe need an in-app notification channel for event-based workflows that works across ALL Pelcro UIs — Default UI, React Elements, and fully custom UIs built directly on the JS SDK. Building rendering logic per UI layer would leave custom-UI publishers without coverage. The JS SDK is the common denominator across all Pelcro frontends.💡 User StoryAs a marketer, I want to send an in-app notification (banner, toast, or inline card) to customers matching an event-based segment, so I can engage users in the moment — regardless of which Pelcro UI surface they are on.As a developer integrating Pelcro, I want a simple way to either auto-render notifications OR listen to an event and render them myself, so I am not forced to migrate UI surfaces just to use this feature.🎯 Definition of Done (DoD)────────────────────────────────ARCHITECTURE — JS SDK MODULE────────────────────────────────✔ New Pelcro.notifications module in the JS SDK, following the same conventions as Pelcro.user, Pelcro.subscription, etc.✔ On user authentication, the SDK calls GET /notifications/active and fetches the list of pending in-app notifications for that customer.✔ For each pending notification, the SDK dispatches a notification.received event consumable by publisher code.✔ The SDK exposes a simple API for retrieval, dismissal, and click tracking: • Pelcro.notifications.list() • Pelcro.notifications.refresh() • Pelcro.notifications.dismiss(id) • Pelcro.notifications.markAsClicked(id) • Pelcro.notifications.on('received' | 'dismissed' | 'clicked', callback)────────────────────────────────TWO INTEGRATION PATHS────────────────────────────────Path 1 — Default UI/React elements:✔ Pelcro.notifications.enable({ position, theme, maxVisible, autoDismissAfter }) opt-in renders notifications automatically with brand-aware styling (site logo + color palette).<ol><li>Default UI and React Elements use this built-in renderer under the hood — zero integration effort for those publishers.</li></ol>Path 2 — Custom UIs✔ Custom-UI publishers subscribe to Pelcro.notifications.on('received', callback) and render notifications however they want.✔ A ~20-line sample HTML/JS snippet is published in the developer docs showing how to subscribe and render.────────────────────────────────Platform UI ────────────────────────────────Add a simple rich text editor for notification content in the automation form.Fields:• Title (required) — plain text, single line, no formatting• Body (required) — rich text editor: bold, italic, links, ordered/unordered lists. No images, no embeds, no custom HTML.• CTA label (optional) — plain text, single line• CTA URL (optional) — validated as URL• Dismissible (toggle, default: true)• Expiry (default: 30 days, configurable per workflow)✔ Notifications are delivered on the customer's next page load after they enter the segment ✔ Notifications are user-scoped — only authenticated customers receive them. Anonymous visitors do not.✔ Notifications NOT loaded by the customer within the expiry window are marked expired and not redelivered.

Trigger automations with In app notifications

🔍 Problem StatementAs a publisher, I can't customize email button colors or add footer content on automated emails, limiting brand and legal compliance control.💡 User StoryAs a publisher, I want automated email buttons to use my account's configured brand color, so my emails stay on-brand.As a publisher, I want to add a custom header and footer to all automated emails, so I can include consistent supplementary content.<s>As a publisher, I want my company's legal name and address shown below the custom footer, so my emails meet legal disclosure requirements.</s>🎯 Definition of Done (DoD)✔ Given an account has a brand color configured in site settings, when an automated email is sent, then all buttons in that email use the configured color as their background.✔ Given a publisher has configured a custom header or footer, when any automated email is sent, then that footer renders below the email body.✔ Given a publisher's legal name and address are configured, when any automated email is sent, then that info renders below the custom footer.✔ This change will impact UI and API, specifically the Email Center settings and template rendering engine.✔ This solution will include the following limitations: [clarify — is footer content limited to plain text/links, or does it support images; is legal name/address a new settings field or pulled from an existing one].

Email Center: Custom Button Background Color, Header, Footer & Legal Info

<h1>Problem Statement</h1>Pelcro currently generates invoices as standard PDF documents only. Customers operating in Germany need to issue invoices that comply with local electronic invoicing standards, which require invoices to be delivered in structured, machine-readable formats.Specifically, customers require support for:<ol><li>XRechnung: a standalone XML electronic invoice format used primarily for German public sector invoicing.</li><li>ZUGFeRD: a hybrid format that combines a standard PDF invoice with embedded XML invoice data.</li></ol>Without support for these standards, customers must manually recreate invoices using third-party tools before submitting them, preventing Pelcro from serving as their complete invoicing solution.<h1>User Story</h1>As a Pelcro customer issuing invoices in Germany,I want Pelcro to generate invoices in both XRechnung and ZUGFeRD formats,so that I can comply with my customers' electronic invoicing requirements without using external systems.<h1>Definition of Done</h1><h2></h2><ol><li>Support generation of invoices in both supported e-invoicing formats:</li><li>XRechnung (XML)</li><li>ZUGFeRD (PDF with embedded XML)</li><li>Generate XML compliant with the supported EN16931/XRechnung specification.</li><li>Populate all mandatory fields from Pelcro invoice data, including:</li><li>Invoice number</li><li>Invoice date</li><li>Supplier information</li><li>Buyer information</li><li>Invoice line items</li><li>Quantity</li><li>Unit prices</li><li>Taxes</li><li>Discounts (where applicable)</li><li>Currency</li><li>Payment terms</li><li>Invoice totals</li><li>Support inclusion of the Leitweg-ID (Routing ID) for XRechnung invoices when required.</li><li>Validate generated XML against the supported specification before delivery.</li></ol><h2>Invoice Generation</h2><h3>XRechnung</h3><ol><li>Generate a standalone XML invoice.</li><li>Allow users to download the XML file.</li></ol><h3>ZUGFeRD</h3><ol><li>Generate the standard PDF invoice.</li><li>Embed the generated XML into the PDF.</li><li>The PDF appearance remains unchanged while containing the embedded XML attachment.</li></ol><h2>Platform</h2><ol><li>Allow users to generate/download invoices in the supported format(s).</li><li>Existing PDF invoice generation continues to work unchanged for customers not using e-invoicing.</li><li>If applicable, allow accounts to configure their preferred invoice format.</li></ol><h2>Validation</h2><ol><li>XML validates against the supported XRechnung/EN16931 specification.</li><li>ZUGFeRD PDFs contain valid embedded XML.</li><li>Invoice values in the XML match those displayed in the PDF.</li><li>Leitweg-ID is included in XRechnung invoices when configured.</li></ol>

Support XML invoices formats

<h2>Problem Statement</h2>The AI Voice Agent currently does not support escalation or transfer to a live support agent. When the AI cannot resolve a customer’s request, the caller has no clear way to continue receiving assistance.Clients need a configurable option within the AI Customer Support settings to define the phone number or routing destination used for live-agent transfers.<h2>User Story</h2>As a client using the AI Voice Agent,I want to configure a live-agent routing number,So that callers can be transferred to my support team when the AI cannot resolve their request or when they ask to speak with a person.<h2>Definition of Done</h2><ol><li>Configure greeting message in the AI settings example "Hello..."</li><li>Add a Live Agent Fallback section under the AI Customer Support settings.</li><li>Allow clients to enable or disable live-agent transfer.</li><li>Allow clients to enter and save a valid phone number or routing destination.</li><li>Define when the transfer should be triggered, including:</li><li>The caller explicitly asks to speak with a live agent.</li><li>The AI cannot understand or resolve the request after a defined number of attempts.</li><li>The requested action is not supported by the AI Voice Agent.</li><li>Before transferring, the AI informs the caller that they are being connected to a live agent.</li><li>If the transfer fails or the number is unavailable, the AI provides a clear fallback message.</li><li>Validate the entered phone number before saving.</li><li>Display the configured routing number in the settings and allow clients to update or remove it.</li><li>Record transfer attempts and outcomes in the call logs.</li></ol>

Support fallback to live agents in Voice Agent + customize greeting message

<h3>Problem Statement</h3>Pelcro does not currently provide a clear way to track the history of address assignments between vendors. When addresses are temporarily reassigned from one vendor to another, users cannot easily identify which addresses originally belonged to the unavailable vendor or restore the previous assignments when that vendor returns. This creates operational risk and requires users to rely on manual records.<h3>User Story</h3>As an Operations Manager,I want to view vendor assignment changes,so that I can restore the correct addresses to their previous vendor without manually identifying them.<h3>Definition of Done</h3><ol><li>Vendor profile pages include an Assignment History section.</li><li>Every individual and bulk vendor reassignment creates an assignment-history record.</li><li>The record includes:</li><li>Previous vendor</li><li>New vendor</li><li>Affected address IDs</li><li>Number of addresses</li><li>Date and time</li><li>User or AI Agent that performed the action</li><li>Optional reason</li><li>Unique operation ID</li><li>Users can view the list of addresses affected by each operation and export it</li></ol>

Vendor Assignment Change History

🔍 Problem StatementAs a Pelcro platform engineer, there is no cross-client aggregation of funnel event data, which makes percentile benchmarking impossible.💡 User StoryAs a Pelcro platform engineer, I want a backend pipeline that aggregates anonymized funnel conversion rates per step across all sites, so that benchmark percentiles can be computed and served per client.🎯 Definition of Done (DoD)✔ Given sites emit standard events (paywall_displayed, registered, subscription_created, renewal_attempted, etc.), when the pipeline runs, then per-step conversion rates are computed per site and stored in an aggregate benchmark table.✔ Given the benchmark table is populated, when queried, then it returns p25, p50, p75, p90 percentile values per funnel step, excluding any site below minimum event volume threshold.✔ Given a site_id, when GET /analytics/funnel-benchmark is called, then it returns that site's conversion rate per step alongside benchmark percentiles for the same step.✔ This change will impact API / Data, specifically a new GET /analytics/funnel-benchmark endpoint and a scheduled Laravel job for aggregation.

Funnel Benchmarking Data Pipeline

🔍 Problem StatementCurrently, the AI Agent is only accessible through a floating chat icon in the bottom-right corner of the platform. As a result, many users overlook it or perceive it as a support widget rather than a core product capability, leading to low adoption and limited engagement.💡 User StoryAs a Pelcro user, I want the AI Agent to be surfaced contextually throughout the platform so that I can easily discover its capabilities and use it to complete tasks, gain insights, and navigate the platform more efficiently.🎯 Definition of Done (DoD)Explore and implement one or more of the following options:1 — Ask Pelcro AI Bar — recommended industry standards (Most SAAS does it)<ol><li>Prominent search-style AI bar in the toolbar row (near date range) on Overview.</li><li>Placeholder frames it as analytics search; scope reflects the active date range.</li></ol>2 — Introduce recommendation cards based on your data

Introduce Proactive AI agent

<h3>Problem Statement</h3>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:<ul><li>In-app purchases (Apple App Store / Google Play), where platforms enforce one active subscription per group</li><li>Web subscriptions, where users can accidentally subscribe twice</li><li>Client apps, which must implement complex and fragile idempotency logic</li></ul>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.<div data-type="horizontalRule"><hr></div><h3>User Story</h3>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.<div data-type="horizontalRule"><hr></div><h3>Proposed Behavior (High Level)</h3><ul><li>Plans may optionally belong to a Subscription Group</li><li>A user may have only one active subscription per group</li><li>Creating a subscription in the same group will:<ul><li>Trigger an upgrade/downgrade flow or</li><li>Be rejected with a clear, deterministic API error (behavior TBD)</li></ul></li></ul><h4>Multiple Groups Are Supported</h4><ul><li>A platform may define multiple independent subscription groups</li><li>A user may have one active subscription per group</li><li>Example:<ul><li>Group A: Content Access</li><li>Group B: Add-on / Premium Tier → One active subscription per group is valid and supported</li></ul></li></ul><div data-type="horizontalRule"><hr></div><h3>Definition of Done (DoD)</h3><ul><li>Subscription Groups can be created and managed</li><li>Plans can be assigned to a group</li><li>Pelcro enforces one active subscription per user per group</li><li>Upgrade/downgrade within a group is supported</li><li>Duplicate subscriptions in the same group are prevented at the platform level</li><li>API behavior is documented and test-covered</li><li>Backward compatible for plans not assigned to a group</li></ul><div data-type="horizontalRule"><hr></div><h3>Impacted Components</h3><ul><li>API – enforcement and upgrade/downgrade logic</li><li>Admin UI – group and plan management</li><li>JS-SDK – subscription creation flows</li><li>Integrations – Apple App Store, Google Play Store, Web Checkout</li></ul><div data-type="horizontalRule"><hr></div><h3>Business Impact</h3><ul><li>Simplifies in-app purchase integrations</li><li>Prevents double billing and duplicate entitlements</li><li>Improves upgrade/downgrade UX</li><li>Aligns Pelcro with Apple / Google subscription models</li></ul>

Prevent duplicate subscriptions with subscription buckets

mesim

<h2>Problem Statement</h2>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 <code>start_date</code>, 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.<div data-type="horizontalRule"><hr></div><h2>User Story</h2>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.<div data-type="horizontalRule"><hr></div><h2>Definition of Done (DoD)</h2><h3>1. Functional Requirements</h3><ul><li>The platform allows administrators to set or backdate the subscription <code>start_date</code>.</li><li>The Subscription Create API accepts an optional <code>start_date</code> parameter.</li><li>Changing the start date does not modify:<ul><li>Invoice start date</li><li>Invoice line-item periods</li><li>Historical invoice data</li></ul></li></ul><h3>2. Renewal Logic</h3><ul><li>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.</li></ul><h3>3. Guardrails</h3><ul><li>Start-date modification (UI or API) allowed only when:<ul><li>The subscription is not set to auto-renew, and</li><li>No renewal phase or future renewal event is scheduled.</li></ul></li><li>Operation must be blocked when renewal logic depends on the existing start date.</li></ul><h3>4. Scope</h3><ul><li>Applies to all plan types (shipment-based and time-based).</li><li>Implemented in:<ul><li>Platform UI (admin-level controls)</li><li>Subscription Create API</li></ul></li></ul><h3>5. UI Note</h3><ul><li>Where applicable, the UI must clearly state: “Start date modifications do not affect invoice dates.”</li></ul>

Subscription Start-Date Override (Platform + API)

🔍 Problem StatementCurrently, 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 StoryAs 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:<ul><li>A required field is presented to users when they attempt to cancel a subscription.</li><li>The field is a dropdown containing a list of reasons configured through the platform.</li><li>If “Other” is selected, an open-text input field appears, allowing the user to specify their reason.</li><li>The open-text input field is required when other is selected.</li><li>The validations happens only on the UI strictly and not on the Open API.</li><li>This change needs to be backward compatible with custom UIs and older react elements versions.</li><li>The selected reason (and optional free-text entry) is stored in the subscription object and is accessible in subscription exports.</li></ul>

Add Cancellation Reason in new UI

🔍 Problem Statement The Pelcro JavaScript SDK (<code>pelcro</code> 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<ul><li>Upgrade Node.js to the current Long Term Support (LTS) release.</li><li>Switch from Yarn to pnpm for faster and more efficient dependency management.</li><li>Update major dependencies (Babel, ESLint, etc.) to their latest stable versions.</li></ul>✔️ Modernize build system<ul><li>Upgrade from Webpack 4 to Webpack 5 for better performance and compatibility.</li><li>Migrate to <code>webpack.config.mjs</code> with ES modules and native <code>import</code> syntax.</li></ul>✔️ Dependencies streamlined<ul><li>Remove any unused dependencies or devDependencies.</li><li>Update remaining dependencies in <code>package.json</code> to their latest stable versions.</li></ul>Test Cases<ol><li>Added unit test coverage for all UI components listed in the coverage report.</li><li>Verified rendering, props handling, and default states.</li><li>Covered edge cases for conditional rendering and error handling.</li><li>Ensured event handlers and callbacks are triggered correctly.</li><li>Validated data formatting and helper utilities with both valid and invalid inputs.</li><li>Increased overall branch and function coverage across the UI component library.</li></ol>

Modernizing the Pelcro JavaScript SDK for Faster Performance

Problem StatementPelcro 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<ol><li>As a Pelcro client, I want to understand how many subscriptions were retained and churned in a given period</li></ol>DoD<ol><li>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:</li><li>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..</li><li>We generate a table with the variable below based on database queries</li></ol><table style="minWidth: 75px"><colgroup><col><col><col></colgroup><tbody><tr><td colspan="1" rowspan="1">Name</td><td colspan="1" rowspan="1">Variable</td><td colspan="1" rowspan="1">Description</td></tr><tr><td colspan="1" rowspan="1">Opening Actives</td><td colspan="1" rowspan="1">OA</td><td colspan="1" rowspan="1">Subscriptions active at the start of period</td></tr><tr><td colspan="1" rowspan="1">New Starts</td><td colspan="1" rowspan="1">NS</td><td colspan="1" rowspan="1">Subscriptions created during period</td></tr><tr><td colspan="1" rowspan="1">Churned (Opening Cohort)</td><td colspan="1" rowspan="1">CO</td><td colspan="1" rowspan="1">Subscriptions that were active at the start but ended during the period and did not renew</td></tr><tr><td colspan="1" rowspan="1">Churned (In-Period)</td><td colspan="1" rowspan="1">CI</td><td colspan="1" rowspan="1">Subscriptions that started and ended during the period (short-term churn)</td></tr><tr><td colspan="1" rowspan="1">Closing Actives</td><td colspan="1" rowspan="1">CA</td><td colspan="1" rowspan="1">Subscriptions active at the end of period</td></tr><tr><td colspan="1" rowspan="1">Closing Actives (Opening Cohort)</td><td colspan="1" rowspan="1">CAO</td><td colspan="1" rowspan="1">Subscriptions that started the period and are still active at end of period</td></tr></tbody></table><ol><li>In order to audit this and verify it is true, verify that CA = OA + NS - CO - CI</li><li>All variables in table above must be exportable</li></ol>3. Generate retention and churn rate numbers based on the table above<ol><li>Subscription Retention Rate = (OA - CO)/OA</li><li>Total Retention Rate = CA / (OA + NS)</li><li>Subscription Churn Rate = CO / OA</li><li>In-Period Churn Rate = CI / NS</li><li>Total Churn Rate = (CO + CI) / (OA + NS) Here is a quick mockup:<a target="_blank" rel="noopener noreferrer nofollow" class="ProsemirrorEditor-link link" href="https://v0-subscription-health-report.vercel.app/">https://v0-subscription-health-report.vercel.app/</a></li></ol>

Accounting

Subscription Health Report for Retention and Churn Insights

<h2>Problem Statement</h2>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.<div data-type="horizontalRule"><hr></div><h2>User Story</h2>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.<div data-type="horizontalRule"><hr></div><h2>Definition of Done</h2>A feature is done when:<ol><li>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.</li><li>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.</li><li>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.</li><li>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.</li><li>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.</li></ol>

Pelcro AI Co-Pilot - Import tool

Abdallah Shapsough

<h3>Problem Statement</h3>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.<div data-type="horizontalRule"><hr></div><h3>User Story</h3>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.<div data-type="horizontalRule"><hr></div><h3>Definition of Done (DoD)</h3>✅ API Layer<ul><li>Add support for editable coupon fields via <code>PATCH /coupons/:id</code> endpoint.</li><li>Allow updates to:<ul><li><code>max_redemptions</code></li><li><code>expires_at</code> (date + time support in ISO8601 format)</li></ul></li><li>Include validation logic to prevent retroactive invalid states (e.g., editing expired coupons to past dates).</li></ul>✅ Platform (Dashboard UI)<ul><li>Update the coupon edit modal/form to allow modification of:<ul><li>Maximum redemptions (integer field with validation)</li><li>Expiration date + time (datetime picker in local timezone)</li></ul></li><li>Ensure that audit logs capture all field changes (e.g., “Max redemptions updated from 100 → 150 by [user_email]”).</li></ul>✅ Data &amp; Audit<ul><li>Maintain versioning for coupon updates for traceability.</li><li>Expose updated timestamps (<code>updated_at</code>) in API responses.</li></ul><h3><s>Problem Statement</s></h3><s>Currently, coupon fields such as </s><s>maximum redemptions</s><s> and </s><s>expiration date</s><s> cannot be edited once a coupon has been created. This limitation forces users to create new coupons whenever adjustments are needed,</s><s>Feedback:</s><s>Would love to be able to edit coupon fields such as max redemption and expire date</s>

Ability to Edit Coupons and Re-Enable Codes

Kristie Wahlquist

<h2>🔍 Problem Statement</h2>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.&nbsp;This results in confusing access behavior, fragmented content availability, and reduced perceived subscription value, often leading to support requests or duplicate subscriptions.<h2>💡 User Story</h2>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.<h2>🎯 Definition of Done (DoD)</h2>A feature is done when:&nbsp;✔️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.<ol><li>Acc multiple sites &gt; if subscription attached to product, return all subscriptions related to that site.</li></ol>&nbsp;✔️ This change will impact API and SDK/ JS part, specifically:<ol><li>Subscription entitlement resolution at the API level</li><li>Paywall evaluation logic within the Pelcro SDK to recognize cross-site entitlements</li><li>No change to purchase flows or checkout UI behavior</li></ol>&nbsp;✔️ This solution will include the following limitations:<ol><li>Applies only to sites under the same Pelcro account</li><li>Does not extend access across different Pelcro accounts</li><li>Products configured for a single site will continue to behave as they do today</li><li>Retroactive application to existing subscriptions is out of scope.</li></ol>

Subscription across multiple sites

<h3>Problem Statement</h3>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 StoryAs 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.

Introduce Activity logs in subscriptions details view

<h2>🔍 Problem Statement</h2>As a Pelcro admin, I experience the inability to apply an existing customer balance to an open invoice that was generated before the balance existed, which results in inefficient manual workarounds, disrupted billing flows, and increased operational overhead.<div data-type="horizontalRule"><hr></div><h2>💡 User Story</h2>As a Pelcro admin, I want to apply an existing customer balance to an already open invoice, so that I can settle outstanding charges accurately without canceling subscriptions or recreating invoices.<div data-type="horizontalRule"><hr></div><h2>🎯 Definition of Done (DoD)</h2>A feature is done when:✔ Given a customer with an available customer balance and an open/past_due invoice generated prior to the balance being added, the admin can apply the balance to the invoice, then the invoice reflects a partial or full payment using that balance.✔ Given the customer balance fully covers the invoice amount, the admin can apply the balance, then the invoice is marked as <code>paid</code> with no additional payment required.✔ Given the customer balance partially covers the invoice amount, the admin can apply the balance, then the remaining amount can be settled by either:<ul><li>Charging the customer’s default credit card (via Charge Customer), or</li><li>Recording an offline payment (via Mark as Paid).</li></ul>✔ This change will impact Admin UI and API, specifically:<ul><li>Admin invoice payment actions</li><li>Customer balance application logic</li><li>Invoice payment state transitions ([clarify API endpoint(s)]).</li></ul>✔ This solution will include the following limitations:<ul><li>Customer balance cannot be applied to <code>void</code>, <code>uncollectible</code>, or <code>paid</code> invoices.</li><li>Customer balance cannot exceed the invoice outstanding amount.</li><li>Automatic balance application to historical invoices is not supported (manual admin action only).</li><li>Subscriber-facing UI behavior remains unchanged.</li></ul>

Allow Admins to Apply Customer Balance to Pre-Existing Open Invoices

Galal Abdo

🔍 Problem StatementFinance teams need to track how subscription revenue transitions from deferred to recognised over time. Without a Deferred &amp; Recognised Revenue Report, reconciliation against accounting standards (ASC 606 / IFRS 15) requires manual spreadsheet work, increasing audit risk and operational overhead.<hr>💡 User StoryAs a finance team member, I want a Deferred &amp; 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.<hr>🎯 Definition of Done (DoD)A feature is done when:✔️ Given a Pelcro organisation with active subscriptions, when a finance user opens the Deferred &amp; 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.

In Planning

Deferred & Recognized Revenue Report

🔍 Problem Statement
As a Pelcro admin, customers often have separate billing and access (login) email addresses, but the customer record exposes only one email field — so admins stuff the second address into Metadata, where it doesn't appear in exports or trigger the right communications.
💡 User Story
As an admin, I want a second, first-class email field on the customer record — a Billing email alongside the existing Main (access/login) email — so both addresses appear in exports and the right one receives the right notifications.
🎯 Definition of Done (DoD)
<ul>
 <li>✔ Given a customer record, when an admin sets a Billing email, then invoices / payment-failure / receipt emails are sent to it (falling back to the Main email when unset).</li>
 <li>✔ Both fields are returned by the Core API and included in customer/subscription exports.</li>
 <li>✔ This change will impact UI / API — specifically the Customer profile (Platform UI), the Customer resource (Core API), and billing email templates.</li>
 <li>✔ Limitations: exactly two email addresses supported; no shipping/notification email beyond Main + Billing in this scope.</li>
</ul>

2nd email address field

JenMaz

🔍 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)
<ul>
 <li>✔ 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.</li>
 <li>✔ Plan Modal, Change-Plan flow, and Checkout plan selector all respect <code>sort_order</code> from the API; no caching conflicts.</li>
 <li>✔ This change will impact UI / API / SDK — specifically the Plans page (Platform UI), the plans Core API (new <code>sort_order</code> field), and the ReactJS Elements Plan Modal component.</li>
 <li>✔ Limitations: plans without <code>sort_order</code> default to creation order (backward-compatible).</li>
</ul>

Reorder pricing plans

Sackadelic

Pelcro today returns a generic invalid result for coupon validation across many distinct business rules (expired, wrong plan, segment, redemption limits, etc.), with inconsistent HTTP statuses and free-text messages whose location varies by case. To support our checkout flow, we need a stable, enumerated <code>failure_reason_code</code> on every coupon validation failure — order preview, subscription commit, and campaign-attached coupons (<code>coupon.valid: false</code>) — returned with one documented HTTP status at a fixed body location, identifying the coupon as the failing input, plus structured <code>failure_reason_detail</code> for support and ops. We will map codes to subscriber-facing copy and will manage any abuse/enumeration messaging on its side — please do not collapse distinct failure reasons in the API. Please provide a published reason-code dictionary, sample error payloads for each code, and confirmation that sticky re-validation on plan change returns plan-eligibility failures distinctly from expired/unknown codes.Attached is a more complete requirements document. Please review.<file-preview-component data-featurebase-content-filename="Checkout-v3-Pelcro-Coupon-Error-Requirements.md" data-featurebase-content-filesize="11751" data-featurebase-content-filetype="text/markdown" data-featurebase-content-key="68a7881585140e496a0d31b9/post/6a67949f5c14469d22d75898/019fa49b-bc99-7bf0-84a2-5c2b7d6a21ed/b64u-Q2hlY2tvdXQtdjMtUGVsY3JvLUNvdXBvbi1FcnJvci1SZXF1aXJlbWVudHMubWQ.md" src="https://68a7881585140e496a0d31b9.featurebase-attachments.com/c/post/6a67949f5c14469d22d75898/019fa49b-bc99-7bf0-84a2-5c2b7d6a21ed/b64u-Q2hlY2tvdXQtdjMtUGVsY3JvLUNvdXBvbi1FcnJvci1SZXF1aXJlbWVudHMubWQ.md?X-Amz-Expires=3600&amp;X-Amz-Date=20260815T110000Z&amp;X-Amz-Algorithm=AWS4-HMAC-SHA256&amp;X-Amz-Credential=DO801TYC4FCVNNEKURKM%2F20260815%2Ffra1%2Fs3%2Faws4_request&amp;X-Amz-SignedHeaders=host&amp;X-Amz-Signature=3ae408ff4d726260988b81cfcad7b6dc01519a2e99b7405023635f4f1a1805a5"></file-preview-component>

Open API coupon validation

Mike Gilbert

<h3>Problem Statement</h3>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.<div data-type="horizontalRule"><hr></div><h3>User Story</h3>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.<div data-type="horizontalRule"><hr></div><h3>Proposed Solution</h3>Introduce a Pause Subscription feature with controlled rules:<ul><li>Subscribers can pause their subscription once per calendar year</li><li>Maximum pause duration: 90 days</li><li>Billing is fully stopped during the pause</li><li>Subscription automatically resumes at the end of the selected period</li><li>Users can resume early at any time</li><li>During pause, user access downgrades to free-tier entitlements</li><li>Admins can override pause/resume states</li></ul>This feature must follow Pelcro’s API-first architecture, with full support across UI, API, SDK, and webhook layers.<div data-type="horizontalRule"><hr></div><h3>Scope &amp; Components Affected</h3><h4>UI (React Elements)</h4><ul><li>Add “Pause Subscription” option in account settings</li><li>Duration selector (up to 90 days)</li><li>Display:<ul><li>Pause status</li><li>Remaining pause time</li><li>Resume button (early resume)</li></ul></li><li>Messaging for:<ul><li>“Once per year” restriction</li><li>Access downgrade during pause</li></ul></li></ul><h4>API (Laravel Backend)</h4><ul><li>New endpoints:<ul><li><code>POST /subscriptions/{id}/pause</code></li><li><code>POST /subscriptions/{id}/resume</code></li></ul></li><li>Extend subscription resource:<ul><li><code>pause_start_at</code></li><li><code>pause_end_at</code></li><li><code>pause_used_this_year</code> (boolean or counter)</li></ul></li><li>Logic for:<ul><li>Enforcing one pause per year</li><li>Validating max 90-day duration</li><li>Blocking billing during pause</li><li>Automatic resume job (cron/queue)</li></ul></li></ul><h4>SDK (JS-SDK)</h4><ul><li>Methods:<ul><li><code>pauseSubscription(subscriptionId, duration)</code></li><li><code>resumeSubscription(subscriptionId)</code></li></ul></li><li>Expose pause metadata in subscription object</li></ul><h4>Admin / Dashboard</h4><ul><li>Admin controls to:<ul><li>Force pause</li><li>Force resume</li><li>Override annual limit (if needed)</li></ul></li><li>Visibility into pause history</li></ul><h4>Webhooks / Integrations</h4><ul><li>Events:<ul><li><code>subscription.paused</code></li><li><code>subscription.resumed</code></li></ul></li><li>Include metadata:<ul><li>Pause duration</li><li>Resume trigger (auto vs manual vs admin)</li></ul></li></ul><div data-type="horizontalRule"><hr></div><h3>Key Functional Requirements</h3><ul><li>Users can pause:<ul><li>Only once per year</li><li>For a maximum of 90 days</li></ul></li><li>Billing:<ul><li>Fully stopped during pause</li><li>Resumes normally after pause</li></ul></li><li>Access:<ul><li>Downgraded to free account level</li></ul></li><li>Resume:<ul><li>Manual (anytime)</li><li>Automatic (end of pause period)</li></ul></li><li>Applies to:<ul><li>Monthly subscriptions</li><li>Annual subscriptions</li><li>Bundles / all subscription types</li></ul></li><li>Admin override:<ul><li>Required for support and edge cases</li></ul></li></ul><div data-type="horizontalRule"><hr></div><h3>Impact &amp; Business Context</h3><ul><li>Client Impact: High — enables modern retention strategy used by leading subscription platforms</li><li>Revenue Impact:<ul><li>Short-term: deferred revenue</li><li>Long-term: reduced churn, improved LTV</li></ul></li><li>User Experience: Significantly improved flexibility and control</li><li>Operational Impact: Requires support tooling (admin overrides)</li><li>Adoption: Likely high across all Pelcro clients</li></ul><div data-type="horizontalRule"><hr></div><h3>Risks &amp; Considerations</h3><ul><li>Billing Complexity:<ul><li>Handling mid-cycle pauses (especially annual plans)</li></ul></li><li>Entitlement Sync:<ul><li>Ensuring real-time downgrade to free tier</li></ul></li><li>Abuse Prevention:<ul><li>Annual limit enforcement critical</li></ul></li><li>Analytics Impact:<ul><li>Need clear distinction between paused vs churned users</li></ul></li></ul>

Introduce Pausing Subscriptions

Gabrielle Sellitti

🔍 Problem StatementAs a media ad sales rep, I manually assemble advertising quotes across disconnected tools, which causes slow turnaround, pricing errors, and lost deals.💡 User StoryAs an ad sales rep, I want to describe a deal in natural language and have the AI assemble a structured quote, so that I can generate accurate quotes in minutes instead of hours.As an ad sales rep, I want to export the finalized quote as a PDF and email it to the prospect, so that I can close without leaving the tool.🎯 Definition of Done (DoD)✔ Given a chat session in the quote UI, when the rep describes ad products, quantities, and terms, then the AI populates a structured quote draft via the Quoting API and renders editable line items.✔ Given a populated quote draft, when the rep confirms it, then the system generates a PDF and sends it to the prospect's email through the Quoting API.✔ Given the AI lacks a required field (rate card, term, customer), when generating the quote, then it prompts the rep for the missing input before finalizing.

Configure Price Quote (CPQ)

🔍 Problem StatementE-commerce SKU orders only support credit card and BACS, limiting checkout options for buyers who prefer other payment methods.💡 User StoryAs a client admin, I want to offer invoice-based payment for e-commerce orders, so that buyers can pay via credit card or offline payment against an invoice.As a client admin, I want to accept PayPal, Google Pay, and Apple Pay for e-commerce orders, so that buyers have more checkout options.As a buyer on the default checkout UI, I want to select from these payment methods, so that I can pay however I prefer.🎯 Definition of Done (DoD)✔ Given e-commerce checkout, when a customer selects "Send Invoice," then an invoice is generated and payable via credit card or offline payment.✔ Given e-commerce checkout, when a customer selects PayPal, Google Pay, or Apple Pay, then the order completes and is paid through that method.✔ This change will impact UI and API, specifically the e-commerce checkout endpoint(s) and the default checkout UI's payment method selector.✔ This solution will include the following limitations: requires each payment gateway (PayPal, Google Pay, Apple Pay) to be configured and enabled at the platform level.

Support additional payment methods for e-commerce orders (Invoice, PayPal, Google Pay, Apple Pay)

🔍 Problem StatementAs a logged-in subscriber, I have no conversational surface to manage my account, which forces me into multi-step UI flows or human CX for routine tasks (view invoices, change address, update payment, switch plan, cancel).💡 User StoryAs a subscriber, I want to open an in-page chat panel on the publisher site and ask the AI agent to read or modify my account, so that I can complete routine tasks without leaving the page or contacting support.As a publisher, I want to embed this concierge as a ReactJS Element on any page, so that I can deploy AI-driven self-serve CX with the same integration model as existing Pelcro Elements.As an end user, I want destructive or financial actions to require explicit confirmation in-chat, so that the agent cannot cancel, charge, or change my plan without my approval.🎯 Definition of Done (DoD)✔ Given a subscriber is authenticated on the publisher site via the Pelcro JS-SDK, when the concierge Element is mounted, then a docked chat panel renders and the session inherits the subscriber's existing Pelcro auth token without a second login.✔ Given the chat session is active, when the user sends a message, then the agent connects to the Pelcro MCP server (FR-01) using the subscriber-scoped bearer token and routes API calls through MCP tools only — no direct REST calls from the front-end.✔ Given an MCP tool is invoked, when the response arrives, then the panel renders structured cards for known entities (invoices, subscriptions, plans, addresses, payment methods) with per-row actions (PDF, change, cancel) and shows the underlying tool name and endpoint for transparency.✔ Given the user requests a write action (address update, payment method change, plan switch, cancellation, refund request), when the agent prepares the call, then the panel surfaces a confirmation step with the exact change diff and blocks execution until the user confirms in-chat.✔ Given any agent response, when it renders, then a persistent footer disclaimer states "AI may be inaccurate. Verify critical actions before confirming."✔ Given a chat session, when the user reloads the page or returns later, then the conversation history persists per-subscriber and is retrievable via a history control in the panel header.✔ Given a publisher wants to embed the concierge, when they add the Element to their page, then they can configure panel position (docked right, floating bubble), branding (logo, accent color), allowed tool scope (read-only vs. read-write), and welcome prompt via standard Element props.✔ This change will impact UI and SDK, specifically a new ReactJS Element ("Subscription Concierge") in pelcro-elements and a session/token handoff helper in pelcro-js-sdk.

Customer Service Concierge

🔍 Problem StatementSubscription metadata is not displayed on the Subscription Details page in the admin dashboard. Admins who have set metadata via the API must use API calls to view it, creating an unnecessary context switch.<hr>💡 User StoryAs a Pelcro admin, I want subscription metadata to be visible on the Subscription Details page, so that I can view custom data directly in the dashboard without making API calls.<hr>🎯 Definition of Done (DoD)A feature is done when:✔️ Given a subscription with metadata, when an admin views the Subscription Details page, then all metadata key-value pairs are displayed in a dedicated section.