Building a payments platform is different from any other software. You don't get the luxury of startup mistakes, and regulation is often seen as a barrier-but it can become a level playing field if approached correctly. Decades of our experience and journey at Zoho took us from innovating with Connected Banking to launching Zoho Payments across multiple countries. A set of mental models consistently guided our thinking across technology, product design, customer experience, compliance, and operations.
These principles influence our day-to-day decision-making. Below, we share examples illustrating how each mental model shaped the platform and our approach to innovation.

Mental Models That Shaped Zoho Payments

First Principles Thinking - Solve the Problem, Not the Symptoms

Traditionally, businesses spent hours manually uploading bank statements and reconciling them against invoices. This process was inefficient and created errors. At first glance, the solution seemed to be adding more features to smooth existing workflows. But First Principles Thinking asks us to strip away assumptions and go back to the basics:

• What is the fundamental problem? Businesses need accurate, timely reconciliation and seamless payment execution.
• What is incidental "baggage"? Manual processes are a byproduct of legacy systems, not a necessity.

With that clarity, we rebuilt the solution from the ground up. We created Connected Banking-direct connectivity with banks to automatically pull statements and allow businesses to make payments from within the ERP itself. By eliminating the original pain point rather than patching it, we redefined the workflow entirely.

Inversion - Detect Everything That Could Go Wrong

Inversion, a mental model championed by Charlie Munger, helped us approach problems from the opposite perspective: instead of asking, "How can we succeed?" we asked, "What could go wrong?" In payments, mistakes aren't just inconvenient-they're expensive and damaging to your reputation.
This inversion lens guided our thinking: Could bugs creep in unnoticed? Could fraudsters exploit loopholes? Could compliance break under edge cases? By systematically flipping the problem, we shaped our architecture and systems to anticipate failures. Inversion also gave birth to two of our most important platforms: 

Detective - Our internal bug detection platform, rooted in the conviction that anything that can go wrong will. Detective performs over 200 million comparisons for every branch merge, catching errors across APIs, code, databases, caches, async jobs, performance, and security. It has become our critical CI/CD platform.
Payments Detective - Built on the same philosophy, this platform focuses on fraud and risk. By analyzing merchant profiles and transaction patterns, it detects suspicious activity early, introducing friction only for fraudsters while keeping genuine customers safe.
Inversion ensured that reliability, resilience, and trust weren't afterthoughts but foundational design choices.

Game Theory - Anticipating Fraud

Fraudsters are among the most sophisticated actors in the ecosystem. To counter them, we had to think strategically, not just defensively. Game theory helped us anticipate their moves by treating fraud prevention as an evolving strategic contest.
Our mindset became: What would a fraudster assume we are doing and how can we surprise them by being two moves ahead? This translated into three guiding principles: 

Hide defensive intentions - Never reveal exactly where or how protections work, ensuring fraudsters can't easily reverse-engineer the system.
Introduce calibrated friction - In high-risk workflows, extra verifications are applied selectively.
Think in payoffs, not absolutes - The goal isn't to eliminate all fraud attempts (impossible), but to make fraud unprofitable.

For example: When suspicious activity is detected, we apply targeted friction or perform manual checks. This makes it unpredictable and costly for fraudsters, while legitimate customers enjoy a seamless flow. Game theory helped us treat fraud prevention as an evolving contest.

Sunk Cost Fallacy - Letting Go to Innovate

Holding onto legacy workflows or outdated integrations can block progress. The sunk cost fallacy reminds us that past investments shouldn't dictate future choices. We could have continued patching manual reconciliation processes. Instead, we chose to let go and built Connected Banking.
Similarly, before Detective was created, we had invested heavily in manual test cases. By building Detective, we deprecated these efforts, ensuring future investments focused on scalable, automated testing. The same principle was applied with Bharat Connect for Business. We had built a closed loop networking module, but when NBBL introduced an interoperable system, we immediately partnered with them, without worrying about our existing investments. It's always about the future, not the past.

Second-Order Thinking- Anticipating Consequences

Solving a problem today is often just the first step. Second-order thinking asks us to consider not only the immediate outcomes of our actions but also the ripple effects-how one decision can create new opportunities or challenges down the line. When we built Connected Banking, the immediate goal was simple: automate payments and reconciliation. But we also thought about ripple effects-how this capability could influence adoption and shape future products. This mindset led naturally to creating a dedicated fintech subsidiary.
Launching Online Payments, Payouts, and POS Devices wasn't incremental; it was a second-order outcome of the initial decision to simplify payments. By anticipating consequences, decisions compounded value. Second-order thinking helped us see beyond immediate wins, guiding investments in architecture, products, and teams that paid dividends years later.

Platforms over Products and Features - The Compounding Effect of Foundations

We always prioritized building platforms over shipping isolated features or products. Features solve an immediate need, but platforms create foundations that unlock multiple possibilities and scale over time. We view our platform as a set of Lego blocks, on which new products can be built quickly. Our payments system was designed as a global platform rather than a country-specific product. Layering local compliance and regulatory nuances onto this foundation allowed Zoho Payments to launch in India and the US without rebuilding from scratch. This has also laid a strong foundation for expanding into many more countries in the future. Platform-first thinking doesn't just simplify future product building; it generates compounding benefits. Every new product launch becomes assembling existing Lego blocks rather than starting from zero. That's the real payoff of prioritizing platforms over features.

Feedback Loops - Learn, Iterate, Improve

A feedback loop is the process of learning from results and using those insights to improve the system. Customer feedback was central: every insight, complaint, or suggestion refined workflows, simplified reconciliation, and improved the payments experience. Complementing this, Detective and Payments Detective acted as continuous internal feedback systems, monitoring code, transactions, and fraud patterns in real time.

Closing Thoughts

These mental models extend beyond payments. Applied thoughtfully, they provide a framework for decision-making in any complex system. Principles like First Principles Thinking, Inversion, and Feedback Loops allow teams to innovate at scale, build resilient platforms, and deliver meaningful impact-even in highly regulated and operationally complex domains.