#.abishek
full scaffoldBOT
Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
mint jackal
There's a dashboard setting that sends customers an email for expiring payment methods
https://dashboard.stripe.com/settings/billing/automatic
vast mica
isn't there a webhook for this? so we can send email from our app?
mint jackal
For the subscription renewal? Or expiring payment methods?
vast mica
both
mint jackal
invoice.upcoming is for subscription renewal
https://docs.stripe.com/billing/subscriptions/webhooks#:~:text=on the subscription.-,invoice.upcoming,-Sent a few
vast mica
ok
mint jackal
The dashboard setting above customer emails allows you to control when its generated (i.e. 7 days prior etc)
vast mica
ok, what about the expiring payment methods?
mint jackal
I believe it's this
https://docs.stripe.com/api/events/types#event_types-customer.source.expiring
vast mica
ok, cool thank you. let me try this. since the card functionality is deprecated, will that event give a payment method object on the request?
mint jackal
I don't see any other events for expiry so I assume it's that one.
I'd say try it out with test clocks if possible. That should confirm the intended behaivor
vast mica
ok, thank you. going to se how to do that with test clocks
wonder how to test the source.expiring 🙂
i am able to add a card that expires by Feb 2024
mint jackal
I'd do:
Create a customer + attach a PaymentMethod with expiry in a couple month + create a subscription.
Run stripe listen to listen for webhook events on the CLI and then advance the clock couple months
Try setting expiry in april or may
vast mica
ok
exactly tried what you mentioned, the customer.source.expiring isn't getting called. Does it happen any specific number of days before it expires?
mint jackal
Ah hmm
Ideally, it's sent at the beginning of the expiry month
For your usecase though, you could just listen to invoice.upcoming and retreive the payment method to look at expiry
vast mica
ok
mint jackal
If the payment method is expiring soon then you can send an email
vast mica
if the payment method updates automatically how long before that happens? don't want both to conflict.
my use case was only if the subscription is about to renew and the payment is about to expire, so I may have to run something custom in this case
mint jackal
There isn't a set time on when the payment method gets updated automatically (although you can listen to the relevant webhook event to know if the payment method got updated automatically)
vast mica
ok, but there isn't a hook that triggers if an automatic update failed, right?
thanks for the link, that helps a bit
looks like that card expiry doesn't seem to work on test clocks
The card expiry is set to May 2024, but I am able to successfully advance till June without any payment errors
mint jackal
Yeah testing with test clocks was just a guess. But I can confirm that we do send those specific events for expiring payment methods
vast mica
any reason why the payments wont fail on the test clocks for expired cards?
i can test if a subscription payment fails in this case
unless I use a card that fails
mint jackal
You'd need to use a card that fails with that specific error code I think. 4242 card wouldn't fail (even if expired)
Like the support article suggests, we assume issuers would still let the charge through
vast mica
ok, i was assuming that there would be a grace period, not 4-5 months
would be good if the dates on payments showed based on the test clocks. The invoices show correctly
full scaffoldBOT
mint jackal
I think the thought process here was that folks typically listen to invoice.paid events (and not at the underlying PaymentIntent)
But seems like a reasonable dashboard feature request
vast mica
ok
automatic payment method update has its own webhook, but will payment_method.updated also be called in addition to that?
also, there are 2 events for this, which one should I subscribe to?
crisp cave
I believe it would get triggered but would reccommend trying this in test mode to confirm
vast mica
these hooks doesn't work on the test mode, tried to use the test clocks. I can't get customer.source.expiring to work as well. Not sure if there is a specific test card that I can use to test these
crisp cave
Ah, my apologies. I read the thread too quickly and misunderstood the context. Checking in to this
vast mica
thank you, for a subscription renewal, what is the ideal webhook to use? invoice.payment.succeeded or invoice.paid ?
crisp cave
I usually recommend paid. The payment_succeeded event is sent specifically for when a payment made the invoice move to a paid status. The paid event does that but also includes everything else that can move the invoice status to paid (like being marked as paid out of band)
vast mica
ok
but, it would be great to be able to test out payment method stuff I was asking above
https://docs.stripe.com/api/events/types#event_types-customer.source.expiring is the one I am most interested to test, because what is the payload received on this is not quite clear from the docs
crisp cave
Unfortunately it looks like we don't have a way to test with the payment_method.updated event and the customer.source.expiring event is only sent for Source objects, not for cards saved as PaymentMethod objects. So I don't think the source expiring event will work for your integration.
We are working on various aspects of this flow but at the moment the best way to impliment this is to track the expiration dates for these cards yourself
vast mica
ok, are there any docs on before when the automatic updates happen, I don't want to send a notification to a customer and the automatic update has already happened after that.
can you point me the docs for automatic payment updates, can seem to find it using the search
also, sometimes when the payment method automatically updates, the card number is usually different. in this case, does a new payment method get created or does the existing payment method get overriden
crisp cave
Looking for docs on both of those
vast mica
thank you
crisp cave
I found this doc section on the automatic updates. Is there a specific thing about them that you are trying to understand? That doc section does not have much info https://docs.stripe.com/payments/cards/overview#automatic-card-updates
vast mica
also, sometimes when the payment method automatically updates, the card number i...
This one ^
based on the docs, it just blindly updates the existing payment info and doesn't create a new payment method
crisp cave
Yep, the pm_ ID that you use should stay the same
vast mica
ok, even though it updates the existing pm_id does it create a new card associated with the pm_id ?
ok, looks like there is no card object, its just part of the same pm object
crisp cave
As in the card_123 object? As far as I know source IDs should stay the same as well
vast mica
its just that, if the card info changes, that would override all previous payment info associated with payments
say a customer gets charged for a Subscription using Visa card ending 1234. On our app, we show what card was used to charge
say it updates automatically to Visa ending 0987.
crisp cave
I think when Stripe displays that on your dashboard it should have the original info. If you are rendering your own page, I am not immediatley sure if there is a way to get the old card info. I will double check on that and get back to you
vast mica
then if I use the payment_method.updated that would just change the association for the previous payment. I have to check may be for the fingerprint and create a new payment method on our end
the problem with this on our end is that we have a unique constraint for the pm_id and the will throw and error if we add another card with the same pm_id
we had to develop our own UI for managing all this because we couldn't use Stripe's Customer Portal for one small feature that doesn't yet exist
crisp cave
Yep, the fingerprint will be updated so you can definitely do that check. Also it looks like our Charge objects have a payment_method_details hash that specifically has the info for the payment method at the time the charge happened. So when the card is updated, this should still have the original last4 to show the user https://docs.stripe.com/api/charges/object#charge_object-payment_method_details-card-last4
full scaffoldBOT
vast mica
ok
let me dig into it. another question, can the value of metadata on the Stripe objects store array objects or only strings?
crisp cave
Only strings
crisp cave
Yep yep, 50 keys of 500 chars each https://docs.stripe.com/api/metadata
Yep, you just need to remember to parse on the other side