feat: merchant integration

[ryanrussell]

trafficstars

Hey @david-plugge

In response to you asking for feedback, here's a first swing...

Feature Description

• Add merchant integration to the template
• Modularize the merchants in .ts so that they are easy to change

I would personally suggest stripe first, just due to being omnipresent...

Questions

Is this in scope for what you are putting together?

Happy to help... you seem to have a strong handle on the new SK changes, JWT best practices and ts...

Thoughts?

[david-plugge]

Really happy to see some feedback!

Nice idea adding first class stripe support, can you elaborate on that? I think we have to keep it simple so a very modular way to add such features would be best.

I was thinking about splitting the code up into a monorepo to extract the helper logic and additional packages eg stripe support into their own package.

[ryanrussell]

I'm understanding the intent here a little better now.

Issue:

• You believe SvelteKit is the first JS framework to get it right and want to use it now, goblins aside
• It takes dedicated cycles to keep up with the breaking changes, community examples are largely deprecated
• I'm looking for a clonable starter similar NextJS Subscription SaaS starter, but with a priority of maintaining a working build on SvelteKit @latest.

If any of all of this is out of scope, please feel free to be direct. :)

This may just be one "sub-module" structurally, as even a subscription and one-time checkout are different flows.

SaaS Subscription Payments Starter

• Modular implementation with Stripe Subscription checkout flow Setup a skeleton that allows the community to submit PR's for other vendors if they choose.
• CRUD for creating a customer and subscription cleanly at both Supabase and Stripe, complete through a thank you page. bonus: Referential integrity through signup process so that no orphans can be created between the platforms bonus: Email as the first auth method so the confirmation process is documented, modularize so other oath vendors could be enabled/swapped easily
• Keep logic in +page.server.ts instead of +page.ts
• Some scripts or unit tests around confirming data ended up in both a Supabase table and a Stripe customer.
• Possibly a docker-compose.yml file (This one is easy for me if you don't want it...)

Are there more things I missed?

Franky, I'm not crystal clear on the latest SvelteKit best practices with the new breaking changes and what is coming in the pipeline and when, but happy to help pull this together if you think it's in scope and of value.

Very happy this is something you would entertain doing, as a first-class solution will save some long nights and lost hairs for the community...

P.S. Styling?

I closed the styling feature as not worthwhile. If you are considering putting in cycles stubbing out a secure Subscription CRUD implementation, that makes pursing #2 more desirable, just re-open it and assign it to me and I'll send PR's adding in tailwind...

Best, Ryan

[david-plugge]

Thanks for claryfying.

I agree, we definately need a starter repo! And I´d add adyen to the merchant list as i´m using it.

One question though, do you want to just create a starter project or also publish packages like sveltekit-supabase-stripe that handle some logic behind the scene?

[ryanrussell]

I'm open to either.

I'm happy to contribute and help pull it together,

I'm specifically lacking the cycles spent in the bowels of the current progress on the SvelteKit roadmap to be able to know:

1. Best practices as of now() for implementing
2. Best practices considering what's coming in the roadmap

What are your theoughts? What I could contribute code-wise to make it easier assuming you're taking the lead on the JWT auth schema/logic?

Happy to chat on discord or something like that to iterate quickly/easily...