What was breaking or what was the risk?
WeView's booking flow required no payment at any stage, for any category. A user could reserve a table, select menu items and confirm with nothing at stake. Vendors carried all the risk: no-shows cost them a table and prepped food, limited-time offers could be burned without a visit, and users had no reason to contribute anything back. The build was functional. The commerce model underneath it was missing.
How does a marketplace handle money without ever holding it?
XMARTECH built three settlement paths and put the platform in none of them. Restaurants and food run on WeView wallet points, spent in-app. Deliverable goods use Pay on Delivery — the customer pays the vendor after receiving the product. Services and venue bookings use Payment at Venue, settled on site. Money moves directly between customer and vendor in every case, so WeView carries no gateway, holds no custody, and stores no card data for ordinary transactions.
How was it built to hold?
One product model with a branching type. Every listing is created through a single four-step flow — Overview, Attributes, Pricing, Booking — and classified as Deliverable, Bookable, or Both. Deliverables carry a delivery estimate, radius, return policy and optional Pay on Delivery; bookables carry available days, time slots, and optional Payment at Venue. Restaurants run an earned-only points wallet with Express Prep for starters, an admin redemption cap, and grace-period auto-cancel on no-shows. Reviews require proof and geofenced arrival check-in. Live Showing and Live Shopping sell from stream, with Live Orders tracked as its own vendor metric. Vendor app handles live ops; vendor web dashboard carries analytics, traffic attribution and product management.
How it's wired
A closed loop. Nothing leaves the platform.
Before u2014 what we audited
Booking with no payment at any stage, in any category. All risk on the vendor, nothing at stake for the user.
After u2014 the closed loop
Activity earns points; points spend inside the platform; vendor balance withdraws via admin or converts to subscription and ads. No gateway, ever, in the everyday flow.
XMARTECH before/after template u2014 the production diagram follows this logic.
What did it produce?
- 12,793 active vendors run on WeView to date
- 8,089 restaurant bookings placed through the platform
- 3 live verticals u2014 restaurants and food, barbershops, electronics
- 3 settlement paths u2014 earned wallet points, pay on delivery, pay at venue u2014 none of them through the platform
- 2 live modes u2014 Live Showing (services) and Live Shopping (goods), with live purchases tracked as their own metric
- 0 external payment gateways in the everyday transaction flow
- Native iOS and Android, plus a vendor web dashboard. Vendors go live daily
info Honest framing: adoption and scale numbers, not durability metrics. No load or uptime figure is claimed, because none has been measured.
flare The part they didn't know to ask for
WeView asked XMARTECH for a live-commerce app. XMARTECH audited the existing flow and found a marketplace with no commerce model underneath it — no payment required at any stage, in any category. The prescription was three settlement paths that share one principle: the platform is never a party to the transaction. Restaurants run on points that can only be earned, never bought. Goods settle on delivery. Services settle at the venue. Money always moves directly between customer and vendor, so WeView carries no gateway, no custody and no chargeback exposure — and because the in-app currency cannot be purchased, faking a review earns nothing.
// The client never asked for it. It was the diagnosis.
Customer app + vendor admin panel
Two connected product surfaces: customer-facing mobile experiences and the Ballpark-branded vendor admin used to run catalog, bookings, and operations.
Customer app u00b7 iOS + Android
What buyers open on their phone
WeView-branded customer surfaces that carry discovery, venue detail, wallet balance and post-booking engagement.
Sign-in paths
Phone OTP, Facebook, or guest u2014 three ways in.
Home + Live
Live vendor reels above the social venue feed.
Venue profile
Offers, posts, menu, reviews u2014 Directions, Call, WhatsApp, Book a Table.
Profile + wallet
Earned points balance, referrals, bookings and payments.
Notifications
Bookings, offers, arrival check-in and review requests.
Vendor admin panel u00b7 Ballpark
What vendors run from the dashboard
Admin-side controls for performance visibility, catalog operations, and the full Deliverable / Bookable / Both product setup flow.
Performance overview
High-level KPIs for orders, bookings, live orders, profile visits, and conversion.
Traffic + revenue analytics
Source-level traffic signals with trend views that support campaign and listing decisions.
Revenue + booking operations
Revenue trends, booking records, top ordered items, and customer engagement snapshots.
Catalog management
Product inventory, status, offers, and category-level controls in one management surface.
Add product u00b7 Step 1
Overview setup with media, category structure, and product metadata before pricing/booking logic.
Add product u00b7 Step 2
Deliverable/Bookable/Both model with delivery estimate, radius, return policy, and optional POD.
Add product u00b7 Step 3
Booking-day setup, slot controls, and optional payment-at-venue for service-led flows.
Under the hood
Verticals
Sure the build is fine, but is the model underneath it?
WeView's app worked. What was missing was the thing nobody had thought to specify. Finding that before it costs you is the job.
forumDirect conversation model
01
You share business goals, constraints, and deadlines.
02
You talk directly with the engineering team, not only account managers.
03
We turn strategy into a scoped delivery plan and execution timeline.
auto_graph Project-type focus
- Offline-first user flows
- Device-level reliability
- Release-safe iteration