#driesvints_unexpected
pure socketBOT
👋 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. Thank you for your patience!
⏱️ We automatically close idle threads, which makes them read-only. Make sure you stick around to chat in realtime! If this thread is closed and you have another question you'll need to start a new thread.
🔗 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/1214946910545379338
📝 Have more to share? You can add more detail below, including code, screenshots, videos, etc.
radiant swan
Hey all. One of our users contacted us because they started to see something weird recently. The invoice_settings->default_payment_method now contains ID's that start with card_. Furthermore, these don't seem to respect the "expand" field on the API. Could this be related to the sources API changes from recently?
We retrieve the default payment method from a customer here (both source and payment method): https://github.com/laravel/cashier-stripe/blob/14.x/src/Concerns/ManagesPaymentMethods.php#L152. We request for expanded objects as you can see.
Then we check if we have a value for default_payment_method. This has always provided us with either null or an expanded payment method object: https://github.com/laravel/cashier-stripe/blob/14.x/src/Concerns/ManagesPaymentMethods.php#L154
We then pass it to a wrapper class in Cashier here: https://github.com/laravel/cashier-stripe/blob/14.x/src/Concerns/ManagesPaymentMethods.php#L155. The second argument always expects an object. But now one of users started seeing card_ string ids coming in for some reason. (see screenshot below)
This seems like a breaking change? We never expected a string value here. Could someone check if something has changed here?
timid gullBOT
pine wing
Do you have the example customer ID from the screenshot?
Ah whoops
you shared it already
looking
Is this the only example customer you have?
some of the logs are out of retention, so if you have other newer examples then those would help look at a complete picture.
radiant swan
will ask the user
pine wing
Also, just wanted to flag that invoice_settings->default_payment_method has always been a string. We never expand that by default (unless your code explicitly makes the request to expand it)
still looking into how this card_xxx became a default payment method on the customer
radiant swan
That's what I meant. We always explicitly ask to expand it
and we always got back null or an object
never a string
pine wing
Ah sorry I was reading too fast and likely missed that piece.
radiant swan
no worries
timid gullBOT
radiant swan
They're not responding immediately. But judging from your response it seems unwanted that card_ can ever become a value of default_payment_method?
strong nymph
That should work fine, PaymentMethods should be backwards compatible with sources like that. We're actually seeing this behave properly while testing ourselves
Can you try making this call again, and then send us the request ID and full response body that you get back?
Also can you try making this request in curl or postman to double check if the raw response body shows this as well? We think this may be a parsing problem, even though that seems unlikely because this was working before
radiant swan
evt_1OpF2LDwVgYYsIHeVwIr9lDK
here's an event
the user now notes all of the requests that failed are from the same user
did you try this with the user I provided?
this is a request that failed: req_wZyQEyZzKCOqIp
they also let me know now that this customer doesn't have any payment methods on file but still have the card_ attached as default_payment_method
"default_payment_method": "card_1FRJvwDwVgYYsIHetGWIqz9K",
I can't make these calls myself btw as I don't own the account and don't have access to the customer
strong nymph
For the event it is expected that this wouldn't be expanded. Events cannot auto expand fields unfortunately.
That request is for a payment method detach, we are actually trying to understand how the card is set as the default PM after being detached. That does look to be a bug as far as I can tell, and we are unsure if that is the reason for this behavior at the moment. Still looking in to that.
And gotcha, we can't make these calls either. I think I have a way of finding the get requests in the logs, will try that and report back with what I can find.
radiant swan
That's cool. Appreciate the help 👍
strong nymph
@radiant swan apologies for the long delay. The leading theory is that this bug with detach is causing expansion to fail. Do you know if this is happening for any other customers that didn't have this detach scenario happen to them?
pure socketBOT
normal spruce
Hello! We've been looking into this, and it appears this particular Customer somehow got into a bad state where the Card in question was detached, but is still showing up for some reason in invoice_settings.default_payment_method, and it always shows up as just the Card ID and can't be expanded.
We still don't know how this happened, but we're continuing to investigate. It's likely we'll be able to fix this Customer at some point and get that Card properly, fully detached.
As far as your code codes, while this kind of thing shouldn't happen (as you said, you should get null or an object back when expanding like this), it's clearly not outside the realm of possibility. I recommend you update your code to account for the possibility of getting a string back for an expanded property, and if that happens treat it as an unexpected/error case that prompts someone to contact Stripe support about the unexpected behavior.