#ntountasakis-connect
1 messages · Page 1 of 1 (latest)
You can use SetupIntent, it won't charge but will authenticate the card, then after the call end you can actually make a payment. Or alternatively you can Auth an over-amount but not capturing it, then after the call capture the amount to bill
Both should work but I would recommend the former, since it doesn't need to decide the over amount
With this workflow, what is my recourse if the payment fails and the user fails to provide another payment method? Is this just an inherent risk?
No it could happen quite frequently. If the payment fails then the SetupIntent will fail, then you have the chance to stop the call happen in the first place and tell the user to use another PaymentMethod
User's credit card could be declined for various reason: expired, insufficient fund, wrong address, or enrolling in new bank program. Worst that could be a fraudsters testing out stolen card
As a business you should see declines are a normal part of the business, its' more of how you would handle the decline and maximize your conversion. For example if the card is declined just because of expiration, you can simply ask for another card, and the user would be happily try their second cc
I guess the part I'm not sure is, ideally I don't want them to proceed with starting the call until I have some idea if the payment method is good. If the card is declined, I'm on the hook for whatever charges they incurred to the person they called.
Yes, that's the idea of SetupIntent
So you create SetupIntent first, your user will need to confirm it. It can tell you if their card is chargable, but it won't charge right away
Okay, so there's not really a scenario where the setup intent informs me this is a valid card. Then they rack up say a $100 bill on one call, and then the card declines it when I actually run the payment because that's above their limit.
Not likely, but hard to guarantee for 100%. Some card does have limitation and if you charge them $1M for example, most issuer bank will decline
When I was reading the docs, I understood the setup intent in the workflow of like an Amazon account. You setup your wallet via the setup intent, and you can actually purchase something much later in the future. How long does the payment method registered in the setup intent valid for?
If I had to guess, the webhooks integration will send me a message saying that the pre-registered payment method is no longer valid?
How long does the payment method registered in the setup intent valid for
We will never know. The bank can suddenly suspend the customer's account. We only know that it was valid at the time we auth
If I had to guess, the webhooks integration will send me a message saying that the pre-registered payment method is no longer valid?
For expiration yes, but for other reasons it's totally up to the bank. And there are thousands of banks or more all over the world
Can you speak to the downsides of the pre auth of the over amount? If I had to guess it probably just lowers conversion rates.
It's hard to decide the over-amount. Even if you can, some banks don't distinguish between auth and captured so it could confuse your customer when they check their bank statement. They can then thought it's a fraud and dispute. It will hurt your business credit score if you have more dispute
I really appreciate your time. Since you strongly suggest against this, one last question. I think my workflow will be at account creation, run the setup intent workflow saving off at least 1 payment method. Is there a way to synchronously check right before the call the payment is most likely still valid?
You mean even after collected SetupIntent?
My understanding is of setup intent is it's a workflow to save off a payment for future use. When they first make an account on the platform, I'll prompt them with the payment page to capture payment details and provide that in the setup intent. Much later they might make a call, that's when I'll want to verify the saved payment is still valid.
Or do you suggest running the setup intent every time, even if I have already recorded the payment details?
No the former sounds correct
If the same user make multiple calls, before each call you still want to re-validate the payment saved in SetupIntent?
Ideally if possible. But even in the scenario where they make their very first call, would like to validate.
If they provided their payment method a long time ago, how can I know that it still is likely to work.
For the first call only, you can use the Attach Payment Method to a new Customer, in other word, delay creating a Customer object until the first call. This API will trigger a card validation AFAIK
That's good to know.
And from then on, the payment method is most likely to work. From what you're telling me it sounds like there's no good way to spot check the payment method. I'll be on the hook for some percentage of calls that the user does and cannot pay for.
Yeah, and it's more of recover after that. Most business need to deal with it honestly
Like you can pause their next call until they update their Payment Methods and pay you the pending amount
Does Stripe offer collections services?
Yes, via Invoice. Just create an Invoice and send. It will have a payment collection interface for customer
Okay, thanks for your patience. This really clears up a lot. Saved me a ton of time!