How to Move from Plaid Sandbox to Production Without Breaking Your App
Updated: Oct 23
A bank connection works in your test environment. Account data appears, the webhook arrives, and the team is ready to launch.
Then a real customer leaves your app to approve access at their bank—and never makes it back. Or the connection succeeds, but transaction data is still loading when your app tells them there is nothing to show.
Moving a Plaid integration from Sandbox to Production deserves more than a credential change. Sandbox proves your core flow can work. Production tests whether that flow can handle real institutions, consent decisions, delayed data, and customers who need help reconnecting later.
In short: Confirm Production access and product eligibility, configure both Link and your backend for Production, remove Sandbox-only code, test OAuth and webhooks, build connection recovery, and release to a small group of real users before opening the feature to everyone.
What Changes Between Plaid Sandbox and Production?
Area | In Sandbox | In Production |
Bank connections | Test institutions and simulated data | Real institutions and customer-authorized data |
Credentials | Sandbox secret | Production secret |
OAuth | Test flows | Institution-specific customer journeys |
Redirects | Local HTTP testing may be possible | Redirect URIs must use HTTPS |
Test helpers | Sandbox users and /sandbox/ endpoints | Remove them from live paths |
Support | Test failures affect the team | Connection failures affect customers |
Sandbox does not reproduce every bank's transaction history, OAuth behavior, or account availability. It is a place to test your implementation, but every live institution can introduce new conditions. Sandbox Items and tokens are test data; plan for customers to create fresh, authorized connections in Production.
Step 1: Decide Which Plaid Products the First Release Needs
Start with the customer workflow, then select the products that support it. Requesting products your first release does not use can complicate consent, account availability, implementation, and billing.
Customer need | Product or workflow to evaluate | Launch question |
Set up a bank account for payments | Plaid Auth | Which payment service will use the verified details? |
Compare account holder information | Plaid Identity | What happens if returned information differs? |
Review financial assets | Plaid Assets or another suitable underwriting product | Does the product fit this specific lending use case? |
Obtain bank-branded PDFs | Plaid Statements | What happens if a statement is unavailable? |
Build a cash flow or budgeting view | Plaid Transactions | How will the app handle data that arrives later? |
Support a Plaid ACH payment journey | Auth plus an appropriate payment service, or another eligible flow | Who moves the money and handles exceptions? |
Move money through Plaid | Plaid Transfer | How will the team track authorization and transfer status? |
Review supported loan and credit accounts | Plaid Liabilities | What will users see when coverage is limited? |
Plaid Auth supplies eligible account information; it does not move money by itself. Plaid Transfer is a separate option for eligible US flows. For new US underwriting projects, check whether Consumer Report is a better fit than Assets before settling the scope.
Step 2: Confirm Production Access Early
Review the Plaid Dashboard and Launch Center for your team's current access and required tasks. Complete the company, application, use-case, and security information relevant to the institutions and products you intend to support.
Do this before committing to a launch date. Some OAuth institutions require completed application and company profiles or security review. Product access and institution registration can also affect which live connections you can test.
Describe the use case in plain language. “We need bank data” gives little context. “Customers connect a bank account so our US lending app can review authorized cash flow data during an application” explains the purpose.
A Plaid implementation partner can help review your product choices and technical readiness.
Step 3: Separate Sandbox and Production Configuration
Inventory every setting that changes with the environment:
Plaid API environment and host
Production secret
Link token creation
Webhook destination
OAuth redirect URI
Product and country settings
Mobile return configuration, where applicable
Logs, alerts, and access permissions
Both the frontend Link flow and server-side API calls must use Production. Keep secrets on the server in controlled configuration, and verify that the deployed app uses the intended values.
Practical release check: Trace one live request from “Connect bank” through Link token creation, Link completion, public-token exchange, and the first product API call. Confirm the environment at each point.
Step 4: Remove Sandbox-Only Behavior
Search the application and deployment configuration for test usernames, fake account responses, hardcoded test institutions, development callbacks, and /sandbox/ endpoints. Check background jobs and support tools as well as the main onboarding flow.
A test helper is easy to miss if the happy path works without it. Ask the engineering team: Would this journey still complete if every Sandbox helper were disabled? Keep Sandbox for future testing, but ensure the live app does not depend on its data or endpoints.
Step 5: Test Plaid Link as a Customer Would
A successful Link callback is only one scenario. Test what a person sees when they complete a connection, exit early, select an ineligible account, decline a permission, lose their session, connect an account again, or return from an OAuth handoff.
The backend should create the Link token and exchange the temporary public token. Store the resulting access token securely on the server and associate it with the correct customer and Item.
Handle exit and event callbacks as well as success. These events can help your product explain what happened and help your team identify where users leave the flow. Keep credentials, access tokens, and unnecessary financial details out of logs.
Step 6: Validate OAuth on Real Devices
OAuth can take a user out of Plaid Link to their bank's website or app and then return them to finish connecting. That return journey is a common place for an otherwise complete integration to fail.
Register the appropriate redirect URI and test it with your Production setup. Production redirect URIs must use HTTPS. The exact web or mobile implementation depends on your platform.
Test what happens if the app is backgrounded, the user cancels at the bank, or local session state changes before they return. The customer should either finish the connection or see a clear way to try again.
Step 7: Treat Webhooks and Data Updates as Production Work
Receiving a webhook in Sandbox does not prove that live processing will withstand repeated deliveries, delayed work, or an unavailable downstream service.
Give the Production endpoint a stable HTTPS address. Process events safely if they arrive more than once, record outcomes, and alert the team when processing repeatedly fails. Configure the appropriate webhook destination for each product and workflow; some settings are supplied during Link token creation, while others are configured at the account level.
If your app uses Plaid Transactions with /transactions/sync, make an initial Sync call for each Item and save its cursor. The SYNC_UPDATES_AVAILABLE webhook begins for that Item only after Sync has been called. Handle added, modified, and removed transactions. While initial data is still being retrieved, show an honest pending state instead of telling users their account has no transactions.
Step 8: Build a Way to Repair Connections
A customer's bank connection may need attention long after onboarding. Credentials can change, consent can expire, and an institution can change its connection method.
Implement Link update mode for relevant Item errors and lifecycle events, including ITEM_LOGIN_REQUIRED, PENDING_DISCONNECT, and PENDING_EXPIRATION where applicable. Show a clear customer message such as: “Your bank connection needs an update. Reconnect to keep your information current.” A raw error code is not a useful next step for a customer.
Step 9: Run a Small Live Pilot
Begin with authorized internal testers and a limited customer group. Include more than one bank and account type where your use case allows it. Watch the complete journey, from opening Link to the first useful result in your app.
Agree on pass criteria before widening access:
Customers can complete Link and return from OAuth.
Token exchange associates the right account with the right user.
Data appears when ready, with a truthful loading state beforehand.
Webhooks are received and processed.
Reconnection works for a testable failure case.
Support staff can investigate without accessing sensitive data.
Monitor connection completion, OAuth returns, webhook errors, data delays, duplicate connections, and support tickets. Know how to pause new connections if a release causes problems while the team investigates existing users' journeys.
Plaid Sandbox-to-Production Launch Checklist
Production access and required products are confirmed.
Launch Center tasks have been reviewed.
Link and backend calls both use Production.
The Production secret is stored securely on the server.
Sandbox users, fake responses, and /sandbox/ calls are absent from live paths.
OAuth redirects and mobile return flows are tested.
Link success, exit, and error journeys are handled.
Webhooks, monitoring, and duplicate-safe processing work.
Initial and ongoing data updates work.
Update mode gives users a clear recovery path.
A small live pilot meets documented acceptance criteria.
Someone owns monitoring and incidents after launch.
How FintegrationFS Can Help
A Plaid developer can make the first connection work. A Production launch also needs product decisions, security review, failure testing, and a team ready to support real users.
FintegrationFS can review an existing implementation, identify Sandbox assumptions still present in live paths, and help test Link, OAuth, webhooks, data updates, and reconnection before a wider release. Explore our Plaid API integration services or talk to a Plaid expert about your launch.
Ready to review your launch plan? Schedule a consultation to discuss your Production migration.
Frequently Asked Questions
1. Can I use my Sandbox secret in Production?
No. Use the Production secret and store it securely on the server.
2. Do Sandbox bank connections move to Production?
No. Customers need fresh, authorized connections in Production.
3. Why does OAuth work in Sandbox but fail live?
Check Production access, institution registration, the HTTPS redirect, and how your app restores the user's session.
4. Why are transactions missing right after Link succeeds?
Initial retrieval can take time. Show a pending state and process updates with the workflow your integration uses.
5. What should we monitor after launch?
Track Link completion, OAuth returns, webhook processing, data freshness, reconnection attempts, and support reports.
