The Architecture Guide: How to Build a US Fintech App Using Plaid, Stripe, Unit, and Alloy Together
Updated: Oct 7
AI Summary: US Fintech App Architecture combines bank connectivity, payment processing, embedded banking, and identity decisioning. Plaid connects external accounts, Stripe handles supported payment acceptance, Unit enables banking services through bank partners, and Alloy orchestrates identity and risk workflows. Your backend coordinates these systems, enforces permissions, records financial activity, and reconciles provider events. Each money movement needs one clearly assigned execution provider. |
A fintech demo can make everything look simple: verify a customer, connect a bank, open an account, and move money. Production introduces the difficult questions. What happens when verification needs review? When a payment returns? When two providers report different statuses?
This guide uses an illustrative US product offering embedded accounts, external bank funding, and paid subscriptions. Its architecture can inform other products, but provider approval and banking arrangements determine which workflows you can launch.
1. Define the US Fintech App Architecture Before Choosing APIs
Start with the customer journey and flow of funds. Identify who pays, who receives money, where balances are held, and what happens when a transaction fails.
For our example, customers link an external bank through Plaid, fund their embedded account through Unit, and pay platform subscription fees through Stripe. Alloy supports configured identity and risk checks during onboarding.
These are separate workflows. A Stripe charge does not automatically credit a customer's Unit account. Any connection between those balances requires a supported settlement arrangement and reconciliation.
Document those boundaries before commissioning fintech software development services. Clear payment ownership prevents duplicate debits and misleading balance displays.
2. How Plaid, Stripe, Unit, and Alloy Fit Together
Platform | Responsibility in this example | Important boundary |
Plaid | Connect external bank accounts and provide consented account data | Plaid Auth does not execute payments |
Stripe | Collect subscription fees through supported payment methods | Stripe balances and Unit balances are separate |
Unit | Enable account opening and supported banking payments through bank partners | Access depends on the approved banking program |
Alloy | Orchestrate identity, fraud, and compliance decision workflows | A workflow outcome does not replace bank approval |
Your backend | Coordinate permissions, payment state, ledger records, and exceptions | Vendor integrations do not supply all application controls |
Keep provider adapters behind your backend. The frontend should request business actions, such as “fund my account,” instead of selecting payment processors or receiving secret credentials.
3. Alloy Onboarding in US Fintech App Architecture
Configure Identity Workflows and Manual Review
Alloy Journeys coordinate configurable onboarding steps, including identity verification, fraud checks, document collection, and review. The exact checks depend on your configured services and policies. See the Alloy Journeys documentation.
Model onboarding as a state machine with pending, additional-information, review, approved, and rejected states. A timeout should leave the application pending rather than silently approving it.
Align Alloy Decisions With Unit Account Approval
Agree with Unit and the relevant bank partner how external verification evidence enters their onboarding process. Avoid running Alloy independently and assuming its approval automatically authorizes account opening.
Unit's documentation describes customers being created when an application is approved. Follow the applicable Unit application flow for your program rather than inventing a direct customer-creation shortcut.
4. Plaid Integration for External Bank Connectivity
Implement Plaid Link and Plaid Auth
The backend creates a link_token; the frontend opens Plaid Link. After completion, the backend exchanges the returned public_token for an access_token and binds the selected account to the authenticated customer.
Keep access tokens server-side. Validate account selection and verification readiness instead of automatically choosing the first linked account.
Plaid Auth supplies banking information for supported payment integrations. Plaid Identity can support ownership checks, while personal identity verification remains a separate concern.
A Plaid developer should define fallback verification, disconnected-account handling, and consent requirements before production.
Request Only Necessary Plaid Data
Plaid Transactions can support a defined financial activity feature. Plaid Assets, Plaid Statements, and Plaid Liabilities serve different financial-data needs and should be enabled only when relevant.
Similarly, a Plaid ACH workflow using Auth and Unit is different from Plaid Transfer. Adding Transfer would introduce another execution provider; do so only for a separately justified, approved use case.
Review Plaid partnership resources and compare MX API integration if coverage evaluation is part of discovery.
5. Unit Account Funding and Banking Payments
For external funding, Plaid can create a Unit-specific processor token through /processor/token/create with processor: "unit". Unit supports consuming that token in documented counterparty and ACH flows. Follow the Unit–Plaid integration guide.
Do not make incoming funds spendable simply because the debit request was accepted. Availability, holds, and return exposure depend on your program's policies and payment state.
For mobile banking app development, show pending and available balances clearly so customers understand what they can use.
6. Stripe Payments Within the Fintech Architecture
Use Stripe for a defined payment-acceptance workflow, such as platform subscriptions. If your product requires marketplace payments, evaluate Stripe Connect separately.
Plaid's Stripe integration uses /processor/stripe/bank_account_token/create. However, the returned bank account token is not a PaymentMethod ID that you can directly insert into a PaymentIntent.
Plaid's current guide describes a supported setup and migration flow and requires Stripe enablement for the Plaid PaymentIntents integration. Follow the official Plaid–Stripe instructions rather than copying a generic token example.
Collect the required ACH debit authorization and handle asynchronous payment outcomes. Stripe distinguishes payment acceptance, transfers between connected accounts, and payouts to external accounts; these operations are not interchangeable.
7. Ledger and Webhooks for US Fintech App Architecture
Your application needs durable financial records, even when providers maintain their own ledgers.
Use a double-entry ledger for the financial obligations your product records. Keep payment objects separate from ledger entries: one payment may generate pending reservations, settlement postings, fees, or reversals.
Recommended event-processing controls include:
Verify webhook authenticity using each provider's supported method.
Persist accepted events before processing them asynchronously.
Deduplicate events and tolerate out-of-order delivery.
Use stable idempotency keys for supported payment operations.
Reconcile application records against provider transactions and settlement reports.
After a request timeout, check its provider status before retrying. An uncertain response does not prove that the payment failed.
8. Security and Compliance in Fintech Solution Development
Separate customer permissions, administrative permissions, and service credentials. Encrypt sensitive information, manage secrets centrally, and exclude account numbers and identity documents from routine logs.
Hosted Stripe components can reduce card-data exposure, but PCI obligations depend on implementation. Plaid Link also does not guarantee your backend never receives bank details: calling Auth directly can return them.
Define responsibility for customer identification, sanctions checks, transaction monitoring, ACH authorization, complaints, and record retention with your partners. Alloy helps execute configured workflows; it does not transfer every compliance obligation away from your business.
Review Plaid security and compliance considerations during design. Have deposit-insurance disclosures and any licensing assumptions reviewed for the actual program structure.
9. Testing, Deployment, and Fintech Development Costs
Begin with a modular backend, durable database, queue, and separate provider adapters. Microservices should follow demonstrated scaling or ownership needs.
Test review outcomes, interrupted linking, webhook replays, duplicate payment requests, ACH returns, and provider outages. Include recovery tests for payments with uncertain status.
For Plaid–Stripe testing, Plaid's guide specifies Stripe test mode rather than Stripe Sandboxes. Confirm compatible test environments for every integration.
Budget for vendor usage, bank-program requirements, support, compliance operations, and reconciliation. The Plaid pricing calculator and pricing overview support preliminary planning; validate assumptions against contracts.
Build observability into your cloud banking software: track unresolved payments, webhook delays, onboarding reviews, and reconciliation differences.
10. US Fintech App Architecture: A Citation-Ready Explanation
How do Plaid, Stripe, Unit, and Alloy work together? Plaid supplies external bank connectivity, Stripe processes supported payment-acceptance workflows, Unit enables banking services through bank partners, and Alloy orchestrates configured identity and risk decisions. The application's backend coordinates approvals, payment routing, financial records, and reconciliation. These services have distinct balances, permissions, and approval requirements.
What is the essential design rule? Assign each money movement to one execution provider and reconcile its outcome before presenting funds as available.
Build Your US Fintech App Architecture With FintegrationFS
Planning a product around Plaid, Stripe, Unit, and Alloy? Discuss your customer journey, banking model, and payment requirements with FintegrationFS to define a financial API integration scope and launch plan.
Frequently Asked Questions About US Fintech App Architecture
1. Do I need all four platforms?
No. Choose services around your product. A subscription app may need Stripe without embedded accounts; a banking product may use Unit and Plaid without a separate Stripe payment workflow.
2. Can Plaid move money without Stripe or Unit?
Plaid Auth cannot. Plaid Transfer can support approved US money-movement use cases, but it is a separate product with its own eligibility and integration requirements.
3. Does Alloy approval automatically open a Unit account?
No. Your banking program must define how verification results support its application process. Account opening remains subject to the required provider and bank approvals.
4. Can a Stripe payment instantly fund a Unit account?
Do not assume that. Stripe and Unit maintain separate financial systems. Moving proceeds between them requires a supported settlement arrangement, appropriate permissions, and reconciliation.
5. What should I ask a fintech software development company?
Ask how it handles returns, duplicate requests, manual reviews, ledger reconciliation, and provider outages. Request an explanation of the flow of funds before agreeing to a delivery estimate.
