#connor_banktransfer-vban

1 messages · Page 1 of 1 (latest)

swift cloakBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1240795657850191902

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

sly lynxBOT
tiny niche
#

connor_banktransfer-vban

worthy shoal
#

Whoa, awesome! I missed that there was dedicated funding instructions API. I knew these virtual bank accounts didn't have a dedicated object like payment methods or other stripe resources, but it's cool that the API also exposes behavioral concepts.

Thank you!

tiny niche
#

yeah this isn't super well documented if you ask me. I gave the feedback a few times

#

But in a way that's the "old way" like if you use ACH Credit Transfer in the past on our API. Nowadays we think it's best to let us render the right VBAN on the PaymentIntent that way you can handle cases where we would want to change the VBAN

worthy shoal
#

You've built an API so strong it trains engineers to think in a "Stripe" way that we sometimes completely fail to think about newer types of behavior and just assume they don't exist. I don't think that's a bad thing though, it's awesome that it's still evolving like this

Thank you very much for the clarification and context there!

tiny niche
#

wow thanks for the kind words 🙂

worthy shoal
#

For sure, I've been telling the team (and anyone who listens) that this is the strongest and best eng experience I've seen. Nothing has come close, y'all are dope

#

Oh sorry, one more thing. Do you have some examples of what goes into a PaymentIntent changing the VBAN? My initial intuition was that it was restricted to PaymentIntent because there might be some configurations or contexts of a PaymentIntent that may require a different VBAN, so it sounds like that still plays a part here as the preferred methodology

tiny niche
#

what goes into a PaymentIntent changing the VBAN?
what I mean is imagine your customer pays you today May 16 so you get a VBAN that ends in 1111 say.
Let's say this Customer doesn't come back for 18 months and now wants to pay you again. There isn't much value having that VBAN "locked" to that Customer for 18 months. But if we did we'd have to reach out, tell you about the change, maybe we move to a new partner or add redundancies or work with other countries, etc.
But if you only look at the VBAN inside the next_action then we don't have to re-use the same one 18 months later.

#

I'm not saying we do that today, as far as I know the VBAN is "assigned" to that Customer under the hood whether you do FundingInstructions or not, but we could, we have sometimes changed partners or expanded. Like in Europe all our VBANs were in one country which was costly for customers in other countries and as we expand we want to be able to provide new VBANs

worthy shoal
#

Perfect, thanks. Even in the PaymentIntent world, we were a bit worried our customers might write down the account and routing info once and then just assume they could use it moving forward. With this additional context, we should prompt them to check the specific purchase as the account is subject to change

tiny niche
#

yeah we'd like do something like "if that VBAN was not used for 18 months" logic or something. But it's tough because of what you said.
Sometimes Customers will pay you $100 for example. And then in a month they pay another merhcant but they think the VBAN is the same so they wire money into the VBAN you used. It can be messy 😅

worthy shoal
#

Haha yup! Wire is our toughest case because it can't be fully contained within Stripe/our service, so there is only so much we can do to prevent user error. We're learning a lot about proper, visible messaging

tiny niche
#

🙂

worthy shoal
#

I spoke too soon, have a few more follow-ups on our end:

  • How long is a PaymentIntent good for? What if I book a trip for 12 (or even 18) months out? If I create a PI at booking time, is the VBA associated with that PI not guaranteed to be valid if they actually pay 2 days before the trip?
  • What happens if a customer wires to an account that they have 'saved on file' with their bank after a potential change of VBA and it's the old VBA? What happens to those funds?
  • Would we receive a notification if the VBA associated with a PI was no longer going to be valid?
  • Would we receive a notification if the VBA associated with a Customer was no longer going to be valid
#

It sounds like for now we can count on a consistent VBA being available, but with our long purchase cycle we will want to build in some protections for long term changes

tiny niche
#

How long is a PaymentIntent good for? What if I book a trip for 12 (or even 18) months out? If I create a PI at booking time, is the VBA associated with that PI not guaranteed to be valid if they actually pay 2 days before the trip?
We don't cancel those but I think creating this 18 months in advance is abnormal. I'd recommend having a firmer plan to only ask them to wire the money when ready to pay and also giving the a deadline.

What happens if a customer wires to an account that they have 'saved on file' with their bank after a potential change of VBA and it's the old VBA? What happens to those funds?
Today we know it's for you and this Customer and the money would move in their CashBalance. Overall we'd know/investigate those funds and in some cases we'd return them back to them potentially (say if it was 5 years later).
Would we receive a notification if the VBA associated with a PI was no longer going to be valid?
We haven't really built this yet. I assume we'd reach out to you or transition the PI back to requires_payment_method but it's back to the point at the first question: don't keep PIs opened for 18 months I'd say
Would we receive a notification if the VBA associated with a Customer was no longer going to be valid
If you use FundingInstructions then it shouldn't happen and if it did we would email you yes

worthy shoal
#

Cool cool, that long purchase window has been a concern of ours as well since there doesn't seem to be a firm definition of how long a PaymentIntent should last (not that it needs one because it's so contextually variable, but sometimes it's good to have best practices to fall back on to know if we're doing something sane or not)

tiny niche
#

it should work, but if I were you I would approach it differently, or use FundingInstructions because you really mean "here's your VBAN, send me money whenever" to your customer

worthy shoal
#

And the implication there is that once we establish a VBA through funding instructions we can generally trust it as an always active account that's one-to-one with a specific customer?

tiny niche
#

yes and if this were to change we would tell you

worthy shoal
#

Perfect, thanks again!

tiny niche
#

sure thing! And if you have follow up questions feel free to come back and ask, my team is here to help!

worthy shoal
#

Right on, have a great rest of the day!