I'm building a website with Reactjs,
the website consists of publishing businesses that customers upload themselves but with a paid subscription, every 30 days the payment will be renewed or the business that they have uploaded will be cancelled.
My headless CMS is now on Wordpress but I'm thinking of moving it to Strapi to make it more scalable and have much more control,
Is it possible for Strapi to accept this data ingestion from a third party? And if with Strapi I can implement that the subscription is paid by Stripe, have everything connected.
My idea is that the client uploads the images of the business, the description, etc. And after he fills in his data, he will be taken to a payment screen, where he will pay the annual or monthly fee.
After all this process, I would enter to accept or reject those businesses that are accepted.
Can you guide me a little with the tools that you recommend, if I should or should not use these.
I am open to your answers.
Thank you very much!
I recommend using this Subscriptions guide to get started. Then, you can use webhooks to manage state in your application and keep everything synced up with Stripe. Here is a more subscription-oriented webhook guide.
Related
I want to publish a website using firebase but I have the following questions:
For how long can I use firebase for free?
Can I add a custom domain name if I have one while publishing the website?
If I publish my website and it started getting more views, will I have to pay for firebase?
Please visit the Firebase Pricing Site
Yes you can use a custom domain name after deploying the website. There is an opportunity in the Firebase console "Add Custom Domain".
You will have to pay for the services when you exceed the free reads etc. in the free firebase plan. But you have to switch to the Blaze Plan first. When you didn't switch to the Blaze Plan, you will just get no more answers from the database etc. after exceeding the free plan.
If you are on Spark plan, you have 360 MB/day bandwidth i.e. once your usage exceeds for the day your website will not be served. This involves all the images, html and css files that you deploy to Firebase hosting. On the other hand, storage is used to store your websites files (you can also request to store previous versions of your website and rollback anytime.)
I am working with a research group that needs to collect Facebook post data for a group of participants over the course of a few months. The goal is let the participants authorize us to collect this information via facebook, and when they post to Facebook, send that information to a secured server.
After reading the Facebook documentation, I'm mostly just confused about how to provide a mechanism for the user to agree to the terms of collecting his/her data. I'm planning on using webhooks to collect the data, which is independent of the client platform, but do I really need to build separate apps for web, iOS and Android just for the approval process?
I'm planning on using webhooks to collect the data, which is independent of the client platform, but do I really need to build separate apps for web, iOS and Android just for the approval process?
You most likely won't get this approved in review anyway.
Permissions must, for the most part, be used to provide a direct benefit to the in-app user experience; collecting data for analytical measures only is explicitly mentioned as a not allowed use case. Whether the users would agree is not relevant here.
For example, user_posts permission, has "non-visible use of this data such as sentiment analysis or guarding against spam bots" marked with a red "X" for nope.
So the only way of getting your app to request the necessary permission(s) from users, would be to add them as testers to the app via app dashboard/API. Anyone with a role in the app which can be asked for any permission, reviewed or not. Those users would however have to have their accounts verified (mobile/text, credit card) and sign up as a "developer" on the FB platform, before your app could send them requests to become testers.
You'd be flying under the radar with that, so to speak. Facebook offers this "loophole" mainly for the purpose of letting developers test and develop their apps properly, before review. It is also explicitly mentioned in the app development FAQ as a way around the need for review, for specific use cases such as wanting to get your blog posts published to your own FB page automatically. It would not cover what you are trying to do so, but it will likely "work" as long as none of your test users specifically raises a complaint with Facebook ...
Not sure if there is any published limit on the number of test users that can be added to an app, people have asked about that in the past, but AFAIK none is documented or otherwise published by Facebook. If there is one, and it is not completely stopping this approach dead in it's tracks (say, a few hundred per app rather than, five), you could use multiple app ids, if you don't need to relate data between user accounts too much - because the app-scoped user ids will be different per app id, so that could making connections between friends that are in different "app-id test groups" etc. difficult. Or you might have to refer to other, less reliable measures of uniquely identifying them, such as email or profile name.
The problem is the following.
Client wants an app, that can be sold to different users via Play Store and AppStore. This app has to have a backend server, but users should be able to see only the data that belongs to their user. This is so far a simple authentication/permission problem, but it gets trickier.
If we had a single backend with User Accounts with permission to manage only data that belongs to them, then whoever sells the app will have to pay for the Firebase account for customers traffic usage too.
So the client wants to sell a pair of app + backend, where backends monthly fees are paid by the customer.
Is there a way to configure something like that in Firebase, and make it easy and friendly enough for the customers to set up their account from the app on first startup?
This format unmanaged user seperator. Firebase has simple authentication. Is is not useful for multicompany. Seperate database or develop custom backend.
It sounds like a fairly standard white-labelled app. I recommend keeping each of the re-sold apps in a separate project, which makes it trivial to then charge each buyer separately for their usage.
I am wondering how the humble bundles donation system works. https://www.humblebundle.com/
How do they know, at the end of the week, how much money was donated to whom?
I'm thinking on how to recreate this in js+php, but I am struggling to figure out how to track transactions.
Thank you in advance
-Jard
All of that data would go in your database. As each transaction comes through you'd save the payer info, receiver info, transaction info, etc. all together in related tables in the db system. You can generate your own reports out of that or write apps to pull data and loop through records to distribute funds or whatever you need to do.
As #Adelphia mentioned, to process the actual payments you can use PayPal's API's. For direct credit cards you'd need to sign up with Payments Pro. For PayPal or guest checkout payments (credit card through PayPal's pages without signing in) you can use Express Checkout.
I have a PHP class library for PayPal that will make all of the API calls very simple for you.
Using something like Paypal's do_direct_payments API you can have your users fill out their info on your site and then make the payment with Paypal's API using PHP. Or you can always just use Paypal's built in tracking tools.
I'm looking to create an app where suppliers can register as well as customers.
I want to restrict registration for suppliers so that they can only register by e-mail and not by facebook or twitter, is this possible? does anyone have any solutions or can anyone point me in the right direction? thanks!
What you are wanting can certainly be built.
In Meteor, Accounts.validateNewUser() is used to pass/fail the creation of new users and Accounts.onCreateUser() can add database fields to new users and optionally fail their creation. You can also get access to login templates instead of leaving them hidden in the project's dot meteor directory.
Evented Mind has a pretty good video presentation on customizing the Meteor Login system but it is behind a paywall. There are actually quite a few useful video HOWTOs in there.... so it may be worth their fairly reasonable monthly video subscription fee. They show how to do OAUTH calls and fetch information from 3rd party providers on the federated logins to be included into user profiles. You can read the code from the presentation freely but the video is still worthwhile.
The same calls they use could be used to set up any kind of information about users as they are created or, I suppose, to reject a user marked "supplier" who is using federated login.