gareth_jones13 What I ended up doing was giving the end-user options to choose from (SPA is a given)
a standard config route that opens their self-scripted/designed page inside flarum's content boundaries. This came with the security-related drawback of restricting the exact location of the Stripe.JS credit card input, or Google/Apple Pay Now buttons, or most other modern payment gateway input methods / forms
a redirect modal that brings a dialogue up similar to the signup form, while also taking advantage of Stripe.js2 and PCMA industry standards. SSL will be needed for stripe to deliver you a payment intent token to securely store payment information on their servers. another config route to a custom billing page that shows an overview of what is offered, a portal for managing payment methods, and reviewing invoices (my choice)
(don't) route them to an off-site Stripe Express Checkout page - this is not a popular choice with online shoppers, especially today with 1-click buy on every site. If people are going to purchase access to your site, they don't want an external transaction link to some random woman in France.
it sounds like you haven't made it quite that far yet- these guidelines apply to flarum's SPA or anyone else's for that matter - the unforgiving block should start on the backend and trickle to your feature/content pitch. Restrict individual post access to a certain group and tag via model visibility scopes (hooking into serializer events worx)
For a secure gateway limited in partial areas, it will require 1- data lock/preventation on backend from protected assets 2-frontend UI/routing adjustments changes +in addition to a workaround for receiving Stripe's webhooks. I think @clarkwinkelmann and @datitisev both gave a nice contrast to what you should expect. i have a few demos up that demonstrate the process from start to finish, buyer to owner, month to month, etc. Once you get passed the little permission constraints, you'll see getting the system to be self-sustainable and maintenance-free (high transaction volume + safe/reliable/trusted) becomes less of a Stripe problem and more of a core content/design+delivery issue.
If you have a team excited early on about "All of our stripe set up is working" i hope they share my enthusiasm as well after all- none of my concerns were ever if (or how good) Stripe works - it just does. I am more interested in your steps after fixing permissions.
