#localpathcomputing - Plaid with Connect
vocal pollen
And it was working for the exact same connected account prior to that date?
Can you share the account id of the platform and connect account?
rich quarry
Yes. Would you like the prod or staging environment?
vocal tendon
👋 Plaid has always created the Token on your platform. The behaviour has been like that since we supported plaid in 2015
If you want to use the token on a connected account though it should still works
rich quarry
But why did it start breaking with no change on our side?
invalid_request_error
The specified bank account does not belong to you.
Was this useful?
Yes
No
req_mNLavNmTh07QE7
vocal tendon
yeah that's a completely different flow, you'd trying to do Issuing topups and that's a pretty advanced and gated flow. Ultimately that flow never worked (or never should have as far as I am aware). You can't really do that flow without multiple extra steps
do you have an example where it worked?
rich quarry
Yea let me find the last successful one
Plaids request req_J04Wp28tqF84yl
Our server then used the btok_ req_x6s1apTA8Aacvo
We used to do it in staging and dev where we would test by giong through tthe Plaid instant verification over and over and then it just stopped working but the weird thing is the ach_credit_transfer account would still work in dev not ach_debit
vocal tendon
Ah thanks for the example
damn so it does mean we did change something, I'm sorry, I wasn't aware we did.
rich quarry
we'll do the link token for plaid
/**
* @param \App\Models\Organization $organization
* @return string
*/
public function linkTokenCreate(Organization $organization): string
{
$response = Http::withHeaders([
'PLAID-CLIENT-ID' => $this->clientId,
'PLAID-SECRET' => $this->secret,
])->post(config('services.plaid.token_create_url'), [
'user' => [
'client_user_id' => 'u-'.auth()->user()->id.'-org-'.$organization->uuid,
],
'client_name' => 'Deka Wallet',
'products' => ['auth'],
'country_codes' => ['US'],
'language' => 'en',
])->throw()->collect();
return $response['link_token'];
}
then do the public token exchange
/**
* @param string $publicToken
* @return string
*/
public function itemPublicTokenExchange(string $publicToken): string
{
$response = Http::withHeaders([
'PLAID-CLIENT-ID' => $this->clientId,
'PLAID-SECRET' => $this->secret,
])->post(config('services.plaid.token_exchange_url'), [
'public_token' => $publicToken,
])->throw()->collect();
return $response['access_token'];
}
and finally use the resulting btok_ from plaid to create a source from it since it is (presumably) instant verified
/**
* @param string $accessToken
* @param string $accountId
* @return string
*/
public function processorStripeBankAccountTokenCreate(string $accessToken, string $accountId): string
{
$response = Http::withHeaders([
'PLAID-CLIENT-ID' => $this->clientId,
'PLAID-SECRET' => $this->secret,
])->post(config('services.plaid.stripe_bank_connect_url'), [
'access_token' => $accessToken,
'account_id' => $accountId,
])->throw()->collect();
return $response['stripe_bank_account_token'];
}
Ultimately we're unlikely to fix that back as it's been months so you will have to change your code/approach for it to work
rich quarry
/**
* Create a new Stripe Source.
*
* @param string $token
* @param \App\Models\Organization $organization
* @return \Stripe\Source
*/
public function create(string $token, Organization $organization)
{
return Source::create([
'type' => 'ach_debit',
'currency' => 'usd',
'token' => $token,
'owner' => [
'email' => $organization->email,
],
], ['stripe_account' => $organization->stripe_connect_id]);
}
So basically Instant verification of ach_debit is out for connect accounts? (to use as a source for issuing topups)
vocal tendon
It will be really convoluted unfortunately but it boils down to something like this
Before you did this:
1/ Plaid creates a btok_123 on the platform
2/ Create a Source on connected account
Now you do this
1/ Plaid creates a btok_123 on the platform
2/ Attach the bank account to a customer via https://stripe.com/docs/api/customers/create + source: 'btok_123'
3/ Create a new token on the connected account from that previously saved bank account via the "clone payment method" approach
[
'customer' => 'cus_123',
'bank_account' => 'ba_123',
],
[
'stripe_account' => $organization->stripe_connect_id],
]
);```
4/ Create a Source on connected account with that new tokenWe can do it using micro deposit verification using CLI or dashboard and I know theres a native stripe tokenizer for FE
Ok yea I had saw that docs and it was hard to understand if that was the way to do it now
it's definitely doable yea I'll try that
vocal tendon
you don't need any micro-deposit
you "just" need the extra call in your PHP
I didn't know we broke it though that's our fault and I will be flagging it internally I'm sorry
I have seen a few questions about this the past few months but no one mentioned it used to work and I just thought the flow was a bit convoluted (it's a pretty legacy API)
rich quarry
Ahh yea bc it was a newer API when we green fielded
the issuing changed some and we first used the docs and it actually worked NP
This is great. it was a huge pain point for us in understanding not so much implementation
vocal tendon
yeah I'm sorry, I'll be chasing down what changed this behaviour overall and if we can see other impacted platforms
while it works, it's really uncommon to use Plaid for this so you might be the only one doing it this way, but still we shouldn't have caused those errors I'm sorry
rich quarry
ok, see our connect accounts use the issuing api so our app is basically a SaaS for helping them distribute, fund, and manage expenses through issuing, and obviously micro deposit verification is not good UX for them
vocal tendon
yep that makes sense
vocal tendon
I found the change we did so I'm having the eng team investigate. Thanks again for the report
rich quarry
Yes ty