Pointricity needed a loyalty rewards ecosystem where vendors earn, customers redeem, and operators manage - all on one platform. The complexity wasn't in any single feature; it was in making three distinct user roles work together without breaking the business logic between them. Here's what that engagement required and what it produced.
The Business Problem
Most loyalty programs are two-sided: a business and its customers. Pointricity was three-sided: vendors who supply points-earning opportunities, customers who earn and redeem, and platform operators who manage compliance, balances, and payouts.
Each side of that triangle has incompatible incentives. Vendors want maximum redemption to drive traffic. Customers want maximum earning with minimum friction. Operators need auditability, fraud controls, and financial reconciliation. Building a platform that serves all three simultaneously - without letting one side's needs compromise another's - is a fundamentally different problem than building a typical e-commerce site.
The client came to me after an initial attempt with a simpler setup failed. The two-sided assumptions baked into off-the-shelf plugins couldn't accommodate the vendor relationship layer. Starting over with purpose-built architecture was the right call.
Scope and Complexity
This engagement ran longer than a typical WordPress build because the product complexity demanded it. Before writing code, I mapped every state transition in the reward lifecycle: earn, hold, verify, approve, transfer, redeem, expire. Each transition had business rules attached, and those rules had to be enforced consistently across all three user types.
The QR-based verification pipeline alone required designing a flow where a customer's physical in-store action created a database event, triggered a webhook to Zoho CRM for CRM-side recording, and updated point balances - all without the user waiting for a server round-trip.
Stripe Connect's split payment architecture needed to be mapped against the vendor payout model. The financial reconciliation between what Stripe processed and what myCred recorded had to be auditable at the transaction level.
What the Client Needed from Me
Pointricity didn't need a developer who could install plugins. They needed someone who could look at a business model with three stakeholder types, five interdependent systems, and a real-time verification requirement - and then architect something that wouldn't collapse under the first edge case.
The engagement included architectural scoping, plugin selection with written rationale, custom integration development, and delivery with documentation the client's team could operate without me present. That last part matters as much as the build itself.
Outcomes
The platform launched with three user roles fully operational. Vendor onboarding, customer earning, QR-verified in-store redemption, Stripe Connect payouts, and Zoho CRM sync all functional from day one.
Post-launch, the platform handled a Black Friday promotion cycle that spiked transaction volume by 8x without requiring emergency infrastructure changes. The architecture had headroom because headroom was designed in from the start.
Key Benefits
- Three-sided marketplace model implemented cleanly on WordPress
- QR verification pipeline with real-time point crediting
- Stripe Connect payout model mapped to vendor financials
- Zoho CRM integration for CRM-side transaction recording
- OTP verification reducing fraudulent redemptions
- Platform documented for client-operated management
FAQ
Why WordPress for a SaaS loyalty platform?
The client's team was already managing WordPress content. The ecosystem of plugins (YITH Multi Vendor, myCred, Stripe) had enough maturity to build on without writing everything from scratch. The constraint was the custom integration work connecting them - that's what made it non-trivial, and why previous attempts failed.
How was fraud handled?
OTP verification on redemption, rate limiting on earn events, and transaction-level auditing in myCred. The Zoho CRM sync also created a second record of every transaction, useful for dispute resolution.
What happened when the QR verification server was slow?
The UX was designed around async verification. The customer sees a "pending" state immediately, and the point credit follows when the server confirms. We never blocked the user on a synchronous server round-trip.
Can this platform scale beyond its initial user base?
The architecture handles horizontal scaling at the WordPress/PHP layer and uses Stripe's infrastructure for financial processing. The bottleneck at scale would be the myCred ledger - there are known patterns for sharding that, which I documented in the handoff notes.
