#huncsuga_best-practices

1 messages · Page 1 of 1 (latest)

daring graniteBOT
#

👋 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/1417232957319413841

📝 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.

left spire
#

Hello
The recommended flow here is to use Confirmation Token + Payment Element.
Card Element is considered legacy and isn't going to receive any future updates.

Is there a particular reason why you're opting to go with the Card Element for your new integration?

civic lily
#

The main reason I’m not going with the Payment Element is that I don’t want to use its pre-built layouts such as the tabs or accordion UI. I’d like to have full control over the placement and styling of the inputs so they can match the rest of my checkout form. From what I’ve seen, this level of customization is only possible with the individual Card Elements, which is why I’ve chosen that approach for my integration.

left spire
#

Gotcha. You can disable the other payment methods which then turns Payment Element into a similar UI as Card Element

daring graniteBOT
civic lily
#

Got it, thanks a lot for the quick response.
Just to be sure — is there a way to fully customize the input fields individually (like number, expiry, cvc), or at least modify the layout itself beyond just disabling the extra payment methods? My main concern is keeping full control over how the fields are arranged to match the design of my checkout flow.

ruby gorge
#

Unfortunately I don't think the payment element is that customizable. We have an appearance API that lets you customize things like shapes and colors, but I'm not seeing a way to adjust how the fields are actually laid out. https://docs.stripe.com/elements/appearance-api

#

If you are going to go forward on the card element, the way I would instead reccommend doing that flow is to create a PaymentMethod on step 1 and then create/confirm the payment method with it on your summary page. If you create a SetupIntent and then a PaymentIntent, it is possible for 3DS to be requested twice which can be frustrating to users.

civic lily
#

  1. If I go with the Payment Element + Appearance API approach, what happens if the user navigates back in the flow? Will the card details entered in the element be lost, or is there any way to repopulate them (e.g. using a previously created token)?

  2. If I stick with the original idea (creating a PaymentMethod on the Details step and confirming it with a PaymentIntent on the Summary step), is there still a chance that the bank sends a $0–$1 authorization upfront — even before the actual Summary step where I confirm the payment?

ruby gorge
#
  1. For both flows the card details will be blank in the element. The best workaround I can immediately think of would be to get the last 4 digits from the ConfirmationToken/PaymentMethod and then have something display in your own UI that indicates that that card will be used if they go forward without adding new details.
  2. Yes the SetupIntent can do a $0 auth, that is what can trigger 3DS at that step. That said, even if this passes it would still be possible for the actual payment step to get a decline. Is there something specific you are trying to achieve at that point that is making you want to use an intent over creating a token/paymentmethod?
civic lily
#

Thanks a lot for the helpful answer. The main reason I was leaning toward Card Elements is because I felt the Payment Element layout limits my flexibility when customizing the design.

One more question: in the future, I’d like to allow users to save their card so that on later purchases they don’t need to re-enter the details, but can simply pick a stored card. Is this feature possible to implement with both the Payment Element and the Card Elements flow, or is one approach better suited for this use case?

ruby gorge
#

Yep, both support that flow, and the Payment Element actually has built in functionality for re-displaying saved payment methods. Finding the docs on this

#

So the main thing to do is set setup_future_usage while creating the payment intent, that will tell Stripe to save the payment method to the customer for later use (an optimize it for on session or off session charges depending on what you pass to that param). That setting will work for both card and payment element:
https://docs.stripe.com/payments/save-during-payment#create-the-paymentintent
Getting PMs to redisplay in the payment element requires you to create something called a CustomerSession as well, this doc section speaks to that:
https://docs.stripe.com/payments/save-during-payment#save-payment-methods

civic lily
#

Thank you very much for your help. I think I have received answers to all my questions.