Tom Catchesides

[halcyon pumice]

I think you can still have multiple Payment Element and mount them one by one separatedly

You would need to use multiple SetupIntents for each instance

[steady yew]

Thanks for the reply! So the approach would be that we can create multiple Payment Element instances, but ensure that a maximum of one is mounted at a time?

re. SetupIntents: we don't need to reuse a payment method, the end user will be selecting one thing to pay for at a time.

[halcyon pumice]

Um yes, but that would be buggy. Why would you need such a page btw?

[steady yew]

Thanks, I'm open to advice here!

The use case is a page where the user can be shown multiple payment amounts (e.g. "pay the next instalment of $10" and "pay the full balance of $50").

Currently, there's a hidden instance of Card Element for each of those options that's shown when the user selects one. The back end is responsible for creating the payment intent and communicating with the front end if further user interaction is required (e.g. SCA).

How would you recommend approaching a situation like this with Payment Element?

[halcyon pumice]

Let's say if the transaction requires SCA, your backend will ping back your frontend to handle it? That sounds a bit manual to me 😅

Safest approach would be moving the Payment Element into... next page when you have the amount fixed. But I understand you want to reduce transitions

Have you tried having multiple Payment Elements instance, pre-initialize it with 3 blocks of

// Set up Stripe.js and Elements to use in checkout form, passing the client secret obtained in step 3
const elements = stripe.elements(options);

// Create and mount the Payment Element
const paymentElement = elements.create('payment');
paymentElement.mount('#payment-element');

Call them paymentElement1 paymentElement2, paymentElement3 in example (with 3 different div name)

you would need elements1 elements2 elements3 since they use different options too. Each option should have the client secret of 3 different Payment Intents

[steady yew]

Yes, that's the approach I'm taking at the moment and it doesn't seem to be working. I'll share some of the console errors

Errors on page load

Further error at the bottom on submitting the form

There might be a race condition in there: the initial series of errors sometimes don't appear when loading a page that only contains three Payment Element instances, but adding more (to stress test this approach) will almost guarantee it for me.

[halcyon pumice]

I think there are red herring too. Have you been able to integrate 1 Payment Element (comment out all others)?

[steady yew]

1 Payment Element is fine

[halcyon pumice]

Do you see the same "Fetch API cannot load ... due to access control" at that case?

[steady yew]

No, with 1 Payment Element there are no console errors.

I will double-check that there aren't any differences between 1 and multiple instances that could cause this, is it okay if I get back to you in a few minutes?

[halcyon pumice]

Sure np

This is interesting tho

[steady yew]

Haha, I'm glad that it's interesting even if there's a risk that we need to significantly change our approach.

[halcyon pumice]

The "Reached maximum amount of queued data" looks problematic to me. Would be easier if you have a public accessible URL

[steady yew]

Would you like me to share a URL with you when I've finished checking things through? If so, is there a way that I can do that privately?

[halcyon pumice]

You can just share it here. I will be sign off soon but one of my colleague will continue to assist 🙂

[steady yew]

OK, here's one example: https://test.lightbluesoftware.com/client-portal/tomcat/invoices/E3E3869DE98FD9A30BEE15330BC2E4CE.php

This is sometimes generating errors on load, but is guaranteed to produce the "Unhandled Promise Rejection: IntegrationError: stripe.confirmPayment(): expected either elements or clientSecret, but got neither." error on trying to submit payment details.

[thorny root]

Hi there!

I just checked your page, and it seems to work. What exactly is the issue?

Oh, I need to try to make a payment to see the error?

I see this error:

Uncaught (in promise) IntegrationError: stripe.confirmPayment(): expected either elements or clientSecret, but got neither.
Can you share your code that calls confirmPayment?

[steady yew]

Thanks for the reply, @thorny root

If you're using the first "Make payment" button, the relevant bits of code are:

` var stripe = Stripe("pk_test_rrwkcwp6gugDErfgiabiP52f");

    const options15BA5FD030914008B330DB65BB7DE890 = {
        clientSecret: $("#payment-form15BA5FD030914008B330DB65BB7DE890").attr("data-secret"),
    };
    const elements15BA5FD030914008B330DB65BB7DE890 = stripe.elements(options15BA5FD030914008B330DB65BB7DE890);
    const paymentElement15BA5FD030914008B330DB65BB7DE890 = elements15BA5FD030914008B330DB65BB7DE890.create( "payment", { layout: { type: "accordion" } } );
    paymentElement15BA5FD030914008B330DB65BB7DE890.mount("#payment-element15BA5FD030914008B330DB65BB7DE890");

`

const form15BA5FD030914008B330DB65BB7DE890 = document.getElementById("payment-form15BA5FD030914008B330DB65BB7DE890"); form15BA5FD030914008B330DB65BB7DE890.addEventListener("submit", async (event) => { const {error} = await stripe.confirmPayment({ //Elements instance that was used to create the Payment Element elements15BA5FD030914008B330DB65BB7DE890, confirmParams: { return_url: "https:\/\/test.lightbluesoftware.com\/client-portal\/invoice.php?businessName=tomcat&invoice=E3E3869DE98FD9A30BEE15330BC2E4CE&action=showPaymentStatus", }, });

lines 92-99 and 122-158

[sacred smelt]

Hi there 👋
I'm jumping in to lend a hand, please bear with me a moment while I catch up on the context here.

[steady yew]

No problem, please let me know if there's any additional information that I can provide

[sacred smelt]

Please first allow me to come back to why are you implementing multiple Stripe Elements in a single page.

The use case is a page where the user can be shown multiple payment amounts (e.g. "pay the next instalment of $10" and "pay the full balance of $50").

Currently, there's a hidden instance of Card Element for each of those options that's shown when the user selects one. The back end is responsible for creating the payment intent and communicating with the front end if further user interaction is required (e.g. SCA).

How would you recommend approaching a situation like this with Payment Element?
You can keep only one Element Instance, and once the customer choose the Payment amount, you render the Stripe Element using the related PaymentIntent ClientSecret using the single Payment Element

[sacred smelt]

Otherwise, you should be passing paymentElement15BA5FD030914008B330DB65BB7DE890 to the confirmPayment and not elements15BA5FD030914008B330DB65BB7DE890

[steady yew]

Thanks! I've just tried changing it to pass paymentElement15BA5FD030914008B330DB65BB7DE890 to the confirmPayment instead of elements15BA5FD030914008B330DB65BB7DE890, but that still gives the same error.

However, it sounds like you're saying we can only have one Element instance on a page. From earlier testing, I discovered that each Element instance can only have one Payment Element instance, so I think that means we need to change this page so that it only uses a single instance of each. Is that correct?

[sacred smelt]

However, it sounds like you're saying we can only have one Element instance on a page. From earlier testing, I discovered that each Element instance can only have one Payment Element instance, so I think that means we need to change this page so that it only uses a single instance of each. Is that correct?
Yes, you should be using only one PaymentElement per single page

[steady yew]

Thanks for clarifying that, in my earlier conversation it sounded like we could use more than one (like we do with the Card Element).

Is it possible to somehow reuse a single Payment Element instance with different payment intents? If not, how would you recommend handling our use case (where the user can select different payment amounts from a single page) within a single page?

[sacred smelt]

Thanks! I've just tried changing it to pass paymentElement15BA5FD030914008B330DB65BB7DE890 to the confirmPayment instead of elements15BA5FD030914008B330DB65BB7DE890, but that still gives the same error.
Did you tried to debug the content of the variable paymentElement15BA5FD030914008B330DB65BB7DE890 ?

Thanks for clarifying that, in my earlier conversation it sounded like we could use more than one (like we do with the Card Element).
Yes, you can have multiple Payment Element, but you need to manage well in your code the creating/mounting of each one and not having conflicts between them otherwise you'll be having errors like you are having and you need to debug it.
Is it possible to somehow reuse a single Payment Element instance with different payment intents? If not, how would you recommend handling our use case (where the user can select different payment amounts from a single page) within a single page?
It's possible by creating and mounting a new PaymentElement whenever a client change the price option they are using. Or simply you use a single PaymentIntent, and once the customer changes the amount you update the related PaymentIntent via API and you keep the UI unchange:
https://stripe.com/docs/api/payment_intents/update#update_payment_intent-amount

[steady yew]

OK, I'll try using those approaches instead. Thanks for your help today!

[sacred smelt]

You're welcome!