Hi @Luis Cajiao , Addressing your Safety concern: when there is a payment or any form of authorization involved that would give a user access to something or spend on something, I sincerely advice that there is a server component involved that verifies this spending or authorization is valid and legitimate. Without this extra validation you could run in undesired consequences causing some entity (whether it be a different user or you as a provider) to run into incorrect/malicious spendings/authorisations. To summarise: that the balance is stored in localStorage is not a problem but should be frequently be retrieved and updated from a server component to the client side . Also when it comes to making payments and giving access to content that is hidden behind a paywall, the signing of these transactions can happen client side but must always be verified by a server component. Addressing your Marketing concern: there are not restrictions when it comes integrating existing/centralised authorisation systems however the question you should ask yourself is whether this is really necessary and desired from an UX and privacy point of view. Because if your users care about privacy, or don't want to connect with a service like Google, it could be that people won't use your service. If you still want to pursue this, maybe consider it an optional element and support different kind of mechanisms. Addressing your Pricing concern: I would consider this a strategy problem. If you want to attract new users early and give them this "i'm an early adopter" kinda feeling, having a reduced price tag is the way to go. However, the downside of this obviously is that you pay for this price reduction and question is whether you can and willing to take this risk.