Other than the time issue, this should not be difficult to implement. Here’s an overview of a low-tech solution with 6 steps:
Create an SQLlite database with a login table (you can alternatively use something even simpler like pysondb if/as required)
Login table to contain required user details + userflag (for paid/unpaid) and startdt & enddt for subscription duration
User gets a screen to register (which does not contain userflag field). You could add your banking / wallet details herein
User to enter payment transaction id into registration screen, if they have paid. If this information is entered, the program should trigger an email to you / store that info into your database (which you can access periodically)
For all paid users, you update userflag & subscription period fields in the database via the backend using a dbbrowser / through a separate screen not available to general users
If a user tries to access paid info, the program checks the login table for userflag=paid and subscription period against current date, and shows paid data accordingly.
How about something more basic, whereby there is no subscription, just links for premium content.
If user wants the premium version of a chart, a button is pressed where let’s say $1 must be paid. If payment response is successful, then advanced chart displayed.
Would a flow like this be simpler to implement? (no user subscription)
For example integrating stripe payment links, with each chart having a different link.
Would streamlit be able to get the response from the payment processor, to know whether a payment went through, and use it to determine which flavor of chart to show?
I’ve actually looked into this for my own app but since Streamlit receives all requests on one endpoint it’s a bit hacky to get it working. I thought it was possible to dive into the Tornado webserver and setup an extra endpoint next to it but it felt pretty cumbersome/messy with the Streamlit code everywhere.
To get the response from the payment processor(I’ve used both Stripe and Mollie) I’ve put down a simple Go API next to my Streamlit app to receive and write the response to the database which I check again in my Streamlit app whenever someone checks a specific page(specific content only shows if a certain flag has been set in the database which my Go code triggers on successful payment).
I’m still hoping Streamlit adds a Flask-like endpoint experience in the future though, for instance how we can use @st.cache now it would be amazing if we could decorate a function with @st.route(’/randomendpoint’, methods = [‘POST’, ‘GET’]) to route traffic to a specific part of the Streamlit app and redirect them to a specific endpoint.
Would be epic!
Hi everyone. it is the first time that I write in the forum. This topic interests me a lot. I have been using streamlit since its first release. After many attempts in trying to connect automated payment methods, via paypal or stripe, I realized that the best solution is another.
The app needs to be structured with both the free and premium version integrated. The difference will be a text input where whoever bought the code (via email, or automated checkout page, or via google forms) will unlock new features.
An example: I write an app that, given a photo as input, I apply the neural style transfer. Users who have not entered the premium code (which will be checked with streamlit secrets) will only see 3 possible applicable styles, while premium users will see 10 styles.
The possibilities are so many, let me know what you think.
I like the access code idea a lot! It would be very simple to implement.
How do you think you would prevent mass sharing of the access code? For example, how do you prevent the case of someone purchasing the access code and posting it online somewhere such as reddit? It all comes down to authenticating a user, curious on your thoughts!
I’ve build a Simple Streamlit Paywall Example (with stripe payment links) you may find helpful:
I use stripe payment links to accept payments and deliver a password to the user, then rely on that password to give access to certain parts of the app.
Thanks for stopping by! We use cookies to help us understand how you interact with our website.
By clicking “Accept all”, you consent to our use of cookies. For more information, please see our privacy policy.
Cookie settings
Strictly necessary cookies
These cookies are necessary for the website to function and cannot be switched off. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms.
Performance cookies
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us understand how visitors move around the site and which pages are most frequently visited.
Functional cookies
These cookies are used to record your choices and settings, maintain your preferences over time and recognize you when you return to our website. These cookies help us to personalize our content for you and remember your preferences.
Targeting cookies
These cookies may be deployed to our site by our advertising partners to build a profile of your interest and provide you with content that is relevant to you, including showing you relevant ads on other websites.