How a cashless product went from zero to the right integration partner

The context

The company's payment product was growing fast — 42% of transaction volume, 5 new businesses going live every week, and the core product was finally stable after months of crisis. But customers kept asking the same question: when can we go cashless?

The industry was moving toward card-based payments. Load money on a card, tap to play, no coins needed. The main competitor already had it. That gap was showing up in every sales conversation. The question wasn't whether to build it. The question was how — because nobody had figured out how to connect a cashless system to the existing payment product, and the technical gap was bigger than anyone expected.

The challenge

The accounting problem was the hidden trap. When a customer loads money on a card, that's recorded as income. When they spend it, that's recorded as income again. Double counting. Every business running cashless would need to fix their books manually every day, or the numbers wouldn't add up.

Three providers were available, each with different technology, different pricing, and different willingness to work together on a solution. Nobody inside the company had mapped the options or defined what 'going cashless' actually required.

The approach

The first move was to understand what we were actually building. Not "a cashless feature" but a specific product definition: what does cashless integration mean for a platform that already runs Square payments? What's the data model? Where does the money flow? I mapped the full transaction lifecycle across deposit, play, and redemption before evaluating any provider.

Then I killed the obvious option. The internal product, OneCashless, had been explored through multiple discovery sessions. On paper it looked like the fastest path. In practice, the product wasn't convincing. The business model was unclear, the technical architecture required work we couldn't justify, and forcing a weak product into production would have created the same crisis the payments team had just spent months fixing. I parked it. Deliberately.

Intercard was the first real test. A $500-per-terminal API fee, but they had existing market presence. I scoped a proof of concept with two pilot centers, got it validated, and put it into daily use. It proved cashless integration was technically viable on the platform.

The real unlock was Amusement Connect. They had something no other provider offered: native compatibility with Square. That meant the double-counting problem had a structural solution, not just a workaround. I initiated a co-development partnership and negotiated a shared roadmap toward feature parity with the Intercard integration.

The double-counting problem got a specific solution. I explored multiple approaches: QR-based app payments, gift card mechanisms, physical hardware swaps. None solved it cleanly. The breakthrough was a payout-based model using Square's gift card infrastructure, where redemptions offset deposits instead of creating new income lines. Clean books. No manual reconciliation.

BowlExpo validated the direction. The industry's largest trade show, and the platform needed to show cashless capability. The team delivered a working integration in under five months from kickoff. Not a demo. A working system.

The results

What I learned

The hardest product decision isn't what to build. It's what to stop building. OneCashless had momentum, internal supporters, and a head start. It also wasn't going to work. Parking it early saved months of engineering time and prevented a second payments crisis.

The second lesson: when the technical problem seems unsolvable, the answer is usually in the data model, not in the UI. The double-counting problem disappeared once I stopped looking for a user-facing fix and started mapping where money actually flows in the system.

The third: choosing a partner isn't a vendor evaluation. It's a product decision. Amusement Connect won not because they had the best pitch, but because their architecture solved a problem ours couldn't solve alone.

Transferable patterns