#ben-clum_api

1 messages · Page 1 of 1 (latest)

rancid wyvernBOT
#

👋 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/1407722428636856363

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

thick spoke
#

Hey there, sorry for the delay

#

You're broadly taking the right approach here, using a timestamp thats on the intended day for both account timezones

#

Can you share an example subscription creation that is not getting the expected charge for the first invoice?

fallow bridge
#

it's in the request ID

#

actually that's an example where we didn't use a billing_cycle_anchor.

#

if we set the billing_cycle_anchor, then the client will not get charged immediately for the full amount. which we don't want.

rancid wyvernBOT
thick spoke
#

How do you expect the partial months to behave if customers subscribe mid month?

#

Or is the anchor always meant to be the next day?

fallow bridge
#

mid-month they would be charged twice (prorated amount, then full amount on the 1st)

think of it this way:

  1. You are currently in BST and it's 12am BST May 1st.
  2. you start a subscription and you want it to be anchored to the 1st of the month.
  3. since it is currently the 1st of the month, you would expect them to just be charged immediately for the full amount. there's no weird math that needs to be done or double-charging the user
  4. but if we try passing some weird anchor date that works for both BST and EST, it'll cause the user to be charged twice in the span of a couple hours (or at the very least, the customer isn't even charged immediately when the subscription starts) , which is absoutely not what our BST customer would want to happen.

does that make sense?

outer flicker
#

Hi there. Taking over

#

Give me a bit to catch up

thick spoke
#

There's no perfect way to do this with the "snap to month" approach you're describing

#

I think the closest fit would be using your business logic to decide when this case should apply, then when it does instead of using billing_cycle_anchor you set trial_end to the next renewal (eg, in this April 30 example you set it to June 1), and using add_invoice_items to include a rounded charge for one month of service.

fallow bridge
#

yeah it would just work automatically if we could change the timezone of an express account

thick spoke
#

when the "trial" (paid first month) ends on june 1, that would become the billing cycle anchor

fallow bridge
#

if you add_invoice_items to a trial subscription, it'll charge those invoice items immediately when the subscription starts, but the regular subscription payment will not be charged?

thick spoke
#

Correct

#

the regular recurring item price will only charge starting after the trial ends, and the trial_end timestamp becomes the new billing cycle anchor

fallow bridge
#

makes sense.

are you able to submit feature requests or no?

  1. ability to pass the desired timezone when creating a subscription (affects how a subscription is anchored to a month)
thick spoke
#

Yep, this is something we've heard before, I'll add your use case as another request 🙂

fallow bridge
#

is there any way I could have some some of "feature request ID" that I can pass to our Stripe rep?