#juls1083

1 messages · Page 1 of 1 (latest)

elder finchBOT
#

Hello juls1083, we'll be with you shortly! Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
juls1083, 6 days ago, 73 messages

compact cypress
#

Hi there!

#

Is your question why the payment failed, or what is this specific log?

broken barn
#

I want to know why the payment failed. The log is the weirdest thing related to it that I've found

#

I assumed that one of the reasons is the fact that this customers attached a new CC using Sources API

#

Which is supposed to be deprecated, and has higher chances of bank declines

compact cypress
#

This is the related PaymentIntent: pi_3NydwLIYOry9WQXw0f5ATk7E

#

And if I check that PaymentIntent in your dashboard I see

The bank returned the decline code transaction_not_allowed, and did not provide any other information.

#

So it's simply the bank that declined this payment.

#

So you have two options:

  • Ask the user to try a different payment method
  • Or as the user to contact their bank to understand the issue
broken barn
#

The user claims that this CC works for other services... so that will be hard...

#

But why this customer had a CC created with sources API?

fervent bone
broken barn
#

AFAIK, a CC created with sources, has very high chance of declines for indian customers. This customer seem to be american, but I've seen an indian address somewhere in the logs...

#

Due to RGI regulations

fervent bone
#

that's news to me!

#

as I understand it these are just the API-facing objects, the actual payment processing internally doesn't depend on that. For example we did support 3D Secure 5 years ago before PaymentMethods pm_xxx existed, it used Sources at the time.
Obviously the Invoice page should not be using Sources and my team has been raising that to the Invoices team for years.

But I wouldn't think it's specifically related to that decline.

#

ah actually we do support PaymentMethods on the Invoice page

#

your account just has a setting enabled on it that means we still create Sources for you

broken barn
#

I searched on the docs for such setting, but I didn't findd it

fervent bone
#

it's not a setting you can change, it's an internal thing

#

if you ask your AE or https://support.stripe.com/?contact=true or something they can take you out of that setting, I think basically we added any merchant who we thought relied on the fact Sources were created(I assume we did some query to see if you ever used like /v1/sources/src_xxx to retrieve an object in an API call, which would break if we started creating PaymentMethods instead, or something like that) to maintain compatibility when we made the change

broken barn
#

I would say we need to use the latest API. Contacting support will make our payment links to use the new API

#

?

fervent bone
#

no it's nothing to do with using the latest API version

broken barn
#

Sorry, I meant payment method API

fervent bone
broken barn
#

Ok, I'll contact support about this then

#

Hopefully, we can see an improvement the next days

fervent bone
#

to be clear I see this as completely unrelated and orthogonal to getting a decline

#

I was just explaining why a Source object src_xxx was created

broken barn
#

Maybe support will tell me why the decline happened then.... Because when it comes to payment links, there's nothing custom that we can do on our side, right?

fervent bone
#

I don't think anyone can say why a specific decline happened, since it's just up to the bank and 9 times of our of 10 the only thing as the merchant/PSP you can do is ask the customer to ask their bank. What we would look for are overall trends or spikes or edge cases.