I want to preface this by saying that we are not sharing any private information that is unique to our relationship with Plaid and we know that you are not asking for that. This is all publicly available information from their website and public communications. We would obviously respect the same protections of any private information we might gather with MX.
I hope the following answers your questions sufficiently.
1. Does plaid enforce single active tokens or allow duplicate tokens for the same account ?
It is possible for merchants to create multiple Plaid Access Tokens for the same bank account that are active. Plaid has a page on their website dedicated to "Preventing Duplicate Items" because this results in additional unnecessary billing and potential confusion for their merchants.
However, they say "for Chase and Charles Schwab, existing Items will be invalidated if an end user adds a second Item using the same credentials".
2. How does plaid’s client and processor integration work?
Client activates a "Processor" in the Plaid dashboard
Client privately requests a "link_token" (a basic auth token to start a user session)
Upon successful user authentication to their bank, plaid returns a "public_token" to the client (typically to the user's browser)
The client pushes the public_token to their server and then exchanges the public_token for a permanent "access_token".
The client can then use the "access_token" to pull bank account information themselves and/or they can create a permanent "processor_token" and send that to the processor to initiate a payment.
The Processor can then use the "processor_token" to retrieve bank account information
We provide our customers and partners with much more detailed and elaborate explanation of this process including code samples at
A Plaid “access_token” and subsequent "processor_token" does not expire according to Plaid.
An “access_token” can be revoked by the Client which will cause all attempts to pull information from the "access_token" and the related "processor_token" to fail.
An “access_token” can also be rotated out for a new “access_token” which will invalidate the old “access_token” and any related “processor_token” to the old “access_token”
If the underlying bank account is closed, the request will return no information about the bank account.
endpoint can be used to retrieve a list of accounts associated with any linked Item. Plaid will only return active bank accounts — that is, accounts that are not closed and are capable of carrying a balance.
For certain banks employing OAuth, the API will instruct the client that their user must re-authenticate access to the bank account information
The link_token and public_tokens do have short expirations periods, but the access_token and process_tokens do not.
4. How does plaid provide token management- is that at the processor level or client level?
Token (access_token) management is only available at the client level.
5. Does plaid support multiple processors for one client ?
Yes. Multiple processors can be enabled in the client dashboard and processor tokens can be created for each enabled "processor."
This allows, for example, the same customer “access_token” to be used in a wealth management app and a payment app.
Please do include if there is a preferred approach from ACHQ’s perspective
As you know, in addition to open-banking data access, tokens represent a "safe" alternative for merchants to storing live bank accounts in their software.
When merchants are creating payments with a token, they typically want to use the same Token every time time they create a new payment from the same customer/same bank account - just like they would do if they were storing and sending us the customer's routing and bank account each time.
With Plaid, the “processor_token” is the permanent representation of that bank account that the merchant can store in their software and reuse for each subsequent, authorized payment.
In our opinion (since you are asking), The MX "authorization_code" introduces a level of complexity to the merchant/processor payment process that is unnecessary and extensive to work around.
The current (abbreviated) MX token process looks like this for the MX Client and the MX Processor:
Client: Get customer's bank authentication
Client: Create authorization_code for processor
Client: Send authorization_code to processor
Processor: Resolve authorization_code to access_token
Processor: Use access_token to get bank account information
The processor “access_token” is a permanent token (for now I know). For future recurring or additional payments from this customer/bank account, this process implies that either the MX Client needs to send a new “authorization_code” for each new payment resulting in multiple access_tokens - or more practically - the MX Client and Processor need to establish a permanent token between each other that can be used for future payments from the same bank account.
When we - by necessity - have to insert the latter concept into the payment process between the MX Client and the Processor, it looks like this:
Client: Get customer's bank authentication
Client: Create authorization_code for processor
Client: Send authorization_code to processor
Processor: Resolve authorization_code to access_token
Processor: Use access_token to get bank account information
Processor: Returns permanent Token to Client
Client: Client sends payment to Processor using the permanent token
Our payments API accepts a bank account or a Token representing a bank account to create a payment. So to make tokenized payments possible for MX merchants, we have to create a separate API for the MX merchants to send us their “authorization_code” so we can resolve that to a permanent MX processor “access_token.” Then we need to return a permanent token back to the MX client that they can use when creating payments for that customer/bank account OR we need to document the requirement to send a different "token" (account_guid) for subsequent payment API requests.
Since the “access_token” is a permanent token and it is only resolvable in the hands of an MX processor like ACHQ, we could choose to return the “access_token” to the MX Client and they can then use that as the permanent Token for that bank account in future payments.
But at that point, the (authorization_code to access_token) process includes an extra stop at ACHQ to complete - which in my opinion - is redundant and unnecessary.
As alluded to above, we can also have the MX Client send the "account_guid" as the permanent Token for additional payments, but this still leaves the MX Client and Processor locked in an extended 7-step process. It doesn't really change the steps involved. It just means we either return the "account_guid" as the permanent token or else tell the merchant to assume the account_guid is the permanent token.
You can eliminate steps #2, #3, #4 and #6 above by letting the MX Client generate a processor “access_token” on their own - the process would like like this:
Client: Get customer's bank authentication
Client: Create processor access_token
Client: Client sends payment to Processor using the permanent token and stores token for future payments
Processor: Processor resolves access_token to bank account information and processes payment
This solves many of complexities inherent in the 7-step process and you lose nothing in the form of authorization from the Client to the Processor. If the MX Client generates and then sends a processor “access_token” to the processor - that is their authorization for the processor to pull that bank account information on their behalf. Inserting an “authorization_code” process between that simply becomes a redundant step that makes the process much more complex.
I understand that the “authorization_code” being short lived allowed the desired processor to be the only one with granted authorized access to that bank account. A potential work-around for that would be requiring a “processorID” or (similar guid identifier tied to the “processor”)in the request to generate the processor “access_token”. MX can assign the processorID to the processor and make it the processor's responsibility to communicate that unique processorID to their MX merchant clients.
There may be some other considerations in the “authorization_code” to “access_token” process I haven't considered, but if those are negligible considerations - I think MX would be better served allowing their merchants to create, store and send and MX processor access_tokens rather than involving the processor in that process.
We appreciate being involved in the discussion and look forward to continued collaboration with the MX team.
Want to print your doc? This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
