#sricar_element-paymentmethod

1 messages ¡ Page 1 of 1 (latest)

severe turretBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1291431731617988649

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

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.

hexed thicket
#

Previously, with the card element, we would gather all the payment method and customer details on the client side, and submit those to the server to create the payment intent.

The customer had the option to include a dynamic donation amount, so we
wouldn't create a payment intent first. Before creating the intent on the server-side, we used to get payment method details to calculate an application fee based on payment method and amount.

We would also create a customer from that payment method and use that to create and confirm the payment intent.

#

We are looking at the recommended approach for setting a donation with bacs direct debit. We've gone through and created a payment intent first on the server side (with just default amount since we don't know the amount the customer wants to donate yet) to render it.

We're looking to update the payment intent with the correct amount, the application fee based on payment method type, and ideally the Stripe customer information before confirming it.

paper junco
hexed thicket
#

I can include some code snippets of what we used to do, and what we're trying to do currently.

paper junco
#

sricar09_element-paymentmethod

#

sricar_element-paymentmethod

hexed thicket
#

We wouldn't use this flow since we aren't able to do that with bacs. Isn't that so?

#

Since we need to create a mandate

paper junco
#

Have you tried? I'm not aware of BACS not working for this flow

hexed thicket
#

We wouldn't have a customer id yet to create a customer session. Previously, we would have information once they've submitted the form. Then we could create the customer for the payment method, and create/confirm the payment intent.

We've been told previously here (https://discord.com/channels/841573134531821608/1290692315593048158) that we aren't able to create and confirm a bacs payment intent all in one request on the server side because of the mandate creation. If we follow the recommend approach, for our use-case, we would still need to update the payment intent with an application fee amount and the valid amount. If we aren't able to create a customer for the payment intent, what would you all recommend?

paper junco
#

Sorry you're rushing a bit through things and mixing up multiple concepts

#

There's no need for a CustomerSession and that doc doesn't require one

#

1/ Render PaymentElement without a client_secret
2/ Create a ConfirmationToken (includes all the Mandate information)
3/ Server-side: create and confirm the PaymentIntent with the right application_fee_amount based on the payment method used in the ConfirmationToken
4/ Client-side: complete any next action such as 3DS if one is needed.

hexed thicket
#

Ok, I was referencing customer session from that doc you shared. We haven't tried that.

When we tried the suggested approach, we weren't able to pass ConfirmationToken without also passing the confirm: true option for the PaymentIntent. When we included confirm: true , it wasn't creating the needed mandate. We'll try it again and provide a snippet to show the error if we see that again.

paper junco
#

Yeah the ConfirmationToken will have the Mandate information. You might have used the PaymentMethod before.
Once you have a failed request, give me the req_12345 and I can look and help you debug

hexed thicket
#

So far, we weren't able to recreate the issue we encountered yesterday with confirm: true. It's looking like I can see the payment method preview information from the confirmation token, and it passes through to setup the payment intent with the mandate. Is there any way you would recommend we create a customer while doing this? Is that option available?

paper junco
#

Why are you trying to create a Customer? What's the logic you are trying to solve?

hexed thicket
#

In our current integration, we create a customer for the given payment method. Passing in customer_id to the payment intents. The use case is the customer may set up a subscription during this process and could then go back and pull up their payment method and edit it. It sounds like we may need to create a customer after this is submitted?

paper junco
#

That's really up to you. You can create the Customer and then the PaymentIntent in that flow right?