Hi Creem team, I have a question regarding the public display of my operator name. Before verification, I provided my real and accurate operator information on my website and legal pages, and I completed Creem's verification using my real identity. My account/domain was then approved. I am not trying to change my legal operator, account owner, or any information that Creem has verified. I only want to keep my real operator name private from the public. Would I be allowed to remove my real personal operator name from my public website, Terms of Service, and Privacy Policy, and instead display a public alias/display name such as “MastCode”? For example: Operator: [my real legal name] Preferred public display: Operated by / Public name: MastCode Creem would still keep my real verified legal identity privately on the account. I only want visitors and customers not to see my personal legal name publicly. Is this allowed under Creem's rules and Merchant of Record requirements? I want to confirm before changing anything. Thank you!

elihz_99216 about 9 hours ago

💡

Feature Request

Currently, we can add discount using discount code. It would be better if we could just pre-apply the discount, again without any code. No code field will be required, and discount will be applied automatically to the products selected.

abhishekjunghare007 10 days ago

💡

Feature Request

I want to build a fully custom checkout experience for both one-time purchases and subscriptions, without redirecting users to creem.io and without embedding the full Creem checkout UI. Similar to Stripe Elements / Payment Element, Creem could provide secure payment components / JS SDK for: card number expiry CVC Apple Pay Google Pay The merchant should control the entire page design, layout, copy and flow on their own domain, while Creem still handles payment processing, subscriptions, taxes and Merchant of Record responsibilities. Ideally the flow would be: create checkout session → render payment elements on merchant site → confirm one-time payment or subscription → receive webhook Sensitive card data should never touch the merchant backend. This would allow a completely native checkout experience on the merchant’s own domain for both purchases and subscriptions.

mykhailo.archemap 10 days ago

💡

Feature Request

It would be great to have a cross-selling feature in Creem.io that allows sellers to recommend related products directly on a product’s checkout or thank-you page. For example, when a customer purchases Product A, we could display: “You may also like” - Related Product B - Related Product C - Bundle or Upgrade It would be even better if sellers could choose which products to show and optionally offer a special discount when the customer adds a recommended product. This could help creators increase their average order value (AOV) and make it easier for customers to discover complementary products. A simple “Related Products / Cross-Sell” section on product pages and checkout would be extremely useful.

craftsvgsofficial 13 days ago

💡

Feature Request

Please add a configurable maximum number of failed renewal payment retries for subscription products, similar to the retry settings available in PayPal. For example, a merchant should be able to set a product to: Maximum retry attempts: 1 If the renewal payment fails and the paid subscription period has already expired, the subscription should then be automatically cancelled instead of continuing payment retries for many additional days. This is especially important for SaaS and access-based services. Once the customer's paid access period has expired, we may want the subscription to terminate immediately after the first failed renewal so the customer can simply create a new subscription later. At the moment Creem controls the retry schedule automatically, and merchants cannot configure the maximum number of attempts. This can result in an old past_due subscription remaining alive for many days and potentially charging the customer after they have already stopped using the service or created another subscription. Ideally this should be configurable per product in the Dashboard and through the API, for example: Maximum payment retries: 0 / 1 / 2 / 3 / Creem default When the configured maximum is reached, Creem should automatically move the subscription to canceled and stop any further collection attempts.

User 13 days ago

💡

Feature Request

I would love to see a rich text editor for product descriptions in Creem.io. Currently, it would be very helpful to have formatting options that allow sellers to create more professional and organized product pages, such as: Headings and subheadings Bold and italic text Bullet points and numbered lists Text alignment Different text sizes Paragraph spacing Highlighted or emphasized text A rich text editor would make product descriptions much easier to read and would allow sellers to clearly present product features, what's included, usage instructions, licensing terms, and other important information. This would significantly improve the presentation of products and create a more professional shopping experience for customers.

craftsvgsofficial 16 days ago

💡

Feature Request

https://discord.com/channels/1262843562140241952/1541906774918176988 **Problem** Activations can't be removed from the dashboard. When a customer changes device, reinstalls, or hits their activation limit, the only way to free a slot is to call the API: POST /v1/licenses/deactivate { key, instance_id } That means a routine support action needs an engineer, or at least someone comfortable with curl and able to find the instance_id first. For teams where support and engineering aren't the same person, it turns a thirty-second fix into a ticket. **Request** Surface activations on the license detail view in the dashboard — listing instances with their status and creation date — and allow deactivating one from there. **Why this should be cheap** The capability already exists; POST /v1/licenses/deactivate does the work and returns the updated activation count. This is a UI gap rather than a platform one.

elihz_99216 18 days ago

💡

Feature Request

**Problem** When upgrading a subscription with proration-charge-immediately, there's no way to show the customer what they're about to be charged. The upgrade endpoint applies the change and takes payment in the same call, so the prorated amount is only knowable afterwards, from the resulting transaction. Any upgrade flow that needs a confirmation step — "You'll be charged $X today, continue?" — can't be built accurately today. It's also awkward wherever disclosing the amount before charging is expected practice. **Why this can't be worked around merchant-side** The prorated base can be calculated in-app with some effort. The tax can't. As merchant of record, Creem calculates VAT, GST and sales tax across 190+ jurisdictions from the customer's location and status, so any figure a merchant computes is an estimate rather than the amount that will actually be charged. Discounts, existing credit balances and final rounding compound the same gap. That makes this a platform capability rather than something merchants can build around. **Request** An endpoint that returns the exact amount an upgrade would charge, without applying it — effectively a preview of the upcoming invoice. Given a subscription, a target product and an update_behavior, it should reflect proration, tax, active discounts, available credit balance and rounding, and return the same total the customer would actually be charged. **Current options and why they fall short** - Estimate it app-side and caveat it as approximate. Works, but isn't authoritative and the receipt may differ from what was shown. - Switch with proration-none and charge the difference through a separate checkout session. The checkout does display the exact taxed total before payment, but it splits one plan change into two transactions and the proration base is still merchant-computed.

elihz_99216 18 days ago

1

💡

Feature Request

Today all update_behavior options (proration-charge-immediately, proration-charge, proration-none) change the subscription immediately. There's no way to schedule a change for the next renewal, so the common SaaS pattern — upgrade immediately, downgrade at period end so the customer keeps what they paid for — has to be built in the merchant's own app: store a pending plan, keep serving the old tier, and call subscriptions.update shortly before current_period_end. Requested by two merchants in the Discord. Polar supports this natively as "Apply on next period."

elihz_99216 18 days ago

1

💡

Feature Request

the current customer portal UI is soo clunky even though it works. a little layout redesign and tabs addition would really help.

realtrixon 21 days ago

💡

Feature Request

There is no ability to edit discounts in the Creem platform side yet. Sometimes we add new products and only option is to delete the discount (and lose all the sale stats on it) and recreate it with the new products selected. Also the product selection in the new UI is not the best UX, we need to select one by one, multi selection dropdown like before would be much more beneficial.

User 21 days ago

💡

Feature Request

Instant Payout in Creem Wallet so we can top-up API Credits for customer A Creem Wallet + Virtual Card tied directly to the merchant balance. The idea would be: Keep available Creem funds inside a Wallet instead of requiring an immediate bank payout. Allow merchants to create a Creem Virtual Card funded by their available Wallet balance. Use that virtual card to pay for business expenses on third-party services — especially API credits, cloud services, AI providers, hosting, and other SaaS tools. Support instant or automatic funding of the virtual card from the Wallet. Let merchants set spending limits, freeze/unfreeze cards, and optionally create separate virtual cards for different services. Clearly separate pending, available, and card-spendable balances. Keep the option to withdraw remaining funds to a linked bank account normally. For businesses that receive customer payments through Creem and then immediately need to spend part of that revenue on infrastructure or external APIs, this would remove the unnecessary flow of: Creem → bank payout → bank/card → third-party API credits Instead, available revenue could be reused directly through the Creem Virtual Card, making cash flow significantly faster and more useful for businesses with high infrastructure costs.

natadtech 24 days ago

1

💡

Feature Request

It would be really useful to be able to generate checkout URLs with a custom_fields[x].value parameter, so the payment form renders with a pre-filled value for that field (or, at minimum, a placeholder in the text inputs). A concrete example where this matters: Suppose you run a multi-tenant SaaS where each tenant can register with the same email on a different domain (e.g. acme.domain.com). That domain has to be stored on the Creem side as well, so you know which subscription is active for which domain. When the checkout URL is generated by the SaaS itself, this data is already known, so it makes sense for it to arrive pre-filled and correct in the form — no room for user error. When the user instead arrives via a generic checkout URL that isn't pre-filled with custom_fields, they may not understand what to enter if there's no placeholder guiding them. For that reason, supporting both a value (pre-filled) and a placeholder (hint text) for custom fields would be a great addition. One more consideration: it would also help to support a read-only property on custom fields. In the multi-tenant case above, the pre-filled domain value should ideally be locked so the user can't accidentally (or intentionally) edit it, since a wrong value would break the mapping between the subscription and the tenant. A read-only flag passed alongside value would cover this cleanly.

Manfredi about 1 month ago

💡

Feature Request

We really need a weekly billing cycle, this will benefit all Creem and their users. I believe this should be easy to add, we need this asap.

seyallc about 1 month ago

1

💡

Feature Request

Products can currently only be priced in USD or EUR. For merchants with customers in the UK, Australia, New Zealand, or Canada, that means those customers check out in a foreign currency: the price looks unfamiliar, their bank converts it at card rates, and many pay a 2 to 3 percent foreign transaction fee on top. It measurably hurts conversion outside the US and EU, and other MoR platforms already support per-currency pricing on a single product. Requests, in order of preference: Per-currency price points on a single product, so one subscription product can carry USD, GBP, EUR, AUD, NZD, and CAD prices and checkout picks the right one by customer location. Failing that, support for creating products in GBP, AUD, NZD, and CAD, so merchants can run one product per currency and route customers server-side. As a lighter interim step, local-currency display at checkout: keep billing in USD but show an approximate converted amount in the customer's own currency before they pay. Happy to beta test any of these.

developer about 1 month ago

1

💡

Feature Request

There's no way to copy a catalog from test mode to live. Everything proven in test has to be recreated by hand in live - products, discounts, webhook endpoint config - and retyping a proven configuration is exactly where a typo enters. ("Clone a product" helps within a mode, but not across them.) A "copy to live" (and back) would close it. We ended up building our own sync script against the products API partly for this reason, and it can't carry the license-key settings because those are dashboard-only.

jayrabe about 1 month ago

💡

Feature Request

Indie launches lean on invite-only betas, founding groups and waitlist waves, and Creem has no native pieces for them today. Three concrete gaps, all hit while designing our own invite beta: Product visibility flag (unlisted/hidden). Today the only option is "don't share the link", and there's no documented statement of whether products are discoverable anywhere. Purchase-access codes - a code required to buy at all, which is different from a discount. Without it, merchants build their own gate in front of your checkout, which is what we're doing. Documented redemption limits on discount codes (single-use, max-N). These may exist; they aren't documented. With those three, "run an invite beta on Creem" becomes a playbook you can own for exactly the indie audience you serve. Without them, every merchant hand-rolls the same gate. Keywords: law of diffusion of innovation drive increase demand

jayrabe about 1 month ago

💡

Feature Request

I want to be able to complete KYC/KYB registration using Chinese characters since my official Mainland China business documents (like the Business License / 营业执照) are in Chinese. Entering details in English/Pinyin can cause verification mismatches.

Liu Chang about 1 month ago

2

💡

Feature Request

The documented failure test cards (4507 9900 0000 0028 / 0010 / 0044) are rejected by save-time card verification everywhere they could attach to a subscription. The customer portal's "Update Payment Details" and even a $0-due trial checkout both decline them. That makes them checkout-only simulators, and leaves no way to take a healthy test sub into past_due/dunning to verify what customers experience (emails, retry cadence, webhook sequence) before going live. Request: either a test card that succeeds on first auth and fails on subsequent charges (à la Stripe's 4000 0000 0000 0341), or a dashboard/API "simulate renewal failure" action in test mode.

jayrabe about 1 month ago

1

💡

Feature Request

The subscription mode, either scheduled or immediate, is only actually honoured on active subscriptions. If the subscription is in a trial state, any request to cancel it is actioned immediately. The documentation doesn't explain what a customer is supposed to do. Many people will sign up for a trial, cancel it, but still expect to be able to use the product during that trial. They just don't want to forget about it and get charged unintentionally. And we do want that for our customers either, relying on customers to forget cancelling trials is a bit shady practice in the industry. This one's quite a big red flag as we quite commonly see, customers subscribe to a trial immediately cancel through fear of forgetting. They can ultimately un-cancel as an informed choice if they wish to continue, or if they do feel comfortable, simply leave the subscription as is and let it renew. People who forget to cancel inevitably lead to chargebacks or support requests. The ask here is simply to honour the cancellation mode for trial subscriptions, the same way it does for active subscriptions. Perhaps this is an implementation bug.

sam about 2 months ago

💡

Feature Request