How to gate content by plan ID in Cursor without redeploying on pricing changes?

Post author
Olivier Nachin
Hi Memberstack team! 👋

I’m building with Cursor and tried to gate my content by checking a plan’s `planId`, but it kept failing for paying members.

I finally had to switch to checking each connection’s `payment.priceId`, which fixes the bug but is really cumbersome: every time we roll out a new price or replace an existing one, I need to jump back into Cursor and push a fresh deploy just to update those IDs.

Is there a reason we can’t rely on a stable planId for paid tiers, or is there a better approach you recommend so we don’t need code changes every time pricing changes? Thanks!

Comments

4 comments

  • Comment author
    Tyler Bell

    Are you not seeing plan ids exposed? Or are the plan ids changing when they are not suppose to?

    0
  • Comment author
    Olivier Nachin

    Thanks Tyler.

    Yes, I did try to rely on the planId initially — but I ran into weird bugs where paying members were not recognized as having access.

    I was working in Cursor, and based on Memberstack’s documentation & examples, the recommendation seemed to be to check payment.priceId instead of planId.

    Here is what Memberstack documentation recommends :

    Critical: Use payment.priceId for Paid Plan Detection

    For paid plans, always check planConnection.payment.priceId rather than planConnection.planId:

    javascript
    // :white_check_mark: CORRECT: Check paid plan using payment.priceId
    const hasPremiumPlan = member?.planConnections?.some(planConnection =>
      planConnection.payment?.priceId === 'prc_premium-monthly-d422107a7' &&
      planConnection.status === 'ACTIVE'
    ) || false;

    // :x: INCORRECT: Checking planId for paid plans (unreliable)
    const incorrectCheck = member?.planConnections?.some(planConnection =>
      planConnection.planId === 'pln_some_plan_id' &&
      planConnection.status === 'ACTIVE'
    );

    So my actual question is:

    why can’t we simply use the planID to detect the user’s plan? Why do we have to rely on the priceID instead?
    In some cases, it would be much more convenient to work with the planID directly.

    0
  • Comment author
    Tyler Bell

    Olivier Nachin you should definitely be able to rely on just the planId (especially if you don't care about what price they are on under that plan)

    you can safely ignore that section of the docs

    if you were experiencing weird bugs with the planIds, let me know what was happening, or if it happens again, with as much detail as you can, so we can look into it

    but in short, yes, you can safely rely on the planId

    0
  • Comment author
    Olivier Nachin

    Thanks for your answer! I will try again 😉

    0

Please sign in to leave a comment.