Handling logic for Buy options after a purchase was complete + commerce transactional features
If a customer has just successfully completed a payment, they should not be presented with buy option for the same subscription again as this does not make sense in most standard scenarios.
Furthermore, for example, an upgrade should cause the customer to pay a gap pro-rata rather than have to pay the full amount again, and a downgrade if allowed should either 1) refund the customer the gap pro-rata or 2) not refund anything. Also, there should also be an option in terms of any subscription changes being deferred to the next payment cycle or being implemented on a pro-rata immediately-adjusted basis.
These are all predictable and standard transactional handling logics and requiring the user to write this logic and test it significantly slows down the launch time. WASP should come with an exhaustive, standard set of configuration options and administrative commerce UI functions to cover all standard commerce transactional scenarios. A complete SaaS solution would also include pro-rata refund, pro-rata credit for downtime compensations, etc built into the admin dashboard. It's all very standard, and entirely unavoidable transactional features for most SaaS businesses, so I would argue against deferring it to the developer, as anything you can do to expedite the launch of SaaS will make WASP more effective in its mission and appeal. Things which are standard, predictable and universal should be included in WASP and work out of the box with minimal configuration. Your success depends on WASP being competitive against the likes of WooCommerce and its beastly subscription plugins.
Furthermore, for example, an upgrade should cause the customer to pay a gap pro-rata rather than have to pay the full amount again, and a downgrade if allowed should either 1) refund the customer the gap pro-rata or 2) not refund anything. Also, there should also be an option in terms of any subscription changes being deferred to the next payment cycle or being implemented on a pro-rata immediately-adjusted basis.
These are all predictable and standard transactional handling logics and requiring the user to write this logic and test it significantly slows down the launch time. WASP should come with an exhaustive, standard set of configuration options and administrative commerce UI functions to cover all standard commerce transactional scenarios. A complete SaaS solution would also include pro-rata refund, pro-rata credit for downtime compensations, etc built into the admin dashboard. It's all very standard, and entirely unavoidable transactional features for most SaaS businesses, so I would argue against deferring it to the developer, as anything you can do to expedite the launch of SaaS will make WASP more effective in its mission and appeal. Things which are standard, predictable and universal should be included in WASP and work out of the box with minimal configuration. Your success depends on WASP being competitive against the likes of WooCommerce and its beastly subscription plugins.
6 Replies
Hi @cassofthenight. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Hmm, I don't know enough to give you a confident answer yet. The knowledge sources provided do not contain specific information about handling transactional features or logic for buy options after a purchase is complete in Wasp.
However, Wasp is a powerful tool that allows for the creation of web apps with both frontend (React) and backend (Node.js, Prisma) from a single source of truth. It's possible that the features you're asking about could be implemented using Wasp, but without specific examples or documentation, it's hard to say for sure.
I recommend checking out the Wasp documentation (https://wasp-lang.dev/docs/general/cli#overview) or their Github issues (https://github.com/wasp-lang/wasp/issues) for more information. You might also consider reaching out to the Wasp community on Discord (https://discord.com/channels/686873244791210014/1210062393128915074) for more specific guidance.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @cassofthenight, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?
WooCommerce is a potential competitor for WASP, as it offers many of the administrative and subscription commerce functions on a no-code basis. WASP needs to put forward its best foot because if it's too lacking in commerce administrative features, it would be easier for users to gravitate towards WooCommerce and its ecosystem of plugins:
I will say that the one downside of WooCommerce is its insane bloat, because it is built on the foundations of a blogging CMS, it is not at all optimized and streamlined for commerce - but it has all the features.
@cassofthenight this would be quite interesting indeed!
You are referring to OpenSaas here, right, when you write Wasp? Beause Wasp is aframework that OpenSaas is based on -> putting all this into Wasp woudln't make sense, but into OpenSaas, potentially it would.
The thing is, that would be quite a lot of stuff being added to OpenSaas on top of what it has so far regarding Stripe and subscriptions. I do see how it could be valublae, the way you presented it, but on the other hand, it would make OpenSaas template super heavy on that side, you could say very boilerplatish. The question is, how simple vs complex do we want to keep OpenSaas template, and in which directions / features?
Best candidate for what you described here is really having a library for Wasp for ECommerce, that user could just plugin when needed, and get all these features. We don't yet have a package/library system at the Wasp-level unfortunately, so this is not doable, but the good news is that we have it on the roadmap! We call it Full Stack Modules (FSM), and it will be one of the main big features we will be going after this year. Once we get that working, I think this would be a perfect candidate for it!
Yes, I see. My point was that out of the box for the OpenSaaS template, subscriptions management isn't adequate without a lot of work by the developer user. It feels somehow that SaaS start-ups are stalled a lot by having to reinvent the wheel. All of these e-commerce specs are almost universal for every SaaS startup. A lot of value could be added by providing a comprehensive out of the box solution
I get that, and it makes sense to me! We will be working on this, but have to figure out the best way to go about it yet. I created an issue for it on our Github for now! https://github.com/wasp-lang/open-saas/issues/187
Hah :D. FYI, general consensus in this Discord is that "da be" :be: represents a smile of disbelief, with undertones of "what the heck" :D.