#ntountasakis-connect

1 messages · Page 1 of 1 (latest)

arctic light
#

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

dreamy spindle
#

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?

arctic light
#

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

dreamy spindle
#

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.

arctic light
#

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

dreamy spindle
#

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.

arctic light
#

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

dreamy spindle
#

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?

arctic light
#

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

dreamy spindle
#

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.

arctic light
#

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

dreamy spindle
#

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?

arctic light
#

You mean even after collected SetupIntent?

dreamy spindle
#

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?

arctic light
#

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?

dreamy spindle
#

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.

arctic light
#

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

dreamy spindle
#

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.

arctic light
#

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

dreamy spindle
#

Does Stripe offer collections services?

arctic light
#

Yes, via Invoice. Just create an Invoice and send. It will have a payment collection interface for customer

dreamy spindle
#

Okay, thanks for your patience. This really clears up a lot. Saved me a ton of time!