Multiple memberships/products with Make's single Webhook Answered
My question is tangentially related to Memberstack, but for Make (Integromat) users.
As Make only allows a single Webhook to be used per scenario, how do you handle selling multiple memberships/products?
Specifically, I have some “standard” memberships.
For these, actions like adding a subscriber to MailerLite and Airtable happen after a payment.intent.succeeded event in Stripe.
Note, I have to use the events in Stripe, because Memberstack (unless things have changed) fires a “new active membership” event even if the payment is pending authentication, so I only want to consider a membership as “active” when the payment is actually completed.
Now, I am adding a second type of one-off membership (a course add-on). For this, I want a set of different things to happen: add to different MailerLite group, add to different Airtable table, send different email.
I know that I can add this all on to the existing Make scenario, but this will make the scenario bigger and less manageable, and if there’s a problem it can break it…
How have others managed this?
Comments
19 comments
Hey Alastair Budge interesting approach you ended up taking by using the stripe webhooks. I ended up using the "plan added" webhooks from Memberstack. I have a few different scenarios where I watch for a new plan or plan added via Memberstack and then I use a module to determine which plan was added and whether or not to allow the scenario to proceed.
I'm not sure this is helpful for your situation but I thought I'd share how I ended up tackling this kind of thing. Hope it sparks some ideas!
Heya John - good to hear from you. I used to do it that way but realised that a plan is added even if a payment isn’t complete. Given that I have a high % of EU cards (where 3D secure is the norm), this is what most of my “plan added” events look like - the payment is pending. Granted, most people do complete the payment, but a small % don’t.
If using payment_intent.succeeded maybe you can you use a router to create a logic flow in the scenario. So if the scenario fires off with an successful payment then the next step might be to retrieve the member from Memberstack and then see if they have a specific plan or plans that meet the criteria so that they will be added to the correct MailerLite group or Airtable etc. All that could happen via one leg in the scenario. Maybe?
Yup, that’s exactly what I’m doing at the moment @John E. Matias 👍
having asked around a bit in the Make community too, it seems like having one large scenario to process every workflow from one trigger is the way to go…
Just kind of scary to keep on adding to an existing workflow that current paying users are going through….
Totally understand the feeling. Sorry I couldn't offer any better ideas!
no worries at all, thank you so much for your help! Always good to get a second opinion (and I think our MS / Make needs are quite similar….)
If I understand correctly, I’ll be facing this issue soon too (thanks for the Stripe tip!). There’s 3 options I was hoping to explore:
It seems there’s pros and cons to all of these.
Marc Hudson thanks for chiming in. I used to go the #2 route, but Make now doesn’t allow a single webhook to fire in multiple scenarios. So, you can only have one scenario with MS Plan added/Stripe payment succeeded” Triggers, you need to route them in different branches.
Oh, Alastair Budge you should actually be able to create another webhook for the same event. If you use the Dev Tools section of Memberstack and add a different webhook endpoint from Make then I think you can get around that issue.
Ahhh, ok, that’s a neat solution!
Alastair Budge I’ve just started using Make with the gift card scenario (which watches for “plan added” in the MS webhook). This discussion sent me down a rabbit hole of testing whether it would fire even if payment was 3DS pending (using Stripe 3DS test cards) … I haven’t been able to get it to fire unless payment actually goes through. So like, phew. But also… am I missing something?
hmm, if you are missing something, I am too 🙂
Perhaps someone frpm MS could advise if there is a smarter/“best” way of solving this? Duncan from Memberstack Tyler Bell?
The watching the event in Stripe isn’t ideal as the Stripe event doesn’t contain all the MS member/plan data I would like, so i have to match this from the receipt email address.
Made this walkthrough/demo that may or not be helpful to some people:
https://share.descript.com/view/ip2YMBvTPbF
Thanks for the video that’s super helpful.
If I understand correctly, everyone in this thread (Alastair Budge, John Matias, Marc Hudson, Al Mazlin), has the issue of not being able to rely on the plan.added memberstack event, b/c it fires even when the payment is still pending (3d secure, etc)?
Also, Alastair Budge, you should be able to swap the memberId with the members email in the retrieve member step. The retrieve endpoint accepts a memberId or email. We need to update the make module working to reflect that.
Correct for me re: plan.added event.
Re: memberID, ah that’s great. I tried to do that with Make but it didn’t accept an email, only an ID.
Hey Tyler. Yup, I thought a member wouldn’t get a plan until the payment is successful. I don’t know what the implications are regarding how long it could take in some cases and whether the user is left wondering where their plan is 🤷♂️
Alastair Budge ah okay, I’ll talk with our Make contractor for him to update the module to allow for emails.
Alrighty, here are a few possible solutions.
My favorite is #2, what do you all think?
Both sound good, Tyler. #2 sounds more sensible.
Another edge case to perhaps think about is people who pay with SEPA Direct Debit. Technically Stripe doesn’t mark the payment as “completed” until the payment arrives (3 working days or so after).
#2 probably the best to avoid breaking any current systems that folks have in place
#2 sounds great, with the flexibility to choose on a case-by-case basis 👍 I imagine I’d use both for different purposes
Please sign in to leave a comment.