Normalizing Commerce Data Chaos
Peter Zhou, CEO of Rutter, on building the Plaid for ecommerce
The hard part in commerce data is not getting access, it is normalizing chaos after access is granted. Rutter is dealing with platforms that expose APIs, but each merchant can customize fields, objects, and workflows differently, especially on enterprise and self hosted systems. That pushes the work from scraping and permissions into deep schema mapping, version support, and edge case coverage, which is why a commerce universal API has to be much more operationally heavy than a bank transaction aggregator.
-
Commerce data is much deeper than bank data. Instead of just balances and transactions, the API has to reconcile orders, SKUs, customers, fulfillments, refunds, payouts, and write actions back into source systems. That makes the abstraction problem larger because each object can vary by platform and by merchant setup.
-
The merchant stack is fragmented and increasingly composable. Many brands use one core commerce system plus separate tools for checkout, marketing, fulfillment, inventory, and accounting. That creates demand for a neutral integration layer, but it also means the data model keeps changing as merchants swap tools and customize their stack.
-
This is the mirror image of Plaid’s problem. Plaid won by masking access friction from banks, then standardizing relatively narrower account data. In commerce, access is often easier, but the underlying data is less standardized, so product quality depends on how many weird implementations the API layer has already seen and handled.
Going forward, the winners in commerce infrastructure will be the companies that can quietly absorb more schema variance than anyone else. As headless and composable commerce spread, the value shifts toward the integration layer that lets fintech and software companies ship one workflow across thousands of merchant setups without building custom logic for every platform and every store.