#mr.chu_16596
clever ruin
Hi there 👋 hm, I'm a bit less familiar with those dashboard fields.
Let me see if I can track them down, but I'm thinking those may be dashboard specific.
gleaming obsidian
oh no... we've developed python scripts to create the scheduled subscriptions
but we want to always have these parameters checked
I assumed that the payment methods would use the dashboard/billing/invoice defaults. It's set up to use Card and PAD
clever ruin
Wait wait, you're asking about the email setting right, not about the PM types being used?
gleaming obsidian
both
clever ruin
Alright, lets take a step back and approach this from a different angle. Can you share the request you made to create one of these Subscriptions, and help me understand what it didn't do that you'd like to change?
gleaming obsidian
you're looking for API responses?
clever ruin
I want the ID of the request you made to our API:
https://support.stripe.com/questions/finding-the-id-for-an-api-request
And to know what behavior about the Subscription that created you're trying to change, and what you'd like to change it to.
gleaming obsidian
To summarize what we're trying to do:
- Schedule a subscription to go out on the first day of the month.
- Charge the customer the product for that month
- Set a 20 due date
- Invoice to have a stripe link with payment options of: Card and PAD only
Ideally we want to set more Iteration phases, but we're finding issues with the date/time. That's another issue.
The subscription settings are a priority for us at the moment...
clever ruin
Looks like you have the 20 days set, and the collection_method set to send_invoice, so those look right.
You're setting the start_date, so that seems to be covered
Does that mean it's just the Payment Method choice you aren't happy with?
(Setting end_behavior to cancel seems like it may not be what you want unless you are intending to create Subscriptions that are canceled after a single phase or plan to update the Subscription Schedule later)
gleaming obsidian
Does that mean it's just the Payment Method choice you aren't happy with?
It's more so of how do I enable those settings.
We don't want to charge our customers as soon as the subscription starts
white wrenBOT
clever ruin
Sorry, I don't think I'm grasping what you're hoping to change. Your Subscription Schedules aren't being created in a way that they automatically change the customer, you're controlling that via the collection_method parameter. It will generate an Invoice that they have 20 days to pay (based on the settings provided in the first request)
Have you tried creating one of these within a Test Clock, where you can advance time and see how the Subscription Schedule and it's Subscription will behave throughout their lifecycle:
https://stripe.com/docs/billing/testing/test-clocks
gleaming obsidian
so right now, my subscriptions are in a scheduled state. I would like to know how I can enable those highlighted items in the subscription settings.
I did use a test clock scenario
If a customer has a payment method on file, it will charge as soon as the subscription is active
clever ruin
No it won't, you didn't set collection_method to charge_automatically
(unless that switched between requests and I'm looking at the wrong one)
gleaming obsidian
No it won't, you didn't set `collection_method` to `charge_automatically`
I'm looking at the response body of one of the POST request i sent you. I see it:
clever ruin
Look inside of phases, you didn't set it at the default level, you set it at the phase level
gleaming obsidian
This is our dashboard settings:
but when I use the API method to create the scheduled subscriptions, the Invoice payment and payment methods are not configured.
gleaming obsidian
Look inside of `phases`, you didn't set it at the default level, you set it at t...
let, me set up a test clock scenario
clever ruin
You can set those settings within default_settings:
https://stripe.com/docs/api/subscription_schedules/create#create_subscription_schedule-default_settings-collection_method
But they can also be defined at the phase level so you can have them fluctuate from phase to phase:
https://stripe.com/docs/api/subscription_schedules/create#create_subscription_schedule-phases-collection_method
gleaming obsidian
almost done setting up a test clock scenario
I have 3 customers, 2 which are using the fake CC info
so, when I advance the clock to Feb. 2, which makes the subscription active. What is the expected behavior?
clever ruin
An invoice that is due in 20 days is generated, and an email would be sent to the customer to pay it except that this is test mode where most email functionality is suppressed.
clever ruin
What do you mean, they are enabled?
gleaming obsidian
in my screenshot
clever ruin
Let's not worry about how the dashboard shows things, lets focus on what we see in the API
gleaming obsidian
Interesting, I advanced the clock
and it shows my subscriptions as active. and Invoices in an open state
clever ruin
As you were hoping?
gleaming obsidian
Yes!
we were worried of manually trying to go in each subscription
to enable those parameters
clever ruin
Gotcha, yeah you shouldn't need to do that, you should be able to set them either inside of phases or default_settings when creating the Subscription Schedules. I would recommend pushing the test clock forward another month, because I'm still nervous the end_behavior you're using isn't what you want, but I may be mistaken.
gleaming obsidian
so we were trying to schedule these subscriptions for a 12 month iteration phas
but we were noticing that invoice dates were wrong
For instance:
We always want our invoices to show the first day of the month and the last day
but when we were advancing the clock ahead, we noticed the next months invoices were showing Mar. 1 - Apr. 1
instead of Mar. 1 - Mar. 31
clever ruin
Try setting your start_date so it's at midnight UTC on the desired date, it's currently 5 AM
gleaming obsidian
we're EST timezone
we've been struggling with this issue for awhile since our implementation.
clever ruin
All of the timestamps in our API are UTC based. I'm not sure how that gets shown in various places in our UI as I'm less familiar with those, I don't know if they take your timezone into account and shift what is displayed for that.
gleaming obsidian
we tried a bunch of things. We changed our dashboard from EST to UTC, and the issue is still present
it's been escalated to our Stripe account holder. We're technically still under implementation phase
clever ruin
Can you humor me and try setting the start_date to midnight UTC?
gleaming obsidian
so for now, we're issuing our subscriptions every month
sure, i'll need to recreate another test clock scenario
clever ruin
👍 I may be wrong, or not understanding where you're looking at the dates on the Invoices (and whether those are the dates you see or the dates your customers see), but I'm pretty sure in my testing midnight UTC has helped my dates be firstofmonth-lastofmonth
gleaming obsidian
i'll give you a play by play
or we can jump on a screensharing session
give me a few mins to set up
clever ruin
Ok, so back to looking at what the dashboard shows you. That I believe does adjust based on your timezone. Are those the dates you were worried about, or the dates in the PDF, or in the API, or somewhere else?
clever ruin
Argh, and of course we don't give a timestamp alongside of those dates for you and I to have a good idea on what is causing them to shift 😅
clever ruin
Yeah, it definitely seems like we're shifting those time to try to match someone's timezone, but we're getting away from the stuff I know well so I'm not really sure what to suggest to avoid that (especially as I'm not sure if we somehow use the customer's timezone to influence that).
Hm, maybe you already had it right by setting the start_date to midnight your timezone
gleaming obsidian
yeah.. even then, the date shifts
the next invoice interations will show Apr. 1 - May 1
it's really weird
clever ruin
Agreed, but unfortunately, seems like something that you may not be able to code your way around right now. It sounded like you had already flagged this to your other Stripe contact(s)?
gleaming obsidian
yes, that's correct
we had looped in a bunch of stripe's engineers . so it's in their purview somewhere in the pipeline
clever ruin
Gotcha, that's probably the best path forward for that concern then.