Xoxoday Plum supports emitting loyalty events from reward marketplace transactions, allowing an internal reference ID to be included in the event payload and forwarded to existing or future loyalty systems.
How Reference IDs Connect Reward Actions to Loyalty Records
During the transaction creation process, Xoxoday Plum accepts an internal reference ID as part of the request. This identifier — typically your organisation’s own loyalty membership number, employee ID, or programme-specific key — is carried forward into the event payload that Xoxoday Plum emits. Your loyalty system receives the event along with this reference, making it straightforward to reconcile the reward redemption against the correct member record. This is particularly valuable when loyalty programmes operate across fragmented systems. If your organisation tracks engagement in SAP SuccessFactors or Darwinbox and reward fulfilment happens through Xoxoday Plum, the reference ID bridges the two without requiring a custom reconciliation layer.A Practical Example
Consider an organisation running a sales incentive programme. A sales representative redeems a reward through the Xoxoday Plum marketplace. At the moment the transaction is created, Xoxoday Plum emits a loyalty event that includes the transaction details alongside the representative’s internal employee reference ID. The loyalty system — whether a homegrown solution or an enterprise platform like Workday — receives this event, credits the appropriate loyalty tier, and updates the leaderboard automatically. No manual intervention is required.Supporting Future Loyalty Integrations
Xoxoday Plum’s event architecture supports both existing and future loyalty system integrations. If your organisation is migrating loyalty platforms or evaluating new vendors, the payload structure Xoxoday Plum emits remains consistent, reducing re-integration overhead. Events carry enough contextual data — including transaction type, timestamp, and the reference ID — to satisfy the intake requirements of most modern loyalty engines. This design also aligns with enterprise compliance expectations. Because event payloads are structured and auditable, they support traceability requirements commonly expected under SOC 2 Type II programmes, giving compliance teams confidence that reward and loyalty data flows are documented and verifiable.Configuring Loyalty Events in Xoxoday Plum
Loyalty event emission is configurable at the transaction level within Xoxoday Plum. Your programme administrator defines which transaction types should trigger events and specifies the reference ID field mapping during integration setup. This keeps event volume meaningful — only transactions relevant to your loyalty programme emit events, avoiding unnecessary noise in your loyalty system’s intake queue. Learn more: [Xoxoday Plum Help Centre — Reward Transaction](Loyalty Programme Integration
Understand how Xoxoday Plum connects reward activity to loyalty systems through structured event payloads and reference ID mapping.
Configuring Transaction Event Payloads
Learn how to define which reward transactions emit events and how to structure payload fields for your loyalty engine.