Feedback
Roadmap
Changelog

Have something to say?

Tell us how we could make the product more useful to you. We URGE you to use the Pelcro Discovery GPT to help structure your thoughts and recommend a feature request that will be quickly digested by our team!

HTML Support for Paywall Titles & Subtitles

🔍 Problem Statement As a Pelcro admin, I experience limitations when configuring paywall messaging because titles and subtitles only accept plain text, which results in being unable to add anchor links or basic HTML elements (e.g. links to Terms, Privacy Policy, or contextual help) within Pelcro-powered Meter and Regular Paywalls. 💡 User Story As a Pelcro admin, I want to add HTML elements (could be initially scoped to anchor links if allowing other elements is too complicated) to the titles and subtitles of Meter and Regular Paywalls during product configuration, so that I can provide richer, contextual messaging and compliance-related links without requiring custom frontend work. 🎯 Definition of Done (DoD) A feature is done when: ✔️ Given a product paywall configuration (Meter or Regular Paywall), when an admin enters supported HTML markup in the title or subtitle fields, then the content is saved, sanitized, and rendered correctly in the Pelcro Default UI. ✔️ This change will impact UI, API, and SDK, specifically: Admin UI: Paywall configuration fields for: Meter step → title, subtitle Select step → title, subtitle Field input type updated from plain text to HTML markup. API: Product / paywall configuration endpoints updated to accept and return sanitized HTML strings. Pelcro Default UI / JS SDK: Meter and Regular Paywalls render allowed HTML elements correctly and consistently. ✔️ This solution will include the following limitations: Only explicitly allowed HTML elements are supported (initial scope limited to tags). All HTML is sanitized server-side; unsupported tags or attributes are stripped or rejected. No support for inline scripts, styles, or advanced HTML elements. Existing text-only configurations remain backward compatible and unaffected.

Galal Abdo About 1 hour ago

Allow Orders to Be Canceled and Refunded Before Being Marked as Paid

Problem Statement Currently, orders must be marked as paid before they can be returned or refunded. Marking an order as paid automatically triggers downstream processing, including sending the order to the warehouse fulfillment system. This creates an operational issue when a client needs to cancel and refund an order before fulfillment. Current Behavior Order must be marked as paid to enable refund/return actions Marking as paid: Triggers order processing Sends the order to the warehouse Causes the order to appear in fulfillment lists Clients must then: Contact the warehouse manually Ask them not to fulfill the order Expected Behavior Orders can be: Refunded without being marked as paid Canceled orders should: Not be sent to the warehouse Not appear in fulfillment lists

Sara Habib About 3 hours ago

Feature Request: full country name available in list & segment exports

Problem: Only the country code is available when exporting single lists or segments. USPS requires the full country name spelled out on an address label and will not accept only the country code. To resolve this, we have to manually add in the full country name after exporting. Example: To ship to Canada, the label must say “Canada” at the end of the address and not “CA” Solution: add the full country name column back into the list and the segments exports so that no manual manipulation is needed in order to use the lists and segments to create address labels. This feature is currently available from the fulfillment export, but not all of our lists get added to a fulfillment.

Katie About 3 hours ago

Append Gift Code Automatically to Gift Redemption URL

Problem Statement Currently, when a customer is gifted a subscription, the gift code is sent separately in the email. The recipient must manually copy and paste the gift code into the redemption page, which creates friction and increases the risk of user error. Proposed Feature Allow the gift redemption URL to automatically include the gift code as a query parameter, so the recipient can redeem the gift without manually entering the code. Example: https://Site.com/?view=gift-redeem&gift_code=@GIFT_CODE@ User Story As a gift recipient, I want the gift code to be pre-filled or automatically applied when I click the redemption link, So I can redeem my gift quickly without copying and pasting a code. Expected Behavior Gift redemption URLs support a gift_code query parameter When present, the gift code is automatically recognized by Pelcro The redemption flow proceeds without requiring manual code entry Business Value Reduces friction in the gift redemption flow Improves conversion and completion rates for gifted subscriptions Decreases support requests related to gift code issues

Sara Habib 3 days ago

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

mesim 4 days ago

Durable Metered Paywall Using Device-Based Identification

Summary Improve Pelcro’s metered paywall so free-article limits cannot be easily reset using incognito mode or simple cookie clearing. Problem Metered paywalls today rely on cookies. Users can bypass them by: Opening incognito/private windows Clearing cookies or cache Reopening the same browser repeatedly This requires no technical skill and undermines meter effectiveness. Clients regularly flag this as a core weakness. Goal Reduce casual meter abuse without: Forcing login for free articles Breaking SEO or crawler access Claiming “perfect” enforcement This is about raising the bar, not eliminating all bypasses. Proposed MVP Use device / browser-based identification (probabilistic fingerprint) Persist meter across sessions in the same browser Prevent repeated incognito resets No login required Same behavior for crawlers Non-Goals Cross-device or cross-browser enforcement Blocking advanced paywall-removal tools Hard paywall behavior Impact Fewer trivial bypasses Higher publisher confidence Estimated 4–6% revenue uplift for metered publishers (customer-provided benchmark) Reduced support escalations and sales objections

Michael Ghattas 4 days ago

✨ Feature Request: Webhook Event for Payment Method Deletion (Braintree)

Affects API (webhooks) Integrations (Braintree, Stripe parity) UI (indirect – user action triggers event) Notifications (downstream client usage) Problem Statement When using Braintree as the payment provider, Pelcro does not emit a webhook event when an end user deletes a saved payment method from their account. The existing source.canceled webhook: Is Stripe-specific Requires manual cancellation on the Stripe side Is not triggered for Braintree customers As a result, clients using Braintree cannot reliably detect or respond to payment method removals. User Story As a Pelcro client using Braintree, I want to receive a webhook event when a user deletes a saved payment method, So that I can notify the user in real time, improve security transparency, and maintain feature parity across payment providers. Requested Behavior Emit a webhook event when a user deletes a payment method while using Braintree New event example: payment_method.deleted or source.deleted Alternatively: extend an existing normalized event if appropriate Provider-agnostic behavior Event should fire consistently for Stripe and Braintree Abstract provider-specific logic behind Pelcro’s API Webhook payload should include customer_id (Pelcro customer) payment_provider (braintree | stripe) payment_method_id (Pelcro + provider reference) subscription_id (nullable, if applicable) timestamp Non-sensitive payment method metadata (e.g. type, last4, brand) Trigger conditions Fired when deletion is initiated via: Pelcro UI Pelcro API JS-SDK (if applicable) Should not depend on provider-side manual actions Expected Outcome Clients can send real-time email notifications confirming payment method removal Parity between Stripe and Braintree integrations Improved security awareness, auditability, and user trust Reduced need for provider-specific workarounds Definition of Done (DoD) A normalized webhook event exists for payment method deletion Event fires for Braintree payment method removals Event behavior is consistent across Stripe and Braintree Webhook payload is documented in Pelcro API docs Event is covered by automated tests No sensitive payment data is exposed Backward compatibility is preserved for existing webhook consumers Notes / Open Questions Should this be a new canonical event (payment_method.deleted) or an extension of an existing one (source.deleted)? Should subscription context be required or optional? Any edge cases when a payment method is auto-removed (e.g. provider invalidation)?

Deiver Romero 5 days ago

Done

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.

Rana Haleem 7 days ago

Manage & Remove Saved Campaign Keys in Subscription Creation Flow

Problem Statement When creating a new subscription in Pelcro, the Campaign Key field displays a dropdown list containing a large number of previously saved entries. Over time, this list becomes cluttered and difficult to navigate. Admins are unable to: Remove outdated or unused campaign keys Manage or clean up the list Easily find the correct campaign key when creating subscriptions for customers This leads to slower workflows, higher risk of incorrect campaign attribution, and poor admin UX. User Story As an admin creating subscriptions for customers, I want to remove or manage saved Campaign Key entries, so I can quickly find and apply the correct key without scrolling through irrelevant or outdated values. Current Behavior Campaign Key dropdown auto-populates with all previously used values No option to: Delete campaign keys Archive unused keys Limit or filter the list List grows indefinitely as new keys are added Expected / Desired Behavior Admins should have the ability to manage Campaign Keys, including one or more of the following options: Option A — Admin Management View all saved Campaign Keys in a settings page Remove or deactivate unused keys Option B — UI Improvements Ability to hide inactive keys from the subscription flow Searchable / filtered dropdown

Sara Habib 10 days ago

Configurable Invoice Due Dates for Subscriptions

User Story As a billing or customer service admin, I want to control or delay invoice due dates for subscriptions, so invoices do not appear past due before the actual billing intent. Current Behavior Due date cannot be edited. No visible configuration at: Product level Subscription level Applies even when: Billing is offline (Not using a payment gateway) Expected / Desired Behavior Admins want to be able to define or override invoice due dates.

Sara Habib 11 days ago

Display One-Time Coupons at Subscription Level in Admin

Problem Statement Currently, one-time (duration = once) coupons applied at signup are not displayed on the subscription record in Pelcro Admin, even though: The discounted price is correctly applied, and There is a visible but empty “Coupon Code” field at the subscription level. This creates confusion for Customer Service teams and limits subscription-level reporting and auditing. User Story As a Customer Service team member, I want to clearly see the coupon code applied to a subscription directly in the Admin, so that I can support customers, audit discounts, and report accurately. Current Behavior (Expected but Limiting) Coupons with duration = once: Shown on invoices only Not shown on the subscription record Coupons with duration = forever: Shown on both subscription and invoice Expected / Desired Behavior Any coupon applied at signup — including one-time coupons — should be: Visible on the subscription level in Admin

Sara Habib 12 days ago

Feature Request: Enforce or Normalize Customer Data to Latin Characters

Problem Statement Some customer records contain non-Latin characters (e.g. Cyrillic, Korean) in names and address fields. This creates operational issues for: Postal fulfillment and mailing houses (unable to process non-Latin scripts) Admin-side customer search and record matching Pelcro currently stores customer input exactly as entered, with no validation, restriction, or transliteration of character sets. User Story As a publisher operations team, we want customer names and addresses to be stored in Latin characters, so that we can reliably search customer records and fulfill postal deliveries without manual corrections or mailing house errors.

Sara Habib 12 days ago

2

Planned

Add Invoice Notes to Subscription Create & Renew Flows

Problem Statement Currently, there is no way to add invoice notes during the Subscription Create or Renew flows before an invoice is generated. As a result, invoices are created without the necessary context or details, requiring manual follow-up or adjustments after invoice generation. User Story As an admin, I want to add invoice notes while creating or renewing a subscription, So that the invoice is automatically generated with the correct notes included.

Rana Haleem 13 days ago

Bill to and Ship to addresses included on generated invoices

As it was explained to me, for subscription based invoices the pdf’s that are generated can only contain the ship to address information on the invoice. It would really be helpful to have both ship to and bill to information displayed on the pdf’s as many of our clients have different addresses for their subscriptions. We often have to manually edit the pdfs to include this information and it is very time consuming. Please consider this feature in a future update, as it is becoming more and more of a problem for us. Thank you

Andrew Cifuentes 13 days ago

In Planning

Apply Credit Notes to Existing Invoices

Problem Statement Admins currently lack a clear way to apply credit notes directly to invoices, making it difficult to properly adjust invoice balances after an invoice has been created. User Story As an admin, I want to be able to apply a credit note directly to an existing invoice, So that I can accurately adjust the invoice balance after it has been created.

Rana Haleem 13 days ago

In Progress

Subscription Start-Date in The Future (Platform + API)

Problem Statement Today, Pelcro requires subscriptions to start immediately upon creation, which limits operational flexibility for customer support and sales teams. Many businesses need to create subscriptions in advance with a specific future start date—for example, when a customer signs up early but requests access to begin later. User Story As a subscription operations, I want to create a subscription with a defined future start date, So that subscription access, billing, and renewal periods begin on the requested date without manual follow-up or adjustments. Subscription Creation & Configuration For accounts using pelcro’s engine A new input field, “Scheduled start date”, is available when creating a subscription. When a scheduled start date is set, the subscription is created in a new scheduled status. The subscription phase does not start until the scheduled start date. No subscriber access is granted before the scheduled start date. ### Billing & Invoicing Introduce a new option when creating a subscription: Billing behavior ☐ Bill immediately (advance invoicing) ☐ Bill starting on the selected date If Bill immediately is selected: Current behavior remains unchanged (invoice gets generated & pays now) If Bill starting on selected date is selected: No invoice is generated at creation Billing, invoicing, and renewal cycles are anchored to the selected date The subscription is created with a scheduled status until the anchor date This allows all invoices to be generated on the same weekday, regardless of when the subscription is created Should work with AI plans Activation & Revenue Recognition On the scheduled start date: The subscription automatically transitions from scheduled to active. The first subscription phase begins. Revenue recognition starts on the scheduled start date. Subscription renewal dates are anchored to the scheduled start date. APIs & Status Exposure The new scheduled status is returned consistently across: Open API Core API Webhooks Status behavior is consistent with existing subscription statuses (e.g., active, canceled, expired). Backward Compatibility Existing subscription behavior remains unchanged when no scheduled start date is provided. No breaking changes are introduced to existing APIs or integrations.

Rana Haleem 14 days ago

In Progress

Cash Revenue recognition

Problem Statement 1 — Eligibility Revenue should only be recognized for invoices that have been successfully fully paid (or partially paid, TBD); unpaid or failed invoices must not contribute to recognized revenue. Problem Statement 2 — Timing Revenue recognition must begin on the invoice payment date, not on the invoice creation date, when payment succeeds after an initial failure. Problem Statement 3 — Subscription Access & Term Alignment Subscription access and the subscription term must begin on the payment success date; if payment succeeds after the initial subscription attempt, the subscription start and renewal dates should shift to align with the payment date. User Story 1 — Revenue Eligibility As a finance user, I want revenue to be recognized only for invoices that are paid, so that unpaid or failed invoices do not count toward recognized revenue. User Story 2 — Revenue Timing As a finance user, I want revenue recognition to start on the invoice payment date, not the invoice creation date, so that revenue timing reflects when payment actually succeeds. User Story 3 — Subscription Access & Term Start As a subscriber, I want my subscription access and renewal period to begin when my payment succeeds, so that my access duration aligns with when I actually paid. Solution 1: Revenue recognition (Problem 1) Revenue is recognized only for invoices with status = paid (Partial payments: TBD). No revenue is recognized for unpaid or failed invoices, and no revenue is backdated to periods before payment. Solution 2: Subscription term alignment (Problem 2) On the first successful payment, the subscription term is anchored to the payment date by setting invoice.current_period_start = invoice.paid_at and invoice.current_period_end = invoice.paid_at + plan_interval, and copying these values to the subscription. This ensures access starts when the user actually pays and renewals align to that date (e.g., Jan 7 → Feb 7). Solution 3: Subscription activation & access (Problem 3) When a subscription is created, payment is attempted immediately, but the subscription remains incomplete and grants no access until the first payment succeeds. If payment fails, the subscription stays pending. When payment succeeds (invoice.paid_at), the subscription becomes active. Definition of Done — Product-level Revenue Recognition Strategy Configuration A new product-level dropdown labeled “Revenue recognition strategy” exists on the Product configuration page. The dropdown has two options: Invoice-creation-based (default) — preserves existing behavior. Invoice-payment-based — enables payment-anchored behavior. All existing products default to Invoice-creation-based with no behavior change. Invoice creation date (Default) Revenue recognition behavior remains unchanged. Unpaid or failed invoices continue to be treated according to current logic. Subscription activation, access, and term dates behave exactly as today. Payment creation date (New) Only invoices with status = paid are included in revenue recognition. Unpaid or failed invoices are automatically excluded from revenue reports. Revenue recognition starts at invoice.current_period_start. invoice.current_period_start is set to invoice.paid_at. invoice.current_period_end is set to invoice.paid_at + plan_interval. Subscription activation occurs only after the first invoice is paid. Subscription current_period_start and current_period_end match the invoice period. Subscriber access begins at current_period_start. Backward Compatibility No breaking changes are introduced. Existing products and subscriptions continue to use Invoice-based behavior unless explicitly updated. Acceptance Criteria Switching a product to Invoice-payment-based immediately enforces payment-anchored access, term dates, and revenue filtering. Revenue reports correctly exclude unpaid invoices for Payment-based products. Revenue reports remain unchanged for Invoice-based products.

Rana Haleem 14 days ago

In Planning

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

Rana Haleem 18 days ago