3DStreet
[epic] billing v1
To improve 3DStreet's ability to be a self-sustaining project, and to cover costs of upcoming features of 3DStreet that will incur hard costs, we should implement a billing system to charge a subscription fee for access to high value features.
Here are some user stories that are required to support this goal:
- As a current user I want to access a feature that is locked and therefore need to upgrade my plan (by initiating the purchase through the application). I expected the locked feature to be available immediately after purchase. Ideally I do not have to leave the application to accomplish this.
- As a new user I want to support 3DStreet and signup for a plan from the pricing page (initiating purchase outside of the application). After I purchase this feature I will want to try this out immediately, so I want to be delivered to a new page where I can do this.
- As a current user I want to change my plan, see my recent bills, when I will be billed next, and have the option to cancel (connect to stripe hosted payment info)
Implementation considerations:
- Suggest using this extension: https://extensions.dev/extensions/stripe/firestore-stripe-payments
- However, note the new extension path from new owner https://github.com/invertase/stripe-firebase-extensions?tab=readme-ov-file#update-2023-10-08
- All default settings look ok for this extension
Feature lock considerations:
- A given layer or model from the "Add new entity" modal can be "locked" without a paid billing plan. Examples of these layers will be Google Maps, Mapbox layer
- How to manage layer feature lock? Should locking be a boolean or enum to support future plans "plus,pro", etc
- How to handle remix considerations, see below.
Remixing considerations:
- It may be possible for a user without a plan to remix a scene created by another user with an unlocked layer
- When the user remixes the scene, it will attempt to make a copy of the remixing scene for the purposes of cloning it
- However that means it will make a copy of layers that are normally locked for other users.
How to deal with this:
- the scene json in the db should be the same for paid and unpaid users, don't use a mechanism like renaming a component to
lock-component-name - api keys for maps services should not be stored in the database, they will need to be loaded at runtime and can be provided in the global environment vars derived from .env files. these should be accessible from the react app after it loads (the editor) as a firebase api key
- Perhaps client-side code can selectively permit loading of the component, or scripts, or ...? to disable this for unpaid users. Another solution is to have a "wrapper" around the paid components, such as
loader-google-tilesthat itself is used to instantiate and modify the underlying 3d tiles component? Fetching the api key and verifying a user's paid status is the responsibility of the loader component. - 3dstreet core viewer should be able to parse any json generated by the editor with paid features. the notable exception are for components dependent upon services requiring API access such as google tiles.
designs:
- figma page wip https://www.figma.com/file/W9jid3A0jgssnIKBFEvG38/3DStreet-2022?type=design&node-id=6320-9106&mode=design
hi @kfarr !
How should the user authentication interface look when they can choose a tariff, and how should this page look? Should it be custom or as provided by stripe?
And, i guess, to fully complete task 407, is it likely necessary to finish the completed version of task 408 (add entity panel), as the payment modal window depends on this functionality?
Hey Rosty
How should the user authentication interface look when they can choose a tariff, and how should this page look? Should it be custom or as provided by stripe?
Let's use as much of the stripe-hosted payment flow as possible.
And, i guess, to fully complete task 407, is it likely necessary to finish the completed version of task 408 (add entity panel), as the payment modal window depends on this functionality?
Yes