Ecommerce & Retail · Payments Infrastructure
CheckyPro
A custom checkout and payment platform for Shopify merchants: gateway integration, Apple Pay and Google Pay, multi-store installs, disputes and settlement reporting. Ongoing since 2025.
- Flagship build
- Focus
- SAAS, CUSTOM-WEB-APP, THIRD-PARTY-INTEGRATION
- Delivered
- 24 Apr 2026
Outcome
Three interdependent features built once rather than twice, on a payment platform stabilised before the roadmap resumed.
What we build for CheckyPro
CheckyPro is a custom checkout for Shopify merchants with the payment infrastructure underneath it. We build and run the gateway integration, Apple Pay and Google Pay, the multi-store install flow, merchant onboarding, dispute handling and settlement reporting.
It sits in the money path, which sets the standard for everything below. A checkout that is merely usually correct is not correct.
The work
Apple Pay needs one verified domain per merchant, so the onboarding flow detects whether a merchant has a custom domain and either verifies it automatically or routes them to the fallback. Duplicate orders traced back to a delay in bank confirmation rather than anything in our code, and are now prevented by checking for an existing order against the same card token before creating a new one.
By mid-2026 the platform moved off a gateway iframe onto a payment-orchestration layer, which gave CheckyPro a fully custom checkout interface, smart routing for higher transaction acceptance, and consolidated settlement reporting across providers.
A decision worth recording
In April the bug queue had been growing for three weeks, nine pull requests were open with one waiting on review since 16 March, and an admin tool committed for March was still not usable. The client had three features ready to prioritise: dispute integration, checkout optimisation and settlement reports.
We recommended holding all three. Checkout optimisation depended on settlement reports to identify which merchants qualified, and building any of it on an unstable base meant building it twice. The team moved to stabilisation and we paused our own pull request reviews to do it. That was the more expensive answer for us.
We changed how the work was governed at the same time, rather than promising to try harder: a named engineer now approves anything touching core flows before it ships, a dedicated project manager joined the client calls so status stopped routing through one person, and weekly technical stand-ups replaced ad-hoc status requests.
Where it is now
Feature delivery restarted once the logs went quiet. The engagement has since been restructured around a dedicated pair of engineers holding the deepest knowledge of the codebase, and the relationship is ongoing.
Technologies
What we built it with
- Integrations
- Shopify
- Apple Pay
- Google Pay
How we built it
Stabilised the platform first, then shipped the roadmap on top of it. In April the bug queue had been growing for three weeks and nine pull requests were open, one waiting on review since 16 March. The next three features on the list were interdependent, and two of them depended on settlement reports that did not exist yet. We moved the whole team onto stabilisation — including pausing our own pull request reviews — cleared the queue, and then built the three features once, on a base that held. Delivered in the original order, all three would have been built twice.
In the client's words
“They told us what NOT to build. That single conversation re-shaped six months of roadmap and saved us a lot of money.”
More case studies
Have a project like this in mind?
Tell us what you're building. We'll show you how we'd approach it and what it would take to ship.