The Payment Problem
A table can share one restaurant bill while each guest still needs to settle a different amount. Calculating those individual shares solves only part of checkout. The product also has to move each guest from the amount they owe into a payment they can complete themselves.
ScanSPLTPay already handled the bill-splitting experience. My task was to extend that flow into payment by integrating Stripe into the existing guest checkout.
The Integration
Working with Martin Bellinger, I implemented Stripe payment functionality inside the existing application.
Historical captures show a guest-facing payment stage with Card and Apple Pay, an Order Total, a Remaining Amount, and a Pay action. A separate Stripe configuration shows an active webhook on the ScanSPLTPay API domain. Together, those artifacts document both sides of the integration: the checkout interaction presented to the guest and a product-specific server endpoint for Stripe events.
The main application used TypeScript and React. GraphQL was part of the earlier API architecture, with the codebase later moving toward tRPC. Stripe payment integration was my primary responsibility during this engagement.
The Payment Flow
At the level visible in the surviving project artifacts, the payment path is straightforward: a guest reaches the payment screen, chooses Card or Apple Pay, Stripe processes the payment interaction, and Stripe events have a dedicated destination within the ScanSPLTPay API.
Conceptual reconstruction based on surviving historical product artifacts.
Where the Product Went Next
My engagement covered an earlier stage of ScanSPLTPay. Development continued afterward.
Today, SSP POS positions Scan. SPLT. Pay. as its guest-facing restaurant experience, with SPLT.ca serving as the public guest application. The product now sits alongside management, waiter, and kitchen software in a broader restaurant platform.
What This Work Shows
This project is a compact example of integration work inside an existing commercial product: identify where an external financial service belongs in the customer journey, connect the customer-facing action with server-side infrastructure, and fit the feature into a codebase that is continuing to evolve.
The later SSP POS product family provides useful context for where ScanSPLTPay went next. My contribution was the earlier Stripe payment capability inside ScanSPLTPay.
Read the full ScanSPLTPay Stripe integration case study for the checkout problem, engineering context, and subsequent product evolution.