wasabi-returnurl

[fierce scaffold]

not sure we have a list directly anywhere, but for the most part you should just always pass one

[fiery cove]

@fierce scaffold so our user is accepting cards payment method type, but is facing issue with redirect set as if_required. They want to not have to redirect their customer to a return_url because that is breaking their order to confirm payment flow. Are there other considerations for cards? Is it based off country of the customer cards, where it's required a return_url?

[fierce scaffold]

I'd try to suggest they fix their implementation to not be broken by a redirect, since it severely limits their ability to take any non-card payments in the future.

in any case I don't think cards ever require a redirect, it's only non-card methods, if that helps!

but lots of methods do require one, off the top of my head, iDEAL/Klarna/SOFORT

[fiery cove]

They are aware of the constraint but they seems to have higher needs for requirements where they want to ensure their order system is call first to confirm items and update the customer balance before they change a customer's payment

[fierce scaffold]

that's not possible when using the PaymentElement

it just won't work, it's not how that component is designed. It's designed to be loaded(with the final, known payment amount and details) when the page loads, then when you hit submit, it processes a payment immediately and redirects to the next page in your flow.

if you want something where you check details first you need something more custom using the individual Elements directly instead but even then, can be tricky.

[fiery cove]

They are also using PayPal and that flow seems to leverage auth and capture, but I'm hesitant to assume/provide that recommendation to them. Do you know if manual capture could work for their use case?

[fierce scaffold]

auth and capture only works for cards

but sure, you can use PaymentElement to authorise an amount and then capture (or refund) afterwards, yes. Works fine. https://stripe.com/docs/payments/capture-later

[fiery cove]

Hmm can you help me understand what you mean by individual elements directly instead?

[fiery cove]

Really? What are the drawback if they want to expand into digital wallets (Google Pay, Apple Pay) in the future?

[fierce scaffold]

https://stripe.com/docs/payments/accept-card-payments for example, using the CardElement in a a custom form instead of the PaymentElement

[fierce scaffold]

those are cards

so no implications. They works just like cards and you can auth-and-capture them.

[fiery cove]

got it so other payment methods: it's referring to iDEAL/Klarna/SOFORT?

in other words: ACH and BNPL

If they are planning to expand into ACH and BNPL, is card element a better fit?

[fierce scaffold]

the Card Element only does card payments so it's not directly relevant there

but other payment methods generally have their own specific types of Element

https://stripe.com/docs/js/elements_object/create_element?type=idealBank etc, and those have separate integrations

but really you should try to use the PaymentElement and Checkout where you can.

sorry, I have to run, I'm in Europe and it's late. The rest of my team is offline for the holiday in the US today, so reach out to https://support.stripe.com/?contact=true if you have any urgent questions!