#honkotonk
vocal tundra
Can you elaborate more on:
but when switching to live the customer gets no payment reservation on his creditcard, so he always gets shown 0 Eur.
storm knoll
Sure
vocal tundra
That seems expected for a Setup Intent, which is often just a $0 authorisation
storm knoll
Its a booking system, where the customer (after doing the booking) enters his creditcard data. The payment consists of two parts. A Down payment and an final payment. Then the setupIntend gets made. Later, when everything for the travel is checked, the vendor can activate the two payments (down and final) separate and manually in the backend and an paymentIntend gets made.
vocal tundra
Ok, and which part in that flow is where you're experiencing what you described here:
but when switching to live the customer gets no payment reservation on his creditcard, so he always gets shown 0 Eur.
storm knoll
Here you can see the customer gets shown 0 Eur when using Google Pay for example.
vocal tundra
Ok, but in which part of the flow is that UI from? The Setup Intent, or a payment?
storm knoll
SetupIntend
The real payment is not to be made instantly, but later by the vendor when everything for the travel ist checked.
vocal tundra
SetupIntend
Then that is expected. A Setup Intent is a zero-amount authorisation. In the authentication flow, which is what that screenshot is, some issues/banks will show the €0 and others won't
We don't in the test authentication flow, but in live environments we (and you) cannot control whats banks display
storm knoll
But the customer needs to get shown the amount he will pay, right?
vocal tundra
Well that's not possible with a Setup Intent as there is no payment at that stage. You're saving/setting up the card for future payments
You could consolidate the saving/setting up of the card into the initial payment as opposed to a separate Setup Intent. That will then make it so that the payment UIs show the true amount: https://stripe.com/docs/payments/save-during-payment
storm knoll
The down payment cannot be done initial. We were told by an stripe member of our onboarding team that this approach is the right one.
vocal tundra
Sure, if you need to collect payment details without a payment then it is the correct approach. But you're unable to control/remove the €0 amount shown in the authentication flow by the bank there I'm afraid
elder magnetBOT
storm knoll
So is it possible to realize the flow i described? Customer enters his payment data, gets shown the full amount, and the two seperate payments are triggered later?
honest lion
Hey! Taking over for my colleague. Let me catch up.
Yes you can collect Customer payment methods following the guide my colleague shared previously with you,
gets shown the full amount
Your integration can show the full amount
Then you trigger two payments.
storm knoll
But not via setupIntents?
honest lion
You can achieve this using multiple ways (using SetupIntents or PaymentIntents). You can collect customer payments details before creating a PaymentIntent, check this guide:
https://stripe.com/docs/payments/accept-a-payment-deferred
storm knoll
That's a completely different setup we are using. We would need to do a complete refactoring for that. The approach we are using was recommended to us.
Is it possible to do a paymentIntents with capture_method manual for collecting payment data, showing the full amount and triggering the two payments later?
honest lion
Is it possible to do a paymentIntents with capture_method manual for collecting payment data, showing the full amount and triggering the two payments later?
You can capture the two payment total amount, and then do the capture for the two payments as one capture.
storm knoll
no idea whats that means. Can we create a paymentIntents with capture_method manual, so the payment is not done initially, and we can trigger the two charges later?
honest lion
Nope. What you can do is to capture only 1 time for the amount of the two payments. Or create two different captures.
storm knoll
What do you mean by capture?
honest lion
Check this guide about using the capture_method: manual with PaymentIntents
https://stripe.com/docs/payments/place-a-hold-on-a-payment-method
storm knoll
i read that about 100 times
honest lion
You first place a hold on the card, then you capture the funds
storm knoll
the problem is we were told to use setupIntents and later trigger the two payments separately, what worked in the Sandbox.
storm knoll
But when using SetupIntents like we do it now, the customer is not getting shown the amout he has to pay but 0 Eur.
storm knoll
But you understand that a customer is getting confused when seeing he has to pay 0 EUR and later someone charges his card twice with a real amount?
honest lion
Unless in your own UI you show them they'll be charged for multiple amounts later after you get the autorisation
honest lion
But you understand that a customer is getting confused when seeing he has to pay...
You can/need explain that to the customer, it's a UX/UI work.
storm knoll
We do, but its still weird. Have you seen the screenshot i posted further up?
honest lion
Yes.
When saving a PaymentMethod without doing a Payment, you ask the customer to just authorize their card without any payment, that's why the 0 amount is displayed.
storm knoll
I don't think we can use that. How can we achieve the flow for the process i described?
Is this a possible approach:
- Create two PaymentIntent with capture_method manual when the customer doeas the booking AT ONCE
- Later and seperatly trigger a PaymentIntent retrieve for each of the PaymentIntent?
honest lion
I think we already discussed all(mostly) the possible options for your use case, but let me summarize them for you:
- Use SetupIntents, save the customer's PaymentMethod and then make the payment attempts
- Use PaymentIntents:
- Create a payment intent with capture manual for the total amount of the two payments and then capture the total amount
- Do a first payment and save the PaymentMethod, then achieve another payment attempt off session
- Collect PaymentMethod before creating an Intent: https://stripe.com/docs/payments/accept-a-payment-deferred
storm knoll
Are these three lines under PaymentIntents alternatives or is it a linear approach?
honest lion
Alternatives
storm knoll
so we need to split the payment like i said, so the first one is not an option. The second one is where the first payment is done right away?
honest lion
The second one is where the first payment is done right away?
You are talking about the second option using PaymentIntents? if so, yes.
storm knoll
Yes. I was talking about this one: "Do a first payment and save the PaymentMethod, then achieve another payment attempt off session"
So first payment right away is like i said not wanted, but the two payments need to be done later seperatly.
honest lion
If you want to do the two payments later you have tow options using SetupIntent or the third option using PaymentIntents
storm knoll
Hmm. That 0 Eur display is a problem for our customers.
honest lion
These are the only options.