When customers open a digital wallet through an online marketplace, they expect a consistent experience regardless of which team handles the identity check. Worldpay reported that digital wallets’ share of U.S. online spending rose from 15% to 39% between 2014 and 2024. For fintech companies adding products and entering new markets, the challenge is keeping that experience consistent without building a separate onboarding system for each one.
Ritvik Pandya, a software engineering manager who works on distributed payment systems, has helped build shared platforms that support financial products across multiple markets. His approach offers an example of where standardization can help and where local differences still matter.
How duplicate workflows add costs
“Product sprawl rarely arrives as one dramatic failure,” Pandya said. “It arrives as several teams rebuilding the same identity check, then discovering they no longer agree on what approved means.”
The duplication can look harmless at first. A wallet team copies an onboarding workflow, a marketplace adapts it for sellers and a regional team adds local checks. Soon, even a small policy change can require updates and testing across several versions. If something goes wrong, teams first have to determine which version made the decision. Customers can feel the effects when different products ask them to repeat the same checks.
Pandya described leading a shift from separate, tightly connected workflows to a shared system that uses events to record changes and notify other services. He recalled a rollout review in which two products displayed the same status but applied different rules. Rather than rename the status, the team moved responsibility for the decision into the shared system.
Shared systems can still accommodate local rules
Marketplace customers face different requirements depending on where they are and what they’re signing up for. Pandya’s approach is to standardize how products handle identity checks, eligibility and status changes while letting each product decide how to guide customers through those steps.
“Reuse fails when the platform team tries to own every screen,” Pandya said. “The shared core should own the meaning of the decision, while the product surface owns how the customer reaches it.”
A marketplace, for example, could keep its own wording and order of steps for sellers while sending the same types of eligibility updates to a shared service. The customer experience could vary without each product having to build its own eligibility system.
Verification and feature access are separate decisions
Verifying a customer’s identity does not mean every feature is immediately available. A crypto wallet user, for example, may complete an identity check before becoming eligible to buy, sell or transfer assets. Repeating the entire sign-up process for each feature can add delays and make controls harder to maintain.
Pandya said his team separated initial onboarding from decisions about which features a customer could use. That gave operations teams a clearer answer when a customer was verified but a specific feature remained unavailable. In his HackerNoon article, “Designing Event-Driven Merchant Onboarding With Kafka,” he explains how teams can use a common set of events to communicate onboarding decisions.
Risk controls extend beyond sign-up
When teams maintain their own rules for geographic eligibility or how funds can move, one product may get an update while another continues using an older rule. Pandya said his team built risk and compliance checks into the shared process for granting feature access so different products could apply those checks consistently while accounting for local requirements.
“A reusable control is not a generic control,” Pandya said. “It is one policy expressed consistently, with the local variation made explicit instead of hidden inside another copy of the flow.”
Keeping the shared system flexible
A shared system can create its own bottleneck if a wallet update or regional integration requires a release across the entire platform. Pandya said his team moved older components into smaller, separate services so teams could update individual parts and limit the spread of failures. The services could change independently while continuing to report customer status in a consistent way.
“The goal is not to make every product look the same,” Pandya said. “It is to make the next launch a controlled extension of the platform, not another private version of onboarding.”