#localpath
1 messages · Page 1 of 1 (latest)
hello! the pending_setup_intent would only have a value if the first payment is $0. for that event that you've shared, the first payment for the Subscription isn't $0
https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=subscription#create-intent
For subscriptions that don’t collect a payment up front (for example, subscriptions with a free trial period), use the client secret from the pending_setup_intent.
Hello. So Google Pay and Apple Pay have slightly different behavior then? Here is the Google Pay one with a pending_setup_intent that works as expected for us
evt_1Oh2RMEd62mULYc9Sb92RDD8
We essentially just start the subscriptions using a future anchor date so there is no charge at the time the subscription is created but the subscriptions first charge will be for the subscribed value.
no, this logic shouldn't have anything to do with Google or Apple pay. Gimme a while to take a look
Ok thank you so much for helping. If you need any more of our Express config or settings I can provide it
if i compare the requests that you're making, i see one of them defines a billing_cycle_anchor and the other one doesn't
if you make the request with the same parameters, the behaviour should be the same
Oh you think could it be bc we're attempting to start the sub the same day as today and we have some logic to calculate that anchor
We're doing this to get our anchor
/**
* If the provided start date is today, we'll leave startDateInSeconds
* undefined and let Stripe automatically handle the start date.
* @param startDate The provided startDate
*/
private calculateStartDateInSeconds(startDate: Date) {
const startDateInSeconds =
startDate && !dayjs(startDate).isToday()
? Math.floor(startDate.getTime() / 1000)
: undefined;
return startDateInSeconds;
}
That would make perfect sense. I think the fix for us would be don't allow Subscriptions to start today and we'll get that behavior. I think the Google Pay tests I was making were all future dates so it was throwing us off
you can see the requests you're making in the Dashboard e.g. https://dashboard.stripe.com/test/logs/req_lCU2MKzbkziDO9 and https://dashboard.stripe.com/test/logs/req_I9PUd2hVsY7dtk if that helps
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
I'll get my other dev to test the flow again using a future date
Thanks so much. This was super informative and great reminder to check my request logs!
If we do choose to do the sub starting today w/o the anchor, would we use a payment intent instead of setup intent?
your code should really just be able to handle both scenarios - maybe take a look at this page to see our code example on how it's being done : https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=subscription#create-intent i.e. steps 6 and 7
Ok got it. Thanks will review this!
on a side note though, if you want the subscription to start on a future date, wouldn't you use Subscription Schedules instead? https://stripe.com/docs/billing/subscriptions/subscription-schedules/use-cases#start-subscription-future
That's a sore subject bc our Api integration was built using Sources and some deprecated or not so great legacy methods of handling subscriptions
To your point its what we probably need to move our code to using now that we're introducing intents and refactoring out creating sources and cloning those sources for payment methods in some other areas outside these Digital Wallets that were adding ow
now *