Revenue-based financing, merchant cash advances, and embedded lending products all depend on the same fundamental capability: understanding a business's financial health well enough to make a credit decision. The quality of that understanding comes down to the data you can access and how quickly you can access it.
We've built this pipeline alongside dozens of fintech lenders, and this guide covers the technical architecture for building a business underwriting pipeline using commerce and accounting data from platforms like Shopify, Amazon, QuickBooks, and Xero, accessed through a unified API.
Most legacy underwriting processes rely on bank statements, tax returns, and manual document uploads. This creates three problems. First, the data is stale. A bank statement from last month doesn't reflect what happened yesterday. Second, the data is incomplete. Bank transactions show money in and money out, but they don't show product-level sales, refund rates, inventory velocity, or revenue by channel. Third, the process is slow. Manual document review creates friction that drives applicants to competitors who can offer faster decisions.
Companies like Ramp, Uncapped, and Parafin have moved beyond this model by pulling data directly from the commerce and accounting platforms their customers already use. This gives them real-time visibility into revenue, expenses, and financial health at a granularity that bank statements simply can't match.
A modern underwriting pipeline built on commerce and accounting data typically pulls from three data sources:
From platforms like Shopify, Amazon, WooCommerce, and BigCommerce, you can access order history with line-item detail, gross and net revenue over any time period, refund rates and chargeback frequency, product catalog and inventory data, and customer acquisition and retention patterns. This data gives you a real-time view of the business's revenue engine. A business with steady month-over-month order growth, low refund rates, and healthy inventory levels is a very different credit risk than one with declining orders and rising returns.
From platforms like QuickBooks, Xero, and NetSuite, you can access profit and loss statements, balance sheets, accounts receivable and payable aging, cash flow statements, vendor payment patterns, and expense categorization. Accounting data provides the financial structure behind the commerce data. Revenue alone doesn't tell you whether a business is profitable, how much debt it carries, or whether it can service additional capital.
From Stripe, PayPal, and Square, you can access transaction volumes, payout history, dispute rates, and processing trends. For businesses that process payments outside their commerce platform, this fills in the revenue picture.
Here is how the data flow works when building this pipeline with a unified API.
Your applicant connects their commerce and accounting platforms through a pre-built authentication widget. This handles the OAuth flow for each platform and returns a connection ID that you use for all subsequent API calls. A single authentication gives you access to all data from that platform without asking the customer to manually export anything.
Once connected, the API begins syncing historical data. For commerce platforms, this typically includes 12 to 24 months of order history. For accounting platforms, this includes the current chart of accounts, financial statements, and transaction history. The initial sync may take minutes to hours depending on the volume of data and the underlying platform's API speed.
A unified API normalizes data across platforms into a consistent schema. This means a Shopify order and an Amazon order have the same field structure. A QuickBooks invoice and a Xero invoice use the same data model. Without normalization, you'd need to build separate parsing logic for each platform, which increases development time and introduces inconsistency in your underwriting model. This is where the value of a unified API really shows up, because while you could in theory build one-off integrations with AI coding tools, the data wouldn't necessarily be normalized to a single schema across systems.
With normalized data flowing into your pipeline, you can compute the signals that matter for your specific underwriting model. Common signals include monthly recurring revenue and revenue growth rate, gross margin derived from accounting data, customer concentration using order data by customer, inventory turnover rate, accounts receivable aging, cash runway calculated from burn rate and bank balance, and refund rate trends.
Underwriting isn't a one-time event. For revolving credit products, merchant cash advances, or revenue-based financing, you need continuous access to updated data. Webhooks notify your system when new orders, invoices, or transactions are created so you can update risk scores and credit limits in real time.
Working with companies like Balance, Parafin, and Mercury, we've observed several patterns that differentiate the strongest underwriting implementations.
They combine data sources. A lending product that sees Shopify revenue, QuickBooks expenses, and Stripe payment volume simultaneously has a far more complete picture than one using bank statements alone. Parker specifically chose to work with us because of how our normalized data model reduces the cost of combining data from multiple platforms.
They automate the entire application flow. When a business applies for financing, connecting their platforms through a single authentication should pull all the data needed for a credit decision. No manual uploads, no back-and-forth with account managers. Mercury's venture debt product uses this approach: applicants link their accounting platforms, and the data flows directly into the underwriting pipeline.
They use commerce data for signals that accounting data misses. Product-level sales data reveals trends that aggregate revenue numbers obscure. A business might have flat top-line revenue but be shifting from high-margin to low-margin products, a signal visible in commerce data but invisible in a bank statement. This is one of the reasons we built our unified API to span both commerce and accounting, because the most accurate underwriting models need both.
The fastest path to building a data-driven underwriting pipeline is to start with a unified API that covers both commerce and accounting platforms. This gives you a single integration point for all the data sources your model needs, a normalized data model that simplifies your parsing and analytics logic, and ongoing data sync so your risk models stay current.
If you're building a lending, underwriting, or embedded finance product and want to see how this architecture works in practice, we work with every customer to map the specific data flows and API calls required for their use case.
Building integrated products is hard. We can do that together. Let's chat.
.png)