Loyalty that talks to the same database as your checkout

Most loyalty platforms force you into one earning model. X3 ships four scheme types from day one: points-only (1 point per ₹1 spent), spend-cashback (return a percentage as wallet credit), tiered perks (Silver/Gold/Platinum with escalating benefits), and paid membership (an annual or monthly subscription that unlocks exclusive pricing, free shipping, or dedicated support — billed via the same payment infrastructure as your orders).

Tier evaluation runs on every qualifying event — order placed, return processed, referral completed, review submitted — not a nightly batch job. A customer who crosses the Gold threshold at 11:58 PM gets their Gold welcome email and benefits at 11:59 PM, not the following morning.

Points are tracked at receipt line-item granularity. When a customer disputes a missing earn, you pull the exact order line, the earn rule that applied, the multiplier in effect at that moment, and the wallet transaction ID — all from one query. No "email your loyalty provider" — your support team resolves it in 90 seconds.

Paid memberships integrate with the billing engine: prorate on upgrade, grace-period on payment failure, auto-downgrade on lapse. The membership state is a first-class tenant in the loyalty graph, not a separate subscription tool stapled on.

X3's segmentation engine reads directly from the event ledger that your storefront, POS, OMS, and loyalty engine all write to. There is no ETL, no warehouse sync, and no third-party CDP contract. Segment membership is always at most seconds stale — because it is computed in the same Postgres cluster where the event was written.

The visual rule builder supports AND/OR nesting with unlimited depth, time-windowed conditions ("placed 3+ orders in the last 90 days"), and frequency-based rules ("returned more than 20% of lifetime GMV"). Every platform event dimension is available: session (device, channel, UTM), order (SKU, category, brand, discount used), return (reason code, restocking fee), loyalty (tier, wallet balance, last redemption), and support (ticket count, resolution time, CSAT score).

Calculated fields are first-class: LTV (net of returns and refunds), AOV (rolling 12-month), purchase frequency (median inter-order days), and days-since-last-order are all computed columns available in the rule builder without writing SQL. For power users, the Custom Formula field accepts arbitrary SQL expressions against the event schema.

Segments evaluate continuously — not once a day, not on a cron. When a customer places an order that pushes them past a threshold, they enter the segment within the next evaluation tick (sub-5 minutes). This is the same latency profile that would require a streaming CDP in a conventional architecture.

Triggered campaigns in X3 fire on platform events, not scheduled sends. The trigger library covers: order completed, cart abandoned (configurable timeout: 30 min / 2h / 12h / 24h), tier upgraded, tier at risk of downgrade, birthday, back-in-stock, first purchase anniversary, and custom event (any event in the ledger can be a trigger).

Channels: Mailgrid email (shared or dedicated IP, DKIM/SPF configured per tenant, SPF alignment enforced, reputation dashboard built in), SMS via Twilio or Exotel (India), and WhatsApp Business API via configured WABA. Each channel is independently throttled — a customer who opted out of SMS still gets the email.

Every campaign supports A/B testing on subject line (email), message body (all channels), send time (fixed vs send-time-optimized), and CTA copy. Traffic split is configurable (50/50 default, adjustable to any ratio). Statistical significance is surfaced in the campaign report — you see conversion rate, revenue per recipient, and 95% confidence interval before you declare a winner.

Revenue attribution is causal, not last-click. X3 traces the originating trigger event through to order completion using the customer identifier and a configurable attribution window (1 / 3 / 7 / 14 / 30 days). Campaign revenue, influenced revenue (order placed during window but not triggered-path), and zero-touch revenue are reported separately so you have an honest picture of campaign lift.

The Journey Builder is a directed-graph automation engine, not a linear drip sequence. You build journeys by connecting typed nodes on a visual canvas. Each node has a specific contract:

Trigger node — the entry point. Supported triggers: all campaign triggers plus segment entry (a customer entering a dynamic segment) and API trigger (for custom integrations). A journey can have multiple trigger nodes with independent entry conditions.

Wait node — hold the customer for a fixed duration (minutes to weeks), until a specific date/time, or until a condition is true ("wait until inventory > 0 for SKU the customer viewed"). Wait nodes are non-blocking — the journey engine polls pending waits on a configurable interval (default: 5 minutes for time-based, event-driven for condition-based).

Condition node — branches the journey based on any event or profile attribute. Branch count is unlimited. Common patterns: "has customer placed a second order? yes → VIP branch, no → re-engagement branch."

Action node — sends a message (email, SMS, WhatsApp, push) or performs a platform action (assign loyalty tier, add to segment, issue wallet credit, create a support ticket). Action nodes fail gracefully — a failed SMS send does not kill the journey; the failure is logged to node_runs and the journey continues.

A/B Split node — randomly routes a percentage of traffic to two or more branches. Used for testing entire journey branches, not just individual messages.

Goal node — marks the desired outcome (e.g., "placed an order"). Customers who reach the goal exit the journey and are counted as converted in the journey report. Goal attribution is used to calculate journey revenue.

Journeys support live sends and dry-run mode. In dry-run, all nodes execute and node_runs records are written, but no messages are delivered and no platform actions are committed. This lets you validate journey logic against real customers before going live.

For multi-brand operators or networks of non-competing retailers (e.g., a food court, a mall group, or a franchise network), X3 supports a cross-brand loyalty pool. Pool membership is opt-in at the tenant level and requires explicit configuration — no tenant's points are shared without their deliberate participation.

Within a pool, points earned at any participating brand are credited to the member's pooled wallet. The redemption scope is configurable: pooled wallet can be redeemed at any participating brand (fully pooled), only at the brand where the customer currently has the highest spend (home-brand preference), or only at the originating brand (brand-siloed earn, pooled visibility only).

Pool analytics surface the metrics that matter for network operators: cross-brand visit rate (members who shop at 2+ brands in the pool over 90 days), basket uplift from cross-brand members vs. single-brand members, and reactivation lift (customers who returned to a brand after redeeming pooled points earned elsewhere).

The reactivation program is a preconfigured journey type: customers who have been inactive at Brand A for 60+ days but active at Brand B receive an automated outreach from Brand A with a pooled-points reminder and a time-limited double-earn event. This consistently drives 8–15% reactivation rates in networks where X3 has deployed it.

The loyalty ledger in X3 is an append-only event log, not a mutable balance column. Every entry has a mandatory reference to its origin: an order_id + order_line_id for earns, a redemption_id for burns, a campaign_id for bonus credits, and an admin_adjustment_id (with reason code and approver) for manual corrections.

This means the current wallet balance is always derivable from the ledger history — it is never stored as a standalone value that can drift out of sync. The balance displayed to the customer and the balance verified by your support team are always computed from the same source of truth.

When a customer migrates from another loyalty platform, their historical earn/burn events are imported as ledger entries with source=MIGRATION and a reference to the original receipt identifier from the source system. The migrated history is queryable, exportable, and available in dispute resolution — you can tell a customer "your 2,400 points from your purchase last October were migrated from your old account on [date]" with a full audit trail.

Dispute resolution at the receipt level means your support team can pull up a specific order, see exactly which earn rule applied, what multiplier was active, whether a promotion stacked, and what the resulting credit was — all in one screen. Disputes are resolved in under two minutes on average, compared to the typical 20–45 minutes when loyalty data lives in a separate system.