Loyalty Configuration Settings

Loyalty Configuration Settings are org level settings that enable or control specific loyalty behaviors and workflows, such as points earning and redemption rules, tier evaluations, tracker processing, promotions, alternate currencies, and loyalty event handling. Depending on whether a configuration is enabled or disabled, the corresponding loyalty behavior is applied within the organization.

To enable or disable any of these configurations, raise a Jira ticket to the PST team.

Below are the supported loyalty configuration settings:

#	Configuration	Purpose	Behavior	Scenario
1	`MAX_ACTIVE_PROMOTIONS_PER_PROGRAM`	This configuration defines the maximum number of promotions that can be active simultaneously within a single loyalty program. It acts as a limit to control the number of concurrent active promotions, ensuring system performance and manageability.	Default Limit: The system may allow 50 active promotions per program by default. Custom Configuration: An organization with complex promotional needs might increase this limit to 100 or 200 active promotions.	A retail brand running a large-scale campaign during a festive season may need to activate multiple promotions (e.g., category-specific discounts, bonus points, tier-based rewards). If the default limit is insufficient, this configuration can be adjusted to accommodate more active promotions.
2	`ALLOW_PROMISED_POINTS_CONVERSION`	This configuration enables the conversion of promised points (pending/provisional points) into redeemable points before the standard conversion period or under specific conditions. It provides flexibility in how promised points are handled within the loyalty program.	Default Behavior: A customer makes a purchase and earns 1,000 promised points. These points remain in a "promised" state for 14 days before converting to redeemable points. With Configuration Enabled: The system can convert those 1,000 promised points to redeemable points immediately or after a shorter period, based on defined criteria.	During a flash sale event, a brand wants to offer instant point availability to drive immediate repeat purchases. With this configuration enabled, customers can earn and redeem points within the same shopping session, boosting engagement and sales.
3	`ENABLE_POINTS_EXPIRY_NEW_FLOW`	This configuration enables a new/updated flow for handling points expiry in the loyalty program. It introduces an improved mechanism for calculating, processing, and managing the expiration of customer points, replacing or enhancing the legacy expiry logic.	Legacy Behavior: Points expiry is processed using an older batch job that may have performance issues or inaccuracies when handling large volumes of customers with varying expiry dates. With Configuration Enabled: The new flow processes points expiry more efficiently, ensuring points expire accurately based on the configured rules (e.g., 12 months from earn date), customers receive timely expiry notifications, and the system handles edge cases like partial redemptions and rollovers correctly.	A retail loyalty program with 10 million members has points expiring on a rolling 12-month basis. The legacy flow struggles with processing expiry for such a large customer base, leading to delays and occasional inaccuracies. Enabling the new flow ensures that expiry is processed efficiently and accurately, even at scale.
4	`ENABLE_ALTERNATE_CURRENCY`	This configuration enables the use of alternate currencies within the loyalty program, allowing organizations to create and manage multiple types of reward currencies beyond the standard loyalty points. This provides flexibility to offer diverse reward mechanisms tailored to different customer segments, campaigns, or business needs.	Default Behavior: A customer earns only standard loyalty points (e.g., 10 points per $1 spent) which can be redeemed for rewards. With Configuration Enabled: The same customer can now earn multiple currencies: Primary Points (10 points per $1 spent), Bonus Miles (5 miles per $1 spent on travel-related purchases), and Cashback Credits (2% cashback on electronics purchases).	An airline loyalty program wants to offer both "Miles" for flight bookings and "Lifestyle Points" for partner retail purchases. With alternate currency enabled, customers can accumulate both currencies separately and redeem them for different reward categories (flights vs. merchandise).
5	`ALLOW_MLP`	This configuration enables Multi-Loyalty Program (MLP) functionality, allowing an organization to operate and manage multiple loyalty programs simultaneously within the same platform. It provides the capability to create distinct loyalty programs for different brands, regions, customer segments, or business units under a single organizational umbrella.	Default Behavior: An organization operates a single loyalty program called "Rewards Plus" for all its customers across all brands. With Configuration Enabled: The same organization can now operate multiple programs: "Fashion Rewards" for the fashion retail brand, "Gourmet Club" for the food and grocery chain, and "Tech Points" for the electronics division.	A large retail conglomerate owns a fashion brand, a grocery chain, and an electronics store. Each brand has a different target audience and loyalty strategy. With MLP enabled, the organization can run separate programs with tailored benefits per brand, and optionally allow customers to link their accounts across programs for a unified view.
6	`ENABLE_POINTS_LEDGER`	This configuration enables the Points Ledger functionality, which provides a detailed, transaction-level record of all points activities for customers. It serves as a comprehensive audit trail for tracking points earned, redeemed, expired, transferred, reversed, and adjusted within the loyalty program.	Default Behavior: A customer's profile shows a total points balance of 5,000 points, but there is no detailed breakdown of how those points were accumulated or spent. With Configuration Enabled: The customer's points ledger shows a complete history with date, transaction type, description, points, and running balance for every activity.	A customer contacts support claiming they should have more points than their current balance shows. With the points ledger enabled, the support agent can review the complete transaction history, identify any redemptions, expirations, or reversals, and provide a clear explanation to the customer.
7	`ENABLE_TIER_DOWNGRADE_ON_PARTNER_PROGRAM_EXPIRY`	This configuration enables automatic tier downgrade for customers when their associated partner program membership expires. It ensures that tier status linked to or dependent on a partner program is appropriately adjusted when the partnership or partner membership is no longer active.	Default Behavior: A customer holds a co-branded credit card that grants them automatic "Gold" tier status. When the credit card is cancelled or expires, the customer retains their "Gold" tier status indefinitely, even though they no longer qualify based on their own activity. With Configuration Enabled: When the partner program expires, the system re-evaluates the customer's tier eligibility based on their standalone activity and automatically downgrades them to the appropriate tier if they no longer qualify.	An airline loyalty program partners with a premium credit card company. Cardholders automatically receive "Elite" status. When a customer cancels their credit card, the system checks if the customer has earned enough flight miles to maintain "Elite" status independently. If not, the customer is downgraded to "Frequent Flyer" or "Base" tier and notified of the change.
8	`ENABLE_IDENTIFIER_IN_PROMOTION_CREATION`	This configuration enables the ability to assign custom identifiers to promotions during the creation process. It allows organizations to define unique, human-readable, or system-specific identifiers for promotions, making them easier to reference, track, and integrate with external systems.	Default Behavior: A promotion is created and assigned a system-generated ID. Business users and external systems must use this opaque ID to reference the promotion. With Configuration Enabled: When creating a promotion, the user can specify a custom identifier (e.g., "SUMMER_SALE_2024_20PCT") that is used across all systems.	A retail organization runs promotions across its website, mobile app, and in-store POS systems. By enabling custom identifiers, the marketing team creates a promotion with identifier "HOLIDAY_BONUS_2024". All platforms reference the promotion using this meaningful identifier, making reports, dashboards, and customer service lookups significantly easier.
9	`ALLOW_POINTS_IN_NEGATIVE_DUE_TO_RETURN`	This configuration allows a customer's points balance to go negative when points are reversed due to a product return or transaction cancellation. It ensures that points awarded on a purchase are fully recovered even if the customer has already redeemed some or all of those points before returning the item.	Default Behavior: If a customer redeems points earned on a purchase and then returns that purchase, the system can only reverse the available balance, leaving some points unrecovered. With Configuration Enabled: The system reverses all points from the returned purchase, resulting in a negative balance. The customer must earn enough points through future purchases before they can redeem again.	A customer purchases an electronics item worth $1,000, earning 1,000 points. They immediately redeem 800 points for a gift card. A week later, they return the item. With this configuration enabled, the system reverses all 1,000 points, the balance becomes -800 points, and future earnings first offset the negative balance before becoming redeemable.
10	`CONF_EMF_ROLLOUT_STATUS`	This configuration controls the rollout status of the Event Management Framework (EMF) for the organization. It determines whether the organization is using the legacy event processing system or has migrated to the new EMF architecture for handling loyalty events, triggers, and workflows.	Legacy Status: An organization on the legacy system processes transactions through older workflows with limited event logging. With EMF Rollout Enabled: Each transaction triggers an event that flows through the EMF pipeline with detailed logs available at each step, enabling efficient handling of complex workflows and simplified support troubleshooting.	A large retail organization experiences occasional delays in points crediting. With EMF rollout enabled, the technical team can trace the transaction event through EMF logs, identify exactly where in the pipeline the delay occurs, and resolve issues faster with detailed event metadata.
11	`CONF_EMF_TRACKER_ROLLOUT_MODE`	This configuration controls the rollout mode for tracker processing within the Event Management Framework (EMF). It determines how customer activity trackers (such as spend trackers, visit trackers, purchase count trackers) are processed and updated — whether through the legacy system, the new EMF-based tracker system, or a hybrid mode during migration.	Legacy Mode: Tracker updates are processed synchronously during transaction processing. Complex tracker scenarios (e.g., rolling 90-day spend) may have performance or accuracy issues. With EMF Tracker Mode Enabled: All tracker updates are processed through EMF with detailed metadata logged for full traceability across total spend, visit count, and category-level trackers.	A loyalty program uses a rolling 12-month spend tracker to determine tier eligibility. With EMF tracker mode enabled, the system accurately calculates spend within the rolling window, automatically excludes expired spend (older than 12 months), and uses precise real-time tracker values for tier evaluations.
12	`ENABLE_TRACK_KPI`	This configuration enables the tracking of Key Performance Indicators (KPIs) within the loyalty program. It allows the system to capture, measure, and report on critical business metrics related to customer behavior, program performance, and promotional effectiveness.	Default Behavior: The organization captures transaction data but lacks aggregated KPI metrics, requiring manual data extraction for performance reports. With Configuration Enabled: The system automatically tracks and aggregates KPIs such as Daily Active Customers, Average Transaction Value, Points Redemption Rate, Tier Upgrade Rate, and Promotion Conversion Rate.	A retail loyalty program manager wants to evaluate the effectiveness of a recent promotion. With KPI tracking enabled, the system provides real-time metrics on promotion participation, conversion rates, and incremental revenue. Executive dashboards display KPI trends over time, enabling data-driven optimization of future campaigns.
13	`POINTS_REDEMPTION_THRESHOLD`	This configuration defines the minimum number of points a customer must have before they are allowed to redeem points. It sets a threshold that prevents redemptions below a specified points balance, ensuring meaningful redemption transactions and reducing operational overhead from micro-redemptions.	Default Behavior (No Threshold): A customer with 10 points can redeem them for $0.10 off their purchase, creating operational overhead with minimal customer value. With Threshold Configured (e.g., 500 points): A customer with 300 points is informed they need at least 500 points to redeem, encouraging continued earning until a more meaningful reward is achievable.	A coffee shop loyalty program sets a redemption threshold of 200 points (equivalent to a free beverage). This ensures customers work towards a tangible reward, the redemption experience feels rewarding, operational complexity is reduced, and customers are motivated to return and earn more points.
14	`CONF_ENABLE_DAILY_DOWNGRADE`	This configuration enables daily evaluation and processing of tier/slab downgrades for customers. Instead of processing downgrades only at fixed intervals (e.g., monthly, quarterly, or at membership renewal), the system evaluates and executes tier downgrades on a daily basis for customers who no longer meet their current tier's qualification criteria.	Default Behavior (Periodic Downgrade): A customer who achieves "Gold" tier retains it until the next periodic review (e.g., annual), even if their spending drops significantly. With Daily Downgrade Enabled: The system checks tier qualification daily. When a customer no longer meets the criteria (e.g., rolling 90-day spend drops below threshold), they are immediately downgraded and notified.	A fitness club loyalty program has tiers based on monthly visit frequency. With daily downgrade enabled, a member who was Platinum last month but accumulates only 10 visits by month-end is downgraded to Silver the next day. This ensures tier status always reflects current engagement levels.
15	`TRACKERS_ALLOWED_IN_UPGRADE_DOWNGRADE`	This configuration defines which specific trackers are permitted to be used when evaluating customer eligibility for tier/slab upgrades and downgrades. It provides granular control over which customer activity metrics are considered during tier evaluation, allowing organizations to customize their tier qualification logic beyond default trackers.	Default Behavior: Tier upgrades are based solely on a single tracker such as "Lifetime Purchases." With Configuration Set: Tier evaluation considers multiple trackers (e.g., Lifetime Purchases ≥ $5,000 OR Visit Count ≥ 50 visits OR Current Points ≥ 10,000), rewarding both high spenders and frequent visitors.	A department store wants to reward both high-value customers and frequent shoppers. They configure Lifetime Purchases, Visit Count, and Category Spend (Premium Brands) as eligible trackers. As a result, customers who qualify via any of these dimensions are recognized and rewarded with the appropriate tier.
16	`ENABLE_POINTS_AWARDED_SOURCE_VALUE_CAPTURING`	This configuration enables the system to capture and store the source value associated with points awarded to customers. It records the original transaction or activity value (e.g., purchase amount, bill value) that resulted in the points being awarded, providing complete traceability between points earned and their originating source.	Default Behavior: A customer earns 500 points from a transaction, but there is no record of what transaction value generated those points. With Configuration Enabled: The points ledger captures the source value alongside the points entry, showing for example that 500 points were earned from a $250 purchase at a rate of 2 points per $1.	A customer contacts support claiming they should have earned more points on a recent purchase. With source value capturing enabled, the support agent can see the exact purchase amount recorded, verify the points calculation, and provide evidence to resolve the dispute or identify any excluded items (e.g., gift cards).
17	`CONF_DVS_COMM_BULK_PRIORITY`	This configuration defines the priority level for bulk communications processed through the DVS (Delivery Verification Service) communication system. It determines the processing order and resource allocation for bulk messages (such as mass campaigns, promotional blasts, and batch notifications) relative to other communication types in the queue.	Default Behavior (Low Priority): Bulk campaign messages are processed with low priority. During peak hours, a promotional email blast to 1 million customers may take several hours as transactional messages take precedence. With Higher Priority Configured: The bulk priority can be temporarily increased to ensure time-sensitive campaigns (e.g., a flash sale announcement) are delivered within the required timeframe.	A retail organization runs OTP messages and order confirmations at highest priority, points notifications at medium priority, and bulk newsletters at configured priority. With CONF_DVS_COMM_BULK_PRIORITY set appropriately, all communication types are processed in the right order, OTPs arrive in seconds, and bulk newsletters are processed during off-peak hours without impacting transactional messages.
18	`ENABLE_LOYALTY_RMQ_COMM`	This configuration enables the use of RabbitMQ (RMQ) as the messaging queue system for processing loyalty-related communications. It allows loyalty events and communication triggers to be processed through a RabbitMQ-based architecture, providing reliable, asynchronous, and scalable message delivery for loyalty program communications.	Default Behavior (Synchronous): When a customer earns points, the system attempts to send a notification synchronously. If the communication service is slow or unavailable, the transaction may be delayed or the notification lost. With RMQ Enabled: The communication event is published to the RabbitMQ queue and processed asynchronously by a consumer, with automatic retry on delivery failure. Transaction processing is unaffected.	A large retail loyalty program processes 100,000 transactions during a flash sale. Without RMQ, the communication system becomes overwhelmed, causing delays. With RMQ enabled, all 100,000 communication events are queued, processed in parallel by multiple consumer instances at a sustainable rate, and no messages are lost even during peak load.
19	`ENABLE_BULK_CONFIG_UPDATE`	This configuration enables the ability to perform bulk updates to configurations within the loyalty platform. It allows administrators to modify multiple configuration settings, promotion rules, program parameters, or other system configurations simultaneously, rather than updating them one at a time.	Default Behavior (Individual Updates): An administrator must open each item individually, make the change, and save — a time-consuming and error-prone process for large sets of records. With Bulk Config Update Enabled: The administrator selects multiple items, applies a change to all simultaneously, and all records are updated in seconds.	A retail organization operates 500 stores. At the start of a new loyalty program year, earn rates need updating across all stores, tier thresholds need adjusting for all programs, and 200 promotions need their validity periods extended. With bulk config update enabled, what would take days of manual work is completed in minutes.
20	`CONF_LIMITING_AGAINST_BILLING_MONTH`	This configuration enables the system to apply limits and caps based on the billing month of transactions rather than the transaction processing date or calendar month. It ensures that promotional limits, earn caps, and other restrictions are evaluated against the billing period associated with the transaction, providing accurate limit enforcement for scenarios where billing cycles differ from calendar months.	Default Behavior: A transaction made on January 31st but processed on February 1st counts against February's cap, even though the purchase was made in January. With Billing Month Limiting Enabled: The transaction's billing month (based on the customer's billing cycle) determines which period's cap it counts against, ensuring accurate limit enforcement across billing periods.	A credit card loyalty program with a billing cycle running from the 15th of each month to the 14th of the next month uses a 50,000-point monthly earn cap. With billing month limiting enabled, all points are awarded correctly against the appropriate billing cycle, regardless of when transactions post to the system.
21	`AUTO_POINTS_CONVERSION_REWARD_ALLOWED`	This configuration enables the automatic conversion of points into rewards without requiring manual customer initiation or intervention. When enabled, the system automatically converts accumulated points into predefined rewards (such as vouchers, coupons, or cashback) once certain thresholds or conditions are met.	Default Behavior (Manual Conversion): Customers must log in, navigate to rewards, and manually initiate redemption. Many customers never complete this process, and points eventually expire unused. With Auto Points Conversion Enabled: The system automatically detects when a threshold is reached, converts the points to a reward, and notifies the customer — no action required on the customer's part.	A grocery loyalty program configures auto-conversion at 5,000 points ($5 voucher), 10,000 points ($10 voucher), and 30 days before expiry (minimum 1,000 points). All customers receive rewards automatically, points breakage is significantly reduced, and customer satisfaction increases due to effortless rewards.
22	`CONF_REVOKE_BADGE_ON_RETURN`	This configuration enables the automatic revocation of badges that were awarded to customers when the qualifying transaction or activity is subsequently returned, cancelled, or reversed. It ensures that badges accurately reflect valid customer achievements by removing badges earned through transactions that are no longer valid.	Default Behavior (No Revocation): A customer earns a "Big Spender" badge from a $500 purchase, then returns that purchase. The badge is retained despite the qualifying transaction no longer being valid. With Badge Revocation on Return Enabled: The system detects the return, evaluates badge eligibility, and automatically revokes any badge whose qualifying transaction has been reversed.	A fashion retailer has badges like "Fashion Forward" (5 fashion items), "Premium Shopper" ($300+ single transaction), and "Loyal Customer" (10 transactions). With badge revocation enabled, when items are returned and badge criteria are no longer met, the relevant badges are automatically revoked and the customer is notified.
23	`CONF_ADDITIONAL_TRACKERS_IN_SLAB_UPGRADE_AND_RENEW`	This configuration allows the system to include additional tracker values (beyond the default ones) when evaluating whether a customer qualifies for a slab upgrade or slab renewal. Trackers are metrics or counters that track specific customer activities such as total spend, number of transactions, visits, and points earned or redeemed.	Default Tracker: A slab upgrade might only consider the customer's total spend. With Additional Trackers: The system can also consider other trackers such as number of visits, number of items purchased, and points earned from specific promotions.	An organization wants to reward both high-spending and highly engaged customers. By configuring additional trackers (e.g., visit count and category spend) alongside total spend, the tier evaluation recognizes multiple dimensions of customer loyalty.
24	`CONF_EMF_NUM_RECOMMENDATIONS`	This configuration determines the maximum number of recommendations (e.g., product recommendations, content recommendations) that should be provided or displayed to the user. It is used in scenarios where recommendations are generated based on certain rules or logic within the EMF framework.	If a system is configured to recommend products to a customer based on their purchase history, this configuration limits the number of recommendations shown (e.g., 5 recommendations).	An organization wants to surface the most relevant product recommendations without overwhelming the customer. By setting a maximum recommendation count, the display remains focused and actionable.
25	`CONF_EMF_ROLLOUT_STATUS`	This configuration defines the rollout status of the EMF (Event Management Framework) for the organization. It controls whether EMF is fully enabled, partially enabled, disabled, or in a transitional state, allowing organizations to manage the phased deployment of EMF-based event processing across their loyalty platform.	DISABLED: All events are processed through the legacy event processing system. EMF features are not available. PILOT: EMF is enabled for specific stores or regions; other stores continue using legacy. MIGRATION: Gradual rollout to additional stores in batches with dual monitoring. ENABLED: All stores are on EMF; legacy system is decommissioned.	A large retail organization migrates to EMF in phases across 500 stores: starting with DISABLED (internal testing), then PILOT (10 stores), then MIGRATION (50 stores per week), and finally ENABLED (all 500 stores on EMF with full capabilities available).
26	`ENABLE_GROUP_PROGRAMS_REDEMPTION`	This configuration enables customers to redeem points across multiple loyalty programs within a group or umbrella structure. It allows points earned in one program to be redeemed in another program within the same group, providing customers with greater flexibility and a unified redemption experience across related brands or business units.	Default Behavior (Isolated Programs): A customer with points at Brand A and Brand B (same parent company) can only redeem at each brand separately and cannot combine balances. With Group Programs Redemption Enabled: The customer can redeem the combined points balance at any participating brand within the group, with points deducted proportionally or from a consolidated balance.	A hospitality conglomerate with Luxury Hotels, Business Hotels, and Budget Hotels enables group redemption. A business traveler who earned 50,000 points at Business Hotels can redeem them for a free night at Luxury Hotels, enjoying a seamless loyalty experience across all three brands.
27	`SUPPLEMENTARY_PARTNER_PROGRAM_LIMIT`	This configuration defines the maximum number of supplementary partner programs that can be linked or associated with the primary loyalty program. It controls how many external partner programs can participate in the loyalty ecosystem, enabling organizations to manage partner integrations while maintaining system performance and operational governance.	Default Behavior (No Limit): An organization can add unlimited partner programs, potentially leading to system performance issues and operational overhead. With Limit Set (e.g., 25): The system blocks addition of a 26th partner program with an appropriate error message, prompting the administrator to remove an existing partner or request a limit increase.	A regional airline loyalty program sets SUPPLEMENTARY_PARTNER_PROGRAM_LIMIT = 20. With 18 partner slots in use across hotels, car rentals, retail, dining, financial, and travel categories, only 2 slots remain. New partnership requests are evaluated carefully, and low-performing partners may be removed to make room for better opportunities while system performance stays stable.
28	`ALLOW_POINTS_TRANSFER`	This configuration enables the ability for customers to transfer loyalty points between accounts. When enabled, customers can send points to other members within the loyalty program, facilitating points sharing, gifting, and pooling among family members, friends, or other designated recipients.	Default Behavior (Transfers Disabled): Customers cannot combine points across accounts, forcing each member to redeem for lesser individual rewards. With Points Transfer Enabled: A customer can transfer points to another account within configured limits (e.g., maximum transfer per transaction, monthly transfer cap, minimum transfer amount). Both parties receive confirmation of the transfer.	A family loyalty program configures transfers with a 10,000-point maximum per transaction and a 3-transfer monthly cap. Family members pool points into one account, enabling the family to collectively redeem for a vacation package that none could have achieved individually.
29	`ALLOW_POINTS_REDEMPTION_REVERSAL`	This configuration enables the ability to reverse points redemption transactions, restoring redeemed points back to the customer's account. When enabled, redemptions can be undone in scenarios such as order cancellations, reward fulfillment failures, customer disputes, or operational errors, ensuring customers are not penalized for failed or cancelled redemptions.	Default Behavior (Reversals Disabled): If a redemption fails (e.g., reward out of stock), the customer loses their points and receives no reward. With Redemption Reversal Enabled: Customer service can initiate a reversal, restoring the redeemed points to the customer's account so they can redeem for an alternative reward.	An online retailer handles multiple reversal scenarios: order cancellations (full reversal), partial returns (proportional reversal), fulfillment failures (full reversal), duplicate redemptions (error correction), and fraud detection. With redemption reversal enabled, points are automatically restored in each scenario, protecting the customer experience.
30	`ENABLE_PARTNER_PROGRAM_LINKING`	This configuration enables the ability to link customer accounts between the primary loyalty program and external partner programs. When enabled, customers can connect their loyalty accounts with partner program accounts, facilitating seamless points earning, redemption, and benefit sharing across multiple loyalty ecosystems.	Default Behavior (Linking Disabled): A customer with both an airline loyalty account and a hotel loyalty account cannot earn airline miles from hotel stays or use airline miles for hotel bookings. Each program operates in isolation. With Partner Program Linking Enabled: Accounts are validated and linked, enabling cross-program earning, point transfers (where allowed), and elite status recognition at partner properties.	An airline loyalty program allows customers to link accounts with Marriott Bonvoy, Hertz Gold Plus, a dining network, a retail shopping portal, and a co-branded credit card. Once linked, the customer earns airline miles on hotel stays, gets elite status recognition at Marriott check-in, and sees all partner earnings in a unified activity feed.
31	`ENABLE_USER_GROUP_LOYALTY`	This configuration enables loyalty program features and functionality at the user group level rather than solely at the individual customer level. When enabled, customers can participate in loyalty activities as part of a defined group (such as families, households, corporate teams, or organizations), allowing for shared points accumulation, collective rewards, group-based tiers, and collaborative loyalty experiences.	Default Behavior (Individual Loyalty Only): Each family member has a separate loyalty account, earns points independently, and must reach redemption thresholds individually. With User Group Loyalty Enabled: Family members can create a group, pool all their points, collectively reach tier thresholds faster, and redeem for group rewards.	A grocery retailer implements household loyalty. The Johnson family (4 members) pools their $950/month combined spend (9,500 pts) to collectively qualify for Gold tier ($800 threshold), redeem for a family movie night package, and have all members enjoy Gold tier discounts — something no individual member could achieve alone.
32	`ENABLE_FLEET_LOYALTY`	This configuration enables loyalty program features specifically designed for fleet customers such as commercial vehicle operators, trucking companies, and delivery services. When enabled, the loyalty program accommodates fleet-specific earning structures, vehicle-level tracking, driver management, consolidated billing, and B2B reward mechanisms tailored to fleet operations.	Default Behavior (Consumer Loyalty Only): A trucking company's drivers each have individual accounts. The company cannot track collective driver earnings, points are fragmented, and no volume-based benefits are available. With Fleet Loyalty Enabled: The company registers as a fleet account, all vehicle fuel purchases earn points to the company account, and the fleet qualifies for tier benefits based on combined volume.	A fuel retailer implements fleet loyalty for "ABC Logistics" (50 trucks, 75 drivers across 3 regions). All fuel purchases earn points to the company account. The fleet earns 53,200 pts/month, qualifies for Platinum tier (40,000+ gal/month), and redeems benefits including a 5¢/gallon discount, priority fueling lanes, free DEF with fill-up, and a dedicated account manager.
33	`ENABLE_AWARD_WHEN_TARGET_ACHIEVED`	This configuration enables the automatic issuance of awards or rewards immediately when a customer achieves a defined target or milestone. When enabled, the system automatically triggers reward fulfillment at the moment of target completion, rather than requiring manual processing, batch jobs, or customer-initiated claims.	Default Behavior (Manual/Batch Processing): A customer completes a target, but the reward is issued only after a batch job runs (potentially days later), by which point the excitement has faded. With Award When Target Achieved Enabled: The system instantly detects target completion and immediately issues the reward to the customer's account, with a push notification sent in real time.	A coffee shop loyalty program instantly awards rewards the moment targets are met: completing the first purchase (50 bonus pts), buying 5 coffees (free coffee voucher), 3 visits in a week (100 bonus pts), and $100 monthly spend ($10 voucher). At 9:00 AM the customer buys their 5th coffee → voucher issued instantly → notification at 9:01 AM → redeemed at 9:02 AM → delighted customer experience.
34	`ALLOW_NEGATIVE_BALANCE_ON_RETURN`	This configuration enables the loyalty system to allow a customer's points balance to go negative when points are reversed due to a product return or transaction reversal. When enabled, if a customer has already spent or redeemed points that were earned from a transaction that is subsequently returned, the system deducts the points and permits a negative balance rather than blocking the return or leaving the points unreversed.	Default Behavior (Negative Balance Not Allowed): If a customer has already redeemed points from a purchase they later return, the system cannot fully reverse the points and may block the return or leave the points partially unrecovered. With Negative Balance on Return Enabled: The system fully reverses all earned points, the balance goes negative, the return is processed smoothly, and the customer must earn back the deficit before redeeming again.	A fashion retailer with high return rates: a customer earns 8,000 pts across purchases, redeems 7,500 pts, then returns a $500 purchase. With negative balance on return enabled, the return is processed frictionlessly, the balance drops to -4,500 pts, and subsequent purchases gradually restore a positive balance — no manual intervention required. Fraud through purchase-redeem-return is also prevented since the customer cannot redeem while in a negative balance.
35	`ALLOW_RETURN_ON_TARGET`	This configuration enables the system to process returns and adjust target/milestone progress when a qualifying transaction is returned. When enabled, returns will decrement the customer's progress toward targets, potentially reversing target achievements and associated rewards if the return causes the customer to fall below the target threshold.	Default Behavior (Returns Don't Affect Targets): A customer achieves a "Spend $500, earn $50 voucher" target, receives the voucher, then returns $200 of the purchase. The target remains "Achieved" despite only $350 net spend, and the customer keeps the voucher unfairly. With Return on Target Enabled: The system recalculates net spend, revokes the target achievement and associated reward if the customer falls below the threshold, and notifies them of the adjustment and how much more is needed to re-achieve.	A retail loyalty program with Bronze ($200), Silver ($500), and Gold ($1,000) monthly spend targets adjusts achievements dynamically as returns occur. A Mar 25 return reducing spend from $1,050 to $750 triggers automatic Gold revocation while retaining Silver status (spend still above $500). Final purchases restore Gold status correctly.
36	`CONF_ENABLE_SIMULATION_API_MODE`	This configuration enables a simulation or "dry-run" mode for API calls, allowing the system to process and evaluate transactions, promotions, and loyalty operations without actually committing the changes to the database or affecting real customer data. When enabled, API requests can be executed in simulation mode to preview outcomes, validate configurations, test integrations, and troubleshoot issues without any permanent impact.	Default Behavior (No Simulation Mode): Developers must create test customers and process real transactions to test new configurations, risking production data pollution and requiring cleanup. With Simulation API Mode Enabled: Developers add `simulation=true` to the API call. The system runs all business logic and returns full results (points earned, promotions triggered, rewards issued) without writing any data to the database.	Testing a new "Double Points Weekend" promotion: the developer sends a `POST /api/v1/transactions?simulation=true` request and receives a full simulated response showing 200 total points earned (100 base + 100 bonus), the "Double Points Weekend" promotion triggered, updated tier progress, and a "WEEKEND20" coupon issued — all with `"data_persisted": false`. No cleanup required.
37	`PE_NEW_UI_ROLLOUT_STATUS`	This configuration controls the rollout status of the new Promotion Engine (PE) user interface, determining which users or organizations have access to the redesigned UI for creating, managing, and monitoring promotions. It enables a phased or controlled rollout of the new UI, allowing for gradual migration from the legacy interface while managing risk and gathering feedback.	DISABLED: All users see the legacy UI; the new UI is not accessible. BETA: Select pilot organizations have access and can toggle between new and legacy UI; feedback is collected. ENABLED: All users have access to the new UI as the default experience; legacy UI accessible via toggle. FORCED: New UI is mandatory for all users; legacy UI is completely disabled.	Phased rollout: Phase 1 - DISABLED (development and internal testing) → Phase 2 - BETA (4 weeks, 5 pilot orgs, feedback collection) → Phase 3 - PARTIAL 25% (2 weeks, gradual rollout) → Phase 4 - PARTIAL 50% (2 weeks, expanded rollout) → Phase 5 - ENABLED (4 weeks, all orgs, legacy optional) → Phase 6 - FORCED (ongoing, all orgs, legacy UI deprecated).

Updated 16 days ago