We use the embedded store front, so users will already have an account on moonbase. There is also a discourse forum, and we would like the users being able to post with their moonbase account. Options seem to be Oauth2 or OpenID connect. Thanks for considering :-)

Daniel Walz 6 days ago

💡

Feature Request

Having the functionality to enable 'Expired Trials Auto-Reset' after a definable period would greatly improve the returning potential customer experience and would increase sales.

Oliver Gretz 11 days ago

💡

Feature Request

For merchants selling books and courses through PDFs, being able to offer watermarking for downloadable files would be great. This way, each customer receives a unique PDF with their information embedded, and can be used to reduce sharing.

Tobias Lønnerød Madsen 13 days ago

💡

Feature Request

When an existing Moonbase customer’s name is updated after account confirmation, the updated name is correctly saved in Moonbase but is not propagated to the corresponding MailerLite subscriber. Our flow is: We create a passwordless customer and provision a license using: POST /api/licenses/provision We set newsletter and product-update consent using: PATCH /api/customers/{customerId} The customer follows the Moonbase account-confirmation link, sets a password, and signs in. After authentication, we update the customer’s real name using: PATCH /api/customer/identity Authorization: Bearer {accessToken} Content-Type: application/json { "name": "Customer Name", "email": "customer@example.com", "communicationPreferences": { "newsletterOptIn": true, "productUpdatesOptIn": true } } The new name is visible on the customer in Moonbase. However, the existing MailerLite subscriber is not updated and retains the placeholder name originally used during provisioning. Expected behavior When a Moonbase customer’s name changes, the MailerLite integration should update the corresponding subscriber’s name while preserving their existing subscription status and communication preferences.

Benedikt 17 days ago

🐛

Bug Reports

Releases should support an additional platform called “Symbols”, under which developers can upload symbol collections for their build products. This enables symbolication of fully stripped Release builds, so crashes and issues on end-user machines can be analyzed meaningfully. Storing the symbols alongside a build in a private manner would streamline this process, instead of having to run a secondary storage system.

Benedikt 20 days ago

💡

Feature Request

It looks like the Storefront API currently allows us to set and update a customer’s billing address, but there does not appear to be an endpoint for retrieving the currently stored address. The sign-in and refresh responses only return the customer ID, name and email, and there is no documented GET endpoint for /api/customer/identity. For a custom customer portal, it would be very useful to have an authenticated endpoint such as: GET /api/customer/identity returning the customer’s name, email, billing address and communication preferences. Without this, we can update the billing address but cannot display or prefill the existing data.

Marc Wensauer 22 days ago

💡

Feature Request

Hi Moonbase team, in the checkout summary, the tax is currently displayed only as an amount, for example: Sales tax: €7.18 It would be much clearer to also show the applied tax rate: VAT (19%): €7.18 This is especially useful for international customers, since the tax rate may vary depending on the customer’s country. For European checkouts, “VAT” would also be more appropriate than the generic term “Sales tax.” Thanks!

Marc Wensauer 22 days ago

2

💡

Feature Request

Hi, we are embedding the Moonbase checkout on our own branded portal. The checkout works well, but the large gray background around the checkout card does not match our design. Is it possible to customize that background color for our store. We only mean the outer page background behind the checkout card, not the checkout card itself. Thanks!

Marc Wensauer 22 days ago

4

💡

Feature Request

Hi Moonbase team, we use the Custom Integration storefront mode. Customers authenticate through our server-side PHP integration using the Storefront API, and the access and refresh tokens remain securely stored in the PHP session. When we open the Embedded Storefront checkout, the browser widget does not recognize the existing customer session and asks for the customer details again. Is there a documented and supported server-to-browser session handoff or SSO mechanism for the Embedded Storefront? For example: a short-lived one-time token a signed session-exchange endpoint or another supported way to initialize the widget with an already authenticated customer We do not want to expose access or refresh tokens in the HTML or manually write the widget’s internal moonbase_authlocalStorage entry. What is the recommended architecture for sharing authentication between a server-rendered custom storefront and the Embedded Storefront checkout? Cheers, Marc

Marc Wensauer 23 days ago

2

💡

Feature Request

Hi, our storefront supports both English and German. Is there currently a way to set the language or locale of the embedded storefront and checkout, for example through Moonbase.setup()? Ideally, when our website is set to German, the complete checkout UI should also appear in German. I could not find a documented locale or language option. Is this already supported, or is localization planned? Cheers, Marc

Marc Wensauer 23 days ago

2

💡

Feature Request

We want to support both static groups where you add customers manually or through APIs, and “segments” which are auto-updated groups of customers decided based on a combination of conditions on customer attributes and/or events.

Tobias Lønnerød Madsen 25 days ago

💡

Feature Request

Today, we support attaching custom metadata to licensing events, but we’d like to also be able to record custom events. This would enable actual product analytics, to know what features are used, and could also be fed into the marketing pipeline through custom segments/groups.

Tobias Lønnerød Madsen 26 days ago

💡

Feature Request

I am experiencing an issue connecting Moonbase to Mailchimp. My Mailchimp account has multiple audiences, and the integration fails with a "Multiple audiences found" error. The current integration does not provide an option to select a specific audience, which prevents successful connection.

Thioune Philipp 28 days ago

🐛

Bug Reports

I want to use Instagram or Tiktok advertising to encourage people to start a trial of my plugin. This way I can get trial sign-ups, and potentially grow a remarketing list without requiring people to make a purchase directly from the advertisement. The problem is there is no good way to start a trial from a mobile device. The usual trial flow requires getting a download, and then activating the trial from within the app/plugin, all of which has to happen on a desktop device. So I want some flow that I can put on a landing page for mobile advertising that does not require a desktop download. One alternative would be to ask a customer to start a new account, and for them to remember that they wanted a trial of a given product when they open the email later on a desktop (if they even do this). This will be quite obscure and unlikely to be successful, since even if they create a new account on the mobile advertising landing page, it will not link directly to the product for the advertisement they responded to. Another alternative is to request an email address and send them a special email to start a trial of the product. The only way to do this right now would be with the third party mailing list service. I understand Moonbase may add this possibility with the Email Campaigns feature in development. However there is currently already an way to create a new license for a product in the management app, which sends a specific email to the customer to collect a license of a product. Theoretically I could have a duplicated product just for the trials with bundling to cross-grade to a full license of the same app with a purchasable product (if this makes sense). Or maybe [here’s the feature request] there could be a way to send a trial flow starter email via an API in a similar way to this. Then I could put that flow into a landing page for my mobile marketing campaign, and the email the customer receives would encourage them to complete the rest of the flow. As it is, I either need to build a mobile flow myself using third party email marketing services, or just send email marketing directly to purchase pages instead. I’m concerned this may have less success than encouraging a trial only. I hope you can help support mobile marketing strategies other than purchase only. Best regards, Nick

Nick about 1 month ago

💡

Feature Request

If I search for a term that doesn’t exist in any feedback posts, I would expect no posts to be returned. I expect exact term search in this case. Instead I seem to get every post back so I don’t know what’s relevant or not. If I search for a term that is in a post title, then I can see that term is highlighted in the results, so that is useful, but I still get a lot more results and I don’t know if the term is somewhere in the body of the post that I can’t see. This makes it difficult to know whether my feedback has already been provided by someone else, so I’m more likely to just make a new post. In time this might lead to a deeper backlog for you than there should be, since some posts might largely duplicate each other. This is feedback, but also a feature request to improve the search in feedback.

Nick about 1 month ago

📥

Feedback

I’m concerned that for some customers, requiring a billing address at the first page of the check-out flow might cause them to bounce. I think for ecommerce for software, many people are used to checking out via Paypal or Google/Apple Pay where they don’t need to provide an address directly to a new unknown, boutique vendor. I.e. to feel like they remain more anonymous with less data being provided. I don’t know legal requirements or what the payment APIs provide/require, but I’m pretty sure many checkout flows online don’t require explicitly entering a new address unless selecting credit card as payment type. So my request is could you please investigate this and consider whether you can move address collection to after choosing payment type. Then for online, email-based, pre-verified payment services, people can feel like they have not had to share information. I think the competition here is plugin vendors using checkouts like those from Shopify where friction like entering an address for each new vendor is not necessary.

Nick about 1 month ago

💡

Feature Request

We should allow customers to sign up and log in with social accounts like Google, Facebook, etc. This should streamline anonymous sign-ups.

Tobias Lønnerød Madsen about 1 month ago

2

💡

Feature Request

We need a dedicated section on customer profiles specifically for adding notes and attachments. This would be incredibly useful for logging all client communications, such as follow-up emails, directly on their profile. While custom metadata can store text, it's not intuitive for this purpose and doesn't support attaching files, making it difficult to keep a complete communication history.

Rai Fan about 1 month ago

💡

Feature Request

The licensing analytics already support breaking down by custom metadata from the licensing client, but we want to also break down by parameters set on customers, licenses, trials and more. This way, we can segment analytics by our custom properties easily.

Christian Haase about 2 months ago

💡

Feature Request

The one thing almost all Moonbase merchants have in addition to Moonbase is a ticketing system for handling customer support cases. If we could build a simple system within Moonbase, exposed in the embedded storefront and connected to customer accounts, it would alleviate and simplify the common setups merchants have. If you have specific thoughts and ideas around this, please share!

Tobias Lønnerød Madsen about 2 months ago

💡

Feature Request