Run the real Plaid Sandbox flow end to end, see why “Plaid” and “Astrada” are two different decisions, and check the integration against a payments-grade security list. No secrets shipped to the browser.
Four steps, each backed by an actual server route using the official plaid Node SDK against sandbox.plaid.com. Every secret-bearing call renders in the dark server lane so you can see the trust boundary.
The server requests a short-lived link_token. Your client_id and secret are attached here, on the server. They never reach the browser.
Plaid Link runs in the browser. The user picks an institution and authenticates. On success Link hands back a one-time public_token. Demo mode simulates Link returning the public_token.
The server swaps the public_token for a long-lived access_token, then seals it (AES-256-GCM) into an opaque token_handle. The browser only ever sees a masked preview and the handle.
The server unseals the handle back into the access token and calls /accounts/get. For ACH, the same token also drives /auth/get (account + routing) and a processor token for Stripe or Dwolla.
The brief names both as if they were one product. They are not. Tell me which outcome you are after and the right integration falls out immediately.
/auth/get returns the account + routing numbers and a processor token feeds Stripe or Dwolla for ACH (or use Plaid Transfer directly). Astrada does not touch bank accounts./auth/get for account + routing; processor tokens to Stripe / Dwolla; or Plaid Transfer for ACH.You asked for a strong grasp of security protocols and industry standards. Here is the working list, with an honest status on each.
client_id and secret are attached on the server route only. Step 1 above shows exactly what the browser receives versus what never leaves the server.
View source or open the network tab. There is no key in the JavaScript and no key in any response body. Every privileged call is a POST to our own route.
The long-lived access_token is sealed with AES-256-GCM before the browser sees a handle, so the client holds opaque ciphertext, never a usable token.
Plaid signs webhooks as a JWT (ES256) in the Plaid-Verification header. Verify the key via /webhook_verification_key/get, check iat freshness, and compare request_body_sha256 in constant time.
Neither integration requires storing raw card numbers. Plaid handles bank credentials; Astrada receives masked card + transaction data from the networks. That keeps PCI scope small. Confirm the exact SAQ with a QSA.
In production each item's access_token is persisted encrypted, keyed by item_id, with key access scoped to the payment service and rotated.
Webhook delivery is at-least-once. Handlers dedupe on event id and are safe to replay, so a settlement update never double-posts.
Store only the fields the product uses, set a retention window, and honor deletion requests. TLS 1.2+ in transit, no tokens written to logs.
※Pills are honest about state. “Live in this build” is verifiable right now on this page. “Coded pattern” is implemented in the source. “Production step” is scoped work for the engagement, not yet wired here.