#JohnnyB - Payments

1 messages · Page 1 of 1 (latest)

regal musk
#

Hi 👋

#

What Stripe products are you using to collect the payment?

pure harbor
#

great question, we're using two:

#
  1. Payment Element for when we send a payment link to the caller
#
  1. Twilio + Stripes: IVR pay
regal musk
#

Okay, but are you generating Charges or Payment Intents? I have no insight into the Stripe + Twilio integration as that is not directly maintained by us

pure harbor
#

Payment intents

regal musk
#

Okay well payment intents don't have a failed status per se. They are designed to allow for recovery to allow users to provide updated payment method details

#

So what part of your integration is not behaving as you expect?

pure harbor
#

we need to have finite statuses

#

if it's successful, the connet the call

#

if it's failed, we need to either disconnect or reroute

#

if it's pending (or recovery status) we can hold it to let them try again

#

otherwise they'll be on an infinite loop

regal musk
#

Okay but that is essentially up to your integration to make those determinations. Stripe has the defined statuses we provide and it's up to our users to design their integration to make best use of them.

#

If you want immediate failure when credit cards are declined or entered incorrectly then using Charges will achieve that result.

pure harbor
#

what are the defined statuses?

#

and how/where do we define the failure parameters for a status?

#

in a perfect world, we can allow 3 recoveries, or switching of a credit card, before giving a hard failure

regal musk
#

in a perfect world, we can allow 3 recoveries, or switching of a credit card, before giving a hard failure
That's up to your integration

pure harbor
#

But which integrationm?

#

these are around your fixed and as you said, defined statuses

#

we will do whatever we have to

#

but we're asking about the way that you report different statuses

#

and also how to modify the tolerance of each (if possible)

#

specfically, where do I configure 3 attempts before we get a failed?

regal musk
#

In whatever software you are using to integrate with Stripe APIs

pure harbor
#

please see test of question

#

rest*

granite python
#

I don't really understand what the question is about unfortunately

pure harbor
#

let me rephrase

#

how do we configure how many attempts for recovery a user can do, before giving a failed payment status

granite python
#

If I understand correctly you are not writing code yourself and are using Twilio's overall integration for payments over the phone right? If so there's no such thing as "recovery" and such

pure harbor
#

I'm not writing the code myself, and have our team of developers on the phone with me

#

We

#

Were not worried about payments from Twilio as they are simply successful or failed, and Twilio allows us to define how many attempts are allowed

#

We use an internal calculation to get a price on our system, we then feed that to Stripe via API to Payment Element, we then use Twilio to send that Payment element link. The client clicks on it and sees your Payment element Page.

The payment is going to either:

  1. Succeed on first try
  2. Fail

Since the customer is on the phone, we need to know what to do.

If failed, we'd like to be able to set how many recoveries are allowed before getting a FAILED status, which forces us to disconnect the call.

granite python
#

Earlier you said you use IVR. IVR is someone typing card details on their phone over a phone call. Not using PaymentElement
Now you say you use PaymentElement and just use Twilio to send a link to your website.

pure harbor
#

...

#

we are using two modes

#

IVR payments, and payments over Stripe links

granite python
#

Ultimately if your question is: how many times can someone confirm the same PaymentIntent in a row and get declined every time, then there is no real limit. It'd be on you/your integration to add limits

pure harbor
#

I want to focus on the Stripe Link Payment Element

#

and not the IVR

#

as twilio is smart enough to allow for specific recovery attempts

#

GREAT, where do we add the limits?

granite python
#

In your own code

#

There is no "setting" for this that you set set to like "17 failed attempts" on a PaymentIntent. You write code, to measure/track all the confirmation and decide when to block

pure harbor
#

ok great

#

thanks