nerder_api

[runic imp]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1349545171309559883

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[gritty prism]

hello! You not being able to add an application fee to a subscription not originally created by your platform is expected behaviour. The originally created subscription has no link to you the platform (this "linkage" to the platform is done when the subscription is created), and won't be able to determine who the application fee is to be transferred to.

[maiden haven]

Ok yes, I remembered correctly about this

that's why as part of a migration script i'm attempting to create new backdates subscriptions and schedule the cancellation of the existing one to avoid double billing

the weird thing tho is:

1. I remember that in the past when I attempted to perform an update adding application_fee_percent that was triggering a failure. This is not the case anymore (req_68r3ARX3uqPUMX)

2. Why when my update contains cancel_at_period_end this actually seems to assign the subscription to my application? (req_fe3s3PJNiRdxQB)

[gritty prism]

I remember that in the past when I attempted to perform an update adding application_fee_percent that was triggering a failure. This is not the case anymore (req_68r3ARX3uqPUMX)

do you have the past request id that triggered a failure?

[maiden haven]

No, it was many years ago

i vaguely remember an error message more or less saying what you are stating here

This seems kinda weird behaviour and smells like a bug actually

1 scenario that comes to my mind to exploit this:

1. Update a sub adding a new application fee while setting cancel_at_period_end to true
2. Issue another update right after setting cancel_at_period_end to false

[gritty prism]

Why when my update contains cancel_at_period_end this actually seems to assign the subscription to my application? (req_fe3s3PJNiRdxQB)

out of curiosity, have you tried any parameters which also ends up assigning the subscription to your application?

[maiden haven]

this effectively will add an application fee to a sub I don't have originally created?

No, I tried for instance with description and wasn't working

and of course adding application_fee_percent alone either

but didn't fail either

[gritty prism]

hrm, okay, can you create a Support Ticket via the link that you're going to get in a moment via DM, and we'll take a deeper look into this. We'll get back to you on the support ticket

[runic imp]

Hello @maiden haven, we have sent you a direct message, please check it at https://discord.com/channels/@me/1349549208709107785

• 🔗The message has instructions on how to open a direct support case with our Developer Support team, in order to help you more effectively.

[gritty prism]

you need to be logged in to your Stripe account before accessing the link

[maiden haven]

Ok I did

I just try to verify my scenario to see if that works

ok it seems it has indeed worked 😅

check in order:

0. req_6cqgFEJyPxr554
1. req_IzinbCKpPESy9k
2. req_XN7WEpMww7eJna

[gritty prism]

hmmm, thanks for trying that out! we'll look into this and follow up!

[maiden haven]

Great

Do you have a possible timeline? Just becuase this is timesensitive on our side as we are performing customers migrations from other providers to Stripe

I can work around it potentially but I'd like to be advised on how to proceed

[gritty prism]

I can't share a timeline right now unfortunately. Aside from the exploit potential, is there something else that would be a blocker for you?

[maiden haven]

Just to give some context

At the moment we have this customer that was previosuly using Stripe manually to bill his customers

now is using our App which offers an integration with Stripe and we've connected them to our platforms

now ideally we'd like to re-create (or take ownership) of all this subscriptions so that our webhook handle can start to work and sync them with our DB

Now I have 2 possible options:

1. Create a new backdated subscription with our application fee and then schedule the cancellation on the exisiting. The problem with this approach right now is that since toggling cancel_at_period_end will effectively assign the sub to our application, the customer will see 2 membership in app instead of one
2. Toggle on and off the cancel_at_period_end assigning the fee. This will create only one subscription in app and from the user prospecitve it will be all ok. I'm not sure tho if this might cause problems on your end or is actually violating some ToS or something by abusing a possible vulnerability/unintended behaviour

[gritty prism]

🤔 like you mentioned, the second one really just seems like a loophole / bug . I'll check in with the relevant folks about this and try to get back to you with which way you should go forward (method 1 or 2) as soon as possible.

[maiden haven]

Ok just FYI i'm in GMT+1 so it's likely I wont be available for the next 7-8h