#newtreyes
faint condor
Hi, @sacred wind
faint condor
Yes
sacred wind
it's not really necessary to create the PaymentMethod ahead of time
you can directly jump in to creating the PaymentIntent and while confirming the Payment it will create the PM for you
faint condor
We need to because we need to calculate the application fee based on the payment method information
sacred wind
sacred wind
We need to because we need to calculate the application fee based on the payment...
oh yeah in that case you're right
faint condor
🙂
sacred wind
double checking on this
give me a few minutes
don't hesitate to ping me back if you feel I'm gone for a long time
are you using paymentMethodCreation: 'manual' when creating the Payment Element?
faint condor
Hi, @round skiff @feral grove
feral grove
Hey there, yes this looks correct for what you're describing
You might need to provide the mandate parameter manually when confirming this i think
But since you're active here a lot we're actually seeking developer to integrate a new beta to make this easier
Would you be interested in trying that?
feral grove
Can you share an object ID like a PM or a PI from your account? Then i can have somebody reach out to you at the email on your account
faint condor
Yes
Give me a minute
Here's one that I just created: pm_1O0lEPIJwkxnVmNViHz5h7gp
Having said this, should I use confirmUsBankAccountSetup? Or what else should I use?
feral grove
The problem you're trying to solve for is adjusting your platform fees, right?
I want ot make sure I understand here, because there's a slight mismatch
faint condor
Yes
feral grove
You're describing confirming "setup" which is for setup intents (non payment), so what do you mean by application fee in that context?
faint condor
Two things
One is that when we show the payment element sometimes we don't have a defined amount so we can't create a payment intent
The other thing is that we also want to be able to adjust the application fee based on the payment method information
feral grove
One is that when we show the payment element sometimes we don't have a defined amount so we can't create a payment intent
Is that because you don't know the amount yet but will soon, or because no payment is going to be collected at this time?
The deferred intent flow can help solve for the first case, letting you create the intent later in the flow
The other thing is that we also want to be able to adjust the application fee based on the payment method information
This sounds like you are ultimately collecting a payment
faint condor
Is that because you don't know the amount yet but will soon,
Correct. The image I am sensing you shows you a field where the user is able to enter the amount (Ex. for donations). So, when the payment element is displayed we still don't have the amount defined but we will have it soon.
This sounds like you are ultimately collecting a payment
Correct again 🙂
(side note: Is there a way to avoid requesting the full name when the entering a US Bank account? We are already requesting for the first name and last name on our side)
feral grove
(side note: Is there a way to avoid requesting the full name when the entering a...
Yes, you can suppress that if you have it, which means you need to provide it when confirming via billingDetails
https://stripe.com/docs/js/elements_object/create_payment_element#payment_element_create-options-fields-billingDetails-name
faint condor
What if we don't have it when showing the payment element but soon afterwards?
feral grove
> Is that because you don't know the amount yet but will soon,
Correct. The imag...
Right, so in this case it sounds like you could use the client-side amount to control the payment element behaviour and update it as the user adjusts that, then only create the PI for the final amount when they click the pay/donate button following the deferred flow linked earlier
You only need to create the payment method (or use the beta i referenced) if you want to confirm on your server
If you flow works to confirm client side, those parts arent needed
Note that you can get the currently selected payment method type from the payment element change event to track for fees etc
faint condor
You only need to create the payment method (or use the beta i referenced) if you want to confirm on your server
We want to do that so that we can define the application fee before creating / capturing the payment intent
feral grove
If you want to strictly enforce this server side (or need more details than just the type), that's up to you, and the beta i noted is a good option
faint condor
We need the payment method information to be able to define the payment intent application fee
I may be missing something here so let me recap just to confirm:
When we display the payment element, there are 2 data elements we don't have:
- the amount
- the application fee amount
In the amount case, we thought it was not possible to create the payment intent with a 0 amount and update it before capturing. Is that possible and we have the wrong assumption?
In the application fee amount case, since we need to payment method information in order to define it, we thought it would be required for us to first capture the payment method (which requires the payment element to be shown and because of 1, we have to create it without a payment intent) so that we can calculate it.
Please let me know if I am missing something silly
Right, so in this case it sounds like you could use the client-side amount to control the payment element behaviour and update it as the user adjusts that, then only create the PI for the final amount when they click the pay/donate button following the deferred flow linked earlier
This is what we do today. We only create the payment intent when the user clicks the pay/donate button
You only need to create the payment method (or use the beta i referenced) if you want to confirm on your server
We need to create the payment method because we need to calculate the application fee on the server side.
Note that you can get the currently selected payment method type from the payment element change event to track for fees etc
Yes, we are doing that too.
Does that make sense?
feral grove
It does, but i want to dig into the amount issue, since I'm not sure where the issue is for you
feral grove
In the amount case, we thought it was not possible to create the payment intent ...
Here you wouldn't create the PI until the user clicks the button, so you should know the amount then right?
faint condor
Oh, the amount has no issue right now. It works without a problem since we create the the PI after the user clicks the button
Our issue is just the fact that we can't use us_bank_account payment methods to confirm the payment intent because of the mandate
and we are not sure how to set the mandate data under this flow
does that make sense?
feral grove
Got it, and that's because you create the payment method and set it to your server to create/confirm the PI server side?
feral grove
Right, so, a couple options:
1/ Instead of creating the PM and sending to server, you instead request the PI from your server for the final amount and application_fee_amount based on the selected type then confirm client-side with confirmPayment -- this obviates the need for handling mandates either manually or using the beta
2/ With the existing flow, you'd need to provide a valid mandate structure in the PI create/confirm call, this is somewhat painful, but not awful
https://stripe.com/docs/api/payment_intents/create#create_payment_intent-mandate_data-customer_acceptance
3/ With the beta i mentioned, you create a new type of token analogous to the createPaymentMethod which contains PM details and mandate info, and provide that when creating/confirming the PI on your server and it handles the mandate for you
feral grove
actually, aren't customers accepting the mandate because of this?
They are, but it's not transported server side for you, unless using this new beta
So you need to specify their acceptance of those terms in mandate_data
faint condor
Instead of creating the PM and sending to server, you instead request the PI from your server for the final amount and application_fee_amount based on the selected type
The calculation requires more information than just the type :/
feral grove
Got it - then really you need the PM server side, or this new beta
If 1/ is not viable
I'm chatting with the person running that now, give me a few minutes to sort out outreach
feral grove
You can use that today without any beta access, but the new tokens in the beta will carry that for you
faint condor
With that, i can get this sorted out. But I will test the beta to help the team
I have the time and will be glad to give something back to the stripe team
feral grove
Thank you ❤️
faint condor
Thank you all
@feral grove I am seeing something strange on the client side. According to the documentation, the change event should contain the payment method type in its value attribute. Nevertheless, this is what I am seeing on the browser. I think this was working previously but now I see it broken. Has something changed in the stripe JS library? Or am I missing something silly?
feral grove
It's just event.value is the type, not value.type
Is r***@n***.u** the right email to contact you?
(owner of the account)
Assuming so, you should now have an email waiting for you 🙂
faint condor
Yes, that's my email
event.value returns undefined
in order to get the right information I had to parse event.data and then traverse it
feral grove
That seems odd 🤔
steep raftBOT
faint condor
now, event.value is not the type but an object containing the type
It does work as expected using event.value.type
@feral grove Received the email. Will work on that next week 🙂
feral grove
Ah, ok great. What was going on with the browser before and that parsing?>
faint condor
I am not sure. For some reason, the console was not seeing the right information for the event object. I guess it's an issue with the browser console since the log shows the right information without a problem.