The Pointricity platform runs on five custom WordPress plugins, each responsible for a discrete functional boundary. This is the technical breakdown of what was built, why those architectural choices were made, and how the integration layers between YITH Multi Vendor, myCred, Stripe Connect, Zoho CRM, and the QR pipeline were implemented.
Plugin Architecture - Why Five Separate Plugins
A single monolithic plugin would have been faster to build and harder to maintain. The Pointricity platform has three user roles (vendor, customer, operator) with overlapping but distinct functional needs. Splitting into five plugins creates clean dependency boundaries.
Plugin 1 - Vendor Registration and Onboarding: Extends YITH Multi Vendor with custom vendor profile fields, document upload for compliance verification, and operator approval workflow. Vendor status gates access to the earning engine.
Plugin 2 - Rewards Engine Integration: Bridges myCred with the multi-vendor context. Handles point earn events scoped to vendor, custom earn rules by product category, point expiry by vendor agreement terms, and balance queries across vendor context.
Plugin 3 - QR Verification Pipeline: Generates unique QR codes per earn event, handles in-store scan via a mobile-accessible endpoint, validates the earn event against business rules, and credits myCred asynchronously via WP-Cron. The customer-facing scan endpoint is rate-limited per customer ID.
Plugin 4 - Stripe Connect Payout Manager: Maps vendor point redemptions to Stripe Connect transfer events. Handles the split between platform fee and vendor payout. Generates a reconciliation ledger that matches myCred records against Stripe transfer history.
Plugin 5 - External Integrations (Zoho CRM + OTP): Pushes transaction events to Zoho CRM via REST API on earn and redeem triggers. Handles OTP generation and verification for high-value redemptions. Uses transient-based OTP storage with 5-minute TTL and one-use enforcement.
YITH Multi Vendor Integration
YITH Multi Vendor provides the vendor isolation layer - each vendor's products, orders, and earnings are scoped to their account. The Pointricity integration extends this at the action/filter level.
Custom yith_wcmv_vendor_earnings filter adjusts earn amounts based on vendor tier and active promotional rules. The Vendor Registration plugin hooks into yith_wcmv_vendor_registration_form to inject additional fields without modifying YITH source files.
Vendor capability checks run at every earn event: yith_vendors()->get_vendor_from_query_var( get_query_var( 'vendor' ) )->is_valid(). No earn event credits without a validated active vendor context.
myCred Rewards Engine
myCred handles the ledger. The Rewards Engine plugin extends it with Pointricity-specific hooks.
Custom point type pointricity_earn separates loyalty points from WooCommerce store credits to prevent ledger contamination. Earn events use mycred_add() with structured log entries: user_id, vendor_id, earn_event_type, amount, timestamp. Logs are queryable for audit.
Point expiry is vendor-configurable. The Rewards Engine plugin runs a daily WP-Cron job that queries outstanding balances with earn timestamps older than the vendor's configured expiry window and processes them via mycred_subtract().
Balance display in the customer dashboard uses mycred_get_users_balance() filtered by point type. No raw database queries on the myCred ledger from outside the plugin.
QR Pipeline Technical Implementation
Each QR code encodes a signed payload: earn_event_id|customer_id|vendor_id|timestamp|signature. The signature uses wp_hash() with a server-side secret. On scan, the endpoint validates signature before processing any business logic.
The scan endpoint is a custom REST route: POST /wp-json/pointricity/v1/redeem-qr. Authentication requires a customer-scoped application password (not nonce - the scan happens from a separate mobile device). Rate limiting enforced at 5 requests per minute per customer ID via transient counter.
Point crediting on successful scan is async: the endpoint returns HTTP 202 immediately, and a WP-Cron event scheduled for 30 seconds later processes the credit after final validation. This prevents the mobile scan from blocking on a slow myCred write.
Stripe Connect Payout Architecture
Stripe Connect's platform account model maps naturally to the multi-vendor context. Each vendor onboards via a Stripe Express account linked to the Pointricity platform account.
The Payout Manager plugin listens to woocommerce_payment_complete and calculates the split: platform fee (configurable per vendor tier) and vendor payout. Stripe's Transfer API handles the split at payment time - no delayed reconciliation needed for standard transactions.
High-value redemptions above a configurable threshold trigger a manual review flag rather than auto-transfer. Operator reviews via a custom WP Admin screen that displays the myCred ledger entry alongside the pending Stripe transfer, with approve/reject controls.
Reconciliation report runs daily: queries all Transfer objects from the Stripe API for the past 24 hours and matches against myCred log entries by earn_event_id. Discrepancies are flagged in a custom database table and surfaced in the operator dashboard.
Key Benefits
- Five plugins with clean dependency boundaries - each independently deployable
- myCred ledger isolated by custom point type - no contamination with store credits
- QR payload cryptographically signed - replay attacks blocked at validation layer
- Stripe Connect split at payment time - no delayed reconciliation debt
- OTP one-use enforcement with 5-minute TTL via transients
- Zoho CRM sync on every earn and redeem event via REST API
- Operator reconciliation dashboard with Stripe-vs-myCred comparison at transaction level
FAQ
Why WP-Cron for the QR credit instead of processing synchronously?
The scan happens from a customer's phone in a store. A synchronous myCred write under slow network or database load would cause the scan to appear to fail, leading to support tickets and frustrated customers. Async processing with a 202 response eliminates that failure mode.
How is the Zoho CRM integration authenticated?
Zoho OAuth2 with server-side token storage. Access tokens are stored in a custom options table row (not exposed to wp-admin), refreshed automatically before expiry. Client ID and secret are in wp-config.php as constants - never in the database.
Can vendors be on different point earn rates?
Yes. Vendor tier configuration in Plugin 1 sets an earn multiplier. The Rewards Engine reads this at earn time and applies it to mycred_add(). Tier changes take effect on new earn events - they don't retroactively recalculate past points.
What happens if the Stripe payout fails?
The Payout Manager plugin catches Stripe API exceptions and logs them with the associated earn_event_id. Failed payouts appear in the operator dashboard for manual retry. myCred credits are not reversed on Stripe failure - the ledger and the payment are handled independently.