Multiple memberships/products with Make's single Webhook Answered

Post author
Alastair Budge

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

  • Comment author
    John Matias

    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!

    0
  • Comment author
    Alastair Budge

    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.

    it’s really not ideal (i would much prefer to have it all working via memberstack), but–unless I’m mistaken–MS doesn’t fire any event when a payment is complete and the membership is actually “active”.
    0
  • Comment author
    John Matias

    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?

    0
  • Comment author
    Alastair Budge

    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….

    0
  • Comment author
    John Matias

    Totally understand the feeling. Sorry I couldn't offer any better ideas!

    0
  • Comment author
    Alastair Budge

    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….)

    0
  • Comment author
    Marc Hudson

    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:

    1. Multi-route approach (mentioned).
    2. Separate Scenarios each with “MS Plan added/Stripe payment succeeded” Triggers followed by a “Plan ID” Filter (if it’s available) right after each Trigger.
    3. A Multi-route approach but use the HTTP module to webhook other “sub-task” Scenarios in order to keep things manageable.

    It seems there’s pros and cons to all of these.

    0
  • Comment author
    Alastair Budge

    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.

    0
  • Comment author
    John Matias

    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.

    0
  • Comment author
    Alastair Budge

    Ahhh, ok, that’s a neat solution!

    0
  • Comment author
    Al Mazlin

    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?

    0
  • Comment author
    Alastair Budge

    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-Hamra 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

    0
  • Comment author
    Tyler Bell

    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.

    0
  • Comment author
    Alastair Budge

    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.

    0
  • Comment author
    Marc Hudson

    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 🤷‍♂️

    0
  • Comment author
    Tyler Bell

    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.

    1. We update the plan.added event where it’s only ever fired when the plan becomes active
    • this could lead to some weird scenarios tho, where the member has the plan with a pending status, but users are no longer able to listen for that.
    1. We create a new event, something like plan.added:active that only ever fires when the plan becomes active

    My favorite is #2, what do you all think?

    0
  • Comment author
    Alastair Budge

    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).

    0
  • Comment author
    John Matias

    #2 probably the best to avoid breaking any current systems that folks have in place

    0
  • Comment author
    Marc Hudson

    #2 sounds great, with the flexibility to choose on a case-by-case basis 👍 I imagine I’d use both for different purposes

    0

Please sign in to leave a comment.