#KuVana

1 messages · Page 1 of 1 (latest)

fervent stirrupBOT
finite dome
#

Hello! Can you give me the ID of the Payment Intent in question?

hearty shadow
#

In this instance I don't have the paymentIntent yet, it should be displaying without the intent

finite dome
#

Ah, the error you're seeing explicitly states you passed in a Payment Intent, which is why I asked for it. Can you provide the code that throws this error?

hearty shadow
#

Yeah, I'm confused there as well, here is the Element

<Elements stripe={stripePromise || null} options={{
      mode: 'payment',
      amount: options.amount,
      currency: 'usd',
      setup_future_usage: options.setupFutureUsage
    }}>
<PaymentElemnt />
</Elements>

and the loadStripe

const stripePromise = loadStripe(configKey, {
  betas: ['elements_enable_deferred_intent_beta_1'],
});
finite dome
#

This integration is no longer in beta. If you remove the beta header does that resolve the issue?

hearty shadow
#

trying

#

Same issue, unfortunately

finite dome
#

Hm, interesting. And you're not setting a client secret anywhere?

hearty shadow
#

No, I have a call that will be made on submit to set the paymentIntent, retrieve the clientSecret and then confirmPayment

#

But it's not being hit yet

finite dome
#

Some other questions:

  1. What is the amount set to?
  2. If you remove setup_future_usage do you see different behavior?
hearty shadow
#

a value aboce $0.50 most recent test was $25 (2500)

#

even with setup_future_usage removed, it still gives the loadError

#

Not sure if it helps, but this is the full Element loaderror

code: "unsupported_parameter"
param: "payment_method_types"
type: "validation_error"
message: "The PaymentIntent you passed doesn't have any payment_method_types that are supported by the Payment Element. Please use a PaymentIntent with a least one of the following payment_method_types: affirm, afterpay_clearpay, alipay, acss_debit, au_becs_debit, bancontact, blik, boleto, card, cashapp, customer_balance, eps, fpx, giropay, grabpay, id_bank_transfer, ideal, klarna, konbini, link, mobilepay, oxxo, p24, pay_by_bank, paynow, paypal, promptpay, demo_pay, revolut_pay, sepa_debit, sofort, us_bank_account, upi, wechat_pay, zip, nz_bank_account, bacs_debit, apple_pay, google_pay, meta_pay, external_paypal, external_venmo, external_catch"
finite dome
hearty shadow
#

Cards, Apple Pay, Google Pay,

finite dome
#

I'm a bit baffled, to be honest. Let me ask someone else internally for help, hang on...

hearty shadow
#

Thank you

finite dome
#

Actually, one quick question: I was looking at your code again and you have <PaymentElemnt /> instead of <PaymentElement />... does correcting that change anything?

hearty shadow
#

That was just a typo transferring it here

<PaymentElement onChange={handlePaymentChange} />
<AddressElement options={{ mode: 'billing' }} onChange={getCardName} />

finite dome
#

A typo? That code is pretty different from what you shared. Can you copy and paste the exact code you're using without modifications?

hearty shadow
#

Can't copy and paste directly, as the Payment Element and Address Element are contained within UI elements but I can give a basic look

<Elements stripe={stripePromise || null} options={{
      mode: 'payment',
      amount: options.amount,
      currency: 'usd',
      setup_future_usage: options.setupFutureUsage
}}>
    <Accordion>
     ...
        <AccordionBody>
            <PaymentElement onChange={handlePaymentChange} />
        </AccordionBody>
        <AccordionBody>
            <AddressElement options={{ mode: 'billing' }} onChange={getCardName} />
        </AccordionBody>
    </Accordion>
</Elements>
#

I did just load up my other view using the same setup, and it is working. But that one starts with a set paymentIntent Id ( invoice flow) where the one I am currently working on is for a dynamic payment flow, meaning they can pay whatever amount they want and we create the paymentIntent on submission

finite dome
#

Can you hard-code a specific amount, like $10, and see if that changes anything? Can you also give me your account ID or a request ID from your account so I can investigate further?

#

And can you provide your publishable key so we can try to reproduce on our end?

hearty shadow
#

Interesting, It rendered the paymentElement that time with the amount of 1000

pk_live_PfCecLqPy7TXBDNUmrepjycY00s3cQvtgj

finite dome
#

Are you sure the amount is being set to what you expect?

#

When the error happens I mean?

#

It sounds like the amount may be invalid.

hearty shadow
#

I had a default amount of 1 onload and it would update the options.amount when the amount textField was updated before the paymentElement was rendered. As far as I can tell, setting it to a minimum of 50 initially allows the paymentElement to render without error

finite dome
#

Gotcha. We're going to improve the error message here so it's less of a mystery what the issue is in the future. 🙂