KINTO took a recurring prepaid event to selling with real payment, per-date and per-location seat control and automatic reconciliation; payments went to production three days after the first commit.
Problem
A recurring event had to be sold by prepayment, with real payment and seat control by date and location, while the team could still edit the page in their visual builder without breaking anything. The previous static publisher did not run the builder’s JavaScript and forced manual uploads.
Signals
- Market: Market demand was not measured in this engagement.
- Business: A recurring event with themed peaks and calendar changes.
- User experience: Buyers arriving from in-app social media browsers failed at the payment gateway; a specific warning and a thank-you page with the exact date were needed.
- Support: A referral field, terms in batches and third-party reservations.
How we understood it
- Iteration on real incidents: edge-platform limits, hosting cache and menu PDFs the crawler missed, all documented as lessons.
What we built and why
- Prepayment landing page with an edge payments service: signed order, embedded checkout from a local gateway, logging to a spreadsheet, webhooks backed by polling, and a payment reconciler.
- Real-browser publisher that faithfully reproduces the visual builder, with preview, redirects and automatic menu discovery.
Why this way: A webhook can be lost, so every payment has a polling fallback and a reconciler; and the publisher uses a real browser so what goes live is what the team saw in the builder.
Transformation
-
Payments in production three days after the first commit; payment flow reinforced with a polling fallback.
-
Publishing from manual to a single command, with visual parity.
-
days from first commit to payments in production: 3 (measured)
What we don’t know yet
- Seats sold and conversion: no evidence.
