#Becca
1 messages ยท Page 1 of 1 (latest)
HI ๐
This is expected behavior. This is because cards with past expiration dates can and do often succeed with the issuing banks.
...oh lol
If you want to test this process you can update the Customer's default payment method to the one we created to return the expired_card decline
https://stripe.com/docs/testing#declined-payments
So you have the Customer subscribe with a valid payment method, collect the first invoice, update the Customer PN to one that fails, then advance the time
Based on the note below that table I didn't think we could attach those cards to a customer?
"Your card has expired"
If it matters, we're using the prebuilt/hosted checkout and I'm changing the card in the customer portal and also tried in the dashboard itself
Oh, this forum is focused on developers coding integrations with the Stripe APIs so that's our default approach. In that case you could use the card specified for Decline after attaching
we're using api/webhooks in addition and the checkout still requires code/developers so figured it fit oops. yeah, I did use that one, but was wanting to see how the error was presented / if it was presented differently to the user when they looked at the portal.
Yeah that makes sense. And I didn't mean to imply your question wasn't welcome, just that our default is to think in terms of API requests
all good!
my goal here is basically to figure out if on my end just a generic "please visit the billing portal to resolve an issue" will suffice or if I need to be more granular in the data on my end. that's why I was curious what the portal would show.
Yes that makes sense. So you're wondering what the Customer Portal would render when the customer accesses it if their Payment Method expired.
correct, was asked to provide a screenshot of what would happen if the card (that was good and had previous successful invoices) expired and then the renewal happened
๐ stepping in as Snufkin needs to step away
Is there an outstanding question here @polar verge ?
I guess it'd just be: is there a way to use test clocks to test card expiry? Or a test card that can be attached to a customer that would fail with expired (or stolen or etc)? It seems like the answer is no things like this can't actually be tested on our integration?
No test clocks won't do that. You want to use our decline test cards here for stuff like that: https://stripe.com/docs/testing#declined-payments
And for a lot of testing you are going to be best off mocking the API response
Those test cards are a different experience since it wouldn't be accepted for the initial payment. Doesn't help any with renewals, right? Do you have a reference for how I could mock the call so that we could see what the portal looks like for a subsequent invoice?
Oh I see, you are looking to test renewals specifically. You are looking for info on mocking the decline response?
I'm not sure what you mean by "so that we could see what the portal looks like for a subsequent invoice?"
Can you clarify?
Yes, I am testing renewals. We are hoping to only log a generic flag to show a generic "check the portal to resolve an issue" message and send users to the customer portal. We'd prefer this over logging specific failure reasons and having different messages. But we want to see what the portal experience is like before making that decision
You can test out the portal just fine here. You will just need to perform an extra step after the initial Sub payment where you updated the Customer's PaymentMethod to one that will decline and then you can see the full experience
The decision impacts which webhooks we need to handle
Sure, I'm just confused why you feel like you can't test this to see the experience that your customer will have?
I think it just comes to there being only 1 test card that can be attached to a customer with 1 failure message.
So I guess we can't see the different scenarios?
Ah okay I see. If I remember correctly, the portal isn't going to display information specific to the payment attempt. It will just show an invoice status in the Invoice History column
So the portal experience isn't going to change for your customer based on the type of decline
Ok, got it, thank you!