#jcrivello-paymentintent-banktransfer
grand roost
@thorny pulsar I think you want to log the content of the PaymentIntent and specifically look at the next_action hash to see https://stripe.com/docs/api/payment_intents/object#payment_intent_object-next_action-display_bank_transfer_instructions
jcrivello-paymentintent-banktransfer
thorny pulsar
Thank you. Actually... is there a way to make the Payment Element display the transfer instructions in the Payment Element itself like ACH Credit used to? It just shows this now, and the user has to submit the form in order to get a modal dialog with the payment instructions. It would be perfect it the Payment Element would just show the instructions, the modal dialog doesn't work well in our application.
grand roost
what happens when you call confirmPayment() in this case?
Like I just tried and it shows an iframe with all the details
thorny pulsar
Here is a more complete description of what I am trying to do:
I am creating a PaymentIntent with a ACH Debit and U.S. Bank Transfers as the acceptable payment types. I want to allow the customer to submit payment either way.
If I do this and then create a Payment Element for this PaymentIntent, it will show two tabs for each payment type. However, the way that the U.S. Bank Transfers tab shows up is pretty confusing from a UX standpoint (as pointed out earlier). It would make much more sense from a UX standpoint if that tab just displayed the wire/ACH instructions. This is how it used to work for ACH Credit and it was perfect, I'm not sure why Stripe changed this.
If I could I would modify the Payment Element so it only shows the ACH Debit tab, and then manually show the wire/ACH instructions in another area of our UI, but I don't think it is possible to hide payment types from Payment Elements if the payment type has been included in the PaymentIntent.
grand roost
it's not really true, PaymentElement never supported ACH Credit in the first place right?
The "bank details" to show to your end customers aren't static, they depend on the context and that's part of having them confirm the PaymentIntent to demonstrate they plan to pay via a bank transfer
The way you want to do this is not really how we built our product
thorny pulsar
They are static for the PaymentIntent are they not?
grand roost
well no, they are shared across payments, but not always, like the old ACH CT integration. And they aren't generated until you really plan to use them, there's a real cost attached to creating those "virtual bank accounts" that work at any bank
I think what you're after is more https://stripe.com/docs/payments/customer-balance/funding-instructions instead which is closer to the old ACH CT
thorny pulsar
No, we need it to be tied to a PaymentIntent for the auto-reconciliation capability.
When you say there is a "real cost attached to creating those virtual bank accounts", is that something we pay for or Stripe pays for?
grand roost
I don't know much about pricing so I don't know what it costs you, but it costs us
Ultimately what you're after is just not possible
thorny pulsar
Interesting
grand roost
You either use the FundingInstructions approach which closely mirrors the old way of creating a VBAN for a customer and they can wire money whenever, or you do it per PaymentIntent which happens at confirmation time in which case there's no guarantee around the VBAN not changing over time and such.
But you can't really do both at once, we don't support that model
thorny pulsar
Oh interesting so if we use the PaymentIntent API there is no guarantee that the VBAN will stay the same for a given customer after it has been generated? Even if they have sent a payment with a previously generated VBAN? That is probably a deal breaker, it will confuse our customers way too much.
If we use FundingInstructions then the money just ends up in the customer's balance and we need to manually apply the balance somewhere?
grand roost
that is my understanding, because a lot could happen between now and their next payment 2 years later
https://stripe.com/docs/payments/customer-balance/reconciliation#cash-automatic-reconciliation As far as I know you can
1/ get money
2/ create/confirm a PaymentIntent which pulls from that bucket of money
willow gazelleBOT
thorny pulsar
Are you sure about that?
grand roost
so you don't need "manual reconciliation" per se
thorny pulsar
"After a customer has been allocated a VBAN, it belongs to them forever. Any additional funds that are sent to that VBAN are automatically added to customer’s cash balance. Because VBANs are permanent, it’s important to understand their limits and best practices for using them.
"
grand roost
that's what the docs literally say
By default, Stripe automatically applies any available cash balance to PaymentIntents and invoices that are awaiting funding. A PaymentIntent is awaiting funding if it is incomplete. An invoice is awaiting funding if it is open and has either not exceeded its due date or has become past due within the last thirty days.
thorny pulsar
"There are several ways to allocate a VBAN to a customer.
When you create and confirm a PaymentIntent with the customer balance payment method, Stripe looks for an existing VBAN that is assigned to the customer and for the country specified in the request. If the customer does not have an appropriate VBAN, Stripe generates a new VBAN for the customer."
grand roost
I think right now you need to spend a couple hours trying a few things in Test mode to get a feel for the different integration paths and how to map from what the old way did
I don't know much about this myself, it's brand new for the US and I'm also 99% more familiar with the old way which I preferred too 😦
thorny pulsar
Ok, actually this has been helpful.
I just want to confirm one last thing, it is my understanding that it is impossible to hide a tab in a Payment Element for a particular payment type if that payment type was included in the PaymentIntent. Does that match your understanding?
grand roost
yes that's correct