#siv_api
sinful tuskBOT
đ 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/1325956074418733170
đ Have more to share? Add more details, code, screenshots, videos, etc. below.
pliant quail
Hi there
narrow mango
hello
pliant quail
This is tricky to solve for, unfortunately
I see this customer signed up for the 7-day trial using a card they saved on ApplePay. The first charge on the non-zero invoice failed because the card had insufficient funds. The card they added on ApplePay was not a credit card but a prepaid Visa
narrow mango
Oh that was a 1 random user who had payment failed, would it be helfpul to provide several?
But interesting, is there anyway I could see if it failed because of aprepaid visa?
pliant quail
Taking a step back, let's say the user had used a credit card to sign up for the trial. It's possible that at sign up time, their card could be used for successful charges but say they replaced their card on day 3 due to a stolen card. When day 7 rolls around, your attempts to charge the old card will also fail.
narrow mango
Thats true, I know theres no way to know what will happen 7 days from now but if we could verify it works on day 0 I think that would help
pliant quail
But interesting, is there anyway I could see if it failed because of aprepaid vi...
You could look at the charge.failed event: https://dashboard.stripe.com/events/evt_3QalRNC29OKMRxYZ0J6TUVVj
Specifically the failure_message and the payment_method_details[card][funding] value
We do use SetupIntents under the hood to save payment method details on sign up so we still validate whether the card details are valid
narrow mango
oh interesting so you are saying what I am asking for already is happening? Like the people who had payment_fail events did have valid cards with enough money at the time of trial start?
pliant quail
Not exactly. They had valid cards. "with enough money" is totally different and not something you can know unless you were to try to confirm a payment for X amount but that still doesn't guarantee that they'll have the necessary amount at the end of the trial
narrow mango
that makes sense
is there a way to prevent prepaid cards and just allow debit and credit cards?
pliant quail
Yes, though not with Checkout
You'd need to integrate with Subscriptions directly and use the PaymentElement: https://docs.stripe.com/payments/build-a-two-step-confirmation
narrow mango
so we would have to get rid of checkout and rebuild things manually with PaymentElement but have more control?
pliant quail
You'd essentially break up the sign up flow into two steps: collect payment details first and inspect the PaymentMethod to determine how to proceed. If card.funding on the PaymentMethod is not credit or debit, prompt the customer to use a different card.
Yep, correct
narrow mango
Hmm okay, thank you for the information. So given what I have explained, where the problem is we are getting a lot of users with failed payments after trials, is there anything we could do in the Checkout infrastructure to help at all? Is it possible to add a 1 time charge at checkout that does not get a trial applied to it?
pliant quail
You could add line items for one-time Prices even if you're using subscription mode: https://docs.stripe.com/api/checkout/sessions/create#create_checkout_session-line_items
These one-time Prices won't be included in the trial. Customers will be prompted to pay for this amount when signing up; only the recurring price will be in the scope of the trial/$0
That said, that still doesn't quite guarantee that the customer will be able to pay for the recurring price at the end of the trial
narrow mango
Okay thank you! Thats good to know. And is there anyway to refund this amount instantly or prorate the trial subscription in anyway?
pliant quail
You'd have to build logic on your end to refund the charge. You could update the customer's credit balance accordingly, which will reduce the amount due on the next invoice: https://docs.stripe.com/billing/customer/balance
narrow mango
thank you, and what happens if they cancel the trial but have a positive credit balance?
pliant quail
Nothing, their positive credit balance would remain and would be applied to a future open invoice
narrow mango
ah okay so I guess we would want to refund it for a better customer experience
pliant quail
Taking a step back, I'm not sure if trial is the right approach here in that case
The one-time charge you're adding to the subscription should only be added if they're paying for some add-on/some item they're getting. The goal of this charge should not be to validate whether charges on the card used will go through
What you can do instead of a trial is give the customer some discount so the first Invoice is not zero
Or you can have a much shorter trial, like a one day trial followed by a discounted first billing period
narrow mango
Good point, thank you! Much to consider. I think that answers all my questions
pliant quail
Happy to help!
narrow mango
Oh
Is there anyway to put a request in
To have stripe disallow prepaid cards in checkout
or any other way that could solve this problem
pliant quail
I can flag this request though I'm not sure what the priority will be given that users who need this level of customization typically use the PaymentElement instead