Stripe Billing Portal: Incorrect Account Displayed

Bug Reports
1

When using Softr’s Stripe checkout, a customer successfully makes a purchase. Softr stores the customer’s email (but does not store the customer.id generated by Stripe). Later, when the customer uses the Stripe Billing Portal, Softr sends Stripe the customer’s email address to identify the account.

This is a BIG problem. It is possible (even encouraged) in Stripe to create multiple customers with the same email address. That is, the email address is not unique. Sending the customer’s email address when opening the Stripe Billing Portal is non-deterministic, you may or may not get the same account created above.

In our case, sometimes the customer clicks on the “Stripe Billing Portal” link in Softr and is shown a different Stripe account (in our case their Substack account in Stripe). There is no way for them to manage their Stripe billing created with Softr!

Per Stripe’s documentation: Activate the no-code customer portal | Stripe-Dokumentation

If there are multiple customers with the same email address, Stripe selects the most recently created customer with that email and an active subscription.

This is a problem if Stripe is used for multiple systems in addition to Softr, or if two or more Softr applications use the same Stripe account. In our case, we are using our Stripe account for both Softr and Substack.

This bug was confirmed by Sofr’s (excellent) chat support:

Regarding your questions, a) Softr stores the customer’s emails when they make purchases through Stripe. b) no, it sends the stored emails to the Stripe Customer billing portal.

Because of this, our customers can not edit their subscriptions purchased through Softr.

Fix: I see two possibilities:

  1. Softr must store the customer.id generated when making a purchase then send this ID to the billing portal later via the Stripe API.
  2. Softr seems to store the Softr application ID in the Stripe customer metadata. This could be used to identify the correct Stripe customer.

This is a CRITICAL bug for us. Our customers can not manage or cancel their subscriptions correctly!!! We are having to manually cancel for them through our customer support.

I am a long-time Stripe developer. I am happy to chat with one of your developers if that would be helpful!

2

@artur

3

Hey folks great feedback. We have relied on email as many customers switched to us from legacy systems having users in stripe with existing subscriptions etc… hence the safest way was to rely on email so we could recognise the customer has the product… Additionally there are cases when one creates a customer in stripe directly or via yet another system and then user logs into softr and can benefit as email is used as a key…

Overall I could see an enhancement to be done on our end to store ids and in cases where we have ids check first with id version then fall back to email. I will check this and communicate timeline

4 Likes
4

I understand that you need to accommodate customers migrating from existing system. But IMO the way to be backwards compatible should not break developers/customers trying to use Stripe in the correct way. Email is ok as a fallback or default if a customer.id is not available, but it should not be the only way.

Thank you for looking into this! Softr + Stripe is a powerful combination, but I believe it is critical to use Stripe as it is designed. This is creating a big mess for us right now because our customers can not manage their subscriptions.

5

@matthieu_chateau @artur

Hi-

I have a work-around in place for this issue and I’d like your feedback. Instead of using Softr’s Stripe Billing Portal block, I create my own Stripe portal with the customer.id. I use a Softr Customizable Form to call to an endpoint in our Zapier installation to do the following:

Basically, I use Stripe’s /customers/search API to find the correct Stripe customer.id that was created by our Softr application. For the query search parameters I use:

email == ‘{customer’s email address stored in softr}’
metadata[‘softr_application_id’] == ‘{our_softr_application_id}’

(search docs: Stripe API reference – Search customers – curl)

It seems that Softr tags each Stripe customer with this metadata, so I’m using that to be sure we are getting the correct customer.

I then use this Stripe customer.id to create a new Stripe Customer Billing Portal Session (docs: Stripe API reference – Create a portal session – curl).

Then we email the new billing portal session URL to the customer’s email to authenticate that they are the customer they claim.

This is working ok for us.

Question: the softr_application_id on the Stripe customer metadata does not seem to be documented within Softr. Is this an attribute I can rely on? Will you continue to support this?

thank you!

6

@drew0 this will work thanks for digging deeper. I was sick was not able to push any other solution forward and also the team is heavily working on action button to be released very soon. Your solution works and we will keep the softr_application_id in place you can rely on it. In fact adding new meta is pretty easy and if more is needed let us know.

7

ok, thank you @artur, we have this solution in production and it working well!

8

I found when a Softr user makes multiple purchases from a pricing block, instead of canceling the user’s subscription and issuing the newer subscription, Stripe creates another customer with every new subscription purchased. Essentially, Softr’s integration with Stripe creates multiple customers from the same Softr user. That is two Stripe customers with the same email address.

Is this what you were finding as well Drew?

9

Yes, email is not a unique customer attribute in Stripe. This is ok for softr imo, but Softr should be storing the customer.id to be able to later open the correct Stripe billing portal. My work-around to this problem is above.

To resolve the “double purchase of the same product” problem, I created a User Group in Softr with a rule ‘User has subscribed to Product X’. Then, on my softr checkout page for Product X, I hide the checkout form if they are a member of that User Group. Instead I show them a block that says “You have already subscribed to Product X”. This prevents them from being able to subscribe a second time.

1 Like
10

Thanks Drew. Agreed about Softr using Stripe IDs. I do not understand why Softr has not used it by now for their Stripe integration. It would have made Softr a lot more valuable for no-coders.

11

@artur another issue has popped up regarding the softr_application_id. It seems that if softr finds a customer with a matching email already in Stripe (perhaps from purchasing a non-softr product), then the softr_application_id is not applied. That is, it seems the soft_application_id is only applied to stripe customers created by softr.

Can you confirm if this is true? I have a work-around in mind, but it would be helpful to know if I’m seeing the situation correctly. Thank you!

12

@artur bumping this question, it is very important to our billing portal:

13

@drew0 let me add that also for the cases when we identify one without softr_application_id

14

@artur I’m sorry, I don’t understand this part:

for the cases when we identify one without softr_application_id

Do you mean that Softr will add the application_id in cases when it updates an existing Stripe customer?

15

@drew0 if softr finds a matching email/user in stripe, we can add the softr_application_id as metadata. Would that help?

16

yes, thank you.

For now, I am updating Stripe customers with the softr_application_id if the customer is missing that metadata. But I would rather not be doing that, it seems that Softr should be the only system writing that value.

17

Has this issue been fixed?

Getting ready to launch my Softr app, concerned about my customer’s experience as a result of the issues that were highlighted here.