Decide on a tech stack

[janbaykara]

Requirements

• [ ] Visitors can select a membership plan
  1. Plan (e.g. all, contemporary, classic)
  2. Solidarity pricing ask, if available
  3. Annual payment discount, if available
• [ ] Visitor is taken to cart -> checkout
• [ ] On completion of the order, members are taken to some kind of thank you page
• [ ] Get or create a django user profile for this member, associate the Shopify customer
• [ ] They should be able to manage their payment / delivery details from the profile page
  • As part of this, books that they have accrued during their membership should show up. This can be inferred from membership periods + the book archives, or it could be manually assigned to users as in the current system.

Technical approach

Original link to all diagrams: https://whimsical.com/data-flow-RKyKtzZnzm6VzsFvucKERT

Shopify's storefront API links to the online store's user profile area

• The simple solution seems to be redirecting to the Shopify online store for customers to directly manage their billing details.

  • [ ] Can we do this...

    • We can't do this without a password, because Multipass is not available on normal Shopify sites.
    • What we can do is make navigation as seamless as possible, through templating and so on.
    • This means using a custom template for Shopify — even though we explicitly want to avoid that!
• We can create/manage customer accounts via API, although this will take a bit of work...
  • Shopify's Storefront API: https://shopify.dev/api/examples/customer-accounts
  • Recharge's API: https://developer.rechargepayments.com/2021-11
  • [ ] How much work is it to build a custom account portal via the API?
  • Update delivery address (simple text fields)
  • Update payment details (this is done via Shopify — a link is generated for this data to be inputed, as far as I recall)
  • View current plan (simple API call)
  • See all purchases / invoices (simple API call)
  • Cancel plan
  • Retention options
• I have reached out to Recharge to see if we can directly embed the subscription management UI into Django, which requires a special request.
  • ❌ We can't

Shopify Multipass is too expensive

Shopify's Multipass functionality would be ideal to sync Django users to Shopify customers, without having to have duplicate credentials. However, it is very expensive: >£1000 per month.

Multipass login is for store owners who have a separate website and a Shopify store. It redirects users from the website to the Shopify store and seamlessly logs them in with the same email address they used to sign up for the original website. If no account with that email address exists yet, one is created. There is no need to synchronize any customer databases.

An alternative: stay with Stripe

We return to Stripe for subscriptions (and maybe also book purchases #4?) as they have a customer billing portal a bit like Shopify's multipass, but for free. Here's a demo.

Upside:

• Products system is fine for membership
• Checkout UI for collecting payments and charging recurring is good!
• We don't need to worry about migrating Stripe subscription data over to Shopify / Recharge

Downside:

• Stripe has no retention / cancellation features, unlike Recharge
• No inventory management for products
• No fulfilment management features for one-off and recurring delivery
• Merch and books/subscriptions continues to be separate

The lack of inventory and fulfilment management could be offset with a third party shipping app that integrates with Stripe.

This option has two variants: Stripe for subscriptions + Shopify for book sales, or Stripe for everything:

And the opposite: move to Shopify for everything, including the theme/template

In this move, the whole stack is held on Shopify. We would build a custom theme based on https://github.com/Shopify/dawn.

Special features related to books and non-ecommerce features like mapping and community forums would have to be built up in a separate stack and then integrated into the user flow somehow.

The pricing for Shopify's multipass sign in (see above) seems to be pushing adopters towards the 'all in Shopify' approach, probably as a commercial strategy.

[janbaykara]

Breaking out the question over SaaS options a bit:

Use an open source e-commerce system that plugs into Django

There is also the choice of using an in-house inventory management system. Whilst we are trying to outsource the intricasies and 'bugspace' of all of this, the fundamental requirements are actually quite simple:

• Buy a book, track how much inventory there is
• Subscribe to a recurring payment, manage your subscription billing and delivery address
• Ideally, reuse payment and delivery details across these two things

Use another headless e-commerce solution with fewer restrictions

This is basically a re-iteration of the "third party e-commerce solution for Stripe"

Some links here: https://snipcart.com/blog/django-ecommerce-tutorial-wagtail-cms

[melaniepatrick]

Thanks Jan. It's a shame about Multipass costing so much. Sounds like our original idea is no longer an option. -- Sounds like sticking with all in Shopify is tricky. Firstly it's going to be hard to move over all the existing subscribers. Secondly it sounds like integrating the bespoke part of our members area is not necessarily as easy as we thought?

-- If we are therefore left with Stripe?: 1) Finding a fulfillment/inventory management system probably isn't too difficult. As long as we have the ability to download excel spreadsheets of names and addresses and linked products/subscriptions this is manageable. And I think the variety of plugins available makes this fairly straightforward for us to set up a proper fulfilment system similar to Shopify if we want to. 2) My main concern is the lack of control over the cancelling, so losing those features Recharge offers us. As Recharge is a Stripe plugin, is it possible to use Recharge without Shopify? So we get those features without having to move over to Shopify? 3) It is possible I will be able to think through ways of making the subscriptions more flexible in themselves, just using Stripe. Which would decrease the need to have the extra pausing / downgrading features from Recharge. I will take a look at Stripe now. 4) In looking at the plugins for Stripe, I did also see a plugin for White Fuse, which I remember you mentioned previously, as a membership integration. I wonder if this might work for us, or is it too templated? Obviously the benefits here are with the membership management rather than the subscriptions. I guess we'd have to look into the subscription side of it but as they use Stripe, and it sounds like we will be using Stripe, perhaps it has clearer benefits now? I see they insist on doing the member migration for you, in order to make sure this is done properly, which could possibly be helpful? They also take GoCardless as well as card payments, which is effectively a direct debit. That would also have very large benefits for us as we lose about 20 people a month through card failure.

-- I admit I am slightly worried about the open-source e-commerce system, I suspect that sticking with Stripe is going to be an easier option. I had a look at a couple of the ones you linked to and I couldn't see anything obvious about subscriptions on them, they were mostly one-off payment systems.

[melaniepatrick]

I've had a look at Stripe. Creating products is good and has lots of options. But shipping isn't very clear?

-- Although I can create products with price options (ie monthly and annual), and I can create shipping prices, I can't see how to link those two things. We need a variety of shipping costs (ie they vary depending on whether people are paying annually or monthly). Perhaps we can take a look at this together? -- Going back to our admin/fulfillment issue: As we currently stand it's impossible to collate the monthly mailing from Stripe because Stripe does not distinguish between gift buyers and members. And doesn't include gift receivers at all as they are not paying.

[janbaykara]

Yes, for these reasons I think we'd want to overlay a subscriptions/fulfillment/inventory system ontop of Stripe, whether open source or paid SaaS.

I agree with you that an open source e-commerce system might have some unintended consequences, although there are some compelling reasons to consider it. For example, there are modern, funded companies that do open source systems like https://saleor.io/ - we can't use this specific example because it doesn't do subscription pricing, but there may be others.

Cancellation / retention features

It would be ideal if we didn't have to build this ourselves, but it's also not absolute impossible to. If we think specifically about the situation, the user flow is:

1. Visit customer profile, looking for the 'cancel' option
2. Taken to a page with some copy and buttons (like "switch to X plan" or "take 3 months off")
3. Continue to whatever

Building a cancellation page might not be that hard to do. The key thing for us is to pick a solution that allows for configuration:

• Easily editable
• Switching a customer to another plan is easy
• Ideally some features like "pause for a while"
  • Recharge kind of has this for only for pay-as-you-go subscriptions. And has "skip next charge / apply discount / delay subscription" options

Things I'll report back on

• [X] I've reached out to Recharge about usage without Shopify, direct to Stripe.
• [ ] I'll look at the range of options we have for Stripe-based systems
  • [ ] I don't remember mentioning https://www.whitefuse.com/ actually, but I will look at this.
  • Solutions I'm looking for:
  • Books
    • Inventory
    • Purchase flow via Stripe
    • Order fulfillment system
  • Membership
    • Purchase flow
    • Recurring billing via Stripe
    • Update delivery and payment details
    • Membership download
  • Ideally a system model that connects these things together!
    • Saved delivery / billing details for a user
    • User has a single purchase / invoice history

[janbaykara]

@melaniepatrick to your initial point re "Sounds like sticking with all in Shopify is tricky."

Firstly it's going to be hard to move over all the existing subscribers.

There are some Shopify/Recharge migration paths. They seem a bit convoluted but not impossible.

What seems a bit trickier is ensuring that we can compile monthly fulfilment docs, because Stripe itself does not distinguish gift givers from recipients.

In LBC Website v1, the records for gifter and recipient users are connected and fulfilment lists are figured out by the app. It's not actually clear to me that we can do this with Recharge / Shopify in a straightforward way.

A simple Shopify-based alternative may be to create new Shopify customers for recipient users in the app, and apply gift card-style discount codes to 'represent' that their subscription has been paid for. Then for future gift purchases, we'd continue to use a gift card-style approach rather than connecting gifters and recipients.

So the migration isn't impossible, I don't think, but as you say: not incredibly easy either. It will probably end up being easier to do this in an app/database that we build and control — i.e. Django, keeping things as they are in Stripe.

Secondly it sounds like integrating the bespoke part of our members area is not necessarily as easy as we thought?

Perhaps. If we think about the specific members area features we're thinking of right now:

• A reading group map can be iframe'd into the Shopify template we build. A simple prototype of this might be an Airtable database that speaks to a web app hosted on Vercel, which is iframed into place. On the other hand, this means building in two places instead of one, which might get tedious in the long run.
• For a community forum system, we could lean on a third party dedicated platform like Circle.so, which would happen outside of Shopify and use a different login. If we went with Django we leave the option open for tighter integration between third party systems and the website.

Shopify also has simple CMS features, so we can do page building and so on in the Shopify. So some of this is possible.

However Shopify won't let us do what we've done with the current LBC website:

• books attached to the user, like a library of what they've had.

And we'll have to be acreative about how we add on certain features direct to the website that we want, by leaning on a separate application database :

• for example book reviews
• or 'group memberships'

So do feel that Django is still a smart direction to 'house' user data and the core website. I'll keep looking at the options.

[melaniepatrick]

Hi Jan Hope things are going ok with the research.

Memberships are dropping fairly fast now, which is the first time this has happened, so it would be helpful to work towards some deadlines we can aim for to get the new changes in place.

1) Getting the move to a new sign-up system and the new subscription options is the first priority: would mid May be possible? And then the members area with new improved features in early July?

2) I'm definitely favouring sticking with Stripe for subscriptions. So we don't lose existing members. Although we can't pause people I think we can present better subscription options in order to retain people.

• I would find it useful to go through Stripe checkout with you so we can work out the details/perameters of what we can do so I can finalise what the new subscriptions will be and how to price them. Also how postage will work.
• Stripe checkout offers the ability to Cross Sell one-off products. So it makes sense to put merch and books on Stripe also, and sell them during the subscription purchase
• We could still use Shopify for the books/merch as well? It will depend how effective a system we can find for the shipping and fulfilment with Stripe. In an ideal world I guess we wouldn't have these items in 2 places but as they are two different purchase pathways I'm sure it's possible.
• Stripe Checkout also offers the ability to Upsell, so we can show people other subscriptions that save them money automatically
• Would be good to investigate if it's possible to show them other options when they go to cancel? If we can't pause, then we need to show them a more affordable option where they get fewer books.

Does this sound sensible to you? So to summarise -- What can we do with Stripe checkout? Can we offer people alternatives at the point of cancellation? -- What integration for shipping will we use with it?

Let me know what you think! Mel

[janbaykara]

Hi Melanie. Today and tomorrow I'll be preparing the technical options that we can discuss and decide on at tomorrow's meeting. I'll post updates in this thread.

For deadlines, we can commit to 30 April, and revisiting community features for July. Our team schedule is oriented around the before-May deadline and I feel we are making progress — taking the time to think now is what will make development for the remaining weeks faster and more efficient!

Both sticking with Stripe or moving to Shopify will retain members. What I'm definitely hearing from you is strong controls around signup and cancellation UX. We'll make sure this is fully addressed. By tomorrow's meeting I can walk you through the Stripe options for this.

[janbaykara]

Today I am meeting with an engineer from ReCharge to discuss exactly how we would go about migrating from Stripe, so that we can put this question to rest.

The strategy for this migration that I'll be looking for maximum detail on is:

• Connecting all Stripe subscriptions to Recharge
• We manually create new customer + subscription records for current "gift recipient" members who haven't got their own payment plan set up
• For "gift givers" who are paying towards a subscription for someone else, we assign them to a legacy subscription product that ables to identify them for future operations

If the migration plan seems clear enough, then Shopify + Recharge can be set up fairly sharply building on top of their reference theme and presents a strong option.

[janbaykara]

Apart from that, I will be:

• Putting together some directions we can take with Wordpress plus Stripe and/or Shopify, and other membership tech stacks
• Evaluating Stripe inventory/shipping options, as you mentioned
• Putting together a walkthrough of Stripe checkout functionality for you

[melaniepatrick]

Lovely thank you!

On Tue, Mar 22, 2022 at 9:53 AM Jan Baykara @.***> wrote:

Hi Melanie. Today and tomorrow I'll be preparing the technical options that we can discuss and decide on at tomorrow's meeting. I'll post updates in this thread.

For deadlines, we can commit to 30 April. Our team schedule is oriented around this deadline and I feel we are making progress — taking the time to think now is what will make development for the remaining weeks faster and more efficient!

Both sticking with Stripe or moving to Shopify will retain members. What I'm definitely hearing from you is strong controls around signup and cancellation UX. We'll make sure this is fully addressed. By tomorrow's meeting I can walk you through the Stripe options for this.

— Reply to this email directly, view it on GitHub https://github.com/commonknowledge/leftbookclub/issues/5#issuecomment-1074959510, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYBPO53SXRHYJ74H2FIYJCLVBGKBJANCNFSM5PUVDXTA . You are receiving this because you were mentioned.Message ID: @.***>

[janbaykara]

I'm putting together a database of options including costs here: https://www.notion.so/commonknowledge/9ab88fc825ac47c8a64ee5429713f035?v=37fde52e0d2b4258ade44ed607072c2a

[melaniepatrick]

On gift subscriptions, it would be good to keep these as recurring subscriptions if we can, but if we have to turn them into a one-off product there seems to be an option to do that with Shopify (as you can create a 'gift card') and there is also a plugin for gift cards for Stripe: https://stripe.com/partners/gift-up, again as a one-off purchase. However I'm not sure how the redemption process would work for these or how we'd keep track of our gift members. So it's certainly preferable to have them on recurring subscriptions in Stripe.

[janbaykara]

Decisions we made after the last meeting:

We decided to go with a website build + continuing on with Stripe for subscriptions, but 'done right'. It is possible to generate coupons which covers the gift membership option.

We still need to...

• [ ] Decide on a web framework: #8

We decided not to go forwards with Shopify because of it has higher fees than Stripe, requires Recharge + Rise.ai to actually manage subscriptions which incur their own fees, and lacks support for customer SSO into community tools like circle.so (#19)