Loyalty Configuration Settings

Loyalty Configuration Settings are org level settings that control 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:

`1. MAX_ACTIVE_PROMOTIONS_PER_PROGRAM`

Purpose: 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.

Detailed Explanation:

By default, loyalty programs may have a predefined limit on how many promotions can run at the same time.
This configuration allows organizations to set a custom cap on active promotions per program.
When the limit is reached, no new promotions can be activated until existing ones are deactivated or expire.
This helps in:
- Preventing system overload due to excessive promotion evaluations
- Maintaining clarity in promotional strategies
- Ensuring optimal performance during transaction processing

Example Use Case:

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.
Scenario: 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.

Impact:

Performance: A higher limit may impact transaction processing time as more promotions need to be evaluated for each transaction.
Operational Control: Helps marketing teams plan and manage promotions within defined boundaries.
Error Prevention: Prevents accidental creation of excessive promotions that could degrade system performance.

How to Verify:

Check Configuration Settings:
Review the organization's configuration settings to see the current value of MAX_ACTIVE_PROMOTIONS_PER_PROGRAM.
Test Promotion Activation:
Attempt to activate promotions beyond the configured limit and verify that the system prevents activation with an appropriate error message.
Review Active Promotions Count:
Check the total number of currently active promotions in the program and compare against the configured limit.
Evaluate Logs:
Check system logs or API responses for any errors or warnings related to exceeding the maximum active promotions limit.

2. `ALLOW_PROMISED_POINTS_CONVERSION`

Purpose: 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.

Detailed Explanation:

Promised Points: These are points that have been allocated to a customer but are not yet available for redemption. They are typically held in a "pending" or "promised" state for a defined period (e.g., 7 days, 30 days) to account for potential returns, cancellations, or fraud checks.
By default, promised points convert to redeemable points only after the configured delay period expires.
When this configuration is enabled:
- The system allows promised points to be converted to redeemable points earlier than the standard delay period.
- This can be triggered manually, via API, or based on specific business rules.
This is useful for:
- VIP or high-tier customers who are trusted and don't need the standard waiting period
- Specific promotional campaigns where instant gratification is desired
- Scenarios where the risk of returns/cancellations is minimal

Example Use Case:

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.
Scenario: 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.

Impact:

Customer Satisfaction: Improves customer experience by providing faster access to earned points.
Increased Redemption Activity: Encourages quicker redemptions, potentially driving repeat purchases.
Risk Exposure: Increases the risk of points being redeemed before returns or cancellations are processed, leading to potential points liability issues.
Fraud Considerations: May require additional fraud checks or restrictions to mitigate abuse.

How to Verify:

Check Configuration Settings: Review the organization's configuration to confirm that ALLOW_PROMISED_POINTS_CONVERSION is enabled.
Review Promised Points Rules: Check the loyalty program settings to understand the default promised points delay period and any exceptions configured.
Test Points Conversion: Perform a test transaction where a customer earns promised points. Trigger the conversion (manually or via API) and verify that the promised points are converted to redeemable points before the standard delay period.
Check Points Ledger: Review the customer's points ledger to confirm Promised points were initially allocated. Conversion to redeemable points occurred as expected. The timing of conversion aligns with the configuration.
Evaluate API Responses/Logs: Check API responses or system logs to confirm that the promised points conversion was processed correctly. Look for any errors or warnings related to early conversion.
Validate Edge Cases: Test scenarios involving returns or cancellations after early conversion to understand how the system handles points reversal.

3. `ENABLE_POINTS_EXPIRY_NEW_FLOW`

Purpose: 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.

Detailed Explanation:

Points Expiry: Loyalty points typically have a validity period after which they expire if not redeemed. This encourages customers to engage with the program and helps organizations manage points liability.
The legacy points expiry flow may have limitations in terms of:
- Performance at scale
- Flexibility in expiry rules
- Accuracy in expiry calculations
- Handling complex expiry scenarios (e.g., partial expiry, rolling expiry)
When this configuration is enabled:
- The system uses the new/optimized flow for processing points expiry.
- This may include improvements such as:
  - More efficient batch processing of expiring points
  - Better handling of FIFO (First-In-First-Out) expiry logic
  - Enhanced support for different expiry strategies (fixed date, rolling, activity-based)
  - Improved accuracy in expiry notifications and calculations
This is particularly useful for:
- Large-scale loyalty programs with millions of customers
- Programs with complex expiry rules
- Organizations migrating from legacy systems

Example Use Case:

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.
- The system handles edge cases like partial redemptions and rollovers correctly.
Scenario: 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.

Impact:

Performance Improvement: The new flow is optimized for handling large volumes of points expiry transactions.
Accuracy: Reduces errors and discrepancies in points expiry calculations.
Customer Communication: Enables more accurate and timely expiry notifications to customers.
Flexibility: Supports more complex expiry strategies and rules.
Migration Consideration: Organizations switching to the new flow should validate that historical points and expiry dates are handled correctly during the transition.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ENABLE_POINTS_EXPIRY_NEW_FLOW is set to true or enabled.
Review Expiry Rules:
- Check the loyalty program's points expiry settings to understand the configured expiry period (e.g., 12 months, fixed date, rolling).
Test Points Expiry:
- Create a test scenario where a customer has points nearing expiry.
- Allow the expiry process to run and verify that:
  - Points expire on the correct date.
  - The correct number of points are expired (FIFO logic if applicable).
  - The customer's points balance is updated accurately.
Check Points Ledger:
- Review the customer's points ledger to confirm:
  - Expiry transactions are recorded with the correct date and points amount.
  - The ledger reflects the accurate remaining balance after expiry.
Validate Expiry Notifications:
- If expiry notifications are configured, verify that customers receive accurate notifications before their points expire.
Evaluate Batch Job Logs:
- Check the batch job or scheduler logs to confirm that the new expiry flow is being executed.
- Look for any errors, warnings, or performance metrics related to the expiry process.
Compare with Legacy Flow (if applicable):
- If migrating from the legacy flow, compare expiry results between the old and new flows for a sample set of customers to ensure consistency.

4. `ENABLE_ALTERNATE_CURRENCY`

Purpose: 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.

Detailed Explanation:

Alternate Currency: In addition to the primary loyalty points, organizations may want to offer other forms of reward currencies such as:
- Bonus points
- Cashback credits
- Miles or travel points
- Game tokens or coins
- Category-specific points (e.g., "Fashion Points", "Grocery Credits")
By default, loyalty programs operate with a single primary points currency.
When this configuration is enabled:
- The system supports the creation and management of multiple alternate currencies.
- Customers can earn, accumulate, and redeem these alternate currencies based on configured rules.
- Each alternate currency can have its own:
  - Earn rules
  - Redemption rules
  - Expiry policies
  - Conversion rates (to/from primary points)
This is particularly useful for:
- Multi-brand organizations wanting brand-specific currencies
- Promotional campaigns with limited-time bonus currencies
- Gamification strategies with special tokens or coins
- Partner programs with co-branded currencies

Example Use Case:

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 (standard)
- Bonus Miles: 5 miles per $1 spent on travel-related purchases
- Cashback Credits: 2% cashback on electronics purchases
Scenario: 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).

Impact:

Enhanced Flexibility: Allows organizations to design more sophisticated and engaging loyalty programs.
Targeted Promotions: Enables category-specific or campaign-specific currencies to drive desired customer behaviors.
Customer Engagement: Increases engagement by offering diverse earning and redemption opportunities.
Complexity in Management: Requires careful planning and management of multiple currencies, including:
- Conversion rates between currencies
- Separate expiry policies
- Reporting and reconciliation
Points Liability: Organizations need to track liability for each alternate currency separately.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ENABLE_ALTERNATE_CURRENCY is set to true or enabled.
Review Alternate Currency Setup:
- Check the loyalty program settings to see the list of configured alternate currencies.
- Verify each currency's properties:
  - Name and identifier
  - Earn rules
  - Redemption rules
  - Expiry policy
  - Conversion rate (if applicable)
Test Alternate Currency Earning:
- Perform a test transaction that qualifies for alternate currency earning.
- Verify that the customer earns the correct amount of alternate currency in addition to (or instead of) primary points.
Test Alternate Currency Redemption:
- Attempt to redeem alternate currency for a reward.
- Verify that the redemption is processed correctly and the alternate currency balance is deducted.
Check Points Ledger:
- Review the customer's points ledger to confirm:
  - Alternate currency transactions are recorded separately.
  - Balances for each currency type are displayed correctly.
- Use the include_alternate_currencies parameter when fetching the points ledger to view all currency types.
Validate Expiry Handling:
- If alternate currencies have different expiry policies, test that expiry is processed correctly for each currency type.
Evaluate API Responses/Logs:
- Check API responses to confirm that alternate currency information is returned correctly in transaction and balance queries.
- Review system logs for any errors related to alternate currency processing.
Review Reports:
- Check loyalty reports to ensure alternate currencies are tracked and reported separately from primary points.

5. ALLOW_MLP

Purpose: 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.

Detailed Explanation:

Multi-Loyalty Program (MLP): This feature allows organizations to run more than one loyalty program, each with its own:
- Earn and burn rules
- Tier/slab structures
- Points currency
- Promotions and campaigns
- Customer base
By default, an organization may be limited to a single loyalty program.
When this configuration is enabled:
- The organization can create and manage multiple independent loyalty programs.
- Each program operates autonomously with its own configurations and rules.
- Customers can be enrolled in one or more programs depending on business requirements.
- Cross-program interactions (e.g., points transfer, shared tiers) can be configured if needed.
This is particularly useful for:
- Conglomerates with multiple brands requiring separate loyalty identities
- Organizations operating in multiple regions with localized loyalty programs
- Businesses wanting to offer different loyalty experiences for different customer segments (e.g., B2B vs. B2C)
- Franchise models where each franchise has its own loyalty program

Example Use Case:

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
- "Tech Points" – For the electronics division
Scenario: 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 "Fashion Rewards" with tier-based benefits and exclusive fashion discounts.
- Run "Gourmet Club" with points-per-visit and recipe rewards.
- Run "Tech Points" with cashback and extended warranty rewards.
- Optionally, allow customers to link their accounts across programs for a unified view.

Impact:

Brand Differentiation: Allows each brand or business unit to have a unique loyalty identity and strategy.
Operational Flexibility: Enables tailored loyalty experiences for different customer segments or markets.
Scalability: Supports organizational growth by accommodating new brands or regions with dedicated programs.
Complexity in Management: Requires robust governance to manage multiple programs, including:
- Separate configurations and rules for each program
- Cross-program reporting and analytics
- Customer data management across programs
Resource Allocation: May require additional resources for managing and maintaining multiple programs.
Integration Considerations: APIs and integrations need to handle program-specific contexts.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ALLOW_MLP is set to true or enabled.
Verify Program Setup:
- Check the list of loyalty programs configured under the organization.
- Confirm that each program has its own:
  - Program ID and name
  - Earn and burn rules
  - Tier structure (if applicable)
  - Promotions and campaigns
Test Program Enrollment:
- Enroll a test customer in one or more loyalty programs.
- Verify that the customer is correctly associated with the intended program(s).
Test Program-Specific Transactions:
- Perform transactions under different programs and verify:
  - Points are earned according to the respective program's rules.
  - Tier progression is tracked separately for each program.
  - Promotions are applied based on the correct program context.
Check Customer Profile:
- Review the customer's profile to confirm:
  - Enrollment status in each program.
  - Separate points balances and tier status per program.
Test Cross-Program Features (if applicable):
- If cross-program features are enabled (e.g., points transfer, group redemptions), test these functionalities to ensure they work as expected.
Evaluate API Responses/Logs:
- Check API requests and responses to confirm that the correct program_id is being passed and processed.
- Review system logs for any errors related to multi-program operations.
Review Reports and Analytics:
- Verify that reports and dashboards provide program-specific insights and can aggregate data across programs if needed.

6. ENABLE_POINTS_LEDGER

Purpose: 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.

Detailed Explanation:

Points Ledger: A chronological record that captures every points-related transaction for a customer, including:
- Points earned (from transactions, promotions, bonuses)
- Points redeemed (for rewards, discounts, vouchers)
- Points expired (based on expiry policies)
- Points reversed (due to returns, cancellations, fraud)
- Points adjusted (manual adjustments by administrators)
- Points transferred (to/from other customers or programs)
By default, the system may only track aggregate points balances without detailed transaction history.
When this configuration is enabled:
- The system maintains a detailed ledger of all points movements.
- Each ledger entry includes metadata such as:
  - Transaction ID
  - Date and time
  - Points amount (credit/debit)
  - Transaction type (earn, redeem, expire, etc.)
  - Source (transaction, promotion, manual adjustment)
  - Running balance
  - Expiry date (for earned points)
This is particularly useful for:
- Customer service inquiries regarding points history
- Audit and compliance requirements
- Debugging and troubleshooting points discrepancies
- Providing customers with transparent points statements

Example Use Case:

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:

Date	Transaction Type	Description	Points	Balance
Jan 01	Earn	Purchase #12345	+500	500
Jan 05	Earn	Welcome Bonus	+200	700
Jan 10	Redeem	Reward Redemption	-100	600
Jan 15	Earn	Promotion XYZ	+1,000	1,600
Jan 20	Expire	Points Expiry	-50	1,550
…	…	…	…	…

Scenario: 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.

Impact:

Transparency: Provides customers and support teams with full visibility into points history.
Audit Compliance: Meets regulatory and audit requirements for maintaining detailed financial records.
Dispute Resolution: Simplifies resolution of customer disputes regarding points balances.
Debugging: Helps technical teams identify and resolve points-related issues.
Storage Considerations: Maintaining detailed ledger records increases data storage requirements, especially for large customer bases with high transaction volumes.
Performance: Querying large ledger histories may require optimized indexing and pagination.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ENABLE_POINTS_LEDGER is set to true or enabled.
Test Points Ledger Retrieval:
- Use the points ledger API or UI to fetch a customer's points history.
- Verify that the ledger returns detailed transaction records.
Validate Ledger Entries:
- Perform various points activities for a test customer:
  - Earn points through a transaction
  - Redeem points for a reward
  - Trigger points expiry
  - Process a return/reversal
- After each activity, check the points ledger to confirm:
  - A new entry is created with correct details
  - Transaction type is accurately recorded
  - Points amount (credit/debit) is correct
  - Running balance is updated accurately
Check Alternate Currencies (if applicable):
- If alternate currencies are enabled, verify that the ledger includes entries for all currency types.
- Use the include_alternate_currencies parameter when fetching the ledger.
Test Pagination and Filtering:
- For customers with extensive history, test pagination to ensure all records can be retrieved.
- Test filtering options (by date range, transaction type, etc.) if available.
Evaluate API Responses:
- Check API responses to confirm that ledger data includes all expected fields:
  - Transaction ID
  - Date/time
  - Points amount
  - Transaction type
  - Source/description
  - Running balance
  - Expiry date (where applicable)
Review Customer-Facing Statements:
- If the organization provides points statements to customers (via app, email, or portal), verify that the statement accurately reflects the ledger data.
Validate Data Retention:
- Confirm that ledger records are retained according to the organization's data retention policies.

7. ENABLE_TIER_DOWNGRADE_ON_PARTNER_PROGRAM_EXPIRY

Purpose: 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.

Detailed Explanation:

Partner Programs: Many loyalty programs have partnerships with external entities (e.g., co-branded credit cards, airline alliances, hotel partnerships, corporate tie-ups) that grant customers elevated tier status or additional benefits.
Customers may receive tier upgrades or maintain tier status based on their participation in these partner programs.
By default, when a partner program membership expires, the customer's tier status in the primary loyalty program may remain unchanged.
When this configuration is enabled:
- The system automatically evaluates a customer's tier eligibility when their partner program membership expires.
- If the customer's tier status was dependent on or boosted by the partner program, the system triggers a tier downgrade to the appropriate level.
- The downgrade is based on the customer's standalone activity and qualifications without the partner program benefits.
This is particularly useful for:
- Co-branded credit card partnerships where tier status is linked to card membership
- Airline or hotel alliance programs with reciprocal tier benefits
- Corporate or B2B partnerships with time-bound tier privileges
- Subscription-based partner programs with expiry dates

Example Use Case:

Default Behavior: A customer holds a co-branded credit card that grants them automatic "Gold" tier status in the loyalty program. 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 co-branded credit card expires:
- The system detects the partner program expiry.
- It re-evaluates the customer's tier eligibility based on their standalone activity (e.g., spend, transactions, points earned).
- If the customer does not meet the "Gold" tier criteria on their own, they are automatically downgraded to the appropriate tier (e.g., "Silver" or "Base").
Scenario: 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.
- The customer is notified of the tier change and the reasons.

Impact:

Tier Integrity: Ensures that tier status accurately reflects customer qualifications and active partnerships.
Fair Treatment: Prevents customers from retaining unearned tier benefits after partner program expiry.
Revenue Protection: Protects the value of tier benefits by ensuring only qualified customers retain elevated status.
Customer Communication: Requires clear communication to customers about the impact of partner program expiry on their tier status.
Customer Experience: May result in negative customer experience if not communicated properly; customers may feel demoted unexpectedly.
Partner Data Integration: Requires reliable data feeds from partner programs to track membership status and expiry dates.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ENABLE_TIER_DOWNGRADE_ON_PARTNER_PROGRAM_EXPIRY is set to true or enabled.
Review Partner Program Setup:
- Verify that partner programs are correctly configured in the system with:
  - Partner program identifiers
  - Tier mapping rules (which partner membership grants which tier)
  - Expiry tracking mechanism
Test Partner Program Expiry Scenario:
- Create a test customer with tier status linked to a partner program.
- Simulate or trigger the partner program expiry for that customer.
- Verify that the system:
  - Detects the partner program expiry
  - Re-evaluates the customer's tier eligibility
  - Downgrades the customer to the appropriate tier (if applicable)
Validate Tier Downgrade Logic:
- Confirm that the downgrade considers the customer's standalone activity:
  - Total spend
  - Number of transactions
  - Points earned
  - Other tier qualification criteria
- Ensure the customer is placed in the correct tier based on their own merits.
Check Customer Profile:
- Review the customer's profile after partner program expiry to confirm:
  - Tier status is updated correctly
  - Tier change history reflects the downgrade
  - Partner program association is marked as expired/inactive
Validate Customer Notifications:
- If tier change notifications are configured, verify that the customer receives appropriate communication about:
  - The partner program expiry
  - The resulting tier downgrade
  - How to regain the previous tier status
Evaluate Logs and Audit Trail:
- Check system logs or audit trails to confirm:
  - The partner program expiry event was captured
  - The tier downgrade workflow was triggered
  - The downgrade was processed successfully
Test Edge Cases:
- Test scenarios where:
  - Customer qualifies for the same tier independently (no downgrade should occur)
  - Customer has multiple partner programs (downgrade only if all relevant partnerships expire)
  - Partner program is renewed before expiry processing (downgrade should be cancelled)

8. ENABLE_IDENTIFIER_IN_PROMOTION_CREATION

Purpose: 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.

Detailed Explanation:

Promotion Identifier: A unique code or reference assigned to a promotion that can be used to identify it across systems, reports, and integrations.
By default, promotions are assigned system-generated IDs (typically numeric or auto-generated UUIDs) that may not be meaningful to business users.
When this configuration is enabled:
- Users can specify a custom identifier when creating a promotion.
- The identifier can follow organizational naming conventions (e.g., "PROMO_SUMMER2024_10OFF", "BF_BONUS_500PTS").
- The custom identifier can be used in:
  - API calls to reference the promotion
  - Reports and analytics
  - External system integrations (e.g., POS, e-commerce platforms)
  - Customer communications
This is particularly useful for:
- Organizations with strict naming conventions for promotions
- Integration scenarios where external systems need to reference promotions by a known identifier
- Reporting and analytics where meaningful identifiers improve readability
- Multi-channel environments where promotions need consistent identification across platforms

Example Use Case:

Default Behavior: A promotion is created and assigned a system-generated ID like "123456" or "a1b2c3d4-e5f6-7890-abcd-ef1234567890". 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:
- Promotion Name: "Summer Sale 20% Off"
- Custom Identifier: "SUMMER_SALE_2024_20PCT"
Scenario: 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".
- The e-commerce platform references the promotion using "HOLIDAY_BONUS_2024" in API calls.
- The POS system applies the promotion using the same identifier.
- Reports and dashboards display "HOLIDAY_BONUS_2024" for easy recognition.
- Customer service can quickly look up the promotion using the meaningful identifier.

Impact:

Improved Readability: Custom identifiers make promotions easier to recognize and reference across teams and systems.
Simplified Integrations: External systems can use consistent, predictable identifiers instead of relying on system-generated IDs.
Better Reporting: Reports and analytics become more intuitive with meaningful promotion identifiers.
Governance and Standards: Enables enforcement of organizational naming conventions for promotions.
Uniqueness Requirement: Custom identifiers must be unique within the organization/program to avoid conflicts.
Validation Overhead: The system must validate that custom identifiers are unique and conform to allowed formats.
Migration Consideration: Existing promotions created before enabling this configuration may not have custom identifiers.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ENABLE_IDENTIFIER_IN_PROMOTION_CREATION is set to true or enabled.
Test Promotion Creation with Custom Identifier:
- Create a new promotion and specify a custom identifier during the creation process.
- Verify that the promotion is created successfully with the custom identifier assigned.
Validate Identifier Uniqueness:
- Attempt to create another promotion with the same custom identifier.
- Verify that the system rejects the duplicate identifier with an appropriate error message.
Test Promotion Retrieval by Identifier:
- Use the custom identifier to fetch the promotion via API or UI.
- Verify that the correct promotion is returned.
Validate Identifier Format Rules:
- Test creating promotions with various identifier formats to understand allowed characters and length limits.
- Verify that invalid identifiers (e.g., special characters, spaces, exceeding length) are rejected with appropriate validation messages.
Check API Responses:
- Verify that API responses for promotion creation and retrieval include the custom identifier field.
- Confirm that the identifier is returned consistently across all relevant endpoints.
Test Integration Scenarios:
- If external systems are integrated, test that they can successfully reference promotions using the custom identifier.
- Verify that transactions or actions triggered by external systems correctly apply the intended promotion.
Review Reports and Analytics:
- Check that reports and dashboards display the custom identifier for promotions.
- Verify that filtering or searching by custom identifier works correctly.
Evaluate Backward Compatibility:
- Confirm that promotions created before enabling this configuration continue to function correctly.
- Verify that system-generated IDs are still available and can be used alongside custom identifiers.

9. `ALLOW_POINTS_IN_NEGATIVE_DUE_TO_RETURN`

Purpose: 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.

Detailed Explanation:

Points Reversal on Returns: When a customer returns a product, the points earned on that purchase are typically reversed (deducted) from their account.
By default, the system may prevent the points balance from going below zero, which can result in:
- Partial recovery of points (only deducting what's available)
- Points leakage and liability issues for the organization
- Customers exploiting the system by redeeming points before returning items
When this configuration is enabled:
- The system allows the points balance to go negative if the reversal amount exceeds the available balance.
- The negative balance must be recovered through future points earnings before the customer can redeem again.
- This ensures full recovery of points awarded on returned transactions.
This is particularly useful for:
- Preventing points fraud and abuse
- Maintaining accurate points liability
- Organizations with liberal return policies
- High-value transactions where significant points are at stake

Example Use Case:

Default Behavior:
- Customer makes a $500 purchase and earns 500 points.
- Customer redeems 400 points for a reward.
- Customer returns the $500 purchase.
- System attempts to reverse 500 points but only deducts 100 points (available balance), leaving 400 points unrecovered.
With Configuration Enabled:
- Customer makes a $500 purchase and earns 500 points.
- Customer redeems 400 points for a reward.
- Customer returns the $500 purchase.
- System reverses all 500 points, resulting in a balance of -400 points.
- Customer must earn 400+ points through future purchases before they can redeem again.
Scenario: A customer purchases an expensive electronics item worth $1,000, earning 1,000 points. They immediately redeem 800 points for a gift card. A week later, they return the electronics item. With this configuration enabled:
- The system reverses all 1,000 points.
- The customer's balance becomes -800 points.
- The customer is informed that they have a negative balance and must earn points to restore it.
- Future earnings will first offset the negative balance before becoming redeemable.

Impact:

Fraud Prevention: Prevents customers from exploiting the system by redeeming points and then returning items.
Accurate Liability Management: Ensures the organization's points liability accurately reflects earned and valid points.
Full Points Recovery: Guarantees that all points from returned transactions are recovered.
Customer Experience: May create friction for customers who unintentionally end up with negative balances; clear communication is essential.
Redemption Blocking: Customers with negative balances cannot redeem points until the balance is restored to positive.
Customer Service Considerations: Support teams need to be trained to handle inquiries about negative balances.
Edge Cases: Organizations need to define policies for customers who become inactive with negative balances.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ALLOW_POINTS_IN_NEGATIVE_DUE_TO_RETURN is set to true or enabled.
Test Return Scenario with Sufficient Balance:
- Create a test customer with a points balance.
- Process a transaction that earns points.
- Process a return for that transaction.
- Verify that points are reversed and the balance is updated correctly (should remain positive or zero).
Test Return Scenario with Insufficient Balance:
- Create a test customer.
- Process a transaction that earns points (e.g., 500 points).
- Redeem most or all of the points (e.g., 400 points redeemed, 100 remaining).
- Process a return for the original transaction.
- Verify that:
  - All earned points (500) are reversed.
  - The balance goes negative (e.g., -400 points).
  - The negative balance is correctly reflected in the customer's profile.
Test Redemption Blocking:
- With a customer in negative balance, attempt to redeem points.
- Verify that the system blocks the redemption with an appropriate error message.
Test Balance Recovery:
- With a customer in negative balance (e.g., -400 points), process a new transaction that earns points (e.g., 500 points).
- Verify that:
  - The earned points first offset the negative balance.
  - The new balance is correctly calculated (e.g., -400 + 500 = 100 points).
  - The customer can now redeem points (if balance is positive).
Check Points Ledger:
- Review the customer's points ledger to confirm:
  - The reversal transaction is recorded with the full points amount.
  - The negative balance is reflected in the running balance.
  - Subsequent earnings show the balance recovery.
Validate Customer Notifications:
- If notifications are configured, verify that customers receive communication about:
  - The points reversal due to return.
  - Their negative balance status.
  - How to restore their balance through future purchases.
Evaluate API Responses:
- Check API responses for balance inquiries to confirm that negative balances are returned correctly.
- Verify that redemption APIs return appropriate error codes when attempting to redeem with a negative balance.
Test Edge Cases:
- Test partial returns and verify proportional points reversal.
- Test multiple returns in succession and verify cumulative negative balance handling.
- Test scenarios where the customer has alternate currencies and verify negative balance handling per currency type.

10. `CONF_EMF_ROLLOUT_STATUS`

Purpose: 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.

Detailed Explanation:

Event Management Framework (EMF): EMF is Capillary's event-driven architecture that processes various loyalty events such as:
- Transaction events (purchases, returns, cancellations)
- Customer events (registration, profile updates, tier changes)
- Points events (earn, redeem, expire, transfer)
- Promotion events (qualification, reward issuance)
- Engagement events (campaigns, communications)
The rollout status indicates the organization's migration stage to EMF:
- Disabled/Legacy: Organization uses the older event processing system.
- Partial Rollout: Some events or modules are processed via EMF while others remain on legacy.
- Full Rollout: All events are processed through EMF.
When EMF is enabled:
- Events are processed asynchronously through a robust, scalable framework.
- Enhanced logging and traceability for event processing.
- Support for complex event-driven workflows and triggers.
- Improved performance and reliability for high-volume event processing.
This is particularly useful for:
- Organizations migrating from legacy systems to modern architecture
- Debugging and troubleshooting event processing issues
- Understanding which processing pipeline is handling loyalty events
- Planning and executing phased migrations

Example Use Case:

Legacy Status: An organization on the legacy system processes transactions through older workflows. Event logging is limited, and debugging complex scenarios is challenging.
With EMF Rollout Enabled: The same organization now processes transactions through EMF:
- Each transaction triggers an event that flows through the EMF pipeline.
- Detailed logs are available for each step of event processing.
- Complex workflows (e.g., multi-step promotions, conditional rewards) are handled efficiently.
- Support teams can trace event processing using EMF logs.
Scenario: A large retail organization experiences occasional delays in points crediting. With EMF rollout:
- The technical team can trace the transaction event through EMF logs.
- They can identify exactly where in the pipeline the delay occurs.
- Root cause analysis is simplified with detailed event metadata.
- Issues can be resolved faster with better visibility.

Impact:

Improved Scalability: EMF is designed to handle high volumes of events efficiently.
Enhanced Traceability: Detailed logging and event tracking for debugging and auditing.
Modern Architecture: Leverages event-driven patterns for better reliability and flexibility.
Complex Workflow Support: Enables sophisticated event-driven workflows and triggers.
Migration Complexity: Transitioning from legacy to EMF requires careful planning and testing.
Behavioral Differences: Some edge cases may behave differently between legacy and EMF systems.
Monitoring Requirements: EMF requires appropriate monitoring and alerting for event processing health.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm the value of CONF_EMF_ROLLOUT_STATUS.
- Possible values may include:
  - DISABLED or 0 – Legacy system
  - PARTIAL or 1 – Partial rollout
  - ENABLED or 2 – Full rollout
  - Or specific module-level flags
Review EMF Module Status:
- Check which specific modules or event types are enabled for EMF processing:
  - Transaction processing
  - Points processing
  - Promotion evaluation
  - Customer events
  - Campaign triggers
Test Event Processing:
- Perform a test transaction or customer action.
- Verify that the event is processed through the expected pipeline (EMF or legacy).
Evaluate EMF Logs:
- Access EMF logs for the organization.
- Verify that events are being captured and processed through EMF.
- Check for:
  - Event receipt timestamps
  - Processing steps and durations
  - Success/failure status
  - Error messages (if any)
Trace Event Flow:
- For a specific transaction or action, trace the complete event flow through EMF:
  - Event ingestion
  - Event validation
  - Rule/promotion evaluation
  - Reward/points processing
  - Outcome recording
- Verify that each step is logged and traceable.
Compare Legacy vs. EMF Behavior:
- If in partial rollout, compare the behavior of events processed through legacy vs. EMF.
- Ensure consistency in outcomes (points awarded, promotions applied, etc.).
Check Processing Latency:
- Monitor event processing times through EMF.
- Verify that events are processed within acceptable latency thresholds.
Validate Error Handling:
- Simulate error scenarios (e.g., invalid data, system failures).
- Verify that EMF handles errors gracefully with appropriate logging and retry mechanisms.
Review Integration Points:
- If external systems are integrated, verify that they receive event notifications or callbacks correctly from EMF.
Monitor EMF Health:
- Check EMF dashboards or monitoring tools for:
  - Event throughput
  - Processing success rates
  - Error rates
  - Queue depths (if applicable)

11. CONF_EMF_TRACKER_ROLLOUT_MODE

Purpose: 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.

Detailed Explanation:

Trackers: Trackers are counters or accumulators that monitor specific customer activities over defined periods. Common trackers include:
- Spend Tracker: Total amount spent by a customer
- Visit Tracker: Number of store visits or transactions
- Purchase Count Tracker: Number of items or transactions
- Points Tracker: Points earned or redeemed
- Category/Brand Tracker: Spend or purchases in specific categories or brands
Trackers are critical for:
- Tier/slab upgrades and renewals
- Target-based promotions and milestones
- Customer segmentation and analytics
The rollout mode determines how tracker updates are processed:
- Legacy Mode: Trackers are updated through the older processing system.
- EMF Mode: Trackers are updated through the new EMF pipeline with enhanced capabilities.
- Shadow/Dual Mode: Both systems process tracker updates for comparison and validation during migration.
- Gradual Rollout: Specific tracker types or customer segments are migrated incrementally.
When EMF tracker mode is enabled:
- Tracker updates are processed asynchronously through EMF.
- Enhanced accuracy and consistency in tracker calculations.
- Better support for complex tracker configurations (e.g., rolling windows, conditional tracking).
- Improved logging and auditability of tracker changes.

Example Use Case:

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:
- A customer makes a purchase of $200.
- The transaction event is published to EMF.
- EMF processes the event and updates all relevant trackers:
  - Total spend tracker: +$200
  - Visit tracker: +1
  - Category tracker (if applicable): +$200 in "Electronics"
- All updates are logged with detailed metadata for traceability.
Scenario: A loyalty program uses a rolling 12-month spend tracker to determine tier eligibility. With EMF tracker mode:
- The system accurately calculates spend within the rolling window.
- Expired spend (older than 12 months) is automatically excluded.
- Tier evaluations use precise, real-time tracker values.
- Any discrepancies can be traced through EMF logs.

Impact:

Improved Accuracy: EMF provides more accurate and consistent tracker calculations, especially for complex scenarios.
Better Performance: Asynchronous processing reduces transaction latency.
Enhanced Traceability: Detailed logs for every tracker update enable easier debugging and auditing.
Complex Tracker Support: Better handling of advanced tracker configurations like rolling windows, conditional tracking, and multi-dimensional trackers.
Migration Risk: Transitioning tracker processing to EMF requires careful validation to ensure data consistency.
Timing Considerations: Asynchronous processing may introduce slight delays in tracker updates being reflected.
Dependency on EMF: Tracker accuracy depends on EMF pipeline health and reliability.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm the value of CONF_EMF_TRACKER_ROLLOUT_MODE.
- Possible values may include:
  - LEGACY or 0 – Legacy tracker processing
  - EMF or 1 – Full EMF tracker processing
  - SHADOW or 2 – Dual processing for validation
  - GRADUAL – Incremental rollout by tracker type or segment
Review Tracker Configuration:
- Check the configured trackers in the loyalty program:
  - Tracker types (spend, visit, count, etc.)
  - Tracking periods (lifetime, annual, rolling, custom)
  - Associated rules (tier qualification, promotion eligibility)
Test Tracker Updates:
- Perform a test transaction for a customer.
- Verify that the relevant trackers are updated correctly:
  - Spend tracker reflects the transaction amount.
  - Visit/transaction tracker increments by 1.
  - Category/brand trackers update if applicable.
Validate Tracker Values:
- Retrieve the customer's tracker values via API or UI.
- Confirm that values match expected calculations based on transaction history.
Evaluate EMF Logs for Tracker Processing:
- Access EMF logs and filter for tracker-related events.
- Verify that tracker update events are logged with:
  - Customer ID
  - Tracker type
  - Previous value
  - New value
  - Transaction/event reference
  - Timestamp
Test Rolling Window Trackers:
- If rolling window trackers are configured (e.g., 90-day spend):
  - Verify that only transactions within the window are included.
  - Confirm that older transactions are excluded from the calculation.
Compare Legacy vs. EMF Tracker Values (if in Shadow Mode):
- If running in shadow/dual mode, compare tracker values from both systems.
- Identify and investigate any discrepancies.
- Ensure consistency before full migration to EMF.
Test Tracker Impact on Tier/Slab:
- Verify that tracker values correctly influence tier upgrades and renewals.
- Test scenarios where a customer crosses a tier threshold based on tracker values.
Test Tracker Impact on Promotions:
- If promotions use tracker-based conditions (e.g., "Spend $500 to unlock bonus"):
  - Verify that tracker values are correctly evaluated.
  - Confirm that promotions trigger when tracker thresholds are met.
Validate Return/Reversal Handling:
- Process a return or transaction reversal.
- Verify that trackers are decremented appropriately.
- Check EMF logs to confirm the reversal event updated trackers correctly.
Monitor Tracker Processing Health:
- Check EMF dashboards or monitoring for tracker processing metrics:
  - Processing latency
  - Success/failure rates
  - Queue backlogs (if any)
Test Edge Cases:
- Test tracker behavior for:
  - Multiple transactions in quick succession
  - Transactions spanning tracker period boundaries
  - Customers with no prior tracker history
  - Tracker resets (e.g., annual reset)

12. `ENABLE_TRACK_KPI`

Purpose: 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.

Detailed Explanation:

KPI Tracking: KPIs are quantifiable metrics that help organizations measure the success of their loyalty program and business objectives. Common KPIs include:
- Customer KPIs: Active customers, new enrollments, churn rate, repeat purchase rate
- Transaction KPIs: Average transaction value, transaction frequency, basket size
- Points KPIs: Points earned, points redeemed, redemption rate, breakage rate
- Tier KPIs: Tier distribution, upgrade rate, downgrade rate
- Promotion KPIs: Promotion participation, conversion rate, ROI
- Engagement KPIs: Campaign response rate, app usage, communication open rates
By default, basic transactional data may be captured, but detailed KPI tracking may not be enabled.
When this configuration is enabled:
- The system actively tracks and aggregates KPI data across various dimensions.
- KPIs can be tracked at multiple levels:
  - Organization level
  - Program level
  - Store/location level
  - Customer segment level
  - Promotion/campaign level
- Data is made available for reporting, dashboards, and analytics.
This is particularly useful for:
- Measuring loyalty program ROI and effectiveness
- Identifying trends and patterns in customer behavior
- Optimizing promotions and campaigns based on performance data
- Executive reporting and business intelligence
- Setting and tracking business goals and targets

Example Use Case:

Default Behavior: The organization captures transaction data but lacks aggregated KPI metrics. Generating performance reports requires manual data extraction and calculation.
With Configuration Enabled: The system automatically tracks and aggregates KPIs:
- Daily Active Customers: 15,000
- Average Transaction Value: $75.50
- Points Redemption Rate: 62%
- Tier Upgrade Rate: 8% month-over-month
- Promotion Conversion Rate: 23% for "Summer Sale" campaign
Scenario: 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 show how many customers who viewed the promotion made a qualifying purchase.
- Incremental revenue attributed to the promotion is calculated.
- Comparison with previous promotions helps optimize future campaigns.
- Executive dashboards display KPI trends over time.

Impact:

Data-Driven Decisions: Enables organizations to make informed decisions based on measurable metrics.
Performance Visibility: Provides clear visibility into loyalty program health and effectiveness.
Goal Tracking: Allows setting and monitoring of business targets and objectives.
Optimization Opportunities: Identifies areas for improvement in promotions, customer engagement, and program design.
Reporting Efficiency: Reduces manual effort in generating performance reports.
Storage and Processing: KPI tracking increases data storage requirements and processing overhead.
Data Latency: Some KPIs may have aggregation delays depending on the reporting frequency configured.
Privacy Considerations: Ensure KPI tracking complies with data privacy regulations and customer consent requirements.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ENABLE_TRACK_KPI is set to true or enabled.
Review KPI Configuration:
- Check which KPIs are configured for tracking:
  - KPI types (customer, transaction, points, tier, promotion)
  - Tracking dimensions (organization, program, store, segment)
  - Aggregation frequency (real-time, hourly, daily, weekly)
  - Retention period for KPI data
Verify KPI Data Capture:
- Perform test transactions and customer activities.
- Verify that relevant KPIs are updated:
  - Transaction count increments
  - Revenue/spend values update
  - Points earned/redeemed are tracked
  - Customer activity metrics reflect the actions
Access KPI Reports/Dashboards:
- Navigate to the KPI reporting section or dashboards.
- Verify that KPI data is displayed correctly:
  - Current values
  - Historical trends
  - Comparisons (period-over-period, segment-over-segment)
Test KPI Aggregations:
- Verify that KPIs are correctly aggregated at different levels:
  - Organization-wide totals
  - Program-specific metrics
  - Store/location breakdowns
  - Customer segment analysis
Validate Promotion KPIs:
- Run a test promotion and verify that promotion-specific KPIs are tracked:
  - Number of customers who qualified
  - Conversion rate
  - Total rewards issued
  - Incremental revenue generated
Check KPI API Endpoints:
- If KPI data is accessible via API, test the relevant endpoints.
- Verify that API responses return accurate and up-to-date KPI values.
Test KPI Alerts/Thresholds (if configured):
- If KPI-based alerts are configured (e.g., alert when redemption rate drops below 50%):
  - Simulate conditions that trigger the alert.
  - Verify that notifications are sent correctly.
Evaluate Data Accuracy:
- Cross-reference KPI values with raw transaction data.
- Verify that aggregations and calculations are accurate.
- Check for any discrepancies or data gaps.
Review Historical KPI Data:
- Access historical KPI data to verify:
  - Data is retained according to configured retention policies.
  - Historical trends are accurately represented.
  - Period-over-period comparisons are correct.
Test KPI Export/Integration:
- If KPI data can be exported or integrated with external BI tools:
  - Test the export functionality.
  - Verify data integrity in the exported format.
  - Confirm compatibility with external analytics platforms.
Monitor KPI Processing:
- Check system logs or monitoring dashboards for KPI processing:
  - Aggregation job status
  - Processing latency
  - Any errors or failures in KPI calculation

13. `POINTS_REDEMPTION_THRESHOLD`

Purpose: 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.

Detailed Explanation:

Redemption Threshold: A minimum points balance requirement that must be met before a customer can initiate a points redemption.
By default, customers may be able to redeem any amount of points, even very small quantities (e.g., 1 point).
When this configuration is set:
- Customers must have at least the configured threshold of points to redeem.
- Redemption attempts below the threshold are blocked with an appropriate message.
- The threshold can be set based on:
  - Absolute points value (e.g., minimum 100 points)
  - Equivalent monetary value (e.g., points worth at least $5)
  - Reward-specific minimums (e.g., minimum points for a specific reward tier)
This is particularly useful for:
- Reducing transaction costs associated with small redemptions
- Encouraging customers to accumulate more points before redeeming
- Ensuring redemptions have meaningful value for customers
- Simplifying reward fulfillment operations
- Managing points liability more effectively

Example Use Case:

Default Behavior (No Threshold): A customer with 10 points can redeem them for $0.10 off their purchase. This creates operational overhead and provides minimal value to the customer.
With Threshold Configured (e.g., 500 points):
- A customer with 300 points attempts to redeem but is informed they need at least 500 points.
- The customer is encouraged to continue earning points until they reach the threshold.
- Once the customer has 500+ points, they can redeem for a more meaningful reward (e.g., $5 off).
Scenario: 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 (free drink) rather than small discounts.
- The redemption experience feels rewarding and memorable.
- Operational complexity is reduced as staff don't process tiny point redemptions.
- Customers are motivated to return and earn more points to reach the threshold.

Impact:

Reduced Micro-Redemptions: Eliminates low-value redemptions that create operational overhead without meaningful customer benefit.
Increased Engagement: Encourages customers to continue engaging with the program to reach the redemption threshold.
Meaningful Rewards: Ensures that when customers redeem, they receive a reward of tangible value.
Operational Efficiency: Simplifies redemption processing and reward fulfillment.
Points Accumulation: May lead to higher average points balances as customers save up to meet the threshold.
Customer Frustration: Customers with points below the threshold may feel frustrated if they cannot redeem; clear communication is essential.
Breakage Consideration: Higher thresholds may increase points breakage (unredeemed points) if customers disengage before reaching the threshold.
Competitive Positioning: Threshold should be balanced to remain competitive with other loyalty programs.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm the value of POINTS_REDEMPTION_THRESHOLD.
- Note the threshold value (e.g., 100 points, 500 points, etc.).
Verify Threshold Documentation:
- Check that the redemption threshold is clearly communicated to customers in:
  - Program terms and conditions
  - Mobile app / website
  - Customer communications
  - Point of sale materials
Test Redemption Below Threshold:
- Create a test customer with points below the configured threshold (e.g., 50 points if threshold is 100).
- Attempt to redeem points.
- Verify that:
  - The redemption is blocked.
  - An appropriate error message is displayed (e.g., "Minimum 100 points required for redemption").
  - The message informs the customer how many more points they need.
Test Redemption At Threshold:
- Create a test customer with points exactly at the threshold (e.g., 100 points).
- Attempt to redeem points.
- Verify that the redemption is allowed and processed successfully.
Test Redemption Above Threshold:
- Create a test customer with points above the threshold (e.g., 500 points).
- Attempt to redeem points.
- Verify that the redemption is allowed and the customer can redeem any amount up to their balance.
Validate Partial Redemption Scenarios:
- If a customer has 600 points and the threshold is 100:
  - Verify they can redeem 200 points (leaving 400, still above threshold).
  - Verify they can redeem 550 points (leaving 50, below threshold for future redemptions).
- Confirm the threshold only applies to initiating a redemption, not to the remaining balance.
Check API Responses:
- Test redemption API calls with points below the threshold.
- Verify that the API returns:
  - Appropriate error code
  - Clear error message indicating the threshold requirement
  - Current balance and required minimum
Test Multiple Redemption Channels:
- If redemptions can occur through multiple channels (POS, app, website, customer service):
  - Test threshold enforcement on each channel.
  - Verify consistent behavior across all channels.
Validate Threshold with Alternate Currencies (if applicable):
- If alternate currencies are enabled, verify whether each currency has its own threshold or shares the same threshold.
- Test redemption thresholds for each currency type.
Review Customer Communication:
- Verify that customers approaching the threshold receive appropriate notifications or encouragement (e.g., "You're only 50 points away from your next reward!").
Test Edge Cases:
- Test redemption when customer has exactly 0 points.
- Test redemption immediately after earning points that cross the threshold.
- Test threshold behavior during promotional periods (if threshold is temporarily lowered).
- Test threshold with customers who have negative balances (if allowed).
Evaluate Business Metrics:
- After implementing the threshold, monitor:
  - Average redemption value
  - Redemption frequency
  - Customer feedback/complaints
  - Points breakage rate

14. `CONF_ENABLE_DAILY_DOWNGRADE`

Purpose: 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.

Detailed Explanation:

Tier Downgrade: When a customer fails to maintain the required activity level (spend, visits, points, etc.) to retain their current tier, they are moved to a lower tier with reduced benefits.
By default, tier downgrades may be processed:
- At the end of a membership cycle (e.g., annually)
- At fixed intervals (e.g., quarterly reviews)
- Only during renewal periods
When this configuration is enabled:
- The system runs a daily job to evaluate all customers' tier eligibility.
- Customers who no longer meet their current tier's retention criteria are downgraded immediately.
- Downgrades are processed daily rather than waiting for periodic review cycles.
- This creates a more dynamic tier system that reflects real-time customer status.
This is particularly useful for:
- Programs with rolling qualification windows (e.g., "maintain $1,000 spend in any rolling 90-day period")
- Organizations wanting tiers to accurately reflect current customer engagement
- Reducing the benefit liability from customers who no longer qualify
- Creating urgency for customers to maintain their activity levels
- Programs with short-term or promotional tiers

Example Use Case:

Default Behavior (Periodic Downgrade): A customer achieves "Gold" tier in January by spending $5,000. Even if they make no purchases for the next 11 months, they retain Gold status until the annual review in December.
With Daily Downgrade Enabled:
- A customer achieves "Gold" tier by meeting the rolling 90-day spend requirement of $2,000.
- In the following months, their spending decreases.
- On day 91, when their rolling 90-day spend drops below $2,000, the daily downgrade job detects this.
- The customer is immediately downgraded to "Silver" tier.
- The customer is notified of the downgrade and informed how to regain Gold status.
Scenario: A fitness club loyalty program has tiers based on monthly visit frequency:
- Platinum: 20+ visits per month
- Gold: 12-19 visits per month
- Silver: 5-11 visits per month
- Bronze: 1-4 visits per month
With daily downgrade enabled:
- A member who was Platinum last month but has only 8 visits so far this month will be evaluated daily.
- At month-end, if they finish with only 10 visits, they are downgraded to Silver the next day.
- This ensures tier status always reflects current engagement levels.

Impact:

Real-Time Tier Accuracy: Tiers accurately reflect customers' current qualification status rather than historical achievements.
Reduced Benefit Liability: Customers who no longer qualify don't continue receiving high-tier benefits.
Increased Engagement Urgency: Customers are motivated to maintain consistent activity to avoid downgrade.
Dynamic Program Feel: Creates a more responsive and dynamic loyalty experience.
Customer Experience Risk: Frequent downgrades may frustrate customers and lead to disengagement; requires careful communication.
Processing Overhead: Daily evaluation of all customers increases system processing requirements.
Communication Volume: May generate more downgrade notifications, requiring robust communication management.
Grace Period Consideration: Organizations may want to implement grace periods to avoid immediate downgrades due to temporary inactivity.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that CONF_ENABLE_DAILY_DOWNGRADE is set to true or enabled.
Review Tier Qualification Rules:
- Check the tier/slab configuration to understand:
  - Qualification criteria for each tier (spend, visits, points, etc.)
  - Retention/maintenance criteria
  - Evaluation window (rolling period, fixed period)
  - Any grace periods configured
Verify Daily Job Scheduling:
- Confirm that the daily downgrade job is scheduled and running.
- Check the job execution time and frequency.
- Review job logs for successful execution.
Test Downgrade Scenario:
- Create a test customer and elevate them to a higher tier.
- Simulate conditions where the customer no longer meets the tier criteria:
  - Adjust their tracker values (if possible in test environment)
  - Wait for the qualification window to lapse
- Allow the daily downgrade job to run.
- Verify that the customer is downgraded to the appropriate lower tier.
Validate Downgrade Logic:
- Confirm that the downgrade evaluates the correct criteria:
  - Rolling window calculations are accurate
  - All relevant trackers are considered
  - The customer is placed in the correct lower tier (not necessarily the lowest)
Check Customer Profile:
- After downgrade, review the customer's profile to confirm:
  - Tier status is updated correctly
  - Tier change date is recorded
  - Tier history reflects the downgrade event
  - Benefits are adjusted to match the new tier
Validate Customer Notifications:
- Verify that downgraded customers receive appropriate notifications:
  - Downgrade notification with reason
  - Information on how to regain the previous tier
  - Updated benefits summary
- Check notification timing (immediate vs. batched)
Test Grace Period (if configured):
- If a grace period is configured before downgrade:
  - Verify that customers are not immediately downgraded when they first fall below criteria.
  - Confirm downgrade occurs only after the grace period expires.
  - Test that customers who re-qualify during the grace period are not downgraded.
Evaluate Batch Job Logs:
- Review the daily downgrade job logs for:
  - Number of customers evaluated
  - Number of customers downgraded
  - Any errors or exceptions
  - Processing duration
Test Edge Cases:
- Test customers exactly at the tier threshold boundary.
- Test customers with multiple tier qualifications (e.g., qualify for Gold by spend but not by visits).
- Test new customers who haven't completed a full evaluation period.
- Test customers with recent returns/reversals that affect their qualification.
- Test behavior during promotional periods with modified tier criteria.
Monitor Downgrade Metrics:
- Track daily downgrade volumes to identify trends:
  - Sudden spikes may indicate issues
  - Seasonal patterns may emerge
- Monitor customer feedback and complaints related to downgrades.
Compare with Periodic Downgrade (if transitioning):
- If migrating from periodic to daily downgrade:
  - Compare downgrade patterns before and after.
  - Ensure no unexpected mass downgrades occur.
  - Validate that the transition is smooth for customers.

15. TRACKERS_ALLOWED_IN_UPGRADE_DOWNGRADE

Purpose: 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.

Detailed Explanation:

Trackers in Tier Evaluation: Tier upgrades and downgrades are typically based on customer activity metrics tracked by the system. Common trackers include:
- Current Points: Active redeemable points balance
- Lifetime Points: Total points earned over the customer's lifetime
- Lifetime Purchases: Total spend amount over the customer's lifetime
- Current Purchases: Spend within the current evaluation period
- Visit Count: Number of transactions or store visits
- Basket Size: Average transaction value
- Category/Brand Spend: Spend in specific product categories or brands
By default, the system may only consider a limited set of standard trackers for tier evaluation.
When this configuration is set:
- Organizations can specify exactly which trackers should be included in upgrade/downgrade calculations.
- Multiple trackers can be combined (e.g., upgrade requires BOTH $5,000 spend AND 20 visits).
- Custom or additional trackers can be included in the evaluation logic.
- Trackers not listed in this configuration are excluded from tier decisions.
This is particularly useful for:
- Creating multi-dimensional tier qualification criteria
- Implementing complex loyalty strategies that reward diverse behaviors
- Aligning tier criteria with specific business objectives
- Differentiating the loyalty program from competitors
- Supporting hybrid programs that value both spend and engagement

Example Use Case:

Default Behavior: Tier upgrades are based solely on "Lifetime Purchases" tracker. A customer who spends $10,000 in a single transaction gets upgraded, while a frequent visitor with moderate spend does not.
With Configuration Set (e.g., Lifetime Purchases, Visit Count, Current Points):
- Tier evaluation now considers multiple trackers.
- Upgrade to Gold requires:
  - Lifetime Purchases ≥ $5,000 OR
  - Visit Count ≥ 50 visits OR
  - Current Points ≥ 10,000 points
- This rewards both high spenders and frequent visitors.
Scenario: A department store wants to reward both high-value customers and frequent shoppers. They configure the following trackers for tier evaluation:
- Lifetime Purchases: Rewards customers who spend large amounts
- Visit Count: Rewards customers who shop frequently, even with smaller baskets
- Category Spend (Premium Brands): Rewards customers who purchase from high-margin premium brands
With this configuration:
- A customer spending $8,000 annually qualifies for Gold via Lifetime Purchases.
- A customer with 60 visits but only $3,000 spend also qualifies for Gold via Visit Count.
- A customer with $4,000 spend on premium brands qualifies via Category Spend.
- All three customer types are recognized and rewarded appropriately.

Impact:

Flexible Tier Criteria: Enables sophisticated, multi-dimensional tier qualification strategies.
Inclusive Recognition: Allows different customer behaviors to be rewarded, not just high spend.
Business Alignment: Tier criteria can be aligned with specific business goals (e.g., driving frequency, promoting specific categories).
Competitive Differentiation: Creates unique tier structures that differentiate the program from competitors.
Complexity Management: More trackers mean more complex tier logic; requires clear documentation and communication.
Customer Understanding: Customers need clear communication about how they can achieve tier upgrades through different paths.
Evaluation Performance: Evaluating multiple trackers may increase processing time for tier calculations.
Consistency: Ensure tracker definitions and calculations are consistent across the system.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm the value of TRACKERS_ALLOWED_IN_UPGRADE_DOWNGRADE.
- Note the list of allowed trackers (e.g., ["LIFETIME_PURCHASES", "VISIT_COUNT", "CURRENT_POINTS"]).
Review Tier/Slab Configuration:
- Check the tier configuration to understand:
  - Tier thresholds for each allowed tracker
  - Whether trackers are evaluated with AND/OR logic
  - Evaluation periods for each tracker
Verify Tracker Definitions:
- Confirm that each allowed tracker is properly defined in the system:
  - Tracker name and identifier
  - Calculation logic
  - Update triggers (which events update the tracker)
  - Reset periods (if applicable)
Test Upgrade via Primary Tracker:
- Create a test customer below the upgrade threshold.
- Simulate activity that increases the primary tracker (e.g., Lifetime Purchases) above the upgrade threshold.
- Trigger tier evaluation (or wait for scheduled evaluation).
- Verify that the customer is upgraded based on the primary tracker.
Test Upgrade via Secondary Tracker:
- Create a test customer below the upgrade threshold for the primary tracker.
- Simulate activity that increases a secondary tracker (e.g., Visit Count) above its upgrade threshold.
- Trigger tier evaluation.
- Verify that the customer is upgraded based on the secondary tracker, even though the primary tracker is below threshold.
Test Downgrade Logic:
- Create a test customer at a higher tier.
- Simulate conditions where ALL allowed trackers fall below the retention thresholds.
- Trigger tier evaluation.
- Verify that the customer is downgraded only when they fail to meet criteria on all allowed trackers.
Test Tracker Exclusion:
- Verify that trackers NOT listed in the configuration are excluded from tier evaluation.
- Simulate high values on an excluded tracker and confirm it does not trigger an upgrade.
Validate Combined Tracker Logic:
- If trackers are combined with AND logic (e.g., must meet BOTH spend AND visits):
  - Test that meeting only one tracker does not trigger upgrade.
  - Test that meeting both trackers triggers upgrade.
- If trackers are combined with OR logic:
  - Test that meeting any single tracker triggers upgrade.
Check Customer Profile and Tier History:
- After tier changes, review the customer's profile to confirm:
  - Correct tier assignment
  - Tier change reason indicates which tracker(s) triggered the change
  - Tier history is accurately recorded
Evaluate EMF/System Logs:
- Check system logs or EMF logs for tier evaluation events.
- Verify that logs show:
  - Which trackers were evaluated
  - Tracker values at time of evaluation
  - Decision logic and outcome
Test Edge Cases:
- Test customers exactly at tracker threshold boundaries.
- Test customers with NULL or zero values for some trackers.
- Test new customers with incomplete tracker history.
- Test tracker values affected by returns/reversals.
- Test behavior when tracker configuration is changed mid-cycle.
Review Customer Communication:
- Verify that tier upgrade/downgrade notifications clearly explain:
  - Which tracker(s) triggered the tier change
  - Current tracker values
  - Requirements to reach the next tier or maintain current tier
Validate Reporting:
- Check that tier reports and analytics correctly attribute tier changes to the appropriate trackers.
- Verify that tracker-based tier distribution reports are accurate.

16. `ENABLE_POINTS_AWARDED_SOURCE_VALUE_CAPTURING`

Purpose: 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.
Detailed Explanation:

Source Value: The original monetary or activity value that triggered the points award. For example:
- Purchase amount that earned the points
- Bill value before discounts
- Qualifying spend amount
- Activity value (e.g., referral bonus value, survey completion value)
By default, the system may only record the points awarded without capturing the underlying source value that generated those points.
When this configuration is enabled:
- The system captures and stores the source value alongside every points award transaction.
- This creates a direct link between points earned and the originating value.
- Source value data is available for:
  - Points ledger entries
  - Transaction history
  - Reporting and analytics
  - Audit and reconciliation
This is particularly useful for:
- Auditing and compliance requirements
- Understanding points-to-value ratios
- Debugging points calculation discrepancies
- Financial reconciliation of points liability
- Customer service inquiries about points earned
- Analytics on earning patterns and behaviors

Example Use Case:

Default Behavior: A customer earns 500 points from a transaction. The points ledger shows:

Date	Type	Points	Balance
Jan 15	Earn	+500	500

There is no record of what transaction value generated these 500 points.

With Configuration Enabled: The same transaction now captures the source value:

Date	Type	Points	Source Value	Balance
Jan 15	Earn	+500	$250.00	500

This shows that the 500 points were earned from a $250 purchase (2 points per $1).

Scenario: 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: $150.00
- They can verify the points calculation: $150 × 2 points/$ = 300 points
- If the customer claims they spent $200, the agent can investigate the discrepancy
- The source value provides evidence for resolving the dispute
- If items were excluded (e.g., gift cards), the source value shows the qualifying amount

Impact:

Complete Traceability: Provides end-to-end visibility from transaction value to points awarded.
Audit Compliance: Meets regulatory and audit requirements for financial traceability.
Dispute Resolution: Simplifies resolution of customer inquiries about points calculations.
Accurate Reconciliation: Enables precise reconciliation of points liability against source transactions.
Analytics Enhancement: Allows analysis of points-to-value ratios, earning efficiency, and customer behavior.
Debugging Support: Helps technical teams identify and resolve points calculation issues.
Storage Requirements: Capturing additional data increases storage requirements.
Processing Overhead: Slight increase in processing time to capture and store source values.
Data Privacy: Source values may contain sensitive financial information; ensure appropriate access controls.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ENABLE_POINTS_AWARDED_SOURCE_VALUE_CAPTURING is set to true or enabled.
Test Points Earning Transaction:
- Process a test transaction with a known value (e.g., $100 purchase).
- Verify that points are awarded according to the earn rules.
- Check that the source value is captured correctly.
Review Points Ledger:
- Access the customer's points ledger.
- Verify that points earn entries include the source value field.
- Confirm the source value matches the original transaction amount.
Validate Source Value Accuracy:
- Test various transaction scenarios:
  - Full-price purchase
  - Discounted purchase (verify if source value is pre-discount or post-discount based on configuration)
  - Partial qualifying purchase (e.g., some items excluded)
  - Multi-item transaction
- Verify that source values are captured accurately in each scenario.
Test Different Points Sources:
- Test points earned from different sources and verify source value capturing:
  - Transaction-based points (purchase amount)
  - Promotion bonus points (qualifying spend or activity value)
  - Manual points adjustment (adjustment value or reference)
  - Referral points (referral value if applicable)
  - Sign-up bonus (may have no source value or a default value)
Check API Responses:
- Query the points ledger via API.
- Verify that API responses include the source value field for each points entry.
- Confirm the data format and field naming.
Validate Reporting:
- Access points-related reports.
- Verify that source values are available in reports.
- Test report aggregations (e.g., total source value for points earned in a period).
Test Points Reversal Scenarios:
- Process a return or transaction reversal.
- Verify that the reversal entry also captures the source value being reversed.
- Confirm the source value matches the original earn transaction.
Validate Historical Data:
- Check if source value capturing applies to:
  - New transactions only (after enabling)
  - Historical transactions (if backfilled)
- Understand any limitations for historical data.
Test Edge Cases:
- Zero-value transactions (e.g., free item with points earn)
- Negative adjustments (returns, corrections)
- Multi-currency transactions (verify currency of source value)
- Transactions with multiple earn rules applied
- Points earned from non-transactional activities
Evaluate Data Export:
- If points data can be exported:
  - Verify that source values are included in exports.
  - Confirm data integrity in exported files.
Review Audit Trail:
- Check audit logs to confirm source values are captured for compliance purposes.
- Verify that source value data is retained according to data retention policies.
Validate Customer-Facing Display (if applicable):
- If source values are displayed to customers (e.g., in app or statements):
  - Verify the display format is clear and accurate.
  - Confirm appropriate labeling (e.g., "Purchase Amount: $100.00 → Points Earned: 200").

17. `CONF_DVS_COMM_BULK_PRIORITY`

Purpose: 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.
Detailed Explanation:

DVS (Delivery Verification Service): A system component responsible for managing, processing, and delivering communications to customers across various channels (SMS, email, push notifications, etc.).
Bulk Communications: Large-scale message deliveries sent to multiple customers simultaneously, including:
- Marketing campaign blasts
- Promotional announcements
- Newsletter distributions
- Mass notifications (e.g., policy updates, program changes)
- Batch transactional messages
Priority Levels: Communications are typically processed based on priority, where:
- High Priority: Time-sensitive, transactional messages (e.g., OTPs, order confirmations)
- Medium Priority: Important but less time-critical messages (e.g., points expiry reminders)
- Low Priority: Bulk marketing and promotional messages
When this configuration is set:
- Bulk communications are assigned the specified priority level in the processing queue.
- Higher priority values result in faster processing and delivery.
- Lower priority values allow transactional messages to be processed first.
- Resource allocation (throughput, server capacity) is adjusted based on priority.
This is particularly useful for:
- Balancing system load between transactional and marketing communications
- Ensuring critical messages are not delayed by bulk campaigns
- Optimizing delivery times for time-sensitive bulk campaigns
- Managing communication infrastructure costs and capacity

Example Use Case:

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 to complete as transactional messages take precedence.
With Higher Priority Configured:
- A flash sale announcement needs to reach all customers within 30 minutes.
- The bulk priority is temporarily increased to ensure faster processing.
- The campaign is delivered within the required timeframe.
- After the campaign, priority is reset to normal levels.
Scenario: A retail organization runs multiple communication types simultaneously:
- Real-time: OTP messages, order confirmations (highest priority)
- Near real-time: Points earned notifications, tier upgrade alerts (medium priority)
- Bulk: Weekly newsletter, promotional campaigns (configured priority)
With CONF_DVS_COMM_BULK_PRIORITY set appropriately:
- OTPs are delivered within seconds regardless of bulk campaign volume.
- Points notifications are delivered within minutes.
- Bulk newsletters are processed during off-peak hours without impacting transactional messages.
- System resources are optimally utilized across all communication types.

Impact:

Delivery Time Management: Controls how quickly bulk messages are processed and delivered.
System Resource Optimization: Balances resource allocation between bulk and transactional communications.
Transactional Message Protection: Lower bulk priority ensures critical transactional messages are not delayed.
Campaign Flexibility: Allows adjustment of priority for time-sensitive bulk campaigns.
Cost Management: Lower priority may reduce infrastructure costs by spreading load over time.
Customer Experience: Ensures customers receive time-sensitive messages promptly while still receiving marketing communications.
Delivery Delays: Very low priority may result in significant delays for bulk campaigns during high-traffic periods.
Throughput Limitations: Priority settings interact with overall system throughput limits.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm the value of CONF_DVS_COMM_BULK_PRIORITY.
- Note the priority level (e.g., numeric value like 1-10, or categorical like LOW/MEDIUM/HIGH).
Understand Priority Scale:
- Clarify the priority scale used by the DVS system:
  - Numeric range (e.g., 1 = lowest, 10 = highest)
  - Categorical values (e.g., LOW, MEDIUM, HIGH, CRITICAL)
- Understand how bulk priority compares to other communication types.
Review Communication Queue Configuration:
- Check the overall DVS queue configuration:
  - Queue processing rules
  - Priority-based routing
  - Resource allocation per priority level
  - Throttling settings
Test Bulk Communication Processing:
- Schedule a test bulk communication campaign.
- Monitor the processing and delivery times.
- Verify that messages are processed according to the configured priority.
Test Priority Comparison:
- Simultaneously trigger:
  - A bulk campaign (e.g., 1,000 test messages)
  - Transactional messages (e.g., OTPs, order confirmations)
- Verify that transactional messages are delivered first if they have higher priority.
- Measure delivery times for both communication types.
Monitor Queue Metrics:
- Access DVS queue monitoring dashboards.
- Observe:
  - Queue depth for bulk communications
  - Processing rate
  - Wait times based on priority
  - Resource utilization
Test Priority Adjustment:
- If priority can be adjusted dynamically:
  - Change the bulk priority setting.
  - Run another test campaign.
  - Verify that processing times change according to the new priority.
Validate Throughput Limits:
- Test bulk campaigns at different volumes.
- Verify that priority settings interact correctly with throughput limits.
- Confirm that high-priority bulk campaigns don't overwhelm the system.
Check Delivery Reports:
- Review delivery reports for bulk campaigns.
- Analyze:
  - Total delivery time (first message to last message)
  - Average delivery latency
  - Delivery success rates
  - Any failures or delays attributed to priority/queue issues
Test Peak Load Scenarios:
- Simulate peak load conditions with multiple communication types.
- Verify that bulk communications are appropriately deprioritized.
- Confirm that transactional messages maintain acceptable delivery times.
Evaluate Channel-Specific Behavior:
- If DVS handles multiple channels (SMS, email, push):
  - Verify that bulk priority applies consistently across channels.
  - Test if channel-specific priority overrides exist.
Review Logs and Audit Trail:
- Check DVS processing logs for:
  - Priority assignment to bulk messages
  - Queue placement and processing order
  - Any priority-related warnings or errors
Test Scheduled Campaigns:
- Schedule a bulk campaign for a specific time.
- Verify that priority settings are applied at the scheduled execution time.
- Confirm that scheduled campaigns don't bypass priority rules.
Validate Retry Behavior:
- Test failed bulk message retries.
- Verify that retried messages maintain the same priority level.
- Confirm retry queues respect priority settings.

18. `ENABLE_LOYALTY_RMQ_COMM`

Purpose: 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.

Detailed Explanation:

RabbitMQ (RMQ): An open-source message broker that enables applications to communicate asynchronously by sending and receiving messages through queues. It provides:
- Reliable message delivery with acknowledgments
- Message persistence and durability
- Load balancing across consumers
- Flexible routing and exchange patterns
- High availability and clustering support
Loyalty Communications: Messages triggered by loyalty events, including:
- Points earned/redeemed notifications
- Tier upgrade/downgrade alerts
- Points expiry reminders
- Promotion qualification notifications
- Reward issuance confirmations
- Milestone achievement messages
- Welcome and onboarding communications
By default, loyalty communications may be processed through:
- Synchronous processing (blocking)
- Alternative queue systems
- Direct API calls
When this configuration is enabled:
- Loyalty communication events are published to RabbitMQ queues.
- Consumer services process messages from the queues asynchronously.
- Failed messages can be retried or moved to dead-letter queues.
- Communication processing is decoupled from transaction processing.
This is particularly useful for:
- High-volume loyalty programs requiring scalable communication processing
- Ensuring transaction performance is not impacted by communication delays
- Reliable message delivery with retry mechanisms
- Distributed system architectures
- Handling traffic spikes during promotional periods

Example Use Case:

Default Behavior (Synchronous/Alternative): 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 may be lost.
With RMQ Communication Enabled:
- Customer makes a purchase and earns 500 points.
- Transaction is processed and completed immediately.
- A "points earned" communication event is published to the RabbitMQ queue.
- The communication consumer picks up the message asynchronously.
- The notification is sent to the customer via their preferred channel.
- If delivery fails, the message is retried automatically.
Scenario: A large retail loyalty program processes 100,000 transactions during a flash sale event:
- Each transaction triggers a points notification.
- Without RMQ, the communication system becomes overwhelmed, causing delays.
- With RMQ enabled:
  - All 100,000 communication events are queued in RabbitMQ.
  - Multiple consumer instances process messages in parallel.
  - Messages are delivered at a sustainable rate without overwhelming downstream services.
  - Transaction processing remains fast and unaffected.
  - No messages are lost even during peak load.

Impact:

Improved Scalability: RabbitMQ handles high message volumes efficiently with horizontal scaling.
Transaction Performance: Decouples communication from transaction processing, ensuring fast transaction completion.
Reliability: Messages are persisted and acknowledged, preventing message loss.
Retry Capability: Failed messages can be automatically retried with configurable policies.
Load Management: Smooths out traffic spikes by queuing messages for controlled processing.
Fault Tolerance: If communication services are temporarily unavailable, messages wait in the queue.
Infrastructure Dependency: Requires RabbitMQ infrastructure to be available and properly maintained.
Latency Introduction: Asynchronous processing may introduce slight delays in communication delivery.
Monitoring Requirements: Requires monitoring of queue depths, consumer health, and message processing rates.
Complexity: Adds architectural complexity compared to synchronous processing.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ENABLE_LOYALTY_RMQ_COMM is set to true or enabled.
Verify RabbitMQ Infrastructure:
- Confirm that RabbitMQ infrastructure is available and accessible:
  - RabbitMQ server/cluster is running
  - Connection credentials are configured
  - Required queues and exchanges are created
  - Network connectivity is established
Review Queue Configuration:
- Check the RabbitMQ queue configuration for loyalty communications:
  - Queue names and bindings
  - Exchange types (direct, topic, fanout)
  - Routing keys
  - Dead-letter queue configuration
  - Message TTL (Time-To-Live) settings
  - Queue durability settings
Test Communication Event Publishing:
- Trigger a loyalty event that generates a communication (e.g., points earn).
- Verify that a message is published to the RabbitMQ queue.
- Check the queue to confirm the message is present.
Test Message Consumption:
- Verify that consumer services are running and connected to the queue.
- Confirm that messages are consumed and processed.
- Check that communications are delivered to customers.
Validate Message Content:
- Inspect messages in the queue to verify:
  - Correct message format and structure
  - All required data is included (customer ID, event type, details)
  - Proper serialization (JSON, etc.)
Test Asynchronous Behavior:
- Process a transaction and measure completion time.
- Verify that transaction completes without waiting for communication delivery.
- Confirm that communication is delivered shortly after (asynchronously).
Test Retry Mechanism:
- Simulate a communication delivery failure (e.g., invalid email).
- Verify that the message is retried according to retry policy.
- Check that failed messages are moved to dead-letter queue after max retries.
Monitor Queue Metrics:
- Access RabbitMQ management console or monitoring tools.
- Monitor:
  - Queue depth (messages waiting)
  - Message publish rate
  - Message consumption rate
  - Consumer count and status
  - Acknowledgment rates
  - Unacknowledged messages
Test High-Volume Scenarios:
- Generate a high volume of loyalty events (e.g., bulk transaction import).
- Verify that:
  - All messages are queued successfully
  - Consumers scale to handle the load
  - No messages are lost
  - Processing completes within acceptable time
Test Failover and Recovery:
- Simulate consumer service failure.
- Verify that messages remain in the queue.
- Restart consumer and confirm message processing resumes.
- Test RabbitMQ cluster failover (if applicable).
Check Dead-Letter Queue:
- Review the dead-letter queue for failed messages.
- Analyze failure reasons.
- Verify that dead-letter messages can be reprocessed or investigated.
Validate Different Communication Types:
- Test various loyalty communication events:
  - Points earned notification
  - Points redeemed notification
  - Tier upgrade alert
  - Points expiry reminder
  - Promotion notification
- Verify that each type is correctly routed and processed.
Review Logs:
- Check application logs for:
  - Message publishing confirmations
  - Consumer processing logs
  - Any errors or exceptions related to RMQ
- Check RabbitMQ logs for connection and queue issues.
Test Configuration Toggle:
- If possible, disable the configuration.
- Verify that communications fall back to the alternative processing method.
- Re-enable and confirm RMQ processing resumes.

19. `ENABLE_BULK_CONFIG_UPDATE`

Purpose: 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.
Detailed Explanation:

Bulk Configuration Update: The capability to update multiple configurations in a single operation, including:
- Promotion settings (earn rules, redemption rules, validity periods)
- Program parameters (tier thresholds, points expiry settings)
- Store/location configurations
- Customer segment rules
- Communication templates
- System settings and feature flags
By default, configuration updates may be limited to individual, one-at-a-time modifications through the UI or API.
When this configuration is enabled:
- Administrators can select and update multiple configurations in a single batch operation.
- Bulk updates can be performed via:
  - Admin UI with multi-select capabilities
  - Bulk upload files (CSV, Excel, JSON)
  - Batch API endpoints
- Changes are applied atomically or with transaction support where applicable.
- Audit trails capture all bulk changes for compliance and rollback purposes.
This is particularly useful for:
- Large-scale program changes (e.g., updating all promotions for a new fiscal year)
- Seasonal adjustments across multiple configurations
- Migration or onboarding scenarios requiring mass configuration setup
- Correcting widespread configuration errors efficiently
- Synchronizing configurations across multiple programs or regions

Example Use Case:

Default Behavior (Individual Updates): An administrator needs to extend the end date for 50 promotions. They must open each promotion individually, modify the end date, and save—a time-consuming and error-prone process.
With Bulk Config Update Enabled:
- Administrator selects all 50 promotions from a list.
- Chooses "Bulk Update" action.
- Specifies the new end date to apply to all selected promotions.
- Confirms the bulk update.
- All 50 promotions are updated simultaneously in seconds.
Scenario: A retail organization operates 500 stores, each with specific configuration settings. At the start of a new loyalty program year:
- Points earn rates need to be updated across all stores.
- Tier thresholds need to be adjusted for all programs.
- 200 promotions need their validity periods extended.
With bulk config update enabled:
- The administrator uploads a CSV file with new earn rates for all 500 stores.
- A single API call updates tier thresholds across all programs.
- All 200 promotions are extended with one bulk operation.
- What would take days of manual work is completed in minutes.

Impact:

Operational Efficiency: Dramatically reduces time required for large-scale configuration changes.
Reduced Human Error: Minimizes mistakes from repetitive manual updates.
Consistency: Ensures uniform changes are applied across all selected configurations.
Faster Time-to-Market: Enables rapid deployment of program-wide changes.
Simplified Administration: Reduces administrative burden for managing complex loyalty programs.
Risk of Mass Errors: A single mistake in bulk update can affect many configurations; requires careful validation.
Rollback Complexity: Rolling back bulk changes may be more complex than individual changes.
Performance Impact: Large bulk updates may temporarily impact system performance.
Access Control: Requires strict permission controls to prevent unauthorized mass changes.
Audit Requirements: Comprehensive audit logging is essential for tracking bulk modifications.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ENABLE_BULK_CONFIG_UPDATE is set to true or enabled.
Verify User Permissions:
- Confirm that appropriate role-based access controls are in place:
  - Only authorized administrators can perform bulk updates.
  - Different permission levels for different configuration types.
  - Approval workflows for critical bulk changes (if configured).
Test Bulk Update via UI:
- Navigate to a configuration management section (e.g., Promotions).
- Verify that bulk selection options are available (checkboxes, "Select All").
- Select multiple items and confirm "Bulk Update" action is available.
- Perform a test bulk update on non-production or test configurations.
- Verify all selected items are updated correctly.
Test Bulk Update via File Upload:
- Prepare a bulk update file (CSV/Excel/JSON) with configuration changes.
- Upload the file through the bulk update interface.
- Verify that:
  - File is validated before processing
  - Errors are reported clearly (e.g., invalid values, missing fields)
  - Valid updates are applied correctly
  - Summary report shows success/failure counts
Test Bulk Update via API:
- Use the bulk update API endpoint with a batch of configuration changes.
- Verify that:
  - API accepts bulk payloads
  - All configurations in the batch are updated
  - API response includes status for each item
  - Appropriate error handling for partial failures
Validate Update Accuracy:
- After bulk update, individually verify a sample of updated configurations.
- Confirm that all specified changes were applied correctly.
- Check that unmodified fields remain unchanged.
Test Validation and Error Handling:
- Attempt bulk updates with invalid data:
  - Invalid values (e.g., negative points, invalid dates)
  - Missing required fields
  - Conflicting configurations
- Verify that:
  - Validation errors are caught before processing
  - Clear error messages identify problematic items
  - Valid items can still be processed (if partial processing is supported)
Check Audit Trail:
- Review audit logs after performing bulk updates.
- Verify that logs capture:
  - User who performed the bulk update
  - Timestamp of the operation
  - List of configurations modified
  - Before and after values (or reference to change details)
  - Bulk operation identifier for grouping related changes
Test Rollback Capability:
- If rollback functionality is available:
  - Perform a bulk update
  - Initiate rollback of the bulk operation
  - Verify all configurations are restored to previous values
- If manual rollback is required:
  - Verify audit logs provide sufficient information for manual restoration
Test Transaction/Atomicity Behavior:
- Perform a bulk update where some items should succeed and others should fail.
- Verify the system behavior:
  - Atomic: All changes succeed or all are rolled back
  - Partial: Successful changes are applied, failures are reported
- Understand and document the expected behavior.
Evaluate Performance:
- Test bulk updates with varying batch sizes:
  - Small batch (10-50 items)
  - Medium batch (100-500 items)
  - Large batch (1,000+ items)
- Measure processing time and system impact.
- Identify any batch size limits or recommendations.
Test Concurrent Access:
- Attempt bulk update while another user is modifying individual configurations.
- Verify that:
  - Conflicts are handled appropriately
  - No data corruption occurs
  - Users are notified of conflicts
Validate Different Configuration Types:
- Test bulk updates for various configuration types:
  - Promotions
  - Earn rules
  - Tier settings
  - Store configurations
  - Communication templates
- Verify that bulk update works consistently across types.
Review Notification/Confirmation:
- Verify that administrators receive:
  - Confirmation before executing bulk updates (with summary of changes)
  - Completion notification after bulk update finishes
  - Summary report of successful and failed updates

20. `CONF_LIMITING_AGAINST_BILLING_MONTH`

Purpose: 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.
Detailed Explanation:

Billing Month: The month associated with a transaction based on the billing cycle or statement period, which may differ from:
- Transaction Date: The actual date when the purchase occurred
- Processing Date: The date when the transaction was processed in the system
- Calendar Month: The standard calendar month (January, February, etc.)
Limits and Caps: Restrictions applied to customer earning or redemption, including:
- Maximum points earnable per month
- Maximum discount per billing cycle
- Promotion usage limits per period
- Earn rate caps
- Redemption frequency limits
By default, limits may be evaluated against:
- Transaction date
- Processing/posting date
- Calendar month boundaries
When this configuration is enabled:
- Limits are calculated and enforced based on the billing month of the transaction.
- Transactions are grouped by their billing period for limit evaluation.
- Late-posted transactions are correctly attributed to their billing month.
- Billing cycle boundaries (not calendar month boundaries) determine limit resets.
This is particularly useful for:
- Credit card loyalty programs with statement cycles
- Subscription-based programs with billing periods
- B2B programs with invoice-based billing cycles
- Programs where transaction posting is delayed
- Ensuring fair limit application regardless of processing delays

Example Use Case:

Default Behavior (Calendar/Processing Month): A customer has a 10,000 points monthly earn cap. They make purchases on January 30th and 31st, but due to processing delays, the January 31st transaction posts on February 1st. The February transaction counts against February's cap, even though the purchase was made in January.
With Billing Month Limiting Enabled:
- The same customer makes purchases on January 30th and 31st.
- Both transactions have a billing month of January (based on billing cycle).
- Even if the January 31st transaction posts on February 1st, it counts against January's cap.
- February's cap remains fully available for actual February billing period transactions.
Scenario: A credit card loyalty program has the following setup:
- Billing cycle: 15th of each month to 14th of next month
- Monthly earn cap: 50,000 points
- Customer's transactions:

Transaction Date	Posting Date	Billing Month	Points
Jan 10	Jan 11	Dec 15 – Jan 14	20,000
Jan 12	Jan 13	Dec 15 – Jan 14	25,000
Jan 16	Jan 18	Jan 15 – Feb 14	30,000
Jan 20	Jan 22	Jan 15 – Feb 14	15,000

With billing month limiting:

Dec 15 - Jan 14 cycle: 45,000 points (within 50,000 cap)
- Jan 15 - Feb 14 cycle: 45,000 points (within 50,000 cap)
- All points are awarded correctly based on billing periods.

Impact:

Accurate Limit Enforcement: Limits are applied based on the actual billing period, not arbitrary calendar boundaries.
Fair Customer Treatment: Customers are not penalized for processing delays or posting timing.
Billing Cycle Alignment: Limits align with customer statements and billing communications.
Consistent Experience: Customers can track their limits against their billing statements.
Reduced Disputes: Fewer customer complaints about limit calculations that don't match their billing cycle.
Complexity: Requires accurate billing month data on transactions.
Data Dependency: System must have access to billing cycle information.
Retroactive Adjustments: Late transactions may affect already-calculated limits for past billing periods.
Reporting Alignment: Reports and analytics must account for billing month vs. calendar month differences.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that CONF_LIMITING_AGAINST_BILLING_MONTH is set to true or enabled.
Understand Billing Cycle Definition:
- Clarify how billing months are determined:
  - Fixed cycle dates (e.g., 1st to 31st, 15th to 14th)
  - Customer-specific billing cycles
  - Statement generation dates
- Identify where billing month data is stored on transactions.
Review Limit Configuration:
- Check the limits that should be evaluated against billing month:
  - Monthly earn caps
  - Promotion usage limits
  - Redemption limits
  - Category/brand-specific caps
- Verify that limits are configured with billing month evaluation.
Test Same Billing Month Transactions:
- Process multiple transactions within the same billing month.
- Verify that all transactions are grouped together for limit calculation.
- Confirm that limits are correctly enforced within the billing period.
Test Cross-Billing Month Transactions:
- Process transactions that span billing month boundaries.
- Verify that each transaction is attributed to its correct billing month.
- Confirm that limits reset at billing month boundaries (not calendar month).
Test Delayed Posting Scenario:
- Process a transaction with a transaction date in one billing month.
- Delay the posting/processing to the next calendar month.
- Verify that the transaction is still evaluated against the original billing month's limits.
Test Limit Cap Enforcement:
- Set up a test customer with a known monthly cap (e.g., 10,000 points).
- Process transactions within a billing month that exceed the cap.
- Verify that:
  - Points up to the cap are awarded
  - Points beyond the cap are correctly limited
  - Limit is evaluated against billing month, not calendar month
Test Billing Month Boundary:
- Process transactions on the last day of a billing month.
- Process transactions on the first day of the next billing month.
- Verify that:
  - Last day transaction counts against the ending billing month
  - First day transaction counts against the new billing month
  - Limits reset correctly at the boundary
Validate Limit Tracking:
- Check the customer's limit usage/tracking data.
- Verify that usage is tracked by billing month.
- Confirm that limit counters reset at billing month boundaries.
Test Multiple Limit Types:
- Test various limit types against billing month:
  - Overall earn cap
  - Promotion-specific limits
  - Category-specific caps
  - Redemption limits
- Verify consistent billing month evaluation across all limit types.
Check Customer-Facing Limit Display:
- If customers can view their limit usage:
  - Verify that displayed limits align with billing month
  - Confirm remaining limit calculations are accurate
  - Check that billing period dates are clearly communicated
Test Retroactive Transaction Scenarios:
- Post a late transaction to a past billing month.
- Verify that:
  - Transaction is attributed to the correct billing month
  - Past billing month limits are re-evaluated
  - Any over-limit situations are handled appropriately
Validate Reporting:
- Generate limit utilization reports.
- Verify that reports can be grouped by billing month.
- Confirm that report totals align with billing month calculations.
Test Edge Cases:
- Transactions exactly on billing month boundary timestamps.
- Transactions with missing or null billing month data.
- Customers with different billing cycle dates (if applicable).
- Billing months with different numbers of days.
- Year-end billing month transitions.
Compare with Calendar Month Behavior:
- If possible, test the same scenario with configuration disabled.
- Compare limit calculations between billing month and calendar month.
- Document the differences for stakeholder understanding.
Review Audit and Logs:
- Check system logs for limit evaluation events.
- Verify that logs indicate billing month is being used for limit calculation.
- Confirm that billing month attribution is logged for each transaction.

21. `AUTO_POINTS_CONVERSION_REWARD_ALLOWED`

Purpose: 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, cashback, or other benefits) once certain thresholds or conditions are met.
Detailed Explanation:

Points Conversion: The process of exchanging loyalty points for tangible rewards, including:
- Vouchers and coupons
- Cashback credits
- Gift cards
- Product rewards
- Partner rewards
- Account credits
Automatic Conversion: The system-initiated conversion of points to rewards without customer action, triggered by:
- Points balance reaching a threshold
- Time-based triggers (e.g., end of month, points expiry approaching)
- Tier-based automatic benefits
- Program rules and configurations
By default, points conversion typically requires:
- Customer-initiated redemption request
- Manual selection of reward type
- Explicit confirmation of conversion
When this configuration is enabled:
- Points are automatically converted to rewards when conditions are met.
- Customers receive rewards without needing to take action.
- Conversion rules define thresholds, reward types, and timing.
- Notifications inform customers of automatic conversions.
This is particularly useful for:
- Reducing points breakage by ensuring points are utilized
- Improving customer experience with effortless rewards
- Programs targeting customers who don't actively manage points
- Subscription or membership programs with automatic benefits
- Preventing points expiry by converting before expiration
- Simplifying the redemption process for customers

Example Use Case:

Default Behavior (Manual Conversion): A customer accumulates 10,000 points over several months. They must log into the app, navigate to rewards, select a voucher, and confirm the redemption. Many customers never complete this process, and points eventually expire unused.
With Auto Points Conversion Enabled:
- Customer accumulates 10,000 points.
- System automatically detects the balance has reached the 10,000-point threshold.
- Points are automatically converted to a $10 reward voucher.
- Customer receives a notification: "Congratulations! Your 10,000 points have been converted to a $10 voucher."
- Voucher is added to the customer's account, ready to use.
Scenario: A grocery loyalty program wants to maximize customer engagement and reduce points breakage:
- Auto-conversion rules configured:
  - At 5,000 points → Convert to $5 store voucher
  - At 10,000 points → Convert to $10 store voucher
  - 30 days before expiry → Convert remaining points to voucher (minimum 1,000 points)
With auto conversion enabled:
- Customer A reaches 5,000 points → Automatically receives $5 voucher
- Customer B has 3,500 points expiring in 25 days → Automatically converted to $3.50 voucher
- Customer C reaches 10,000 points → Automatically receives $10 voucher
- All customers receive rewards without any action required
- Points breakage is significantly reduced
- Customer satisfaction increases due to effortless rewards

Impact:

Reduced Points Breakage: Ensures points are converted to rewards before expiry.
Improved Customer Experience: Customers receive rewards automatically without effort.
Increased Engagement: Automatic rewards encourage customers to return and use them.
Simplified Program: Removes friction from the redemption process.
Higher Perceived Value: Customers feel rewarded without having to "work" for it.
Predictable Liability: Points are converted to defined rewards, making liability more predictable.
Loss of Customer Choice: Customers may prefer to choose their own rewards.
Unwanted Conversions: Some customers may not want automatic conversion (e.g., saving for larger rewards).
Communication Dependency: Requires robust notification system to inform customers of conversions.
Reward Inventory: Must ensure sufficient reward inventory for automatic issuance.
Opt-Out Considerations: May need to provide opt-out options for customers who prefer manual control.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that AUTO_POINTS_CONVERSION_REWARD_ALLOWED is set to true or enabled.
Review Auto-Conversion Rules:
- Check the configured auto-conversion rules:
  - Points threshold triggers (e.g., at 5,000 points, 10,000 points)
  - Time-based triggers (e.g., X days before expiry)
  - Reward types for each conversion rule
  - Conversion rates (points to reward value)
  - Minimum/maximum conversion amounts
  - Frequency limits (e.g., once per month)
Verify Reward Configuration:
- Confirm that rewards for auto-conversion are properly configured:
  - Reward/voucher templates exist
  - Reward values are defined
  - Validity periods are set
  - Reward inventory is available (if applicable)
Test Threshold-Based Conversion:
- Create a test customer with points just below the threshold.
- Add points to reach or exceed the threshold.
- Verify that:
  - Points are automatically converted to the specified reward
  - Correct number of points are deducted
  - Reward is issued to the customer's account
  - Conversion happens within expected timeframe
Test Expiry-Based Conversion:
- Create a test customer with points approaching expiry.
- Wait for the expiry trigger window (e.g., 30 days before expiry).
- Verify that:
  - Points are automatically converted before expiry
  - Conversion follows the expiry-based rules
  - Customer retains value that would have been lost
Validate Conversion Accuracy:
- Test various points balances and verify conversion calculations:
  - Exact threshold amount (e.g., exactly 5,000 points)
  - Above threshold (e.g., 5,500 points - verify if excess is converted or retained)
  - Multiple threshold levels (e.g., 10,000 points triggering higher-value reward)
- Confirm conversion rates are applied correctly.
Check Customer Notifications:
- Verify that customers receive notifications for auto-conversions:
  - Notification is sent promptly after conversion
  - Message clearly explains the conversion (points deducted, reward received)
  - Reward details and usage instructions are included
  - Notification channel matches customer preferences (email, SMS, push)
Verify Points Ledger:
- Review the customer's points ledger after auto-conversion.
- Confirm that:
  - Points deduction is recorded with appropriate reason/description
  - Transaction reference links to the reward issued
  - Balance is updated correctly
Verify Reward Issuance:
- Check the customer's reward/voucher wallet.
- Confirm that:
  - Reward is visible and accessible
  - Reward value matches the conversion
  - Validity period is correct
  - Reward is usable (test redemption if possible)
Test Conversion Frequency Limits:
- If frequency limits are configured (e.g., max one auto-conversion per month):
  - Trigger multiple conversion conditions within the limit period
  - Verify that only the allowed number of conversions occur
  - Confirm subsequent conversions are queued or skipped appropriately
Test Opt-Out Functionality (if available):
- If customers can opt out of auto-conversion:
  - Set a test customer to opt-out status
  - Trigger conversion conditions
  - Verify that no automatic conversion occurs
  - Confirm points remain in the customer's account
Test Edge Cases:
- Points balance exactly at threshold
- Points balance just below minimum conversion amount
- Multiple conversion rules applicable simultaneously
- Customer with zero or negative points balance
- Conversion during points freeze or account suspension
- Conversion when reward inventory is depleted
Validate Batch Processing:
- If auto-conversion runs as a batch job:
  - Verify job scheduling and execution
  - Check job logs for successful processing
  - Confirm all eligible customers are processed
  - Monitor job performance and duration
Review Audit Trail:
- Check audit logs for auto-conversion events:
  - Conversion trigger reason
  - Points converted
  - Reward issued
  - Timestamp
  - System/job identifier
Test Reporting:
- Generate reports on auto-conversions:
  - Total points converted
  - Number of customers affected
  - Rewards issued by type
  - Conversion trends over time
- Verify report accuracy against actual conversions.
Validate Financial Reconciliation:
- Confirm that auto-conversions are properly reflected in:
  - Points liability reports
  - Reward liability reports
  - Financial reconciliation statements

22. `CONF_REVOKE_BADGE_ON_RETURN`

Purpose: 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 that were earned through transactions that are no longer valid.
Detailed Explanation:

Badges: Recognition awards given to customers for achieving specific milestones or completing certain activities, such as:
- First purchase badge
- Spending milestone badges (e.g., "Spent $500", "Spent $1,000")
- Category-specific badges (e.g., "Fashion Enthusiast", "Tech Lover")
- Frequency badges (e.g., "5 Visits", "10 Purchases")
- Promotional or campaign badges
- Behavioral badges (e.g., "Early Bird Shopper", "Weekend Warrior")
Badge Revocation: The removal of a previously awarded badge from a customer's profile when the qualifying criteria are no longer met.
By default, badges may be:
- Permanently awarded once earned (never revoked)
- Manually managed by administrators
- Not linked to transaction reversals
When this configuration is enabled:
- The system automatically evaluates badge eligibility when returns/reversals occur.
- Badges earned from returned transactions are automatically revoked.
- Customer badge counts and collections are updated in real-time.
- Badge history maintains a record of revocations for audit purposes.
This is particularly useful for:
- Maintaining badge integrity and accuracy
- Preventing gaming of badge systems through purchase-and-return behavior
- Programs where badges unlock tangible benefits or rewards
- Ensuring fairness among customers
- Compliance with program terms and conditions

Example Use Case:

Default Behavior (No Revocation): A customer makes a $500 purchase and earns the "Big Spender" badge. They then return the entire purchase for a refund. The customer retains the "Big Spender" badge despite no longer meeting the criteria.
With Badge Revocation on Return Enabled:
- Customer makes a $500 purchase.
- System awards the "Big Spender" badge (requires $500+ single purchase).
- Customer returns the $500 purchase the next day.
- System detects the return and evaluates badge eligibility.
- "Big Spender" badge is automatically revoked.
- Customer is notified of the badge revocation.
Scenario: A fashion retailer has a badge program with the following badges:
- "Fashion Forward": Purchase 5 items from the Fashion category
- "Premium Shopper": Single transaction of $300+
- "Loyal Customer": Complete 10 transactions
With badge revocation enabled:
- Customer buys 5 fashion items → Earns "Fashion Forward" badge
- Customer returns 2 fashion items → Badge is revoked (only 3 qualifying items remain)
- Customer makes a $350 purchase → Earns "Premium Shopper" badge
- Customer returns $100 worth of items → Badge is revoked (transaction value now $250)
- Customer completes 10 transactions → Earns "Loyal Customer" badge
- Customer returns 1 full transaction → Badge is revoked (only 9 valid transactions)

Impact:

Badge Integrity: Badges accurately represent genuine customer achievements.
Fraud Prevention: Prevents gaming through purchase-and-return schemes to collect badges.
Fair Recognition: Ensures all customers earn badges through legitimate qualifying activities.
Benefit Protection: If badges unlock rewards or benefits, revocation prevents unearned access.
Program Credibility: Maintains the value and credibility of the badge program.
Customer Experience Risk: Customers may be frustrated by badge revocation, especially if unexpected.
Communication Necessity: Requires clear communication about revocation policies.
Complexity: Adds complexity to return processing and badge management.
Edge Cases: Partial returns, exchanges, and timing issues require careful handling.
Historical Badges: Need to determine policy for badges earned before configuration was enabled.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that CONF_REVOKE_BADGE_ON_RETURN is set to true or enabled.
Review Badge Configuration:
- Understand the badges configured in the system:
  - Badge names and descriptions
  - Earning criteria for each badge
  - Whether each badge is eligible for revocation
  - Any badges exempt from revocation rules
Understand Revocation Logic:
- Clarify how revocation is evaluated:
  - Is the original qualifying transaction tracked?
  - Are cumulative criteria re-evaluated (e.g., total spend)?
  - What happens with partial returns?
  - Is there a grace period before revocation?
Test Single Transaction Badge Revocation:
- Award a badge based on a single transaction (e.g., "Spent $500+").
- Process a full return of that transaction.
- Verify that:
  - Badge is automatically revoked
  - Customer's badge collection is updated
  - Badge no longer appears on customer profile
Test Cumulative Badge Revocation:
- Award a badge based on cumulative criteria (e.g., "5 purchases").
- Process a return that brings the count below the threshold.
- Verify that:
  - System re-evaluates cumulative criteria
  - Badge is revoked when threshold is no longer met
  - Badge is retained if threshold is still met after return
Test Partial Return Scenario:
- Award a badge based on transaction value (e.g., "$300+ purchase").
- Process a partial return that reduces the transaction below the threshold.
- Verify that:
  - Badge is revoked if remaining value is below threshold
  - Badge is retained if remaining value still meets threshold
Verify Customer Notification:
- After badge revocation, check that the customer receives notification:
  - Notification is sent promptly
  - Message clearly explains which badge was revoked
  - Reason for revocation is provided
  - Information on how to re-earn the badge is included (if applicable)
Check Badge History:
- Review the customer's badge history.
- Verify that:
  - Original badge award is recorded
  - Revocation event is recorded with timestamp
  - Reason for revocation is captured
  - History provides complete audit trail
Test Re-Earning Revoked Badge:
- After badge revocation, have the customer complete qualifying activity again.
- Verify that:
  - Badge can be re-earned
  - Re-earned badge is properly awarded
  - Badge history shows the re-earn event
Test Badge with Unlocked Benefits:
- If badges unlock benefits (e.g., discounts, access):
  - Award a badge that unlocks a benefit
  - Verify benefit is accessible
  - Process return to trigger revocation
  - Verify that:
    - Badge is revoked
    - Associated benefit is also revoked/disabled
    - Customer can no longer access the benefit
Test Multiple Badges from Same Transaction:
- Process a transaction that awards multiple badges.
- Return the transaction.
- Verify that all applicable badges are revoked.
Test Timing and Delays:
- Process a return after significant time has passed since the original transaction.
- Verify that revocation still occurs correctly.
- Check if there are any time limits on revocation eligibility.
Test Edge Cases:
- Return processed on a different day than original transaction
- Exchange (return + new purchase in same transaction)
- Partial return that still meets badge criteria
- Return of transaction that contributed to multiple badges
- Badge earned from non-transactional activity (should not be affected by returns)
- Customer with badge earned before configuration was enabled
Validate Exemptions:
- If certain badges are exempt from revocation:
  - Test that exempt badges are not revoked on return
  - Verify exemption rules are correctly applied
Review Audit Logs:
- Check system audit logs for badge revocation events:
  - Customer identifier
  - Badge revoked
  - Triggering return transaction
  - Timestamp
  - System process that executed revocation
Test Reporting:
- Generate badge reports and verify:
  - Revocation counts are tracked
  - Revocation reasons are categorized
  - Badge retention rates can be analyzed
  - Reports distinguish between earned, revoked, and active badges
Validate Customer-Facing Display:
- Check customer-facing interfaces (app, web portal):
  - Revoked badges are removed from active badge display
  - Badge count is updated correctly
  - Any badge-related status or tier is updated

23. `CONF_ADDITIONAL_TRACKERS_IN_SLAB_UPGRADE_AND_RENEW`

The configuration CONF_ADDITIONAL_TRACKERS_IN_SLAB_UPGRADE_AND_RENEW is related to slab upgrades and renewals in a loyalty program. It is used to define additional trackers that should be considered when determining a customer's eligibility for a slab upgrade or renewal.

Purpose:
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
Points earned or redeemed
Example Use Case:
Default Tracker: By default, a slab upgrade might only consider the customer's total spend.
Additional Trackers: With this configuration, the system can also consider other trackers, such as:
Number of visits
Number of items purchased
Points earned from specific promotions
Impact: This ensures that customers who meet the criteria through multiple activities (not just the default tracker) are eligible for slab upgrades or renewals.
How to Verify:
Check Tracker Configurations:
Review the tracker settings in the loyalty program to see which trackers are included by default and which are added via this configuration.
Analyze Workflow Logic:
Look at the slab upgrade and renewal workflows to see how these additional trackers are factored into the decision-making process.
Evaluate EMF Logs:
Check the EMF logs to confirm how these additional trackers influence the slab upgrade or renewal process.

24. `CONF_EMF_NUM_RECOMMENDATIONS`

The configuration CONF_EMF_NUM_RECOMMENDATIONS is typically related to EMF (Event Management Framework) and is used to define the number of recommendations that should be generated or processed in a specific workflow or system.

Purpose:

It is likely used in scenarios where recommendations (e.g., product recommendations, content recommendations, or similar) are generated based on certain rules or logic.
This configuration determines the maximum number of recommendations that should be provided or displayed to the user.

Example Use Case:

If a system is configured to recommend products to a customer based on their purchase history, this configuration might limit the number of recommendations shown (e.g., 5 recommendations).

How to Verify:

To confirm its exact purpose and usage:

Check the workflow logic in the EMF logs to see where this configuration is applied.
Review the rulesets, conditions, and actions in the workflow to understand how this configuration impacts the recommendation process.

25. `CONF_EMF_ROLLOUT_STATUS`

Purpose: 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.

Detailed Explanation:

EMF (Event Management Framework): A core system component that handles the processing of events within the loyalty platform, including:
- Transaction events (purchases, returns, exchanges)
- Customer events (registration, profile updates, tier changes)
- Points events (earn, redeem, expire, transfer)
- Promotion events (qualification, reward issuance)
- Communication events (triggers, deliveries)
- Integration events (external system interactions)
Rollout Status: The deployment state of EMF, which can typically be:
- DISABLED / OFF: EMF is not active; legacy event processing is used
- PILOT / PARTIAL: EMF is enabled for select features, stores, or customer segments
- ENABLED / FULL: EMF is fully active for all event processing
- MIGRATION: Transitional state during migration from legacy to EMF
By default, organizations may be on legacy event processing systems.
When this configuration is set:
- The system routes events through the appropriate processing framework based on the status.
- Feature availability may depend on EMF rollout status.
- Performance characteristics and capabilities change based on the active framework.
- Monitoring and logging behavior aligns with the configured status.
This is particularly useful for:
- Phased migration from legacy systems to EMF
- Risk mitigation during system upgrades
- A/B testing of event processing frameworks
- Gradual rollout to monitor performance and stability
- Quick rollback capability if issues arise

Example Use Case:

Default Behavior (DISABLED): All events are processed through the legacy event processing system. EMF features and capabilities are not available.
With Rollout Status Set to PILOT:
- EMF is enabled for specific stores or regions (e.g., pilot stores).
- Transactions from pilot stores are processed through EMF.
- Transactions from other stores continue using legacy processing.
- Performance and accuracy are monitored before full rollout.
Scenario: A large retail organization is migrating to EMF in phases:
Phase 1 - DISABLED:
- All 500 stores use legacy event processing.
- EMF infrastructure is set up and tested in isolation.
Phase 2 - PILOT:
- 10 pilot stores are migrated to EMF.
- Status: CONF_EMF_ROLLOUT_STATUS = PILOT
- Pilot store transactions processed via EMF.
- Remaining 490 stores continue on legacy.
- 4-week monitoring period for stability and performance.
Phase 3 - MIGRATION:
- Gradual rollout to additional stores in batches.
- Status: CONF_EMF_ROLLOUT_STATUS = MIGRATION
- 50 stores per week migrated to EMF.
- Dual monitoring of both systems.
Phase 4 - ENABLED:
- All 500 stores on EMF.
- Status: CONF_EMF_ROLLOUT_STATUS = ENABLED
- Legacy system decommissioned.
- Full EMF capabilities available.

Impact:

Controlled Migration: Enables safe, phased migration to EMF with rollback capability.
Risk Mitigation: Limits blast radius of potential issues during migration.
Performance Optimization: Allows performance comparison between legacy and EMF.
Feature Availability: Some advanced features may only be available with EMF enabled.
Monitoring Clarity: Clear understanding of which system is processing events.
Flexibility: Supports various rollout strategies (by store, region, customer segment).
Complexity: Managing two parallel systems during migration adds operational complexity.
Consistency: Must ensure consistent behavior between legacy and EMF during transition.
Testing Requirements: Requires thorough testing at each rollout phase.
Resource Utilization: May require running both systems simultaneously during migration.
Training: Teams need to understand both systems during transition period.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm the value of CONF_EMF_ROLLOUT_STATUS.
- Note the current status (e.g., DISABLED, PILOT, MIGRATION, ENABLED).
Understand Status Definitions:
- Clarify what each status value means for the organization:
  - Which features are enabled/disabled at each status
  - Which entities (stores, regions, segments) are affected
  - What processing path events take at each status
Verify Infrastructure Readiness:
- Confirm that EMF infrastructure is properly set up:
  - EMF services are deployed and running
  - Message queues are configured
  - Database connections are established
  - Monitoring and alerting are in place
Test Event Routing (PILOT/MIGRATION Status):
- Process a transaction from a pilot/migrated entity.
- Verify that the event is routed through EMF.
- Process a transaction from a non-migrated entity.
- Verify that the event is routed through legacy processing.
Validate Event Processing:
- For EMF-processed events, verify:
  - Events are captured correctly
  - Event payloads contain all required data
  - Events are processed in the correct order
  - Processing outcomes match expected results
Check EMF Logs:
- Review EMF processing logs:
  - Events received and processed
  - Processing duration and performance
  - Any errors or exceptions
  - Event routing decisions
Compare Legacy vs. EMF Processing:
- Process identical transactions through both systems (if possible).
- Compare outcomes:
  - Points calculations
  - Promotion evaluations
  - Tier evaluations
  - Communication triggers
- Verify consistency between systems.
Test Feature Availability:
- Identify features that depend on EMF.
- Verify that:
  - EMF-dependent features work when status is ENABLED
  - EMF-dependent features are appropriately disabled/hidden when status is DISABLED
  - Partial feature availability aligns with PILOT/MIGRATION status
Monitor Performance Metrics:
- Compare performance metrics between legacy and EMF:
  - Event processing latency
  - Throughput (events per second)
  - Error rates
  - Resource utilization
- Verify that EMF meets or exceeds performance requirements.
Test Rollback Capability:
- If issues arise, verify that rollback is possible:
  - Change status from PILOT/MIGRATION back to DISABLED
  - Confirm events route back to legacy processing
  - Verify no data loss or inconsistency during rollback
Validate Entity-Level Configuration:
- If rollout is by entity (store, region):
  - Verify the list of EMF-enabled entities
  - Confirm entity-level routing is accurate
  - Test boundary cases (new stores, store transfers)
Check Integration Points:
- Verify that integrations work correctly with EMF:
  - External system callbacks
  - Webhook deliveries
  - API responses
  - Real-time data feeds
Test Error Handling:
- Simulate error conditions:
  - EMF service unavailable
  - Message queue failures
  - Processing exceptions
- Verify that:
  - Errors are handled gracefully
  - Fallback mechanisms work (if configured)
  - Alerts are triggered appropriately
Validate Data Consistency:
- After processing events through EMF:
  - Verify customer data is accurate
  - Confirm points balances are correct
  - Check that tier statuses are properly updated
  - Validate promotion tracking is accurate
Review Audit Trail:
- Check that EMF maintains proper audit trails:
  - Event timestamps
  - Processing decisions
  - Outcome records
  - Error logs
Test Status Transitions:
- Test changing the rollout status:
  - DISABLED → PILOT
  - PILOT → MIGRATION
  - MIGRATION → ENABLED
  - ENABLED → DISABLED (rollback)
- Verify that transitions are smooth and properly logged.
Validate Monitoring and Alerting:
- Confirm that monitoring is configured for the current status:
  - EMF health dashboards
  - Processing metrics
  - Error rate alerts
  - Queue depth monitoring
- Verify alerts trigger appropriately for anomalies.
Check Documentation and Runbooks:
- Verify that operational documentation reflects the current status:
  - Troubleshooting guides
  - Escalation procedures
  - Rollback instructions
  - Contact information for support

26. `ENABLE_GROUP_PROGRAMS_REDEMPTION`

Purpose: 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.

Detailed Explanation:

Group Programs: A collection of related loyalty programs operating under a common umbrella, typically representing:
- Multiple brands under one parent company
- Different business units or divisions
- Regional programs within a global structure
- Partner programs in a coalition
- Sub-programs within a master loyalty program
Cross-Program Redemption: The ability to use points earned in Program A to redeem rewards in Program B, where both programs belong to the same group.
By default, loyalty programs operate in isolation:
- Points earned in Program A can only be redeemed in Program A
- Each program maintains separate points balances
- No cross-program visibility or redemption capability
When this configuration is enabled:
- Customers can redeem points across any program within the group.
- Points balances may be consolidated or visible across programs.
- Redemption rules can span multiple programs.
- Unified customer experience across the program group.
This is particularly useful for:
- Conglomerates with multiple retail brands
- Hospitality groups with multiple hotel/restaurant brands
- Airlines with partner programs
- Retail groups wanting to encourage cross-brand shopping
- Organizations consolidating previously separate loyalty programs

Example Use Case:

Default Behavior (Isolated Programs): A customer earns 5,000 points at Brand A and 3,000 points at Brand B (both owned by the same parent company). They can only redeem 5,000 points at Brand A and 3,000 points at Brand B separately. They cannot combine points for a larger redemption.
With Group Programs Redemption Enabled:

Customer earns 5,000 points at Brand A.
- Customer earns 3,000 points at Brand B.
- Customer can now redeem all 8,000 points at either Brand A or Brand B.
- Customer chooses to redeem 8,000 points for a $80 voucher at Brand A.
- Points are deducted proportionally or from a consolidated balance.
Scenario: A hospitality conglomerate operates three brands:
- Luxury Hotels: High-end properties, 10 points per $1
- Business Hotels: Mid-tier properties, 5 points per $1
- Budget Hotels: Economy properties, 3 points per $1
With group programs redemption enabled:
- A business traveler earns 50,000 points at Business Hotels throughout the year.
- For a vacation, they want to stay at a Luxury Hotel.
- They can redeem their 50,000 Business Hotels points for a free night at Luxury Hotels.
- The redemption is processed seamlessly across programs.
- Customer enjoys a unified loyalty experience across all three brands.
Redemption Options Available:

Program	Points Balance	Can Redeem At
Luxury Hotels	20,000	Luxury, Business, Budget
Business Hotels	50,000	Luxury, Business, Budget
Budget Hotels	10,000	Luxury, Business, Budget
Total Available	80,000	Any Program

Impact:

Enhanced Customer Flexibility: Customers can redeem points where it's most valuable to them.
Unified Experience: Creates a cohesive loyalty experience across brands.
Increased Engagement: Encourages customers to engage with multiple brands in the group.
Higher Perceived Value: Larger combined points balance feels more valuable.
Cross-Brand Traffic: Drives customers to try other brands within the group.
Reduced Breakage: More redemption options mean fewer expired/unused points.
Complexity: Cross-program redemption adds complexity to points management.
Liability Allocation: Need to determine how points liability is allocated across programs.
Conversion Rates: May require points conversion rates between programs with different earn rates.
Fraud Risk: Cross-program redemption may create new fraud vectors.
Reconciliation: Financial reconciliation between programs becomes more complex.
System Integration: Requires integration between program systems.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ENABLE_GROUP_PROGRAMS_REDEMPTION is set to true or enabled.
Identify Group Structure:
- Understand the program group structure:
  - Which programs are in the group
  - Program identifiers and relationships
  - Any hierarchy or parent-child relationships
  - Programs excluded from cross-redemption (if any)
Review Redemption Rules:
- Check the cross-program redemption rules:
  - Which programs can redeem from which
  - Points conversion rates between programs (if different)
  - Minimum/maximum redemption amounts
  - Any restrictions or exclusions
Verify Points Visibility:
- Check if customers can see points from all programs:
  - Consolidated balance view
  - Individual program balances
  - Points source identification
Test Cross-Program Redemption:
- Create a test customer with points in Program A.
- Attempt to redeem points at Program B.
- Verify that:
  - Redemption is allowed
  - Correct points are deducted from Program A
  - Reward is issued in Program B
  - Transaction is recorded in both programs
Test Points Conversion (if applicable):
- If programs have different points values:
  - Verify conversion rates are applied correctly
  - Test redemption with conversion calculation
  - Confirm customer sees accurate converted values
Test Multi-Program Points Combination:
- Create a test customer with points in multiple programs.
- Attempt a redemption that requires combining points from multiple programs.
- Verify that:
  - Points from multiple programs can be combined
  - Deduction is allocated correctly across programs
  - Total redemption value is accurate
Validate Redemption at Each Program:
- Test redemption scenarios at each program in the group:
  - Redeem Program A points at Program A (same program)
  - Redeem Program A points at Program B (cross-program)
  - Redeem Program A points at Program C (cross-program)
- Verify consistent behavior across all combinations.
Test Partial Redemption:
- Test redeeming only a portion of available cross-program points.
- Verify that:
  - Partial redemption is processed correctly
  - Remaining points are accurate in source program
  - Points deduction priority is followed (if configured)
Check Points Ledger:
- Review points ledger entries after cross-program redemption:
  - Deduction entry in source program
  - Reference to redemption in destination program
  - Accurate timestamps and transaction IDs
  - Clear audit trail
Test Redemption Restrictions:
- If certain redemptions are restricted:
  - Test restricted scenarios (should be blocked)
  - Test allowed scenarios (should succeed)
  - Verify clear error messages for restrictions
Validate Customer-Facing Experience:
- Check customer-facing interfaces:
  - Points balance display (consolidated or by program)
  - Redemption options show cross-program availability
  - Clear indication of which program points will be used
  - Confirmation screens show accurate details
Test Reversal/Cancellation:
- Process a cross-program redemption.
- Cancel or reverse the redemption.
- Verify that:
  - Points are restored to the correct source program
  - Reward is cancelled in the destination program
  - Ledger entries reflect the reversal
Check Liability Allocation:
- Verify how points liability is managed:
  - Which program bears the liability for cross-program redemption
  - Inter-program settlement or transfer mechanisms
  - Financial reporting accuracy
Test Edge Cases:
- Redemption exactly equal to single program balance
- Redemption requiring points from all programs in group
- Customer with zero balance in one program
- Redemption at a program where customer has no earn history
- Simultaneous redemptions across programs
- Redemption during points expiry processing
Validate Reporting:
- Generate redemption reports:
  - Cross-program redemption volumes
  - Points flow between programs
  - Redemption by source and destination program
- Verify report accuracy and completeness.
Test Program-Specific Rules:
- If programs have different redemption rules:
  - Verify destination program rules are applied
  - Test minimum redemption thresholds
  - Check reward availability by program
Review Notifications:
- Verify customer notifications for cross-program redemption:
  - Redemption confirmation includes program details
  - Points source is clearly identified
  - Reward details and usage instructions are accurate
Test API Behavior:
- Test cross-program redemption via API:
  - API accepts cross-program redemption requests
  - Response includes accurate program information
  - Error handling for invalid cross-program requests
Validate Fraud Controls:
- Verify fraud prevention measures:
  - Velocity limits across programs
  - Suspicious activity detection
  - Cross-program redemption monitoring

27. `SUPPLEMENTARY_PARTNER_PROGRAM_LIMIT`

Purpose: 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.

Detailed Explanation:

Supplementary Partner Programs: External loyalty programs or partners that integrate with the primary loyalty program to provide:
- Points earning opportunities at partner locations
- Points redemption options with partners
- Points transfer capabilities between programs
- Reciprocal benefits and rewards
- Coalition loyalty partnerships
Partner Program Limit: The maximum count of partner programs that can be configured and active simultaneously.
By default, there may be no limit or a very high default limit on partner programs.
When this configuration is set:
- The system enforces the specified maximum number of partner programs.
- Attempts to add partners beyond the limit are blocked.
- Organizations must prioritize and manage their partner portfolio.
- System resources are protected from excessive partner integrations.
This is particularly useful for:
- Managing system complexity and performance
- Controlling integration and maintenance overhead
- Ensuring quality over quantity in partner relationships
- License or contractual compliance
- Tiered partnership offerings (basic vs. premium partner slots)
- Governance and operational control

Example Use Case:

Default Behavior (No Limit): An organization can add unlimited partner programs, potentially leading to system performance issues, integration complexity, and operational overhead.
With Partner Program Limit Set (e.g., 25):
- Organization can configure up to 25 supplementary partner programs.
- When attempting to add the 26th partner, the system blocks the addition.
- Administrator receives a message: "Partner program limit reached. Maximum 25 partner programs allowed."
- Organization must remove an existing partner or request a limit increase.
Scenario: A regional airline loyalty program manages partnerships strategically:
SUPPLEMENTARY_PARTNER_PROGRAM_LIMIT = 20
Current Partner Portfolio (18/20 slots used):

Category	Partners	Count
Hotels	Marriott, Hilton, IHG	3
Car Rental	Hertz, Avis, Enterprise	3
Retail	Amazon, Walmart, Target	3
Dining	DoorDash, Uber Eats	2
Financial	Chase, Amex, Citi	3
Travel	Booking.com, Expedia	2
Fuel	Shell, BP	2
Total	—	18

Available Slots: 2 remaining
With this limit:
- The airline can add 2 more strategic partners.
- New partnership requests are evaluated carefully.
- Low-performing partners may be removed to make room for better opportunities.
- System performance remains stable with a controlled number of integrations.

Impact:

System Performance: Limits prevent excessive integrations that could degrade performance.
Operational Manageability: Keeps partner portfolio at a manageable size.
Quality Focus: Encourages focus on high-value partnerships over quantity.
Resource Planning: Predictable integration and maintenance workload.
Governance: Provides control over partner ecosystem growth.
Cost Control: Limits integration and ongoing maintenance costs.
Strategic Prioritization: Forces prioritization of most valuable partnerships.
Business Constraints: May limit growth opportunities if limit is too restrictive.
Partner Relationships: May need to decline or delay potential partnerships.
Flexibility: Requires limit adjustment process for legitimate expansion needs.
Competitive Disadvantage: Competitors with more partners may offer broader earning/redemption options.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm the value of SUPPLEMENTARY_PARTNER_PROGRAM_LIMIT.
- Note the maximum number of partner programs allowed.
Count Current Partner Programs:
- List all currently configured supplementary partner programs.
- Count the total number of active partners.
- Calculate remaining available slots (Limit - Current Count).
Review Partner Program List:
- Access the partner program management interface.
- Verify the list of configured partners:
  - Partner program names
  - Partner program IDs
  - Integration status (active, inactive, pending)
  - Partner categories
Test Adding Partner Within Limit:
- If slots are available, attempt to add a new partner program.
- Verify that:
  - Partner is added successfully
  - Partner count increases by one
  - Partner appears in the active partner list
  - Integration can be configured
Test Adding Partner at Limit:
- If at or near the limit, attempt to add a partner that would exceed the limit.
- Verify that:
  - System blocks the addition
  - Clear error message is displayed indicating limit reached
  - Existing partners are not affected
  - Guidance is provided (remove partner or request increase)
Verify Limit Enforcement Points:
- Test limit enforcement at various points:
  - Admin UI partner creation
  - API partner creation
  - Bulk partner import (if available)
- Confirm consistent enforcement across all methods.
Test Partner Removal:
- Remove an existing partner program.
- Verify that:
  - Partner count decreases
  - Slot becomes available for new partner
  - Previously blocked addition now succeeds
Check Partner Status Impact:
- Verify how different partner statuses affect the count:
  - Active partners (should count toward limit)
  - Inactive partners (verify if counted or not)
  - Pending partners (verify if counted or not)
  - Suspended partners (verify if counted or not)
Validate UI Display:
- Check partner management interface:
  - Current partner count is displayed
  - Limit is visible
  - Remaining slots are shown
  - Visual indicator when approaching limit
Test Limit Modification:
- If limit can be modified:
  - Increase the limit and verify more partners can be added
  - Decrease the limit below current count and verify behavior
  - Check if existing partners are affected by limit decrease
Review Partner Categories:
- If limits apply per category:
  - Verify category-specific limits
  - Test adding partners within each category
  - Confirm cross-category limit behavior
Test Bulk Operations:
- If bulk partner import is available:
  - Attempt to import partners that would exceed limit
  - Verify partial success (up to limit) or complete rejection
  - Check error reporting for bulk operations
Validate API Behavior:
- Test partner management APIs:
  - GET partners returns accurate count
  - POST new partner respects limit
  - API error responses are clear and informative
  - Rate limiting or throttling behavior
Check Audit Trail:
- Review audit logs for partner management:
  - Partner additions logged
  - Partner removals logged
  - Limit-blocked attempts logged
  - User/admin who performed actions
Test Edge Cases:
- Exactly at limit (adding one more should fail)
- One below limit (adding one should succeed)
- Simultaneous partner additions approaching limit
- Partner with multiple integration types (count as one or multiple?)
- Reactivating a previously removed partner
Verify Reporting:
- Generate partner program reports:
  - Total partner count
  - Partners by category
  - Partner utilization/performance
  - Limit utilization percentage
Check Notifications/Alerts:
- Verify alerts are configured for:
  - Approaching limit threshold (e.g., 80% utilized)
  - Limit reached
  - Partner addition blocked
- Confirm notifications reach appropriate administrators.
Review Documentation:
- Verify that partner limit is documented:
  - Current limit value
  - Process to request limit increase
  - Partner prioritization guidelines
  - Impact of limit on partnership strategy
Test Integration Impact:
- Verify that existing partner integrations continue to function:
  - Points earning at partners
  - Points redemption with partners
  - Points transfer between programs
  - Partner data synchronization
Validate License/Contract Compliance:
- If limit is tied to licensing or contracts:
  - Verify limit matches contractual terms
  - Check for limit tier options (upgrade paths)
  - Confirm compliance reporting is accurate

28. `ALLOW_POINTS_TRANSFER`

Purpose: 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.

Detailed Explanation:

Points Transfer: The movement of points from one customer's account to another customer's account within the same loyalty program, including:
- Gifting points to friends or family
- Pooling points within a household
- Transferring points between personal accounts
- Corporate-to-employee points transfers
- Points donations to charity accounts
Transfer Types: Various transfer scenarios that may be supported:
- One-to-One: Single sender to single recipient
- Household Pooling: Multiple family members sharing a points pool
- Bulk Transfer: One sender to multiple recipients
- Scheduled Transfer: Recurring or future-dated transfers
By default, points are typically locked to the earning customer's account with no transfer capability.
When this configuration is enabled:
- Customers can initiate points transfers to other members.
- Transfer rules and limits are enforced.
- Both sender and recipient accounts are updated accordingly.
- Transfer history is maintained for audit purposes.
This is particularly useful for:
- Family loyalty programs where members want to combine points
- Gift-giving occasions (birthdays, holidays)
- Helping others reach redemption thresholds
- Corporate programs with employee rewards
- Increasing program engagement and perceived value
- Reducing points expiry by enabling transfers to active users

Example Use Case:

Default Behavior (Transfers Disabled): A customer has 15,000 points but needs 20,000 for a desired reward. Their spouse has 10,000 points in a separate account. They cannot combine points and must each redeem for lesser rewards individually.
With Points Transfer Enabled:
- Customer A has 15,000 points.
- Customer A's spouse (Customer B) has 10,000 points.
- Customer B transfers 5,000 points to Customer A.
- Customer A now has 20,000 points and can redeem for the desired reward.
- Customer B retains 5,000 points.
- Both customers receive confirmation of the transfer.
Scenario: A family loyalty program for a retail chain:
Transfer Rules Configured:
- Maximum transfer per transaction: 10,000 points
- Maximum transfers per month: 3
- Minimum transfer amount: 500 points
- Transfer fee: None (or 5% of points transferred)
- Eligible recipients: Any program member
Family Points Pooling Example:

Family Member	Starting Balance	Transfer	Ending Balance
Parent 1	25,000	Receives 15,000	40,000
Parent 2	18,000	Sends 8,000	10,000
Teen Child	12,000	Sends 7,000	5,000
Total	55,000	—	55,000

With transfers enabled:
- Family consolidates points to Parent 1's account.
- Parent 1 redeems 40,000 points for a family vacation package.
- Remaining points stay with individual members.
- Family achieves a reward none could reach individually.

Impact:

Increased Flexibility: Customers have more options for using their points.
Higher Engagement: Points sharing creates social connections within the program.
Reduced Breakage: Points are more likely to be used rather than expire.
Family Appeal: Attracts households who want to pool rewards.
Gifting Opportunities: Creates emotional connections through points gifting.
Faster Redemption: Customers can reach redemption thresholds faster.
Fraud Risk: Points transfers can be exploited for fraud or money laundering.
Liability Complexity: Points liability tracking becomes more complex.
Tax Implications: Transferred points may have tax considerations in some jurisdictions.
Account Security: Requires robust security to prevent unauthorized transfers.
Abuse Potential: May be used to circumvent individual earning limits.
Support Volume: May increase customer service inquiries about transfers.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ALLOW_POINTS_TRANSFER is set to true or enabled.
Review Transfer Rules:
- Check the configured transfer rules and limits:
  - Minimum transfer amount
  - Maximum transfer amount per transaction
  - Maximum transfers per day/week/month
  - Transfer fees (if any)
  - Eligible sender criteria
  - Eligible recipient criteria
  - Cooling-off periods for new accounts
Verify Feature Availability:
- Check customer-facing interfaces:
  - Transfer option visible in app/website
  - Transfer menu accessible
  - Clear instructions provided
Test Basic Points Transfer:
- Create two test customers with points balances.
- Initiate a transfer from Customer A to Customer B.
- Verify that:
  - Points are deducted from Customer A
  - Points are credited to Customer B
  - Both balances are updated correctly
  - Transfer is recorded in both accounts
Test Transfer Limits:
- Test minimum transfer amount:
  - Attempt transfer below minimum (should fail)
  - Attempt transfer at minimum (should succeed)
- Test maximum transfer amount:
  - Attempt transfer above maximum (should fail)
  - Attempt transfer at maximum (should succeed)
Test Frequency Limits:
- If transfer frequency limits exist:
  - Perform transfers up to the limit (should succeed)
  - Attempt one more transfer (should fail)
  - Verify limit reset after the period expires
Validate Transfer Fees:
- If transfer fees are configured:
  - Initiate a transfer and verify fee calculation
  - Confirm fee is deducted from transferred amount or sender's balance
  - Verify recipient receives correct net amount
  - Check fee is recorded appropriately
Check Points Ledger:
- Review sender's points ledger:
  - Debit entry for transferred points
  - Transfer reference/ID
  - Recipient information
  - Timestamp
- Review recipient's points ledger:
  - Credit entry for received points
  - Transfer reference/ID
  - Sender information
  - Timestamp
Test Recipient Validation:
- Test transfers to valid recipients (should succeed).
- Test transfers to invalid recipients:
  - Non-existent account (should fail)
  - Inactive account (verify behavior)
  - Blocked account (should fail)
  - Self-transfer (verify if allowed or blocked)
Test Insufficient Balance:
- Attempt to transfer more points than available balance.
- Verify that:
  - Transfer is blocked
  - Clear error message is displayed
  - No partial transfer occurs
  - Sender's balance is unchanged
Verify Notifications:
- Check that both parties receive notifications:
  - Sender receives transfer confirmation
  - Recipient receives points received notification
  - Notifications include transfer details (amount, date, other party)
Test Transfer Reversal/Cancellation:
- If transfer reversal is supported:
  - Initiate a transfer
  - Request reversal within allowed window
  - Verify points are returned to sender
  - Verify points are deducted from recipient
- If reversal is not supported, verify this is clearly communicated.
Test Security Controls:
- Verify authentication requirements:
  - Password/PIN confirmation for transfers
  - OTP verification (if configured)
  - Biometric confirmation (if available)
- Test unauthorized transfer attempts (should be blocked).
Test New Account Restrictions:
- If cooling-off periods exist for new accounts:
  - Create a new account
  - Attempt immediate transfer (should fail if restricted)
  - Wait for cooling-off period
  - Attempt transfer again (should succeed)
Validate Fraud Controls:
- Verify fraud prevention measures:
  - Velocity limits
  - Unusual pattern detection
  - High-value transfer alerts
  - Suspicious recipient flagging
Test Edge Cases:
- Transfer of exact full balance
- Transfer to recently created account
- Multiple simultaneous transfers
- Transfer during points expiry processing
- Transfer of points from different earn sources
- Transfer when recipient is at points cap (if applicable)
Check API Behavior:
- Test points transfer via API:
  - API endpoint accepts transfer requests
  - Proper authentication required
  - Validation errors return clear messages
  - Successful transfers return confirmation
Validate Reporting:
- Generate transfer reports:
  - Total points transferred
  - Number of transfers
  - Top senders and recipients
  - Transfer trends over time
  - Fee revenue (if applicable)
- Verify report accuracy.
Test Household/Family Linking:
- If household linking is available:
  - Link family member accounts
  - Verify simplified transfer between linked accounts
  - Test transfer limits for linked vs. unlinked accounts
Review Audit Trail:
- Check comprehensive audit logs:
  - All transfer attempts (successful and failed)
  - User/customer who initiated transfer
  - IP address and device information
  - Timestamp and transaction details
  - Approval chain (if applicable)
Test Points Type Restrictions:
- If certain points types cannot be transferred:
  - Verify restricted points are excluded from transfer
  - Confirm only transferable points are available
  - Check clear messaging about restrictions
Validate Tax/Compliance Handling:
- If tax implications exist:
  - Verify tax documentation is generated
  - Check reporting for large transfers
  - Confirm compliance with local regulations

29. `ALLOW_POINTS_REDEMPTION_REVERSAL`

Purpose: 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.

Detailed Explanation:

Points Redemption: The process of exchanging accumulated loyalty points for rewards, including:
- Vouchers and coupons
- Product rewards
- Cashback or statement credits
- Partner rewards
- Experiences and services
- Charitable donations
Redemption Reversal: The process of undoing a redemption transaction by:
- Restoring the redeemed points to the customer's account
- Cancelling or invalidating the issued reward
- Updating transaction history to reflect the reversal
- Adjusting points liability accordingly
By default, redemptions may be final and irreversible once processed.
When this configuration is enabled:
- Authorized users can initiate redemption reversals.
- Points are credited back to the customer's account.
- Associated rewards are cancelled or marked as invalid.
- Complete audit trail is maintained for all reversals.
This is particularly useful for:
- E-commerce order cancellations where points were used
- Reward fulfillment failures (out of stock, delivery issues)
- Customer service dispute resolution
- Correcting operational or system errors
- Fraud remediation
- Improving customer experience and trust

Example Use Case:

Default Behavior (Reversals Disabled): A customer redeems 10,000 points for a product reward. The product is out of stock and cannot be fulfilled. The customer loses their points and receives no reward, leading to frustration and complaints.
With Redemption Reversal Enabled:
- Customer redeems 10,000 points for a product reward.
- Product is found to be out of stock.
- Customer service initiates a redemption reversal.
- 10,000 points are restored to the customer's account.
- The unfulfilled reward is cancelled.
- Customer is notified and can redeem for an alternative reward.
Scenario: An online retailer with points-based checkout:
Reversal Scenarios Handled:

Scenario	Original Redemption	Reversal Action	Points Restored
Order Cancelled	5,000 pts for $50 discount	Full reversal	5,000 pts
Partial Return	5,000 pts for $50 discount	Partial reversal (60% returned)	3,000 pts
Fulfillment Failure	8,000 pts for gift card	Full reversal	8,000 pts
Duplicate Redemption	2,000 pts (error)	Error correction	2,000 pts
Fraud Detection	15,000 pts (fraudulent)	Fraud reversal	15,000 pts

With redemption reversal enabled:

Customer places order using 5,000 points for $50 discount.
Customer cancels order before shipment.
System automatically triggers redemption reversal.
5,000 points are restored to customer's account.
Customer receives confirmation of points restoration.
Customer can use points on future purchases.

Impact:

Customer Satisfaction: Customers are not penalized for failed or cancelled redemptions.
Operational Flexibility: Enables correction of errors and handling of exceptions.
Trust Building: Demonstrates fairness and customer-centric policies.
Fraud Remediation: Allows recovery of points in fraud cases.
Reduced Complaints: Fewer escalations related to lost points.
Accurate Liability: Points liability reflects actual outstanding obligations.
Abuse Potential: May be exploited for fraudulent reversal requests.
Complexity: Adds complexity to redemption and reward management.
Reward Recovery: Physical rewards may be difficult to recover after reversal.
Financial Impact: Reversals affect revenue recognition and liability calculations.
Audit Requirements: Requires robust audit trails for compliance.
Time Sensitivity: Some reversals may have time limits or conditions.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ALLOW_POINTS_REDEMPTION_REVERSAL is set to true or enabled.
Review Reversal Rules:
- Check the configured reversal rules and policies:
  - Time limit for reversals (e.g., within 30 days)
  - Eligible redemption types for reversal
  - Required approvals or authorization levels
  - Partial reversal support
  - Automatic vs. manual reversal triggers
Verify User Permissions:
- Confirm appropriate role-based access:
  - Which roles can initiate reversals
  - Approval workflows for high-value reversals
  - Audit access for reversal history
Test Full Redemption Reversal:
- Process a test redemption (e.g., 5,000 points for a voucher).
- Initiate a full reversal of the redemption.
- Verify that:
  - All 5,000 points are restored to customer's account
  - Voucher is cancelled/invalidated
  - Points ledger shows reversal entry
  - Customer balance is updated correctly
Test Partial Redemption Reversal:
- If partial reversals are supported:
  - Process a redemption (e.g., 10,000 points)
  - Initiate a partial reversal (e.g., 4,000 points)
  - Verify that:
    - 4,000 points are restored
    - 6,000 points remain redeemed
    - Reward is adjusted accordingly (if applicable)
Validate Points Ledger:
- Review the customer's points ledger after reversal:
  - Original redemption entry (debit)
  - Reversal entry (credit)
  - Clear reference linking reversal to original redemption
  - Accurate timestamps
  - Reason/notes for reversal
Check Reward Status:
- Verify the status of the reversed reward:
  - Voucher/coupon marked as cancelled or invalid
  - Reward cannot be used after reversal
  - Reward inventory updated (if applicable)
  - Partner notified (for partner rewards)
Test Time-Based Restrictions:
- If reversal time limits exist:
  - Attempt reversal within allowed window (should succeed)
  - Attempt reversal after window expires (should fail or require override)
  - Verify clear messaging about time restrictions
Test Automatic Reversals:
- If automatic reversals are configured (e.g., order cancellation triggers):
  - Process a redemption linked to an order
  - Cancel the order
  - Verify automatic reversal is triggered
  - Confirm points are restored without manual intervention
Test Manual Reversals:
- Process a redemption.
- Manually initiate reversal through admin interface.
- Verify that:
  - Reversal form captures required information
  - Reason for reversal is mandatory
  - Approval workflow is triggered (if configured)
  - Reversal is processed after approval
Verify Customer Notifications:
- Check that customers receive notifications for reversals:
  - Points restoration confirmation
  - Reason for reversal (if appropriate)
  - Updated points balance
  - Information about cancelled reward
Test Reversal of Different Redemption Types:
- Test reversals for various redemption types:
  - Voucher/coupon redemption
  - Product reward redemption
  - Cashback redemption
  - Partner reward redemption
  - Points + cash combination redemption
- Verify consistent behavior across types.
Test Points Expiry Interaction:
- Process a redemption using points that would have expired.
- Reverse the redemption after the original expiry date.
- Verify behavior:
  - Are restored points given new expiry date?
  - Do restored points retain original expiry?
  - Is this clearly communicated to customer?
Test Reversal with Used Reward:
- Process a redemption and issue a reward.
- Simulate the reward being used (e.g., voucher redeemed at POS).
- Attempt reversal.
- Verify that:
  - Reversal is blocked (reward already used)
  - Clear error message is displayed
  - Alternative resolution path is suggested
Validate Fraud Controls:
- Verify fraud prevention measures:
  - Limits on reversal frequency
  - High-value reversal alerts
  - Pattern detection for suspicious reversals
  - Velocity checks
Test Approval Workflows:
- If approval workflows are configured:
  - Initiate a reversal requiring approval
  - Verify pending status until approved
  - Approve the reversal and verify processing
  - Reject a reversal and verify points remain redeemed
Check Financial Reconciliation:
- Verify that reversals are properly reflected in:
  - Points liability reports
  - Revenue recognition adjustments
  - Financial reconciliation statements
  - Partner settlement reports (if applicable)
Test Edge Cases:
- Reversal of very old redemptions
- Reversal when customer account is inactive/closed
- Reversal of redemption made with transferred points
- Multiple reversals of the same redemption (should be blocked)
- Reversal during system maintenance or batch processing
- Reversal of promotional/bonus redemptions
Review Audit Trail:
- Check comprehensive audit logs:
  - Original redemption details
  - Reversal initiator (user/system)
  - Reversal reason and notes
  - Approval chain (if applicable)
  - Timestamp of all actions
  - IP address and session information
Validate Reporting:
- Generate reversal reports:
  - Total reversals by period
  - Reversal reasons breakdown
  - Points restored volume
  - Reversal rate (reversals vs. total redemptions)
  - High-reversal customers or patterns
- Verify report accuracy and completeness.
Test API Behavior:
- Test redemption reversal via API:
  - API endpoint accepts reversal requests
  - Proper authentication and authorization
  - Validation of reversal eligibility
  - Clear error responses for invalid requests
  - Successful reversal confirmation
Validate Customer-Facing Display:
- Check customer-facing interfaces:
  - Reversal reflected in transaction history
  - Updated points balance displayed
  - Cancelled reward status visible
  - Clear explanation of reversal

30. `ENABLE_PARTNER_PROGRAM_LINKING`

Purpose: 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.

Detailed Explanation:

Partner Program Linking: The process of establishing a connection between a customer's account in the primary loyalty program and their account(s) in external partner programs, enabling:
- Cross-program points earning
- Points transfer between programs
- Shared benefits and status recognition
- Unified customer experience across partners
- Data sharing for personalization
Link Types: Various linking arrangements that may be supported:
- One-to-One: Primary account linked to one partner account
- One-to-Many: Primary account linked to multiple partner accounts
- Bidirectional: Both programs can initiate and recognize the link
- Unidirectional: Only one program initiates/controls the link
By default, loyalty programs operate independently with no account linking capability.
When this configuration is enabled:
- Customers can initiate linking from the primary program interface.
- Partner program credentials or identifiers are validated.
- Linked accounts are stored and maintained securely.
- Cross-program transactions and benefits become available.
This is particularly useful for:
- Airline alliances and hotel partnerships
- Retail coalition loyalty programs
- Credit card and merchant partnerships
- Travel and hospitality ecosystems
- Brand partnerships and co-branded programs
- Expanding earning and redemption opportunities

Example Use Case:

Default Behavior (Linking Disabled): A customer has separate accounts with an airline loyalty program and a hotel loyalty program. They cannot earn airline miles from hotel stays or use airline miles for hotel bookings. Each program operates in isolation.
With Partner Program Linking Enabled:
- Customer logs into the airline loyalty program.
- Customer navigates to "Link Partner Programs."
- Customer selects the hotel partner program.
- Customer enters their hotel loyalty program credentials.
- Accounts are validated and linked.
- Customer can now earn airline miles on hotel stays.
- Customer can transfer miles to hotel points (if allowed).
- Customer's elite status may be recognized at partner hotels.
Scenario: An airline loyalty program with multiple partners:
Available Partner Programs for Linking:

Partner Category	Partner Program	Link Benefits
Hotels	Marriott Bonvoy	Earn 2 miles per $1 on stays, status match
Hotels	Hilton Honors	Earn 1.5 miles per $1 on stays
Car Rental	Hertz Gold Plus	Earn 500 miles per rental, priority service
Car Rental	Avis Preferred	Earn 400 miles per rental
Dining	Restaurant Network	Earn 3 miles per $1 at participating restaurants
Retail	Shopping Portal	Earn up to 10 miles per $1 at select retailers
Financial	Co-branded Credit Card	Earn 2 miles per $1 on all purchases

Customer's Linked Accounts:

Partner	Linked Account	Status	Link Date
Marriott Bonvoy	#12345678	Active	Jan 2024
Hertz Gold Plus	#87654321	Active	Mar 2024
Co-branded Card	****4567	Active	Jun 2023

With partner linking enabled:

Customer books a Marriott hotel through the airline portal.
Airline miles are automatically credited via the linked account.
Customer's airline elite status is recognized at Marriott check-in.
All partner earnings appear in a unified activity feed.

Impact:

Expanded Earning Opportunities: Customers earn points/miles across a broader ecosystem.
Enhanced Value Proposition: Program becomes more valuable with partner benefits.
Customer Convenience: Single view of cross-program activity and benefits.
Competitive Advantage: Rich partner network differentiates the program.
Increased Engagement: More touchpoints for customer interaction.
Data Enrichment: Cross-program data enables better personalization.
Partner Revenue: Drives business to partner programs.
Integration Complexity: Requires robust API integrations with partners.
Data Privacy: Must handle cross-program data sharing carefully.
Security Risks: Linked accounts create additional attack vectors.
Dependency: Program value becomes dependent on partner relationships.
Support Complexity: Cross-program issues require coordination.
Maintenance Overhead: Links must be maintained and validated over time.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ENABLE_PARTNER_PROGRAM_LINKING is set to true or enabled.
Identify Available Partners:
- List all partner programs available for linking:
  - Partner program names
  - Partner categories
  - Link benefits for each partner
  - Any restrictions or eligibility requirements
Review Linking Requirements:
- Understand the linking process requirements:
  - Required credentials or identifiers
  - Verification methods (OAuth, API validation, manual)
  - Customer eligibility criteria
  - Terms and conditions acceptance
Verify Feature Availability:
- Check customer-facing interfaces:
  - "Link Partner Programs" option visible
  - Partner list displayed correctly
  - Linking instructions are clear
  - Mobile and web availability
Test Account Linking Process:
- Initiate linking with a test partner account.
- Complete the linking flow:
  - Select partner program
  - Enter partner credentials/identifier
  - Authorize the connection
  - Confirm successful linking
- Verify that:
  - Link is established successfully
  - Linked account appears in customer profile
  - Confirmation notification is sent
Validate Partner Account Verification:
- Test linking with valid partner credentials (should succeed).
- Test linking with invalid credentials:
  - Wrong account number (should fail)
  - Incorrect password (should fail)
  - Non-existent account (should fail)
- Verify clear error messages for failures.
Test Cross-Program Earning:
- With linked accounts, complete a qualifying activity at partner.
- Verify that:
  - Points/miles are credited to primary program
  - Earning appears in transaction history
  - Correct earn rate is applied
  - Partner transaction details are captured
Test Cross-Program Redemption:
- If cross-program redemption is enabled:
  - Initiate redemption using primary program points at partner
  - Verify redemption is processed correctly
  - Confirm reward is delivered through partner
Test Status Recognition:
- If status matching/recognition is enabled:
  - Link accounts with elite status in primary program
  - Verify status is recognized at partner
  - Test status benefits at partner locations
Test Points Transfer:
- If points transfer between linked programs is enabled:
  - Initiate transfer from primary to partner program
  - Verify points are deducted from primary
  - Confirm points are credited to partner
  - Check conversion rates are applied correctly
Validate Link Management:
- Check linked account management features:
  - View all linked accounts
  - See link status and details
  - Update linked account information
  - Refresh/re-validate links
Test Account Unlinking:
- Unlink a previously linked partner account.
- Verify that:
  - Link is removed successfully
  - Cross-program benefits stop
  - Historical transactions are preserved
  - Customer is notified of unlinking
Test Multiple Partner Links:
- Link multiple partner accounts to one primary account.
- Verify that:
  - All links are maintained correctly
  - Each partner functions independently
  - No conflicts between partners
  - Unified view of all linked accounts
Verify Security Controls:
- Test security measures for linking:
  - Authentication required before linking
  - Secure credential handling
  - OAuth token management (if applicable)
  - Session security during linking flow
Test Link Expiry/Renewal:
- If links have expiry periods:
  - Check link expiry notifications
  - Test link renewal process
  - Verify behavior when link expires
  - Confirm re-linking process
Validate Data Sharing:
- Verify what data is shared between programs:
  - Customer profile information
  - Transaction history
  - Status and tier information
  - Preferences and consents
- Confirm data sharing aligns with privacy policies.
Check Customer Notifications:
- Verify notifications for linking events:
  - Successful link confirmation
  - Link failure alerts
  - Cross-program earning notifications
  - Link expiry reminders
  - Unlinking confirmation
Test Edge Cases:
- Linking already-linked partner account
- Linking to partner account owned by different customer
- Linking when partner program is temporarily unavailable
- Linking with special characters in credentials
- Linking from multiple devices simultaneously
- Partner account closure after linking
Validate Customer-Facing Display:
- Check customer interfaces:
  - Linked accounts section in profile
  - Partner program logos and branding
  - Link status indicators
  - Cross-program activity feed
  - Combined benefits summary
Test API Behavior:
- Test partner linking via API:
  - Link initiation endpoint
  - Link status query
  - Unlink endpoint
  - Cross-program transaction APIs
- Verify proper authentication and error handling.
Review Audit Trail:
- Check audit logs for linking events:
  - Link creation with timestamp
  - User who initiated linking
  - Partner program details
  - Verification method used
  - Unlink events and reasons
Validate Reporting:
- Generate partner linking reports:
  - Total linked accounts by partner
  - Linking trends over time
  - Cross-program transaction volumes
  - Most popular partner programs
  - Link success/failure rates
- Verify report accuracy.
Test Partner API Integration:
- Verify partner API connectivity:
  - API health checks
  - Timeout handling
  - Error recovery
  - Rate limiting compliance
Check Terms and Consent:
- Verify that linking requires:
  - Acceptance of terms and conditions
  - Data sharing consent
  - Partner program terms acknowledgment
- Confirm consent is recorded and auditable.
Test Fraud Prevention:
- Verify fraud controls for linking:
  - Velocity limits on linking attempts
  - Suspicious activity detection
  - Account verification requirements
  - Alerts for unusual linking patterns

31. `ENABLE_USER_GROUP_LOYALTY`

Purpose: 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.

Detailed Explanation:

User Group Loyalty: A loyalty model where multiple individual customers are organized into groups that share loyalty benefits, including: Household/Family Groups: Family members pooling points and benefits Corporate Groups: Employees earning for company rewards Team Groups: Sports teams, clubs, or community organizations Membership Groups: Premium membership tiers with shared benefits Affinity Groups: Groups based on shared interests or affiliations
Group Loyalty Features: Capabilities enabled at the group level: Shared points pool across group members Group-level tier qualification and status Collective earning toward group goals Group rewards and redemptions Group leaderboards and challenges Consolidated group statements and reporting
By default, loyalty programs operate at the individual customer level only.
When this configuration is enabled: Groups can be created and managed within the loyalty program. Members can be added to and removed from groups. Points and benefits can be shared or pooled at the group level. Group-specific rules, tiers, and rewards become available.
This is particularly useful for: Family-oriented retail and travel programs B2B loyalty programs with corporate accounts Subscription services with household plans Community and membership organizations Programs wanting to increase household engagement Encouraging group participation and social loyalty

Example Use Case:

Default Behavior (Individual Loyalty Only): Each family member has a separate loyalty account. Parents and children earn points independently. A child's small purchases don't contribute to family rewards. Each person must reach redemption thresholds individually.
With User Group Loyalty Enabled: Family creates a "Smith Household" loyalty group. Parents and two children are added as group members. All family members' purchases contribute to the group points pool. Family collectively reaches Gold tier faster. Group can redeem pooled points for a family vacation reward. Family receives a consolidated monthly statement.
Scenario: A grocery retailer implements household loyalty:

Group Structure - "Johnson Family":

Member	Role	Individual Earning	Contribution to Group
Sarah Johnson	Primary	$500/month	5,000 pts
Mike Johnson	Adult Member	$300/month	3,000 pts
Emma Johnson	Teen Member	$100/month	1,000 pts
Jake Johnson	Child Member	$50/month	500 pts
Group Total	—	$950/month	9,500 pts

Group Benefits:

Combined monthly spend: $950 qualifies for Gold tier (vs. $800 threshold) Pooled points: 9,500 pts/month enables faster redemption Group reward: Family movie night package (8,000 pts) Shared benefits: All members get Gold tier discounts

Individual vs. Group Comparison:

Metric	Individual Model	Group Model
Tier Achieved	Sarah: Silver, Others: Bronze	All: Gold
Monthly Points	Fragmented across 4 accounts	9,500 pooled
Time to $50 Reward	Sarah: 2 months, Others: 4+ months	Family: 1 month
Engagement	Low for minor spenders	High for all members

Impact:

Increased Household Engagement: All family members contribute meaningfully.
Faster Reward Achievement: Pooled points reach thresholds faster.
Higher Program Value: Group benefits exceed individual benefits.
Stronger Loyalty: Families become more committed to the program.
Social Dynamics: Creates shared goals and collaborative experiences.
Competitive Advantage: Differentiates from individual-only programs.
B2B Enablement: Supports corporate and organizational loyalty models.
Complexity: Group management adds operational complexity.
Disputes: Potential for intra-group conflicts over points usage.
Privacy Concerns: Group members may see each other's activity.
Fraud Risk: Groups may be created fraudulently to game the system.
Support Volume: Group-related inquiries increase support needs.
Liability Tracking: Points liability becomes more complex with groups.

How to Verify:

Check Configuration Settings:

Review the organization's configuration to confirm that ENABLE_USER_GROUP_LOYALTY is set to true or enabled.

Review Group Configuration:

Check the configured group settings: Group types available (family, corporate, etc.) Maximum members per group Minimum members required Member roles and permissions Group creation eligibility

Verify Feature Availability:

Check customer-facing interfaces: "Create Group" or "Family Account" option visible Group management section accessible Group features clearly explained Mobile and web availability

Test Group Creation:

Create a new loyalty group. Verify that: Group is created successfully Group name and details are saved Primary member/admin is assigned Group ID is generated Confirmation notification is sent

Test Member Addition:

Add members to an existing group. Test various addition methods: Invite by email Invite by phone number Invite by member ID Direct addition (if allowed) Verify that: Invitation is sent to prospective member Member can accept/decline invitation Accepted member appears in group roster Member count is updated

Test Member Roles and Permissions:

Verify different member roles: Primary/Admin: Full control Adult Member: Standard permissions Child/Minor Member: Limited permissions Test role-specific capabilities: Who can add/remove members Who can redeem group points Who can view group activity

Test Points Pooling:

Have multiple group members make purchases. Verify that: Individual earnings contribute to group pool Group points balance is updated correctly Individual contribution is tracked Points attribution is accurate

Validate Group Points Balance:

Check group points balance calculation: Sum of all member contributions Any group-level bonuses applied Deductions for group redemptions Accurate running balance

Test Group Tier Qualification:

If group-level tiers exist: Verify group tier is calculated from combined activity Test tier upgrade based on group metrics Confirm all members receive tier benefits Test tier downgrade scenarios

Test Group Redemption:

Initiate a redemption using group points. Verify that: Authorized members can redeem Points are deducted from group pool Reward is issued appropriately Redemption is logged with member who initiated

Test Individual vs. Group Earning:

Verify earning allocation rules: Do points go to individual, group, or both? Is there a split percentage? Can members choose allocation? Test various earning scenarios.

Test Member Removal:

Remove a member from a group. Verify that: Member is removed successfully Member's future earnings no longer contribute to group Historical contributions are handled per policy Removed member is notified

Test Group Dissolution:

Dissolve/delete an existing group. Verify that: Group is properly closed Remaining points are distributed per policy Members are converted to individual accounts Historical data is preserved

Validate Group Statements:

Generate group loyalty statement. Verify that: All member activities are included Group totals are accurate Individual contributions are visible Redemptions are attributed correctly

Test Privacy Controls:

Verify privacy settings for groups: What activity is visible to other members Purchase details visibility Points balance visibility Configurable privacy options

Test Group Limits:

Test maximum member limits: Add members up to the limit (should succeed) Attempt to exceed limit (should fail) Test minimum member requirements: Verify group functionality with minimum members

Test Group Invitations:

Verify invitation workflow: Invitation sent successfully Invitation expiry handling Duplicate invitation prevention Invitation cancellation Declined invitation handling

Test Member in Multiple Groups:

If allowed, test member belonging to multiple groups. If not allowed, verify restriction is enforced. Check earning allocation when in multiple groups.

Validate Group Notifications:

Verify group-related notifications: Group creation confirmation Member addition/removal alerts Group milestone achievements Group redemption notifications Tier change notifications

Test Group Challenges/Goals:

If group challenges are available: Create a group challenge Track collective progress Verify goal completion recognition Test group reward distribution

Test Corporate/B2B Groups:

If corporate groups are supported: Create a corporate group Add employee members Test corporate earning rules Verify corporate redemption options Check corporate reporting

Check Admin Management:

Verify admin capabilities for groups: View all groups Manage group settings Override group actions Resolve group disputes Generate group reports

Test Edge Cases:

Group with only one member Primary member leaving the group All members becoming inactive Group points expiry handling Member with negative individual balance joining group Simultaneous redemptions by multiple members

Review Audit Trail:

Check audit logs for group activities: Group creation and modification Member additions and removals Points contributions and redemptions Role changes Group settings changes

Validate Reporting:

Generate group loyalty reports: Total groups by type Average group size Group vs. individual earning comparison Group redemption patterns Most active groups Group tier distribution Verify report accuracy.

Test API Behavior:

Test group management via API: Create group endpoint Add/remove member endpoints Group balance query Group redemption endpoint Verify proper authentication and authorization.

Validate Fraud Controls:

Verify fraud prevention for groups: Suspicious group creation patterns Unusual member addition activity Group points manipulation detection Velocity limits on group actions

32. `ENABLE_FLEET_LOYALTY`

Purpose: This configuration enables loyalty program features specifically designed for fleet customers, such as commercial vehicle operators, trucking companies, delivery services, and businesses with multiple vehicles. When enabled, the loyalty program can accommodate fleet-specific earning structures, vehicle-level tracking, driver management, consolidated billing, and B2B reward mechanisms tailored to fleet operations.

Detailed Explanation:

Fleet Loyalty: A specialized loyalty model designed for businesses that operate multiple vehicles, including:
- Trucking Companies: Long-haul and regional freight carriers
- Delivery Services: Last-mile delivery and courier companies
- Transportation Companies: Bus, taxi, and ride-share fleets
- Construction/Industrial: Heavy equipment and service vehicle fleets
- Corporate Fleets: Company cars and sales force vehicles
- Government/Municipal: Public service and emergency vehicle fleets
Fleet Loyalty Features: Capabilities specific to fleet operations:
- Vehicle-level points tracking and rewards
- Driver identification and earning attribution
- Fleet account hierarchy (company → fleet → vehicle → driver)
- Volume-based tier structures and discounts
- Fuel card integration and tracking
- Consolidated invoicing and statements
- Fleet manager dashboards and controls
- Bulk redemption and reward distribution
By default, loyalty programs are designed for individual consumers (B2C).
When this configuration is enabled:
- Fleet accounts can be created with hierarchical structures.
- Vehicles and drivers can be registered and tracked.
- Fleet-specific earning rules and tiers are activated.
- Fleet management tools become available.
This is particularly useful for:
- Fuel and petroleum retailers
- Truck stops and travel centers
- Auto parts and service providers
- Fleet management companies
- B2B loyalty programs targeting commercial customers
- Programs wanting to capture high-volume fleet business

Example Use Case:

Default Behavior (Consumer Loyalty Only): A trucking company's drivers each have individual loyalty accounts. The company cannot track or manage driver earnings. Points are fragmented across dozens of driver accounts. No volume-based benefits are available for the fleet's collective purchasing power.
With Fleet Loyalty Enabled:
- Trucking company registers as a fleet account.
- 50 trucks and 75 drivers are added to the fleet.
- All fuel purchases across the fleet earn points to the company account.
- Fleet qualifies for Platinum tier based on combined volume.
- Fleet manager can view all transactions and allocate rewards.
- Company redeems points for fleet maintenance services.

Scenario: A fuel retailer implements fleet loyalty for commercial customers:
Fleet Account Structure - "ABC Logistics":
ABC Logistics (Fleet Account)
├── Fleet Manager: John Smith
├── Billing Contact: [email protected]
│
├── Region: Northeast
│ ├── Truck #101 - Driver: Mike Johnson
│ ├── Truck #102 - Driver: Sarah Williams
│ └── Truck #103 - Driver: Tom Brown
│
├── Region: Southeast
│ ├── Truck #201 - Driver: Lisa Davis
│ ├── Truck #202 - Driver: James Wilson
│ └── Truck #203 - Driver: Maria Garcia
│
└── Region: Midwest
├── Truck #301 - Driver: Robert Lee
├── Truck #302 - Driver: Jennifer Martinez
└── Truck #303 - Driver: David Anderson

Fleet Earning Summary (Monthly):

Metric	Value	Points Earned
Total Gallons	45,000 gal	45,000 pts
Transactions	450	4,500 bonus pts
DEF Purchases	$2,500	2,500 pts
Store Purchases	$1,200	1,200 pts
Monthly Total		53,200 pts

Fleet Tier Benefits (Platinum - 40,000+ gal/month):
- 5¢ per gallon discount
- Priority fueling lanes
- Free DEF with fill-up
- Dedicated account manager
- Monthly fleet performance reports

Impact:

B2B Market Capture: Enables targeting of high-value commercial customers.
Volume Incentives: Rewards collective fleet purchasing power.
Operational Efficiency: Centralized management for fleet operators.
Customer Retention: Sticky relationships with fleet accounts.
Data Insights: Rich data on fleet operations and patterns.
Revenue Growth: Fleet customers represent significant recurring revenue.
Competitive Differentiation: Specialized offering vs. consumer-only programs.
Complexity: Fleet hierarchies add significant system complexity.
Integration Requirements: Fuel card and fleet management system integrations.
Support Needs: Dedicated support for fleet account management.
Customization: Fleet customers often require customized terms.
Credit Risk: B2B accounts may involve credit and billing complexity.
Fraud Exposure: Fleet cards and driver fraud require monitoring.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ENABLE_FLEET_LOYALTY is set to true or enabled.
Review Fleet Configuration:
- Check the configured fleet settings:
  - Fleet account types available
  - Hierarchy levels supported
  - Maximum vehicles per fleet
  - Maximum drivers per fleet
  - Fleet tier structures
Verify Feature Availability:
- Check fleet management interfaces:
  - Fleet registration option available
  - Fleet dashboard accessible
  - Vehicle management section
  - Driver management section
  - Fleet reporting tools
Test Fleet Account Creation:
- Create a new fleet account.
- Verify that:
  - Fleet account is created successfully
  - Company information is captured
  - Fleet ID is generated
  - Fleet manager is assigned
  - Billing information is recorded
  - Confirmation is sent
Test Fleet Hierarchy Setup:
- Configure fleet hierarchy:
  - Add regions/divisions (if supported)
  - Add vehicles to the fleet
  - Add drivers to vehicles
- Verify that:
  - Hierarchy is correctly structured
  - Parent-child relationships are maintained
  - Navigation through hierarchy works
Test Vehicle Registration:
- Add vehicles to the fleet.
- Capture vehicle information:
  - Vehicle ID/number
  - License plate
  - Vehicle type (truck, van, car)
  - Fuel type
  - Tank capacity
- Verify that:
  - Vehicle is added successfully
  - Vehicle appears in fleet roster
  - Vehicle can be assigned to drivers
Test Driver Registration:
- Add drivers to the fleet.
- Capture driver information:
  - Driver ID
  - Name and contact
  - License number
  - Assigned vehicle(s)
  - Driver card/PIN
- Verify that:
  - Driver is added successfully
  - Driver is linked to vehicle(s)
  - Driver credentials are issued
Test Fleet Earning:
- Process transactions for fleet vehicles/drivers.
- Verify that:
  - Points are earned to fleet account
  - Transaction is attributed to correct vehicle
  - Transaction is attributed to correct driver
  - Fleet earning rules are applied
  - Volume bonuses are calculated
Validate Fleet Points Balance:
- Check fleet points balance:
  - Total fleet points
  - Points by region/division
  - Points by vehicle
  - Points by driver
- Verify accurate aggregation at all levels.
Test Fleet Tier Qualification:
- Verify fleet tier calculation:
  - Based on combined volume (gallons, spend)
  - Tier thresholds for fleet accounts
  - Tier benefits applied to entire fleet
- Test tier upgrade and downgrade scenarios.
Test Fleet Redemption:
- Initiate redemption from fleet account.
- Verify that:
  - Authorized users can redeem
  - Fleet-specific rewards are available
  - Points are deducted from fleet pool
  - Reward is issued appropriately
  - Redemption is logged with approver
Test Driver-Level Earning:
- If drivers earn individual rewards:
  - Verify driver-level points tracking
  - Test driver reward redemption
  - Check driver leaderboards (if available)
Test Fuel Card Integration:
- If fuel cards are integrated:
  - Process transaction with fleet fuel card
  - Verify card is linked to correct vehicle/driver
  - Confirm transaction details are captured
  - Check fuel volume and amount accuracy
Validate Fleet Reporting:
- Generate fleet reports:
  - Transaction summary by period
  - Fuel consumption by vehicle
  - Spending by driver
  - Points earned and redeemed
  - Tier status and progress
- Verify report accuracy and completeness.
Test Fleet Manager Dashboard:
- Access fleet manager dashboard.
- Verify availability of:
  - Fleet overview and KPIs
  - Real-time transaction feed
  - Vehicle and driver status
  - Points balance and activity
  - Alerts and notifications
  - Management tools
Test Fleet Billing/Invoicing:
- If consolidated billing is enabled:
  - Generate fleet invoice
  - Verify all transactions are included
  - Check pricing and discounts applied
  - Confirm invoice delivery
Test Driver Card Management:
- Manage driver cards/credentials:
  - Issue new driver card
  - Suspend driver card
  - Replace lost card
  - Set spending limits
- Verify card status changes take effect.
Test Vehicle Restrictions:
- If vehicle-level restrictions exist:
  - Set fuel type restrictions
  - Set daily/weekly limits
  - Set geographic restrictions
- Verify restrictions are enforced at POS.
Test Fleet Promotions:
- If fleet-specific promotions exist:
  - Verify fleet promotions are applied
  - Test volume-based bonus structures
  - Check fleet-exclusive offers
- Confirm promotions don't apply to consumer accounts.
Test Multi-Location Fleet:
- For fleets operating across locations:
  - Verify earning at multiple locations
  - Check location-based reporting
  - Test cross-location benefits
Test Fleet Account Modifications:
- Modify fleet account:
  - Update company information
  - Change fleet manager
  - Adjust billing details
  - Modify tier/pricing
- Verify changes are applied correctly.
Test Driver/Vehicle Removal:
- Remove a driver from the fleet.
- Remove a vehicle from the fleet.
- Verify that:
  - Removal is processed correctly
  - Historical data is preserved
  - Future transactions are blocked
  - Credentials are deactivated
Test Fleet Account Closure:
- Close a fleet account.
- Verify that:
  - Account is properly closed
  - Outstanding points are handled per policy
  - All vehicles/drivers are deactivated
  - Final statement is generated
  - Historical data is retained
Validate Fraud Controls:
- Verify fleet fraud prevention:
  - Unusual transaction patterns
  - Card usage anomalies
  - Driver behavior monitoring
  - Velocity limits
  - Geographic alerts
Test Edge Cases:
- Fleet with single vehicle
- Driver assigned to multiple vehicles
- Vehicle with multiple drivers
- Transaction without driver identification
- Fleet tier boundary calculations
- Mid-month fleet account creation
Review Audit Trail:
- Check audit logs for fleet activities:
  - Account creation and modifications
  - Vehicle and driver management
  - Transactions and earnings
  - Redemptions and rewards
  - Card management actions
Test API Behavior:
- Test fleet management via API:
  - Fleet account creation
  - Vehicle/driver registration
  - Transaction posting
  - Balance and reporting queries
- Verify proper authentication and authorization.
Test Integration Points:
- Verify integrations with:
  - Fleet management systems
  - Fuel card processors
  - ERP/accounting systems
  - Telematics providers
- Confirm data synchronization accuracy.

33. `ENABLE_AWARD_WHEN_TARGET_ACHIEVED`

Purpose: 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.
Detailed Explanation:

Target Achievement: The completion of a predefined goal or milestone set within the loyalty program, including:
- Spend Targets: Reach $500 spend in a month
- Visit Targets: Complete 10 visits in a quarter
- Purchase Targets: Buy 5 items from a specific category
- Points Targets: Accumulate 10,000 points
- Behavioral Targets: Complete profile, refer friends, write reviews
- Streak Targets: Shop 4 consecutive weeks
- Tiered Targets: Progressive milestones with increasing rewards
Automatic Award: The immediate, system-triggered issuance of rewards upon target completion, including:
- Bonus points
- Vouchers and coupons
- Cashback credits
- Free products
- Status upgrades
- Badges and recognition
- Entry into sweepstakes
By default, target achievements may require:
- Manual review and approval
- Batch processing at scheduled intervals
- Customer-initiated reward claims
- Administrative intervention
When this configuration is enabled:
- Rewards are issued instantly upon target achievement.
- No manual intervention or claim process is required.
- Customers receive immediate gratification and notification.
- Target tracking and reward issuance are tightly integrated.
This is particularly useful for:
- Creating instant gratification experiences
- Gamification and engagement programs
- Time-sensitive promotions and challenges
- Reducing operational overhead for reward processing
- Improving customer satisfaction with immediate rewards
- Driving real-time behavioral reinforcement

Example Use Case:

Default Behavior (Manual/Batch Processing): A customer completes a "Spend $200" target on Monday. The batch job runs on Friday night. The customer receives their reward voucher on Saturday morning—5 days after achievement. By then, the excitement has faded.
With Award When Target Achieved Enabled:
- Customer makes a purchase that brings their monthly spend to $205.
- System instantly detects target achievement ($200 spend target).
- $20 reward voucher is immediately issued to customer's account.
- Customer receives push notification: "Congratulations! You've earned a $20 voucher!"
- Customer can use the voucher on their very next purchase.
Scenario: A coffee shop loyalty program with multiple targets:

Configured Targets and Awards:

Target	Criteria	Award	Timing
First Purchase	Complete 1st transaction	50 bonus points	Instant
Coffee Lover	Buy 5 coffees	Free coffee voucher	Instant
Weekly Regular	Visit 3 times in a week	100 bonus points	Instant
Monthly Maven	Spend $100 in a month	$10 reward voucher	Instant
Breakfast Club	Buy 10 breakfast items	Free breakfast combo	Instant
Anniversary	1 year membership	500 bonus points + badge	Instant

Customer Journey Example:
9:00 AM - Customer buys 5th coffee of the month
→ Target "Coffee Lover" achieved
→ FREE COFFEE VOUCHER issued instantly
→ Push notification sent

9:01 AM - Customer sees notification
→ "You've earned a FREE coffee!"
→ Voucher visible in app wallet

9:02 AM - Customer redeems voucher
→ Gets free coffee immediately
→ Delighted customer experience

Impact Comparison:

Metric	Batch Processing	Instant Award
Time to Reward	1–7 days	< 1 second
Customer Excitement	Diminished	Peak
Redemption Rate	45%	78%
Program Engagement	Moderate	High
Operational Effort	Manual review	Automated

Impact:

Instant Gratification: Customers receive rewards immediately, maximizing excitement.
Higher Engagement: Real-time rewards reinforce desired behaviors.
Increased Redemption: Immediate rewards are more likely to be used.
Operational Efficiency: Eliminates manual processing and batch job dependencies.
Better Customer Experience: Seamless, frictionless reward experience.
Gamification Enhancement: Supports real-time game mechanics and challenges.
Behavioral Reinforcement: Immediate rewards strengthen habit formation.
System Load: Real-time processing may increase system load during peak times.
Error Handling: Instant awards require robust error handling and recovery.
Reversal Complexity: Reversing instant awards may be more complex.
Fraud Exposure: Instant rewards may be exploited before fraud is detected.
Inventory Management: Real-time reward issuance requires real-time inventory checks.
Notification Dependency: Requires reliable notification system for instant alerts.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ENABLE_AWARD_WHEN_TARGET_ACHIEVED is set to true or enabled.
Review Target Configuration:
- Check the configured targets:
  - Target names and descriptions
  - Achievement criteria
  - Associated awards/rewards
  - Target periods (daily, weekly, monthly, lifetime)
  - Target audience/eligibility
Review Award Configuration:
- Check the awards linked to targets:
  - Award types (points, vouchers, products)
  - Award values
  - Award validity periods
  - Award limits (per customer, total)
Verify Feature Availability:
- Check customer-facing interfaces:
  - Targets visible in app/website
  - Progress tracking displayed
  - Award details shown
  - Achievement history accessible
Test Basic Target Achievement:
- Create a test customer below a target threshold.
- Process activity that completes the target.
- Verify that:
  - Target achievement is detected instantly
  - Award is issued immediately
  - Customer balance/wallet is updated
  - Achievement is recorded
Measure Award Timing:
- Record timestamp of qualifying transaction.
- Record timestamp of award issuance.
- Verify that:
  - Award is issued within seconds (not batch delayed)
  - Timing meets "instant" expectations
  - No manual intervention required
Test Customer Notification:
- Upon target achievement, verify notifications:
  - Push notification sent immediately
  - Email notification sent (if configured)
  - SMS notification sent (if configured)
  - In-app message displayed
- Confirm notification content includes:
  - Congratulations message
  - Target achieved
  - Award details
  - How to use the award
Validate Award Issuance:
- Check the issued award:
  - Correct award type
  - Correct award value
  - Proper validity period
  - Visible in customer's wallet/account
  - Usable immediately
Test Different Target Types:
- Test instant awards for various target types:
  - Spend-based targets
  - Visit/frequency targets
  - Quantity-based targets
  - Points accumulation targets
  - Behavioral targets
- Verify consistent instant award behavior.
Test Different Award Types:
- Test instant issuance of various awards:
  - Bonus points
  - Vouchers/coupons
  - Cashback
  - Free product rewards
  - Badges
- Verify each award type is issued correctly.
Test Target Progress Tracking:
- Verify real-time progress updates:
  - Progress bar updates with each activity
  - Remaining amount to target is accurate
  - Progress percentage is calculated correctly
- Confirm progress is visible to customer.
Test Multiple Targets Achievement:
- Create scenario where single transaction achieves multiple targets.
- Verify that:
  - All applicable targets are detected
  - All corresponding awards are issued
  - Multiple notifications are sent (or consolidated)
  - No awards are missed
Test Target with Multiple Tiers:
- If tiered targets exist (e.g., Bronze at $100, Silver at $250, Gold at $500):
  - Test achievement of each tier
  - Verify correct award for each tier
  - Test skipping tiers (e.g., $0 to $300 in one transaction)
Test Award Limits:
- If award limits exist:
  - Test earning up to the limit (should succeed)
  - Test exceeding the limit (should be capped)
  - Verify clear messaging when limit reached
Test Target Period Reset:
- For periodic targets (daily, weekly, monthly):
  - Achieve target in current period
  - Wait for period to reset
  - Verify target resets and can be achieved again
  - Confirm new award is issued for new period
Test Edge Cases:
- Transaction exactly at target threshold
- Transaction significantly exceeding target
- Target achieved at period boundary (midnight)
- Multiple transactions in rapid succession
- Target achieved during system maintenance
- Concurrent target achievements by same customer
Test Transaction Reversal Impact:
- Achieve a target and receive instant award.
- Reverse the qualifying transaction.
- Verify behavior:
  - Is the award revoked?
  - Is the target reset?
  - Is the customer notified?
- Document expected behavior.
Validate Points Ledger:
- For points-based awards:
  - Check points ledger entry
  - Verify award reason/description
  - Confirm target reference
  - Check timestamp accuracy
Validate Voucher/Reward Wallet:
- For voucher-based awards:
  - Check voucher appears in wallet
  - Verify voucher details are correct
  - Confirm voucher is immediately usable
  - Test voucher redemption
Test Customer Eligibility:
- If targets have eligibility criteria:
  - Test eligible customer (should receive award)
  - Test ineligible customer (should not receive award)
  - Verify eligibility is checked in real-time
Check System Performance:
- Monitor system performance during instant award processing:
  - Transaction processing time
  - Award issuance latency
  - Notification delivery time
  - System resource utilization
- Verify no degradation during peak loads.
Test Offline/Delayed Scenarios:
- If transactions can be posted with delays:
  - Post a backdated transaction that achieves a target
  - Verify award is still issued
  - Check if award timing reflects transaction time or processing time
Review Audit Trail:
- Check audit logs for target achievements:
  - Target achieved timestamp
  - Qualifying transaction reference
  - Award issued details
  - Customer notification status
  - Any errors or exceptions
Validate Reporting:
- Generate target achievement reports:
  - Targets achieved by period
  - Awards issued by type
  - Achievement rates by target
  - Customer participation rates
  - Award redemption rates
- Verify report accuracy.
Test API Behavior:
- Test target and award via API:
  - Transaction API triggers target evaluation
  - Award issuance is reflected in API responses
  - Target progress queryable via API
- Verify real-time behavior through API.
Test Fraud Controls:
- Verify fraud prevention for instant awards:
  - Velocity limits on target achievements
  - Suspicious pattern detection
  - Award limits per customer
  - Transaction validation before award
Compare with Batch Processing:
- If possible, compare instant vs. batch behavior:
  - Disable configuration and verify batch processing
  - Re-enable and verify instant processing
  - Document differences in timing and behavior

34. `ALLOW_NEGATIVE_BALANCE_ON_RETURN`

Purpose: This configuration enables the loyalty system to allow a customer's points balance to go negative when points are reversed or deducted 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 will deduct the points and permit a negative balance rather than blocking the return or leaving the points unreversed.
Detailed Explanation:

Points Reversal on Return: When a customer returns a product or a transaction is reversed, the points originally earned from that transaction should typically be reversed (deducted) from the customer's account.
Negative Balance Scenario: This occurs when:
- Customer earns points from a purchase
- Customer redeems or spends those points
- Customer later returns the original purchase
- System attempts to reverse the earned points
- Customer's current balance is less than the points to be reversed
Default Behavior: Without this configuration, the system may:
- Block the return until points are available
- Only reverse points up to the available balance (partial reversal)
- Require manual intervention to process the return
- Leave earned points unreversed (points leakage)
When this configuration is enabled:
- Points are fully reversed regardless of current balance
- Customer's balance can go negative
- Negative balance must be recovered through future earnings
- Returns are processed without friction
This is particularly useful for:
- Ensuring accurate points liability management
- Preventing points fraud through purchase-and-return schemes
- Maintaining seamless return experiences at POS
- Accurate financial reconciliation of points
- Programs with high return rates (e.g., fashion, e-commerce)
- Protecting program integrity

Example Use Case:

Default Behavior (Negative Balance Not Allowed):
- Customer buys $200 worth of products, earns 2,000 points.
- Customer redeems 2,000 points for a $20 reward.
- Customer returns the $200 purchase.
- System attempts to reverse 2,000 points but balance is 0.
- Return is blocked or points reversal fails.
- Store manager must intervene, causing delays and frustration.
With Negative Balance on Return Enabled:
- Customer buys $200 worth of products, earns 2,000 points.
- Customer redeems 2,000 points for a $20 reward.
- Customer returns the $200 purchase.
- System reverses 2,000 points.
- Customer's balance becomes -2,000 points.
- Return is processed smoothly.
- Customer must earn 2,000 points before having a positive balance again.
Scenario: A fashion retailer with high return rates:
Customer Transaction History:

Date	Transaction	Points Earned	Points Redeemed	Balance
Jan 1	Purchase $500	+5,000	—	5,000
Jan 5	Purchase $300	+3,000	—	8,000
Jan 10	Redemption	—	-7,500	500
Jan 15	Return $500 purchase	-5,000	—	-4,500
Jan 20	Purchase $200	+2,000	—	-2,500
Jan 25	Purchase $150	+1,500	—	-1,000
Feb 1	Purchase $100	+1,000	—	0
Feb 5	Purchase $250	+2,500	—	2,500

With Negative Balance Enabled:

Return on Jan 15 is processed without issues
Customer's balance goes to -4,500 points
Subsequent purchases gradually recover the negative balance
By Feb 5, customer is back to positive balance
No manual intervention required throughout
Business Protection:
- Customer cannot redeem while balance is negative
- Points liability is accurately maintained
- Fraud through purchase-redeem-return is prevented
- Return process remains frictionless

Impact:

Accurate Liability: Points liability reflects true earned vs. reversed points.
Fraud Prevention: Prevents gaming through purchase-redeem-return cycles.
Seamless Returns: No friction at POS for return transactions.
Operational Efficiency: Eliminates manual intervention for points-related return issues.
Financial Accuracy: Ensures points accounting is always balanced.
Program Integrity: Maintains fairness across all customers.
Customer Experience Risk: Customers may be frustrated by negative balances.
Communication Needs: Clear explanation required for negative balance situations.
Redemption Blocking: Customers cannot redeem until balance is positive.
Recovery Time: May take time for customers to recover from negative balance.
Edge Cases: Very large negative balances may require special handling.
Customer Retention Risk: Extreme negative balances may cause customer churn.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ALLOW_NEGATIVE_BALANCE_ON_RETURN is set to true or enabled.
Review Related Configurations:
- Check related settings:
  - Maximum negative balance allowed (if capped)
  - Negative balance recovery rules
  - Redemption blocking when negative
  - Notification settings for negative balance
Understand Business Rules:
- Clarify the business rules for negative balances:
  - Is there a maximum negative limit?
  - How long can a balance remain negative?
  - Are there consequences for prolonged negative balance?
  - Can negative balances be written off?
Test Basic Negative Balance Scenario:
- Create a test customer with 0 points.
- Process a purchase that earns 1,000 points (balance: 1,000).
- Redeem all 1,000 points (balance: 0).
- Process a return of the original purchase.
- Verify that:
  - Return is processed successfully
  - 1,000 points are reversed
  - Balance becomes -1,000 points
  - No errors or blocks occur
Test Partial Balance Scenario:
- Create a test customer with 500 points.
- Process a return that requires 1,000 points reversal.
- Verify that:
  - Full 1,000 points are reversed
  - Balance becomes -500 points
  - Partial reversal does NOT occur
Validate Points Ledger:
- Review the customer's points ledger after negative balance:
  - Original earn entry
  - Redemption entry
  - Reversal entry (showing full reversal)
  - Running balance showing negative value
- Verify all entries are accurate.
Test Redemption Blocking:
- With a negative balance, attempt to redeem points.
- Verify that:
  - Redemption is blocked
  - Clear error message is displayed
  - Customer is informed of negative balance
  - Required points to reach positive balance is shown
Test Balance Recovery:
- With a negative balance, process new purchases.
- Verify that:
  - New points are earned normally
  - Points are applied against negative balance
  - Balance gradually moves toward positive
  - Redemption is allowed once balance is positive
Test Customer-Facing Display:
- Check how negative balance is displayed:
  - App/website shows negative balance clearly
  - Negative indicator (minus sign, red color)
  - Explanation of why balance is negative
  - Information on how to recover
Test Notifications:
- Verify notifications for negative balance events:
  - Notification when balance goes negative
  - Explanation of the cause (return processed)
  - Information about redemption restrictions
  - Guidance on earning back to positive
- Check notification channels (email, SMS, push).
Test Maximum Negative Limit:
- If a maximum negative limit exists:
  - Process returns that would exceed the limit
  - Verify behavior at the limit
  - Check if return is blocked or alternative handling
Test Multiple Returns:
- Process multiple returns that accumulate negative balance.
- Verify that:
  - Each return is processed correctly
  - Negative balance accumulates properly
  - No artificial limits block legitimate returns
Test Return Without Prior Redemption:
- Process a return when customer has sufficient positive balance.
- Verify that:
  - Points are reversed normally
  - Balance remains positive (or zero)
  - Standard reversal process applies
Test Points Expiry Interaction:
- If points have expiry:
  - Test return of transaction with expired points
  - Verify how expiry interacts with negative balance
  - Check if expired points are still reversed
Test Different Points Types:
- If multiple points types exist (regular, bonus, promotional):
  - Test negative balance for each type
  - Verify type-specific handling
  - Check if negative applies to specific type or overall
Test Tier/Status Impact:
- Verify if negative balance affects tier status:
  - Does negative balance impact tier calculation?
  - Are tier benefits affected?
  - Is tier downgrade triggered?
Test POS Integration:
- Process return at POS with negative balance scenario.
- Verify that:
  - POS processes return without errors
  - Points reversal is communicated to POS
  - Receipt shows points reversed
  - No cashier intervention required
Test E-commerce Returns:
- Process online return with negative balance scenario.
- Verify that:
  - Online return is processed smoothly
  - Points reversal is automatic
  - Customer is notified appropriately
  - Account reflects negative balance
Test Edge Cases:
- Return of very old transaction
- Return when customer account is inactive
- Partial return (verify proportional points reversal)
- Return with mixed payment (points + cash)
- Return of promotional/bonus points transaction
- Multiple returns in single day
- Return that would create extremely large negative balance
Test Account Closure with Negative Balance:
- Attempt to close account with negative balance.
- Verify behavior:
  - Is closure allowed?
  - Is negative balance written off?
  - Is there a settlement requirement?
Test Reporting:
- Generate reports related to negative balances:
  - Customers with negative balances
  - Total negative points liability
  - Average recovery time
  - Negative balance by cause (returns, adjustments)
- Verify report accuracy.
Test Financial Reconciliation:
- Verify negative balances in financial reports:
  - Points liability calculations
  - Negative balance impact on liability
  - Reconciliation with transaction records
Review Audit Trail:
- Check audit logs for negative balance events:
  - Return transaction details
  - Points reversal amount
  - Resulting negative balance
  - Timestamp and user/system info
Test API Behavior:
- Test return processing via API:
  - API accepts return with negative balance result
  - Response includes new balance (negative)
  - Error handling for edge cases
- Query balance API returns negative value correctly.
Test Customer Service Tools:
- Verify customer service capabilities:
  - View negative balance details
  - Explain negative balance to customer
  - Manual adjustment options (if allowed)
  - Escalation procedures for disputes
Test Fraud Scenarios:
- Verify fraud controls:
  - Alerts for suspicious return patterns
  - Monitoring of customers with frequent negative balances
  - Limits on negative balance accumulation
  - Flagging of potential abuse
Compare with Disabled Configuration:
- If possible, test with configuration disabled:
  - Verify return is blocked or partial reversal occurs
  - Document the difference in behavior
  - Confirm configuration controls the behavior

35. `ALLOW_RETURN_ON_TARGET`

Purpose: 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.

Detailed Explanation:

Targets/Milestones: Goals set within the loyalty program that customers work toward, such as:
- Spend targets (e.g., "Spend $500 this month")
- Visit targets (e.g., "Visit 10 times this quarter")
- Quantity targets (e.g., "Buy 5 items from Category X")
- Points accumulation targets (e.g., "Earn 10,000 points")
- Streak targets (e.g., "Shop 4 consecutive weeks")
Return Impact on Targets: When a transaction that contributed to target progress is returned:
- The contribution should be removed from target progress
- If target was achieved, achievement may need to be reversed
- Associated rewards may need to be revoked
- Target status should reflect accurate qualifying activity
By default, returns may:
- Not affect target progress (targets remain achieved)
- Be ignored in target calculations
- Require manual adjustment
- Create discrepancies between actual activity and target status
When this configuration is enabled:
- Returns automatically decrement target progress
- Target achievements are re-evaluated after returns
- Rewards may be revoked if target is no longer met
- Target tracking accurately reflects net qualifying activity
This is particularly useful for:
- Maintaining target integrity and accuracy
- Preventing gaming through purchase-and-return schemes
- Ensuring fair target achievement across customers
- Accurate tracking of promotional campaign performance
- Programs with high return rates
- Protecting reward liability from fraudulent claims

Example Use Case:

Default Behavior (Returns Don't Affect Targets):
- Customer has a target: "Spend $500, earn $50 voucher"
- Customer makes $550 purchase, achieves target, receives $50 voucher
- Customer returns $200 of the purchase
- Target remains "achieved" despite only $350 net spend
- Customer keeps the $50 voucher unfairly
With Return on Target Enabled:
- Customer has a target: "Spend $500, earn $50 voucher"
- Customer makes $550 purchase, achieves target, receives $50 voucher
- Customer returns $200 of the purchase
- System recalculates: Net spend = $350
- Target status changes from "Achieved" to "In Progress"
- $50 voucher is revoked
- Customer is notified of the adjustment
- Customer needs $150 more to re-achieve the target
Scenario: A retail loyalty program with monthly spend targets:
Target Configuration:

Target Tier	Spend Required	Reward
Bronze	$200	500 bonus points
Silver	$500	$25 voucher
Gold	$1,000	$75 voucher + Free shipping

Customer Journey with Returns:

Date	Transaction	Amount	Cumulative Spend	Target Status
Mar 1	Purchase	+$300	$300	Bronze ✓ (500 pts awarded)
Mar 8	Purchase	+$250	$550	Silver ✓ ($25 voucher awarded)
Mar 12	Return	-$150	$400	Silver revoked, Bronze ✓
Mar 15	Purchase	+$400	$800	Silver ✓ ($25 voucher re-awarded)
Mar 20	Purchase	+$250	$1,050	Gold ✓ ($75 voucher awarded)
Mar 25	Return	-$300	$750	Gold revoked, Silver ✓
Mar 28	Purchase	+$300	$1,050	Gold ✓ ($75 voucher re-awarded)

With Return on Target Enabled:
- Mar 12 return reduces spend from $550 to $400
- Silver target ($500) is no longer met
- $25 voucher is revoked
- Customer retains Bronze status (still above $200)
- Mar 25 return reduces spend from $1,050 to $750
- Gold target ($1,000) is no longer met
- $75 voucher is revoked
- Customer retains Silver status (still above $500)
- Final purchase restores Gold status

Impact:

Target Integrity: Targets accurately reflect net qualifying activity.
Fraud Prevention: Prevents gaming through purchase-achieve-return schemes.
Fair Program: All customers must legitimately achieve targets.
Accurate Liability: Reward liability reflects actual achievements.
Campaign Accuracy: Promotional campaign results are accurate.
Trust: Maintains program credibility and fairness.
Customer Friction: Customers may be frustrated by target reversals.
Communication Needs: Clear explanation required for target adjustments.
Complexity: Adds complexity to return processing and target tracking.
Reward Recovery: Revoked rewards (especially used ones) may cause issues.
Edge Cases: Partial returns, timing issues require careful handling.
Support Volume: May increase customer service inquiries.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that ALLOW_RETURN_ON_TARGET is set to true or enabled.
Review Target Configuration:
- Check the configured targets:
  - Target names and descriptions
  - Achievement criteria (spend, visits, quantity)
  - Associated rewards
  - Target periods (daily, weekly, monthly, campaign)
  - Return adjustment rules
Review Related Configurations:
- Check related settings:
  - Reward revocation on target reversal
  - Grace periods before revocation
  - Notification settings
  - Partial return handling
Test Basic Return Impact on Target:
- Create a test customer with no target progress.
- Process transactions to achieve a target.
- Verify target is achieved and reward is issued.
- Process a return of a qualifying transaction.
- Verify that:
  - Target progress is decremented
  - Target status is re-evaluated
  - If below threshold, target is marked as not achieved
Test Target Achievement Reversal:
- Achieve a target (e.g., $500 spend target).
- Receive the associated reward.
- Process a return that brings spend below $500.
- Verify that:
  - Target status changes from "Achieved" to "In Progress"
  - Associated reward is revoked
  - Customer is notified of the reversal
Test Partial Return:
- Achieve a target with a single large transaction.
- Process a partial return of that transaction.
- Verify that:
  - Target progress is reduced proportionally
  - Target status is re-evaluated based on remaining amount
  - Appropriate action is taken (maintain or revoke)
Test Return Below Threshold:
- Achieve a target with spend slightly above threshold.
- Process a small return that keeps spend above threshold.
- Verify that:
  - Target progress is decremented
  - Target remains achieved (still above threshold)
  - Reward is retained
Test Multiple Tier Targets:
- If tiered targets exist (Bronze, Silver, Gold):
  - Achieve Gold tier
  - Process return that drops below Gold but above Silver
  - Verify Gold reward is revoked
  - Verify Silver reward is retained (or issued if not already)
  - Verify Bronze reward is retained
Validate Target Progress Display:
- Check customer-facing target progress:
  - Progress updates after return
  - Accurate remaining amount shown
  - Status reflects current achievement level
  - History shows adjustments
Test Reward Revocation:
- When target is reversed, verify reward handling:
  - Unused reward is revoked/cancelled
  - Reward disappears from customer wallet
  - Reward cannot be used after revocation
- Document behavior for already-used rewards.
Test Already-Used Reward Scenario:
- Achieve target and receive reward.
- Use/redeem the reward.
- Process return that reverses target achievement.
- Verify behavior:
  - Is the used reward value recovered?
  - Is there a points/balance adjustment?
  - Is the return blocked?
  - Document the configured behavior.
Test Customer Notifications:
- Verify notifications for target adjustments:
  - Notification when target progress decreases
  - Notification when target achievement is reversed
  - Notification when reward is revoked
  - Clear explanation of the cause
- Check notification channels (email, SMS, push, in-app).
Test Different Target Types:
- Test return impact on various target types:
  - Spend-based targets (return reduces spend)
  - Visit-based targets (return may reduce visit count)
  - Quantity-based targets (return reduces item count)
  - Points-based targets (return reduces points earned)
- Verify consistent behavior across types.
Test Target Period Boundaries:
- Achieve a monthly target near month-end.
- Process return in the following month.
- Verify behavior:
  - Does return affect previous month's target?
  - Is there a cutoff for return impact?
  - Document period-specific rules.
Test Streak/Consecutive Targets:
- If streak targets exist (e.g., "Shop 4 consecutive weeks"):
  - Build a streak toward target
  - Process return that removes a qualifying transaction
  - Verify streak is recalculated
  - Check if streak is broken or maintained
Test Multiple Transactions Contributing to Target:
- Achieve target through multiple transactions.
- Return one of the contributing transactions.
- Verify that:
  - Only the returned transaction's contribution is removed
  - Other transactions' contributions remain
  - Target is re-evaluated based on remaining contributions
Test Return of Non-Qualifying Transaction:
- Process a return of a transaction that didn't contribute to any target.
- Verify that:
  - Target progress is unaffected
  - No target adjustments occur
  - System correctly identifies non-qualifying returns
Test Points Ledger and Target Tracker:
- Review points ledger after return:
  - Points reversal entry
  - Target adjustment entry (if separate)
- Review target tracker:
  - Progress history shows adjustment
  - Accurate timeline of changes
Test Re-Achievement After Reversal:
- Have target reversed due to return.
- Process new qualifying transactions.
- Verify that:
  - Target can be re-achieved
  - Reward is re-issued upon re-achievement
  - No duplicate rewards for same achievement
Test Grace Period (if configured):
- If grace period exists before target reversal:
  - Process return that would reverse target
  - Verify target remains achieved during grace period
  - Check if re-qualifying during grace period prevents reversal
  - Verify reversal occurs after grace period expires
Test Edge Cases:
- Return exactly equal to target threshold contribution
- Return of transaction from previous target period
- Multiple returns in rapid succession
- Return during target evaluation/batch processing
- Return of transaction that achieved multiple targets
- Return when customer has multiple active targets
Test POS Integration:
- Process return at POS.
- Verify that:
  - Target adjustment is communicated to POS
  - Receipt shows target impact (if applicable)
  - Cashier is informed of reward revocation (if applicable)
Test E-commerce Returns:
- Process online return.
- Verify that:
  - Target adjustment is automatic
  - Customer is notified appropriately
  - Account reflects updated target status
Review Audit Trail:
- Check audit logs for target adjustments:
  - Return transaction details
  - Target progress before and after
  - Achievement status change
  - Reward revocation (if applicable)
  - Timestamp and system info
Validate Reporting:
- Generate target-related reports:
  - Target achievements and reversals
  - Rewards issued and revoked
  - Return impact on targets
  - Net target achievement rates
- Verify report accuracy.
Test API Behavior:
- Test return processing via API:
  - API processes return with target impact
  - Response includes target adjustment details
  - Target status queryable via API
- Verify accurate real-time updates.
Test Fraud Controls:
- Verify fraud prevention:
  - Alerts for suspicious achieve-return patterns
  - Monitoring of frequent target reversals
  - Flagging of potential abuse
  - Limits on re-achievement attempts
Compare with Disabled Configuration:
- If possible, test with configuration disabled:
  - Verify returns do not affect target progress
  - Confirm targets remain achieved after return
  - Document the difference in behavior

36. `CONF_ENABLE_SIMULATION_API_MODE`

Purpose: 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.

Detailed Explanation:

Simulation Mode: A testing/preview capability that processes requests through the full business logic but does not persist any changes, including:
- Transaction Simulation: Preview points earned, promotions triggered, and rewards without recording the transaction
- Redemption Simulation: Validate redemption eligibility and calculate outcomes without deducting points
- Promotion Simulation: Test promotion rules and see what would be awarded
- Tier Simulation: Preview tier changes based on hypothetical activity
- Campaign Simulation: Test campaign targeting and messaging without sending
Use Cases for Simulation Mode:
- Integration Testing: Validate API integrations without affecting production data
- Configuration Validation: Test new promotion or rule configurations before going live
- Customer Service: Preview what a customer would earn/receive without processing
- Training: Train staff on system behavior without real consequences
- Troubleshooting: Debug issues by simulating problematic scenarios
- What-If Analysis: Analyze potential outcomes of different scenarios
By default, all API calls are executed in live mode, committing changes to the database.
When this configuration is enabled:
- APIs accept a simulation flag/parameter
- Simulated requests are processed through full business logic
- Results are returned as if the operation was executed
- No data is persisted or committed
- No notifications are sent
- No external systems are affected
This is particularly useful for:
- Development and QA environments
- Pre-production testing
- Customer service tools
- Integration validation
- Promotion testing before launch
- Training and demonstration purposes

Example Use Case:

Default Behavior (No Simulation Mode):
- Developer wants to test a new promotion configuration
- Must create test customers and process real transactions
- Test data pollutes the database
- Mistakes affect real records
- Cleanup is required after testing
- Risk of accidentally affecting production data
With Simulation API Mode Enabled:
- Developer adds simulation=true parameter to API call
- API processes the transaction through all business logic
- Response shows: points earned, promotions triggered, rewards issued
- No transaction is recorded in the database
- No points are added to customer's account
- No notifications are sent
- Developer validates the configuration is correct
- No cleanup required

Scenario: Testing a new "Double Points Weekend" promotion:

Simulation API Request:
POST /api/v1/transactions?simulation=true
{
"customer_id": 12345,
"transaction_amount": 100.00,
"transaction_date": "2024-03-16",
"store_id": "STORE001",
"line_items": [
{
"sku": "PROD001",
"quantity": 2,
"amount": 50.00
},
{
"sku": "PROD002",
"quantity": 1,
"amount": 50.00
}
]
}
Simulation API Response:
{
"simulation": true,
"simulation_note": "This is a simulated response. No data was persisted.",
"transaction_result": {
"base_points_earned": 100,
"promotions_triggered": [
{
"promotion_id": 5001,
"promotion_name": "Double Points Weekend",
"bonus_points": 100,
"reason": "2x points on weekend transactions"
}
],
"total_points_earned": 200,
"new_points_balance": 5200,
"tier_progress": {
"current_tier": "Silver",
"points_to_next_tier": 2800
},
"rewards_issued": [],
"coupons_triggered": [
{
"coupon_code": "WEEKEND20",
"discount": "20% off next purchase"
}
]
},
"warnings": [],
"data_persisted": false
}

Comparison:

Aspect	Live Mode	Simulation Mode
Business Logic	Executed	Executed
Response Data	Real results	Simulated results
Database Write	Yes	No
Points Balance	Updated	Unchanged
Transaction Record	Created	Not created
Notifications	Sent	Not sent
External Calls	Made	Skipped / Mocked
Reversible	Requires reversal	N/A (nothing to reverse)

Impact:

Safe Testing: Test configurations without risk to production data.
Faster Development: Developers can iterate quickly without cleanup.
Better Validation: Validate complex scenarios before going live.
Customer Service: Preview outcomes for customers without commitment.
Training: Train staff safely on system behavior.
Troubleshooting: Debug issues without creating more problems.
Integration Testing: Validate integrations without side effects.
Performance Consideration: Simulation still consumes system resources.
Accuracy Dependency: Simulation accuracy depends on implementation completeness.
External Systems: External integrations may not be fully simulated.
Time-Sensitive Logic: Simulation may not perfectly replicate time-based rules.
Concurrency: Simulation doesn't account for concurrent real transactions.
Security: Simulation endpoints need proper access controls.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm that CONF_ENABLE_SIMULATION_API_MODE is set to true or enabled.
Review API Documentation:
- Check API documentation for simulation parameters:
  - Parameter name (e.g., simulation, dry_run, preview)
  - Supported endpoints
  - Request format
  - Response format differences
Verify Feature Availability:
- Check which APIs support simulation mode:
  - Transaction APIs
  - Redemption APIs
  - Enrollment APIs
  - Points adjustment APIs
  - Promotion evaluation APIs
Test Basic Transaction Simulation:
- Record customer's current points balance.
- Send a transaction API request with simulation flag.
- Verify that:
  - API returns successful response
  - Response includes calculated points/rewards
  - Response indicates simulation mode
- Check customer's points balance again.
- Verify balance is unchanged.
Validate Simulation Response Content:
- Compare simulation response to live response structure:
  - Points earned calculation
  - Promotions triggered
  - Rewards/coupons issued
  - Tier impact
  - Other relevant data
- Verify simulation response includes all expected fields.
Test Simulation Indicator in Response:
- Verify response clearly indicates simulation mode:
  - simulation: true flag
  - Simulation disclaimer/note
  - Clear differentiation from live response
Verify No Database Changes:
- Before simulation: Query database for customer records.
- Execute simulation API call.
- After simulation: Query database again.
- Verify that:
  - No new transaction records created
  - Points balance unchanged
  - No new rewards/coupons created
  - No audit log entries (or marked as simulation)
Test Promotion Evaluation in Simulation:
- Configure a test promotion.
- Send simulation request that should trigger the promotion.
- Verify that:
  - Promotion is evaluated correctly
  - Bonus points/rewards are calculated
  - Promotion details are in response
  - No actual bonus points are awarded
Test Redemption Simulation:
- Send redemption API request with simulation flag.
- Verify that:
  - Eligibility is validated
  - Points deduction is calculated
  - Reward details are returned
  - Actual points are NOT deducted
  - No reward is actually issued
Test Simulation with Insufficient Balance:
- Simulate a redemption exceeding customer's points.
- Verify that:
  - Simulation correctly identifies insufficient balance
  - Error/validation message is returned
  - No partial processing occurs
Test Tier Calculation in Simulation:
- Simulate a transaction that would cause tier upgrade.
- Verify that:
  - Tier change is calculated and shown in response
  - Actual tier is NOT changed
  - Customer remains in original tier
Verify No Notifications Sent:
- Configure notification triggers (email, SMS, push).
- Execute simulation that would trigger notifications.
- Verify that:
  - No emails are sent
  - No SMS messages are sent
  - No push notifications are sent
- Check notification logs to confirm.
Test Simulation with External Integrations:
- If external systems are integrated (e.g., coupon providers):
  - Execute simulation that would call external system
  - Verify external system is NOT called
  - Or verify external system receives simulation flag
Test Multiple Simulations:
- Execute multiple simulation requests for same customer.
- Verify that:
  - Each simulation is independent
  - Simulations don't affect each other
  - Customer data remains unchanged throughout
Test Simulation vs. Live Comparison:
- Execute simulation request, record response.
- Execute identical live request.
- Compare responses:
  - Core calculations should match
  - Simulation should have simulation indicators
  - Live should have actual record IDs
Test Simulation with Complex Scenarios:
- Test simulation with:
  - Multiple line items
  - Multiple promotions
  - Stacked discounts
  - Target/milestone progress
  - Coupon application
- Verify all complex logic is evaluated correctly.
Test Simulation for Different Customer States:
- Test simulation for:
  - New customer (no history)
  - Active customer (with balance)
  - Customer near tier threshold
  - Customer with active targets
  - Customer with restrictions/blocks
- Verify accurate simulation for each state.
Test Error Handling in Simulation:
- Send invalid simulation requests:
  - Missing required fields
  - Invalid customer ID
  - Invalid product codes
- Verify that:
  - Errors are returned appropriately
  - Error messages are clear
  - No partial data is persisted
Test Simulation Parameter Variations:
- Test different ways to invoke simulation:
  - Query parameter: ?simulation=true
  - Header: X-Simulation-Mode: true
  - Body parameter: "simulation": true
- Verify supported methods per documentation.
Test Simulation Access Controls:
- Verify simulation mode access:
  - Which API keys/users can use simulation
  - Is simulation restricted to certain environments
  - Are there rate limits for simulation
- Test unauthorized simulation attempts.
Test Simulation in Different Environments:
- If available, test simulation in:
  - Development environment
  - Staging/QA environment
  - Production environment (if allowed)
- Verify consistent behavior across environments.
Test Time-Based Simulation:
- If simulation supports custom timestamps:
  - Simulate transaction with future date
  - Simulate transaction with past date
  - Verify time-based promotions are evaluated correctly
Test Simulation Performance:
- Measure simulation response times.
- Compare to live API response times.
- Verify simulation doesn't significantly impact performance.
- Test simulation under load.
Review Audit/Logging:
- Check if simulation requests are logged:
  - Are simulations logged separately?
  - Is there a simulation flag in logs?
  - Can simulations be distinguished from live calls?
- Verify logging meets compliance requirements.
Test Simulation for Batch Operations:
- If batch APIs support simulation:
  - Simulate batch transaction upload
  - Verify batch is evaluated but not persisted
  - Check batch-level response
Validate API Documentation Accuracy:
- Compare actual simulation behavior to documentation.
- Verify all documented features work as described.
- Note any discrepancies.
Test Simulation with Webhooks:
- If webhooks are configured:
  - Execute simulation that would trigger webhook
  - Verify webhook is NOT fired
  - Or verify webhook receives simulation indicator
Test Disabling Simulation Mode:
- If possible, disable the configuration.
- Attempt simulation API call.
- Verify that:
  - Simulation parameter is ignored, OR
  - Error is returned indicating simulation not available

37. `PE_NEW_UI_ROLLOUT_STATUS`

Purpose: 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.

Detailed Explanation:

Promotion Engine (PE): The module within the Capillary platform used to create, configure, manage, and analyze promotional campaigns, including:
- Points-based promotions
- Discount promotions
- Bonus/multiplier promotions
- Tiered promotions
- Target/milestone-based promotions
- Coupon promotions
New UI Rollout: The process of transitioning users from the legacy/old promotion engine interface to a redesigned, modernized interface with:
- Improved user experience and navigation
- Enhanced promotion builder/wizard
- Better visualization of promotion rules
- Streamlined workflows
- New features and capabilities
- Improved performance
Rollout Status Values: Typically includes states such as:
- DISABLED / OFF: New UI is not available; users see only legacy UI
- BETA / PILOT: New UI available to select beta users/orgs
- PARTIAL / GRADUAL: New UI available to percentage of users
- ENABLED / ON: New UI is fully available to all users
- FORCED / MANDATORY: New UI is mandatory; legacy UI is disabled
This configuration allows:
- Controlled feature rollout to minimize risk
- A/B testing of new vs. legacy UI
- Gradual user migration with training
- Quick rollback if issues are discovered
- Feedback collection from early adopters
This is particularly useful for:
- Managing major UI transitions
- Reducing risk of widespread issues
- Allowing users to adapt gradually
- Gathering feedback before full rollout
- Supporting different readiness levels across organizations

Example Use Case:

Rollout Status = DISABLED:
- All users see the legacy Promotion Engine UI
- New UI is not accessible
- No changes to user experience
Rollout Status = BETA:
- Select pilot organizations/users have access to new UI
- Beta users can toggle between new and legacy UI
- Feedback is collected from beta participants
- Issues are identified and fixed before wider rollout
Rollout Status = ENABLED:
- All users have access to the new UI
- New UI is the default experience
- Legacy UI may still be accessible via toggle
- Users can choose their preferred interface
Rollout Status = FORCED:
- New UI is mandatory for all users
- Legacy UI is completely disabled
- All users must use the new interface
Scenario: Phased rollout of new Promotion Engine UI:
Rollout Timeline:

Phase	Status	Duration	Audience	Actions
Phase 1	DISABLED	—	None	Development and internal testing
Phase 2	BETA	4 weeks	5 pilot orgs	Beta testing, feedback collection
Phase 3	PARTIAL (25%)	2 weeks	25% of orgs	Gradual rollout, monitoring
Phase 4	PARTIAL (50%)	2 weeks	50% of orgs	Expanded rollout
Phase 5	ENABLED	4 weeks	All orgs	Full availability, legacy optional
Phase 6	FORCED	Ongoing	All orgs	Legacy UI deprecated

User Experience by Status:
DISABLED:

┌─────────────────────────────────┐
│ Promotion Engine (Legacy) │
│ [Create Promotion] [View All] │
│ ┌─────────────────────────────┐ │
│ │ Legacy promotion builder... │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────┘

BETA/ENABLED:
┌─────────────────────────────────┐
│ Promotion Engine │
│ [Try New UI ✨] [Legacy UI] │
│ ┌─────────────────────────────┐ │
│ │ Toggle available to switch │ │
│ │ between interfaces │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────┘

FORCED:
┌─────────────────────────────────┐
│ Promotion Engine (New) │
│ [Create Promotion] [View All] │
│ ┌─────────────────────────────┐ │
│ │ New promotion builder only │ │
│ │ Legacy UI no longer available│ │
│ └─────────────────────────────┘ │
└─────────────────────────────────┘

Impact:

Controlled Risk: Phased rollout minimizes impact of potential issues.
User Adaptation: Users have time to learn the new interface.
Feedback Loop: Early feedback improves the final product.
Rollback Capability: Easy to revert if critical issues arise.
Training Alignment: Training can be scheduled with rollout phases.
Feature Parity: Ensures new UI has all needed features before forcing migration.
Complexity: Managing multiple UI versions adds complexity.
Support Burden: Support team must know both interfaces during transition.
Documentation: Documentation needed for both UIs during rollout.
User Confusion: Some users may be confused by interface changes.
Data Consistency: Promotions created in either UI must work correctly.
Testing Overhead: Both UIs must be tested during transition period.

How to Verify:

Check Configuration Settings:
- Review the organization's configuration to confirm the current value of PE_NEW_UI_ROLLOUT_STATUS.
- Note the current status (DISABLED, BETA, PARTIAL, ENABLED, FORCED, etc.).
Verify Status Value:
- Confirm the exact status value:
  - What are the valid status values?
  - What is the current status for this organization?
  - Is status set at org level or global level?
Test DISABLED Status:
- If status is DISABLED:
  - Navigate to Promotion Engine
  - Verify only legacy UI is displayed
  - Confirm no option to access new UI
  - Check that new UI URLs return error or redirect
Test BETA Status:
- If status is BETA:
  - Verify if current org/user is in beta group
  - If in beta: Confirm new UI is accessible
  - If not in beta: Confirm only legacy UI is available
  - Check for beta indicator/badge in UI
Test ENABLED Status:
- If status is ENABLED:
  - Navigate to Promotion Engine
  - Verify new UI is accessible
  - Check for toggle/switch between new and legacy UI
  - Confirm both interfaces are functional
Test FORCED Status:
- If status is FORCED:
  - Navigate to Promotion Engine
  - Verify only new UI is displayed
  - Confirm legacy UI is not accessible
  - Check that legacy UI URLs redirect to new UI
Verify UI Toggle Functionality:
- If toggle between UIs is available:
  - Click toggle to switch to new UI
  - Verify new UI loads correctly
  - Click toggle to switch back to legacy UI
  - Verify legacy UI loads correctly
  - Check that preference is remembered
Test New UI Access:
- Access the new Promotion Engine UI.
- Verify that:
  - UI loads without errors
  - Navigation is functional
  - All menu items are accessible
  - Page renders correctly
Test Legacy UI Access:
- Access the legacy Promotion Engine UI.
- Verify that:
  - UI loads without errors (if not FORCED)
  - All legacy features are functional
  - No degradation due to new UI rollout
Verify Feature Parity:
- Compare features between new and legacy UI:
  - Create promotion
  - Edit promotion
  - View promotion list
  - Promotion analytics
  - Promotion scheduling
  - Rule configuration
- Document any feature gaps.
Test Promotion Creation in New UI:
- Create a new promotion using the new UI.
- Verify that:
  - Promotion builder/wizard works correctly
  - All rule types are available
  - Promotion saves successfully
  - Promotion appears in promotion list
Test Promotion Creation in Legacy UI:
- Create a new promotion using the legacy UI.
- Verify that:
  - Legacy builder works correctly
  - Promotion saves successfully
  - Promotion is visible in both UIs
Test Cross-UI Compatibility:
- Create promotion in new UI, view/edit in legacy UI.
- Create promotion in legacy UI, view/edit in new UI.
- Verify that:
  - Promotions are fully compatible
  - No data loss or corruption
  - All fields are displayed correctly
Test User Preference Persistence:
- Select preferred UI (new or legacy).
- Log out and log back in.
- Verify that:
  - Preference is remembered
  - User returns to preferred UI
  - Preference survives session changes
Verify Role-Based Access:
- Test with different user roles:
  - Admin users
  - Marketing users
  - Read-only users
- Verify appropriate access in both UIs.
Test New UI Specific Features:
- If new UI has exclusive features:
  - Identify new features
  - Test each new feature
  - Verify features work correctly
  - Document new capabilities
Test Performance:
- Compare performance between UIs:
  - Page load times
  - Promotion list loading
  - Search/filter responsiveness
  - Save operation speed
- Document any performance differences.
Verify Error Handling:
- Test error scenarios in new UI:
  - Invalid inputs
  - Network errors
  - Session timeout
- Verify errors are handled gracefully.
Test Browser Compatibility:
- Test new UI in supported browsers:
  - Chrome
  - Firefox
  - Safari
  - Edge
- Verify consistent behavior across browsers.
Test Mobile/Responsive Behavior:
- If applicable, test new UI on:
  - Tablet devices
  - Mobile devices
  - Different screen sizes
- Verify responsive design works correctly.
Verify Help/Documentation Links:
- Check help links in new UI:
  - Do they point to updated documentation?
  - Is documentation accurate for new UI?
  - Are tooltips and hints helpful?
Test Rollout Status Change:
- If possible, test changing the rollout status:
  - Change from DISABLED to ENABLED
  - Verify new UI becomes available
  - Change from ENABLED to DISABLED
  - Verify new UI becomes unavailable
Verify Analytics/Tracking:
- Check if UI usage is tracked:
  - New UI adoption metrics
  - Feature usage in new UI
  - User feedback collection
- Verify tracking is functional.
Test Notification/Announcement:
- Check for rollout announcements:
  - Banner announcing new UI
  - Tutorial or onboarding for new UI
  - Release notes or changelog
- Verify users are informed of changes.
Review Audit Logs:
- Check audit logs for UI-related entries:
  - UI preference changes
  - Promotions created in new vs. legacy UI
  - Any UI-specific logging
Test Feedback Mechanism:
- If feedback collection is enabled:
  - Locate feedback option in new UI
  - Submit test feedback
  - Verify feedback is received
Verify Rollback Capability:
- Confirm rollback process:
  - Can status be changed quickly if issues arise?
  - Is there a documented rollback procedure?
  - Test rollback in non-production if possible
Document Current Status:
- Record the current rollout status.
- Note any organization-specific settings.
- Document expected timeline for status changes.
- Identify contacts for rollout questions.

Updated about 8 hours ago

1. MAX_ACTIVE_PROMOTIONS_PER_PROGRAM

2. ALLOW_PROMISED_POINTS_CONVERSION

3. ENABLE_POINTS_EXPIRY_NEW_FLOW

4. ENABLE_ALTERNATE_CURRENCY

5. ALLOW_MLP

6. ENABLE_POINTS_LEDGER

7. ENABLE_TIER_DOWNGRADE_ON_PARTNER_PROGRAM_EXPIRY

8. ENABLE_IDENTIFIER_IN_PROMOTION_CREATION

9. ALLOW_POINTS_IN_NEGATIVE_DUE_TO_RETURN

10. CONF_EMF_ROLLOUT_STATUS

11. CONF_EMF_TRACKER_ROLLOUT_MODE

12. ENABLE_TRACK_KPI

13. POINTS_REDEMPTION_THRESHOLD

14. CONF_ENABLE_DAILY_DOWNGRADE

15. TRACKERS_ALLOWED_IN_UPGRADE_DOWNGRADE

16. ENABLE_POINTS_AWARDED_SOURCE_VALUE_CAPTURING

17. CONF_DVS_COMM_BULK_PRIORITY

18. ENABLE_LOYALTY_RMQ_COMM

19. ENABLE_BULK_CONFIG_UPDATE

20. CONF_LIMITING_AGAINST_BILLING_MONTH

21. AUTO_POINTS_CONVERSION_REWARD_ALLOWED

22. CONF_REVOKE_BADGE_ON_RETURN

23. CONF_ADDITIONAL_TRACKERS_IN_SLAB_UPGRADE_AND_RENEW

24. CONF_EMF_NUM_RECOMMENDATIONS

25. CONF_EMF_ROLLOUT_STATUS

26. ENABLE_GROUP_PROGRAMS_REDEMPTION

27. SUPPLEMENTARY_PARTNER_PROGRAM_LIMIT

28. ALLOW_POINTS_TRANSFER

29. ALLOW_POINTS_REDEMPTION_REVERSAL

30. ENABLE_PARTNER_PROGRAM_LINKING

31. ENABLE_USER_GROUP_LOYALTY

32. ENABLE_FLEET_LOYALTY

33. ENABLE_AWARD_WHEN_TARGET_ACHIEVED

34. ALLOW_NEGATIVE_BALANCE_ON_RETURN

35. ALLOW_RETURN_ON_TARGET

36. CONF_ENABLE_SIMULATION_API_MODE

37. PE_NEW_UI_ROLLOUT_STATUS

`1. MAX_ACTIVE_PROMOTIONS_PER_PROGRAM`

2. `ALLOW_PROMISED_POINTS_CONVERSION`

3. `ENABLE_POINTS_EXPIRY_NEW_FLOW`

4. `ENABLE_ALTERNATE_CURRENCY`

9. `ALLOW_POINTS_IN_NEGATIVE_DUE_TO_RETURN`

10. `CONF_EMF_ROLLOUT_STATUS`

12. `ENABLE_TRACK_KPI`

13. `POINTS_REDEMPTION_THRESHOLD`

14. `CONF_ENABLE_DAILY_DOWNGRADE`

16. `ENABLE_POINTS_AWARDED_SOURCE_VALUE_CAPTURING`

17. `CONF_DVS_COMM_BULK_PRIORITY`

18. `ENABLE_LOYALTY_RMQ_COMM`

19. `ENABLE_BULK_CONFIG_UPDATE`

20. `CONF_LIMITING_AGAINST_BILLING_MONTH`

21. `AUTO_POINTS_CONVERSION_REWARD_ALLOWED`

22. `CONF_REVOKE_BADGE_ON_RETURN`

23. `CONF_ADDITIONAL_TRACKERS_IN_SLAB_UPGRADE_AND_RENEW`

24. `CONF_EMF_NUM_RECOMMENDATIONS`

25. `CONF_EMF_ROLLOUT_STATUS`

26. `ENABLE_GROUP_PROGRAMS_REDEMPTION`

27. `SUPPLEMENTARY_PARTNER_PROGRAM_LIMIT`

28. `ALLOW_POINTS_TRANSFER`

29. `ALLOW_POINTS_REDEMPTION_REVERSAL`

30. `ENABLE_PARTNER_PROGRAM_LINKING`

31. `ENABLE_USER_GROUP_LOYALTY`

32. `ENABLE_FLEET_LOYALTY`

33. `ENABLE_AWARD_WHEN_TARGET_ACHIEVED`

34. `ALLOW_NEGATIVE_BALANCE_ON_RETURN`

35. `ALLOW_RETURN_ON_TARGET`

36. `CONF_ENABLE_SIMULATION_API_MODE`

37. `PE_NEW_UI_ROLLOUT_STATUS`