Table of Content:

I. Create plaidLinkToken

II. Submit plaidLinkToken to launch Plaid session

III. Receive plaidPublicToken after the customer completes the Plaid Link flow

IV. Exchange the plaidPublicToken for a plaidAccessToken

V. Submit the plaidAccessToken to process an ACH WEB transaction

VI. Processing Future Payments Using an Existing plaidAccessToken 

I. Create plaidLinkToken

Call the POST/plaid/link/token/create endpoint to generate a plaidLinkToken. 

Note: Because a plaidLinkToken expires after four hours, your application should generally generate a new token each time the customer begins the payment flow. 

II. Submit plaidLinkToken to launch Plaid session

When the customer begins the payment process, pass the plaidLinkToken generated in Step I to Plaid's JavaScript SDK to launch the Plaid Link interface.

To process an ACH WEB transaction using a plaidAccessToken, the general workflow is as follows:

1. Include the Plaid Javascript SDK in your web application:

   <script src="https://cdn.plaid.com/link/v2/stable/link-initialize.js"></script>

   For additional details, please visit: https://plaid.com/docs/link/web/

2. Initialize the Plaid JavaScript SDK using the plaidLinkToken generated in Step I:

   Plaid.create({
       token: plaidLinkToken,
       onSuccess: async (plaidPublicToken) => {
          ...
       }
   }).open();

   At this point, Plaid Link guides the customer through authenticating with their financial institution and authorizing access to the selected bank account.

Simulator:

You can use the Plaid simulator in our Labs environment to test this workflow. Manually enter or paste a plaidLinkToken to launch the Plaid UI and generate a plaidPublicToken

III. Receive plaidPublicToken after the customer completes the Plaid Link flow

After the customer successfully completes the Plaid Link flow, Plaid returns a temporary plaidPublicToken through the onSuccess callback.

IV. Exchange the plaidPublicToken for a plaidAccessToken

Call the POST/plaid/item/public_token/exchange endpoint to exchange the temporary plaidPublicToken for a long-lived plaidAccessToken. 
The plaidAccessToken identifies the customer's linked bank account and is conceptually similar to a PayJunction vaultId. It can be stored and reused for future ACH WEB transactions. 

If you intend to reuse the plaidAccessToken for future transactions, you should also store the associated account details (accountMask, accountType, and bankName) so they can be presented to the customer during future authorizations.

V. Submit the plaidAccessToken to process an ACH WEB transaction

The process described above, authorizes you to immediately process an ACH WEB payment. To complete the workflow simply submit the plaidAccessToken to the POST/transactions endpoint. 

Before processing the transaction, PayJunction performs a balance check through Plaid. If insufficient funds are detected, the transaction is declined with Response Code 51 (Declined Insufficient Funds).

If the transaction is approved, it will settle at the scheduled time for your ACH batch.

VI. Processing Future Payments Using an Existing plaidAccessToken 

The workflow above is sufficient to process the customer's initial Web ACH payment.

However, additional steps are necessary to process future payments. To be compliant with Nacha's rules for Web ACH, it's required to have a "Cardholder Portal" to allow the customer to manage the payment plan. The minimum requirement for this portal depend on the type of payment plan:

Once a plaidAccessToken has been created, the customer does not need to complete the Plaid Link flow again unless they choose to link a different bank account or the existing token becomes invalid. Future payments can be initiated using the stored plaidAccessToken, subject to Nacha's authorization requirements described below.

Regular Schedule (fixed amount):

• The portal needs to be able to authenticate the customer and retain an audit log containing the customer's unique identifier, IP address, and timestamp for each portal login.
• Present the authorization terms and collect an affirmative confirmation (for example, an "I Agree" checkbox).
• The Authorization must clearly identify the amount of each payment.
• The Authorization must display the name of the bank and the last 4 digits of the account.
• The Authorization must clearly identify the frequency and the number of installments.
• The Authorization must be kept for 2 years.
• The portal must allow the linked bank account to be updated.
• The portal must provide access to prior payment receipts for this schedule.
• For "perpetual" plans, the portal must have clear instructions on how to cancel the plan.

Irregular Payment plans (variable amounts and/or dates):

• The portal needs to be able to identify each user and log the metadata (IP Address, timestamp and unique identifier of the user) of each user login. 
• Present the authorization terms and collect an affirmative confirmation (for example, an "I Agree" checkbox).
• The Authorization must display the name of the bank and the last 4 digits of the account.
• The Authorization must be kept for 2 years.
• The portal must allow to update the linked bank account.
• The authorization must explain how the customer will be notified before each payment. 
• The customer must receive advance notice at least 10 calendar days before each debit. The notice must include the payment amount.
• The portal must provide access to prior payment receipts.

Note: This article describes PayJunction's implementation of ACH WEB using Plaid. For information about Plaid Link itself, including supported institutions and the user experience, refer to Plaid's documentation.