#l0rdandbooz_api

1 messages · Page 1 of 1 (latest)

hearty pendantBOT
#

👋 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/1344169600174133361

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

lofty hound
#

Hi! Do you have an object ID I can look at?

limpid cypress
#

Which object are you wanting to look at? Payment method or something else?

#

here is a payment method one pm_1QoI4vQ6PD4queU4AJxDPLzy

hearty pendantBOT
static basin
#

Hi there, yes we only surface the last4 of the us bank account, but that PaymentMethod should be resusable on any future transaction. Could you clarify why/what do you need in your use case?

limpid cypress
#

This isn't for a stripe payments type integration. I'm sorry I should have specified that. It is for debiting and crediting of a bank account. I want to use Stripe's financial connections tool to verify ownership rather than something long and cumbersome like microdeposits.

static basin
#

After you verified the ownership by SetupIntent like you did, you still have the original bank account number and routing you received from them, right?

limpid cypress
#

correct, essentially I have the user input the full bank and routing number, and then I want to compare based on what financial connections returns after user signs in and verifies ownership through that (though really I'm open to changing this flow)

The problem is I only receive back the last 4 and full routing

Is there some other way I should be handling this or do you think that'd be sufficient?

static basin
#

No I think that (the last4) should be sufficient, as long as you are looking at the same SetupIntent Id

limpid cypress
#

And by same setup intent id you just mean the same verification session? My worry is I'll have a user misinput one of the preceding digits and we won't be able to compare those so we'll debit the incorrect acccount.

This money transmission will be independent of stripe. I am using stripe to verify ownership before we debit and credit these accounts. I am trying to verify they have ownership of the account they manually inputted.

Basically: user inputs account -> stripe financial connection session lets them sign into that account -> stripe financial connections returns last 4 and routing

which we compare and then from there consider it to be verified or not

static basin
#

I mean the same SetupIntent Id seti_1QoI4KQ6PD4queU4DNlNkiS1.
If you customer misinput anything, what you received and what Stripe API returns to you still be the same (that they key-in). Or are you letting your customer input separately from the data you have?

limpid cypress
static basin
#

Basically: user inputs account -> stripe financial connection session lets them sign into that account -> stripe financial connections returns last 4 and routing
The same data should be returned here. There is only 1 input from the user

limpid cypress
static basin
#

-user selects an account
This is on the Stripe UI, correct?

limpid cypress
static basin
#

Can it have multiple choices?

#

(Or have you seen it has multiple choices?)

limpid cypress
# static basin (Or have you seen it has multiple choices?)

yes. They can choose any bank from the financial connections screen but if it is different then the routing number will fail

example: user is trying to link a chase account but picks wells fargo FAIL

example: User is trying to link a chase account and picks a chase account with same last 4 of the maually entered input PASS

the second example would in theory pass even if the digits before the last 4 were incorrect. This is where my worry stems from and why it'd be nice if there was a way to get full account and routing number from stripe, or maybe i'm just being paranoid and this is sufficient

static basin
#

Where does this checking logic FAIL or PASS here belong to? Your application or Stripe?

#

Overall I think this should be sufficient

#

It's the confirmation step presented to the user, and they picked the bank account

limpid cypress
#

my application is where we'd be doing the comparisons. client and serverside to ensure no shenanigans.

Stripe's payment method would of course be fully verified but the manually inputted stuff is what I'm wondering on

#

is there any way to get the full account and routing number from stripe's verification?

static basin
#

Yeah I see what you mean. And no unfortunately the current revealed info is all we have. Exposing the whole account number has some other security concern too

limpid cypress
#

Do you think what I’m doing right now is sufficient?

#

Are there any sort of private permissions that may be available? We are an atypical customer in that we use issuing and treasury as well

static basin
limpid cypress
#

correct.

#

I switched it a little to where it no longer contains the routing number and account number in the POST body as it was causing some issues with stripe but it still originates from the same spot

static basin
#

Yep so how about store a mapping of the full acount number + routing here, with the pm_xxx returned from the response?

limpid cypress
#

Would you mind expanding a little on what you mean?

Unfortunately even if you pass those details into the setup intent it lets you switch to whatever bank you want whose details are then returned rather than what you started with

static basin
#

Was req_UtJz0PntetiEKB triggered by this step?

-user selects an account

limpid cypress
#

No that req is part of the setup to open the financial connection modal and allow them to select it

#

So it occurs before the modal is able to be opened

#

But after the manual entry

static basin
#

Okie, but in its response you have pm_1QoI4KQ6PD4queU4gtYR58lc, right? Can you call a Retrieve Payment Payment API with this Id, and look at its us_bank_account ?

#

Please paste the result here

limpid cypress
#

Yeah give me a sec

#

{
"id": "pm_1QoI4KQ6PD4queU4gtYR58lc",
"object": "payment_method",
"allow_redisplay": "unspecified",
"billing_details": {
"address": {
"city": null,
"country": null,
"line1": null,
"line2": null,
"postal_code": null,
"state": null
},
"email": null,
"name": "devote 2",
"phone": null
},
"created": 1738559976,
"customer": null,
"livemode": false,
"metadata": {},
"type": "us_bank_account",
"us_bank_account": {
"account_holder_type": "company",
"account_type": "checking",
"bank_name": "STRIPE TEST BANK",
"financial_connections_account": null,
"fingerprint": "PSsrK0Tjlr4yE4ob",
"last4": "1116",
"networks": {
"preferred": "ach",
"supported": [
"ach"
]
},
"routing_number": "110000000",
"status_details": {}
}
}%

static basin
#

Awesome

#

So let's do this: store a map from (full account number + routing) to the fingerprint here (PSsrK0Tjlr4yE4ob)

#

Then when you perform the check later on, take the user selected pm, do a same Retrieve API and get its fingerprint, then compare with this stored value

#

It match, you know that's the exact same full account number + routing

limpid cypress
#

wait ok. So does the fingerprint change based on whats stored within the payment method???

static basin
#

Yes, it should be based on full account number + routing

#

(Please test )

limpid cypress
#

yes of course. If true this would be incredible though. Thank you bro

#

and that is only based on full account and routing number? no other values?

static basin
limpid cypress
#

holy crap. ok I will check but even still this is a new line to check out

#

appreciate you dude. Seriously.