#HODL_MODE - Subscription Changes

1 messages · Page 1 of 1 (latest)

soft bolt
#

Let's chat in this thread

#

Give me a moment to catch up

fringe cipher
#

Thanks so much!

soft bolt
narrow sky
#

Chiming in as I've run into the exact same blocker and emailed Stripe a few times but never really got anywhere with it. Is there someone specific we could reach out to?

fringe cipher
#

🙏

#

Lan Roche from Stripe's Partner team met with us last week and told me to email him with the details. Haven't heard back yet, and I'm anxious to know if this issue was flagged or if it's being investigated.

crystal plover
fringe cipher
#

Thanks @crystal plover. Reading over it now

#

This seems to coincide with the first instances of that error (last summer), but I'm really struggling to understand the implications. Our App's Connect settings are as shown

unknown.png
#

"When connecting a second platform to a Standard account, the user will create a new account to use with your platform instead. The Connect Onboarding flow will automatically direct users to create the new account. Your platform will then be automatically connected to the new account that the user has created."

👆 So is this saying that our connected customers would need to create a second account for this to work?

crystal plover
#

Looking at this some more @fringe cipher to figure out how to best raise this internally. I see the issue you're describing and why it doesn't work well for your use case. New accounts are for platforms which wouldn't be a good fit here either, necessarily, since you want to help with recovery of existing subscriptions.

fringe cipher
#

Ah, that makes sense. I was just looking for how "Platforms" were defined... and yes, we're not really tackling that functionality.

#

I've seen a few mentions of this You can't make any changes on a subscription that was not created by your application here in the discord and various places online, but never found a clear explanation of whether this was Stripe policy or just an edge case that should be eliminated.

The harm I see is it hurts Stripe's ability to grow a diverse app ecosystem, because you'd have large incumbent apps that take ownership of a subscription upon creation, and then there's no way for developers to create or build experiences to improve upon subscription management.

south tundra
#

There's a bit of a misunderstanding overall so I'm going to take over for a bit, hope it's okay

#

The real issue here is that a secondary platform/extension (Profitwell) is allowed to change your subscription and when they do, you can't touch/modify it anymore.

#

Can I ask you to provide me with a concrete example so that I can track it down?

fringe cipher
#

Sure, want a request ID?

south tundra
#

yes

fringe cipher
#

Also, should I DM for security purposes or does it not matter?

south tundra
#

if you share the req_123 it doesn't matter

#

but you can totally DM if you want

#

Okay so that request you gave me fails because you are trying to cancel a subscription yourself, but you didn't create that subscription. So it's normal that you can't do that

#

This has been true for quite some time that platform A is not allowed to modify subscriptions created by platform B. Since money is involved with application fees, if you were allowed to do this, then you could end up getting platform B's money, which is not viable.

fringe cipher
south tundra
#

Application Fees are a feature that lets platforms take a share of the subscriptions/payments they create

#

whether there's any way to determine if a subscription was created by a separate platform
There isn't unfortunately. I assume you do this because the majority of your connected accounts create subscriptions themselves and you get stuck when some have subscriptions created by another platform (be it Profitwell or ClickFunnels or Recurly or hundreds of others)?

fringe cipher
#

Exactly. It's happens just enough to frustrate our customers and makes our Stripe integration look sloppy

south tundra
#

Unfortunately that's been a limitation for a long time, it's not something we just rolled out

fringe cipher
#

Also worth noting, and I'm going to butcher Stripe's terminology here, but our app has limited scope and cannot do anything related to account management, payment remittances, etc...

south tundra
#

Unfortunately this is not a limitation we can fix 😦

fringe cipher
south tundra
#

no, I'm replying to you saying you don't do payment remittances and first. I'm saying that at the end of the day you have full write access on the account and when you try to change a subscription, you might (and are) changing another platform's subscription

#

it'd be the same if it was your own subscription and ProfitWell was un-canceling it and the customer complained to you that they were charged

fringe cipher
south tundra
#

I mean sure, but it's better to not put anyone in this situation than remediate it later

fringe cipher
#

Gotcha. Thanks for looking into this for us. I don't suppose there's any chance Stripe would include a property on the subscription object so we'd know if that subscription was already owned by another org? We're really trying to make our extension work, but it's hard when these big platforms come in and pickoff a bunch of our customers subscriptions. If we knew ahead of time, we could at least work with our customers to implement callbacks that would make requests using their own API key.

#

One client was so frustrated they offered to just give us their API key... which would've worked, but we just didn't feel comfortable with this at the time.

south tundra
#

I don't suppose there's any chance Stripe would include a property on the subscription object so we'd know if that subscription was already owned by another org
I'll file an ask but I'm dubious we'd add this soon 😦

#

One client was so frustrated they offered to just give us their API key... which would've worked, but we just didn't feel comfortable with this at the time.
Yeah strongly recommend not going down that road, it comes with even bigger issues later

#

Can I ask what operations you do on a subscription?

fringe cipher
#

All we do is apply discounts, pause, and cancel

#

and of course GET /subscription/:id

south tundra
#

what do you call "pause"

fringe cipher
#

pause_collection

south tundra
#

yeah unfortunately those are pretty substantial changes to the subscription and you can't do that if it's managed by another app

#

You might want to ask your customers when you onboard them if they use a third-party subscription management solution

fringe cipher
#

Many started using Profitwell's reactivation product after they were customers with us, but any new subscriptions that get created via Profitwell are then owned by them.

south tundra
#

yeah and that's what my colleague was saying: we're changing OAuth so that an account can't have 2 platforms that manage different things, they'd be in separate accounts

#

but it's tricky because some platforms are more "extensions" like yours where you augment features, you don't fully own the subscription management

#

so you are allowed to connect to existing accounts and you hit this issue

fringe cipher
#

exactly. that's why i had trouble wrapping my head around those change docs they sent

south tundra
#

yeah the easy thing would have been to just block it entirely, but it doesn't make sense for extensions. Just for analytics platforms for example but also yours

fringe cipher
#

oh weird, so I wouldn't be able to run ChartMogul and Profitwell and Baremetrics anymore

#

Need to read up more on becoming/ migrating to be a "platform." That might be the best way forward to ensure we're able to deliver a smooth experience to future connected orgs.

south tundra
#

oh weird, so I wouldn't be able to run ChartMogul and Profitwell and Baremetrics anymore
you can. I meant if we had fully blocked this entirely, it'd be a real issue for extensions. So we allow extensions like those and yours

#

But let's say you're Shopify, and you accept one-time payments on a store. You want an account just for your volume. If the business also uses Invoice2Go for their freelance invoicing payments, Shopify doesn't need to see those transactions, and vice versa

#

that's what our OAuth changes are focused on

narrow sky
#

Hey @south tundra thanks for laying out all of the details. I completely understand wanting to restrict access when application fees are involved. It seems reasonable to add in a check for if those fees exist on the subscription object, and only block (multiple) 3rd party access if that's the case. This blanket policy seems pretty inhibiting for extensions within your ecosystem which have no interest in owning subscriptions

south tundra
#

yeah but right now it's more "if App A owns a sub, they want to prevent any other app from modifying it". In a way that's totally fair/normal as an API design, though annoying for you

narrow sky
#

For instance, Billflow had to write a completely new integration so that Churnkey customers and billflow customers could overlap. I do understand this policy works well for merchant-type "platform" accounts

south tundra
#

It seems reasonable to add in a check for if those fees exist on the subscription object, and only block (multiple) 3rd party access if that's the case
Most subscriptions created by a Connect platform have an application fee. Not all, but the vast majority
They also have a relationship with the business and the customer, they are on the hook for those payments working properly. If I use ClickFunnels, and they charge $100 a month to John Doe, and suddenly John Doe is charged $1000 because another app made an update but ClickFunnels doesn't know and still send a $100 receipt, that's a huge trust issue. And sure they can use webhooks and build their app defensively against all of this, but they shouldn't have to.

narrow sky
#

Completely understand. But that same trust issue exists if ClickFunnels is connected to Acme, Inc. and suddenly charges John Doe $1000 and Acme Inc. is on the hook for it. Fundamentally, Stripe account owners need trust in the apps that are connected. And audit trails exist (outside of subscription application owner) to address when there is foul play

south tundra
#

it's not about foul play though, it's about someone else changing data you own

#

like I see what you're saying, I've been at Stripe for many years and when we designed the OAuth changes I advocated for apps like yours to make sure we supported them (and we do!) through it.
But at the end of the day, some apps do things that they don't want other apps to be able to change without their approval, and Subs is one that has been locked for many years

#

but you might hit this more as you grow upmarket and start getting businesses that already use another platform

narrow sky
#

Yeah ultimately its a conflation of ownership and who created the subscription, which are often tied but not always. And with Stripe dealing with a massive swathe of customers I understand the simplification. Profitwell may have created the subscription, but they did it on behalf of Acme inc and I'm sure would be happy to give "ownership" to Acme. Relationships like this are often comes tied with 0% application fee, which is why I was inquiring about a check for application fee existence before blocking requests

south tundra
#

Yep that makes sense and it's something we carefully reviewed but it's a lot harder to assume intent than it seems. Some apps take no fee on the sub but take a fee monthly on your volume and still see themselves as "owners" of the sub
But this is a great discussion, I'm going to share the whole conversation with the team that built some of those changes so that we keep thinking about them

I do like the idea of deciding whether you own a subscription as an app or not. I don't see us building this soon (the limitations has been here for longer than me though we evolved it over the years) but it's important to think about as we evolve our API

narrow sky
#

Thank you @south tundra !