#mayhul_api

1 messages ¡ Page 1 of 1 (latest)

ebon galeBOT
#

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

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

shadow glacier
#

Hi! Can you please share an example Payment Intent ID?

ebon galeBOT
broken marlin
#

Yes, I can share one in a moment

#

pi_3QfIO9ReasGoXvEm0j1mmsA1 in acct_1Pn9wJReasGoXvEm

willow canopy
#

hiya! i'm taking over my colleague, give me just a bit to catch up

#

it looks like that payment intent has a null setup_future_usage

#

but let me see if there's a better option

broken marlin
#

ok thanks. It's strange to be that it defaults to null. Given that this is a payment intent for a subscription, wouldn't it make sense for it to default to off session payments?

willow canopy
#

yeah i agree it's a little odd, i might run through a test real quick using my own integration to make sure i see the exact same thing as you

#

also fyi i'm juggling a few threads right now so apologies in advance if i'm a little slow getting back to you!

broken marlin
#

all good

willow canopy
#

ok yep, confirmed that in my own test integration it defaults to null setup_future_usage

#

still testing a few things out

#

ok, fyi i'm not seeing anything more elegant than updating the payment intent

#

i might need to spend a little more time experimenting with my integration to know for certain, but updating the payment intent should definitely work

broken marlin
#

So if we update it to have setup_future_usage=off_session, that will save it to the customer profile? And it will be used the next time the subscription is charged?

#

Relatedly, do you have any advice on testing past due subscriptions locally? What's the easiest way for me to get a subscrition in test mode into a past due state

willow canopy
#

i was actually just working on that! have you used test clocks before?

broken marlin
#

I haven't

willow canopy
#

these are essential for testing billing scenarios

#

what i would do is something along the lines of:

  1. create a test clock
  2. create a customer and pass the test clock into the test_clock parameter, and give them a valid invoice_settings.default_payment_method (e.g. pm_card_visa)
  3. create a subscription for the customer
  4. advance the test clock a few days
  5. update the customer's invoice_settings.default_payment_method to a card that will fail, e.g. pm_card_visa_chargeDeclined
broken marlin
#

ok gotcha thank you that's helpful. And that would scoped to just that customer/subscritpion? it wouldn't affect other things in the test instance?

willow canopy
#

test clocks are really cool in that they flag the customer for automatic deletion when the test clock expires, so the kinda clean up after themselves. and yes all of the updates i mentioned above would be scoped to the customer and subscription

#

you can have multiple test clocks running at the same time for different customers. they each have their own internal timer that's independent of the rest of the acccount

broken marlin
#

ok thank you for all your help, I'll try that out

willow canopy
#

no worries! i'll leave the thread open for a little longer in case you have followup questions