This project has turned out to be a little more involved than I anticipated 😉 i welcome the challenge and am enthused to share some of the goals, challenges, and updates
full rewrite of Cashier (this includes a restructure that will allow me to easily "plug in" new payment providers using adapters .e. PayPal) etc
client and server validation for all forms - the most sensitive being payment info using Stripe.js3 industry standard. Rest assured, absolutely no PII is stored from this extension and never will be. The only thing that may be stored is a temporary "intent token", which must be validated through local+remote+stripe API (so will expire) - its permissions may also be localized to a specific event
new subscription plans are no longer required to be created in Stripe dashboard. Previously it was required to setup your plan in Stripe, then select it from this extension.
since payment intent tokens may be optionally attached to accounts, we must not mistakenly authorize a charge if an admin gets funky with his provider plan settings - so now plans must created locally. This deters some recurring subscription from being billed an incorrect amount (if somebody changes a "confirmed" plan price thru provider dashboard)
created plan is automatically synced with Stripe API, and both back and frontend accurately represent the billing state - (i.e. if certain plan has some issue, users won't even be able to see the option to subscribe)
If there is some mismatch with settings, it will be marked invalid and will never be used
if you already have a validated/working plan configured, and you suddenly decide to delete or modify this plan later on - all other subscriptions on the previous plan will be marked as cancelled (at the end of their billing period) and they will have to manually resubscribe.
-- warning is given loud and clear before its done, and (as expected) all users registered on the old plan will get updates in their billing tab / notifications regarding pending cancellation
users can Pay with Apple Pay, Google, or Samsung Pay if they wish. This will restrict their billing cycle to manual (must pay per cycle) for the current time, however is much easier for mobile users that could just be paying with a fingerprint
frontend UI additions, such as marking members as subscribed in their profile / badge; firing notifications to users 7 days before their next bill cycle; showing admin webhook logs, optionally displaying banners to users whose previously active subscription was lapsed+more
Conversely, if Paywall does not have any accurate current plan settings, existing subscriptions will be cancelled on the day of their renewal.
Even if a customer has stored intent tokens for their payment methods, this extension will be will destroying them and will not be responsible for any payment liability. (There is a user-definable grace period before this happens)
while this only briefly covers a few of the challenges that have delayed a release, with most features were locked 2 weeks ago and since then have only been focusing on specific use states, reliability etc
I can 100% promise you that no other service currently integrates payments for Flarum users as tightly as this does already, until or unless something better is developed to hook into flarum the same way. More on this soon, again
