#bankorh-capture
shut torrent
Hi there, when you mention uncaptured payments, are your referring to payments that are authorised but has not been charged yet?
hard robin
Yes. In frontend we create the payment method for a payment intent and request backend to capture
Just wonder what will happen if capturing failed, e.g. during front end failed to call our backend
shut torrent
Thank you for the clarification.
I was wondering if you could provide more information about your use case please?
I was to recommend having PaymentIntent auto-confirm when the PaymentMethod is provided and payment created on the client https://stripe.com/docs/api/payment_intents/create#create_payment_intent-confirm
hard robin
Understand that auto confirm is recommended. But for our use case, after the payment method is attached to the payment intent, we want to inform our backend to update the application fee and capture.
We are updating the application fee based on the payment method used.
Out development so far for this is fine, we able to collect the payment with correct application fee. just that we can't confirm what happened to those uncaptured payments.
Oh, forgot to mention that we are doing this for the connected account .
shut torrent
Thank you very much for sharing your use case.
In this case, I would suggest the use of SetupIntent [0], where PaymentMethod can be attached to the Customer for future use.
After your Customer has a PaymentMethod attached, you can use this PaymentMethod to create a PaymentIntent and adjust the amount to pay.
hard robin
We tried this too, but it seems not for our use case as it requires to create customer first. We are only doing one time charge.
Once our users provide their card details, we charge immediately. And the flow ends.
shut torrent
Thank you for the information, just wanted to confirm for your use case, with reference to https://stripe.com/docs/payments/capture-later
e.g. for an $8 item, you are first authorising and capturing $10, after working out the correct application fee, for say $0.80, then capture the amount of $8+0.80=$8.8 from the card (as $8.8 is less than the authorised amount, this is successful).
Your concern is, what happens if the client and server lost connection, i.e. the customer entered card details, but the call to server was unsuccessful therefore the payment has not been successful?
hard robin
For our use case, let's say our platform asks $10 for the payment (using on_behalf_of and transfer_data.destination to same connected account), next, user enters the card details, and call our server to capture.
Before capturing, we check the "source" of that payment intent, let's say card, we can get the issued country and brand, then we decide the fee based on those and capture with different application fee.
User is still paying $10, but the connected account will have to pay different application fees to our platform.
I meant the net amount the connected account received is vary on the payment method the customer use.
ebon fox
makes sense @hard robin What's the question exactly?
I think also you're confused by "confirm" and "capture", they mean entirely different things
hard robin
Oh? What's the different?
ebon fox
confirm is about when the authorisation is attempted (when we try to charge the card)— by default it happens on the client side when you confirm the PaymentIntent with confirmCardPayment etc. With confirmation_method=manual it happens on your server.
capture is about holding funds on the card after that authorisation happens, instead of moving the funds into your Stripe account immediately. It works with either mode and isn't really related.
hard robin
So if we set confirmation method to manual, we will need to capture at backend too, right?