#juls1083

1 messages · Page 1 of 1 (latest)

grim joltBOT
#

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, 1 days ago, 13 messages
• juls1083, 1 days ago, 10 messages

last dew
#

Should I try to add more data, maybe billing data needs to be added to the function, even though is labeled as optional?

icy bay
#

Hi, let me help you with this.

#

Where are you getting the error?

last dew
#

When executing confirmCardSetup function, the setup intent response has this error code

icy bay
#

What's localPendingSCAToken?

last dew
#

the client secret attached from the subscription's pending_setup_intent

#

If it's null, we create a new Setup Intent, which returns a new client secret

icy bay
#

Could you please share more of your relevant frontend code? It seems like confirmCardSetup doesn't pick up the payment method details.

last dew
#

`import { CardNumberElement } from '@stripe/react-stripe-js'

const cardElement = elements.getElement(CardNumberElement)

const response = await stripe.confirmCardSetup(localPendingSCAToken, {
payment_method: {
card: cardElement,
},
})`

#

It seems like confirmCardSetup doesn't pick up the payment method details.
What crushes me is that it happens randomly for some users only. I wonder if there's something else, because I see the payment_intent_incompatible_payment_method error code on many responses

#

I was going to try and include billing details on the function, to see if the error rate declines..... But it really shouldn't

#

(of course, impossible to reproduce this on non-prod environments)

icy bay
#

Is this charge happening as a result of a Subscription update? Why? Doesn't the Customer already have a PM provided?

last dew
#

This is for off-session payments. It happens when the user is adding it's PM to their account

#

The fact that the error code starts with payment_intent also is confusing 🤔

icy bay
#

I've never seen this error. Also, this is not an off-session payment because the confirmation and the error comes from the Frontend. So your integration might not be correct.

last dew
#

This is the integration for adding a credit card. The setup intent can only be created from the frontend using stripe-js

icy bay
last dew
#

First we create a subscription in trial mode. Then, the user has a month to add its credit card. So it does make sense

icy bay
#

Where does this come from? localPendingSCAToken
Are you saving it somewhere?

#

I don't know yet exactly what's the problem here, but I see a few questionable points:

  • You're using an old API version on the frontend 2019-08-14
  • The frontend API version is not matching the backend one 2020-08-27
  • The SetupIntent is created by the Subscription update. It's better to collect the Payment Method when creating a Subscription or separately with a standalone SetupIntent: https://stripe.com/docs/payments/save-and-reuse?platform=web&ui=elements
  • The issue might be related to the CardElement and confirmCardSetup. I recommend you to use Payment Element instead (see the guide above).
#

I suggest you to go through these options and see if any of it fixes the problem.

last dew
#

It comes from here: subscription.LatestInvoice.PaymentIntent.ClientSecret

If it's null, we create a new setup intent, and we retrieve its client secret

grim joltBOT
hoary geode
last dew
#

The issue might be related to the CardElement and confirmCardSetup. I recommend you to use Payment Element instead (see the guide above).
I'm confused here. There's no payment happening at that stage of the flow, and the docs suggest using a Setup Intent to configure a new Payment Method

hoary geode
#

The 'Payment Element' can be used with to save cards with a Setup Intent too. It's not payment exclusive despite the name

last dew
#

I'm checking the API version... IS it advisable that I upgrade the stripe-js library to the latest version, if the backend API is 2020-08-27?

hoary geode
last dew
#

I use that

hoary geode
last dew
#

We check the latest invoice payment intent client secret, if nil, we check the subscription.PendingSetupIntent.ClientSecret

#

If nil as well, we create a new one

#

But this error should not be related, isn't it, whether the setup intent is new or existing, the confirmCardSetup function should work

hoary geode
#

So I'd start there

#

You can see in the request payload there's no card details passed from confirmSetup

last dew
#

But this is abstracted away via Elements component...

#

You mean that, if no card data is on the POST request, it was not retrieved?

hoary geode
#

Should be yep

#

I mean that the cardElement variable is not defined in that instance

#

Hard to say why without seeing the code. Normally that happens if the Element is not a child of the Elements group/provider

last dew
#

This is an example of the /confirm endpoint payload. Is it an option to add this data manually if cardElement is null?

Screenshot_2023-10-20_at_12.44.19.png
#

I would like to ask for the API version as well, how can I assure that frontend and backend are aligned? On the backend I see only the date, while the frontend uses NPM versioning

hoary geode
last dew
#

This is a standard request on test environment

hoary geode
#

But that shouldn't be necessary really it'll use your account default (as will the backend libs)

hoary geode
last dew
#

Yes, only on live mode, and randomly once per day or so.... It doesn't happen to most of our customers. That's what leads me to believe that this is related to the credit card details, and not to the frontend code

#

I was also asking about sending more data to the confirmCardSetup function (like the billing details)

hoary geode
#

You can see in the example you shared, there's no card details passed from the front-end into the API request

#

Let me find a correct example on your account

last dew
#

Yes, I know them....

hoary geode
#
Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

#

So for some reason in some of your confirmCardSetup calls the cardElement variable is null/undefined to its omitted from the API request

last dew
#

Not confirmCardPayment, it's confirmCardSetup

hoary geode
#

Typo

#

Either way, same principle applies

last dew
#

I'll look for more examples about using the Elements API, to see if there's another option, or maybe a better defensive code...

Anyway, thanks for your time 🙇‍♂️

#

I have another question related to the API versioning, before wrapping up this thread....

Our live Publishable key was created on 2018, does that mean that we have to generate a new one, since our backend API is from 2020-08?

#

Is that why our Frontend and Backend API versions differ?

hoary geode
#

When the API key was generated shouldn't matter. Stripe.js requests will use the account default version (unless overriden) whyich is 2019-08-14

#

2020-08-27 there

last dew
#

I see, so the Frontend should override as well

hoary geode
#

Well 3 options:

  • Override in Stripe.js.
  • Removed the backend override.
  • Upgrade account default (will also impact webhooks).
#

In reality I don't think the API version mismatch is related to your issue at hand, but it does help to have your integration using the same versions