#nshah97_proration-transfer-data
honest gorgeBOT
👋 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/1239555742512582777
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
ancient token
hi there!
in transfer_data you set a amount_percent. and if you edit the price or the amount_percent, then the correct amount will be sent to the connected account.
solar sleet
Agreed, however:
Suppose a customer, on 1st May, signs up to a subscription for 100 GBP with 85% being transferred to Account A, then 85 GBP would have been transferred to Account A. Then, on 15th May, they switch to one that's 200 GBP with 85% being transferred to Account B. Will a portion of the original transfer to Account A get automatically reversed/diverted to ensure that only 50% of 85% of 100 GBP (100 * 0.85 * 0.50 = 42.5 GBP) is transferred to Account A, and later (on 1st June) 50% of 85% of 200 GBP (200 * 0.85 * 0.5 = 85 GBP) is transferred to Account B ?
In this example, for the month of May, half of the time is spent on the 100 GBP subscription and half on the 200 GBP subscription. The customer therefore should have paid (once the proration has taken place) a total of 50 + 100 = 150 GBP, for May. Account A should get 85% of 50 GBP and Account B should get 85% of 100 GBP.
ancient token
if you change the price of a Subscription, then there might be a propration and a new payment required. if that's the case, then the new payment will be transferred correctly to the connected account
you can learn more about prorations here: https://docs.stripe.com/billing/subscriptions/upgrade-downgrade
solar sleet
Thanks, these docs however do not consider the scenario I've explained above
I.e. modifying subscriptions mid-billing cycle with transfer data being set
spring flare
Hi there 👋 jumping in as my teammate needs to step away soon.
Regarding your initial question; updating a Subscription does not cause retroactive updates to the objects it created previously, you should be seeing the same while testing this in testmode. Those changes are only applied going forward.
Reading through the other scenario you laid out.
Hm, that's a really good point.
I don't believe past transfers are adjusted automatically, but you should be able to confirm that within testmode using a Test Clock:
https://docs.stripe.com/billing/testing/test-clocks
honest gorgeBOT
nshah97_proration-transfer-data
solar sleet
Okay thank you for clarifying that.
Assuming past transfers aren't automatically adjusted, how would this be done manually?
One way I can think of is:
- Cancelling and issuing a prorated refund for the existing 100 GBP subscription whilst reversing a prorated amount of the associated transfer to Account A (I'm assuming this is possible since it is via the Stripe Dashboard?)
- Creating a new subscription to the 200 GBP subscription, setting transfer data to Account B.
In this method, the billing date to a user changes (since it's a new subscription), but this is not a big deal to us.
Is there a better way to do this ?
spring flare
Is the billing cycle anchor shifting "not a big deal" or desired behavior?
The approach you described sounds like it will work. You can automatically reverse a Transfer as part of a refund created for a Destination Charge. That is discussed here:
https://docs.stripe.com/connect/destination-charges?platform=web&ui=stripe-hosted&lang=node#issue-refunds
solar sleet
It is neither desired nor undesired behaviour. It wouldn't affect us much as far as I can think. The main thing is ensuring the correct amounts are directed to the correct accounts for a given month.
Is there a less cumbersome way to achieve this, that you're aware of, of course?
spring flare
No there isn't, this is going to be a complex scenario.
solar sleet
Okay, well thanks to both you and @ancient token (for now at least 😉 )