Eligibility & Validation
A subvention applies to a transaction only when every eligibility check passes. These checks run automatically during order processing -- the system evaluates each subvention against the transaction details, the customer's history, and the EMI scheme selected at checkout. If any single check fails, the subvention is excluded and the next eligible subvention (by priority) is evaluated.
The checks span multiple dimensions: order amount constraints, EMI scheme matching, usage limits, validity periods, priority rules, and discount validation. Each dimension is configured when you create or edit a subvention in Command Center across the Setup, Details, and Payment Modes tabs. Understanding how these checks work helps you design subventions that target the right transactions, avoid misconfigurations, and troubleshoot why a subvention was or was not applied.
EMI scheme matching is the most involved check. Because subventions are inherently tied to EMI -- either Card EMI or Cardless EMI -- the system must confirm that the subvention's EMI targeting aligns with the EMI scheme the customer selected. This includes matching payment mode, tenure, frequency, currency, and (for Card EMI) issuer, card network, and BIN. A mismatch on any of these attributes disqualifies the subvention for that transaction.
The sections below explain each eligibility dimension in detail, starting with a summary table and then covering each check individually.
Eligibility Criteria at a Glance
| Eligibility Check | Field | Condition | Notes |
|---|---|---|---|
| Order amount (min) | min_order_amount | Order amount ≥ min_order_amount | 0 = no minimum |
| Order amount (max) | max_order_amount | Order amount ≤ max_order_amount | 0 = no maximum |
| Payment mode | payment_mode_code | Must match: card_emi or cardless_emi | -- |
| Tenure | allowed_emi_tenures | Subvention tenure must match EMI scheme tenure | Required match |
| Frequency | frequency field | Subvention frequency must match EMI scheme frequency | Required match |
| Currency | currency | Must match EMI scheme currency | -- |
| Issuer/bank | issuer_bank | Must match (Card EMI only) | -- |
| BIN | bin_include/exclude lists | BIN must pass include/exclude rules (Card EMI only) | If configured |
| Overall usage | max_usage | complete_usage + 1 ≤ max_usage | 0 = unlimited |
| Per-user usage | max_usage_per_user | user_usage + 1 ≤ max_usage_per_user | 0 = unlimited |
| Per-card usage | max_usage_per_card | payment_instrument_usage + 1 ≤ max_usage_per_card | 0 = unlimited |
| Validity period | start_date, end_date | Current date must be within start and end dates | -- |
| Priority | priority | Must be greater than 0 and unique per active sub-merchant | -- |
| Discount validation | discount values | Discount must be less than EMI scheme interest rate | -- |
Order Amount Validation
Order amount checks ensure the subvention is only applied to transactions within a defined price range. These constraints are set in the Setup tab when creating or editing a subvention. Both checks are independent -- you can configure a minimum without a maximum, a maximum without a minimum, or both together.
Minimum order amount
The order total must be greater than or equal to the min_order_amount value configured on the subvention. This prevents subventions from applying to low-value orders where EMI may not be practical or where the interest reduction would be trivially small.
If min_order_amount is set to 0, the minimum constraint is effectively disabled -- any order amount satisfies this check. This is the default when you want the subvention to apply regardless of order size.
For example, if you set min_order_amount to 5000, an order of 4999 fails this check and the subvention is not applied. An order of 5000 or above passes.
Set a minimum order amount that aligns with the EMI threshold your payment partners support. Most issuers require a minimum transaction amount for EMI eligibility (commonly 2500 or 3000). Setting your subvention's minimum at or above this threshold avoids situations where the subvention matches but the EMI scheme itself is unavailable.
Maximum order amount
The order total must be less than or equal to max_order_amount when max_order_amount is greater than 0. This caps your exposure on high-value transactions where the interest subsidy could be significant.
If max_order_amount is set to 0, the maximum constraint is disabled -- there is no upper limit on the order amount. This is the default for subventions that should apply to all order sizes above the minimum.
When both minimum and maximum are configured, the order total must fall within the range: min_order_amount ≤ order_amount ≤ max_order_amount. If the maximum is less than the minimum (a misconfiguration), no order can satisfy both constraints and the subvention effectively never applies.
EMI Scheme Matching
EMI scheme matching is the core eligibility dimension for subventions. Since subventions exist specifically to reduce EMI interest, the system must verify that the subvention's EMI targeting configuration aligns with the EMI scheme the customer has selected at checkout. This matching happens across multiple attributes, and all must align for the subvention to qualify.
The matching logic differs slightly between Card EMI and Cardless EMI. Card EMI requires matching on card-specific attributes (issuer, scheme, card type, geography, and optionally BIN). Cardless EMI uses a simpler matching model based on the EMI provider.
Payment mode code matching
The subvention's payment_mode_code must match the payment mode of the transaction. Subventions support exactly two payment mode codes:
card_emi-- the subvention applies to Card EMI transactions only.cardless_emi-- the subvention applies to Cardless EMI transactions only.
A subvention configured for card_emi does not match a cardless_emi transaction, and vice versa. This is the first check in the EMI matching sequence. If the payment mode does not match, none of the subsequent EMI-specific checks are evaluated.
When you configure a subvention in the Payment Modes tab, the system captures which EMI types you have enabled (Card EMI, Cardless EMI, or both via "Allow All Payment Modes"). Each enabled type generates separate matching rules.
Tenure and frequency matching
The subvention's allowed EMI tenures must include the tenure of the EMI scheme selected by the customer. Tenure represents the number of monthly installments -- for example, 3 months, 6 months, 12 months, or 24 months.
If a subvention is configured for 6-month and 12-month tenures, a customer selecting a 9-month EMI plan does not match. Only a 6-month or 12-month selection passes this check.
Frequency matching works alongside tenure. The subvention's frequency must match the EMI scheme's frequency. In standard EMI configurations, frequency is typically monthly, but the system validates this explicitly to handle any non-standard frequency configurations your payment partners might offer.
Both tenure and frequency are required matches -- neither is optional. If either fails, the subvention does not apply to that EMI scheme.
The available tenures for a subvention are limited to what your payment partners support. If a specific tenure is not available during subvention creation, check with your payment partner or contact Nimbbl support to confirm whether that tenure is supported for the relevant issuer and card type.
Currency matching
The subvention's currency must match the EMI scheme's currency. In most cases, both are set to INR (Indian Rupees) for domestic transactions. This check ensures that a subvention configured in one currency is not accidentally applied to an EMI scheme denominated in another.
Currency is set during subvention creation in the Setup tab. Only active currencies configured for your sub-merchant are available for selection.
Issuer and bank matching
For Card EMI subventions, the system checks whether the card's issuer bank matches the subvention's issuer targeting. This includes several card-specific attributes:
- Issuer bank -- the bank that issued the customer's card (for example, HDFC, ICICI, SBI, Axis). The subvention's issuer configuration must include the card's issuing bank.
- Card scheme -- the card network (Visa, Mastercard, RuPay, and others). If the subvention targets specific schemes, the card must belong to one of them.
- Card type -- credit or debit. If the subvention is restricted to a specific card type, only that type qualifies.
- Geography -- domestic (issued in India) or international (issued outside India). If configured, the card's geography must match.
All configured attributes are evaluated as an AND condition. If you restrict a subvention to HDFC Visa Credit cards, the card must be issued by HDFC, on the Visa network, and be a credit card. A Mastercard from HDFC or a Visa debit card from HDFC would both fail.
For Cardless EMI subventions, issuer matching is simpler. The system checks whether the Cardless EMI provider selected by the customer is included in the subvention's allowed issuers list. If the subvention is configured to allow all Cardless EMI issuers, this check passes automatically.
BIN matching
BIN (Bank Identification Number) matching provides the most granular level of card targeting. This check applies only to Card EMI subventions that have BIN-based targeting configured. If no BIN rules are configured, this check is skipped.
When BIN rules are active, the system evaluates the card's BIN against two lists:
- Include list -- if configured, the card's BIN must appear in this list (or fall within a configured BIN range) for the subvention to apply.
- Exclude list -- if configured, the card's BIN must not appear in this list. A BIN that matches the exclude list disqualifies the subvention.
If both lists are configured, the BIN must pass both checks: it must be in the include list and not in the exclude list. BIN ranges (for example, 526217 through 526219) are expanded and checked against each individual BIN within the range.
Usage Limit Tracking
Usage limits control the total number of times a subvention can be redeemed. These limits prevent runaway costs and let you scope a promotion to a defined number of transactions, users, or payment instruments. Each limit is configured independently, and all configured limits must pass for the subvention to apply.
Overall usage limit
The max_usage field sets the total number of redemptions allowed across all customers, all cards, and all transactions. When a subvention reaches its maximum usage, it is no longer eligible for any new transaction.
The system checks: if max_usage is greater than 0 and complete_usage + 1 > max_usage, the subvention fails the usage check. Here, complete_usage represents the number of successful redemptions already recorded.
Setting max_usage to 0 disables this limit entirely -- the subvention can be redeemed an unlimited number of times. Use this for evergreen promotions where you do not need to cap total redemptions.
For time-bound campaigns (for example, a festival sale), set max_usage to the number of redemptions your budget can support. Once the limit is reached, the subvention stops applying automatically without requiring manual deactivation.
Per-user usage limit
The max_usage_per_user field limits how many times a single customer can redeem the subvention. This prevents one customer from consuming a disproportionate share of the promotion.
The system checks: if max_usage_per_user is greater than 0 and user_usage + 1 > max_usage_per_user, the subvention fails for that customer. The user_usage value tracks how many times the specific customer has already redeemed this subvention.
Setting max_usage_per_user to 0 means no per-user limit -- a single customer can redeem the subvention as many times as the overall usage limit allows.
Per-user tracking is based on the customer identifier associated with the order. If the same customer checks out with different identifiers (for example, different email addresses or phone numbers), each identifier is tracked separately. Ensure your order creation process consistently uses the same customer identifier to maintain accurate per-user usage tracking.
Per-card usage limit
The max_usage_per_card field limits redemptions on a specific payment instrument. This is primarily relevant for Card EMI subventions where you want to ensure the benefit is distributed across different cards rather than concentrated on a single card.
The system checks: if max_usage_per_card is greater than 0 and payment_instrument_usage + 1 > max_usage_per_card, the subvention fails for that card. The payment_instrument_usage value tracks redemptions against the specific card number (or equivalent instrument identifier).
Setting max_usage_per_card to 0 disables per-card tracking. For Cardless EMI subventions, per-card limits are typically not applicable since there is no physical card, but the field can still be configured if needed for provider-level tracking.
Usage tracking mechanism
Usage limits are tracked and enforced in real time during order processing. When a customer selects an EMI option at checkout and a subvention is evaluated, the system checks all three usage dimensions (overall, per-user, and per-card) against their current counts before applying the subvention.
Usage counters are incremented only when a payment succeeds with the subvention applied. Failed or abandoned transactions do not count toward usage. This means the usage count reflects actual successful redemptions, not attempted ones.
All three limits are checked independently. A subvention with max_usage of 100, max_usage_per_user of 2, and max_usage_per_card of 1 requires that the overall count is below 100, the specific customer's count is below 2, and the specific card's count is below 1 -- all at the same time. If any one limit is exceeded, the subvention does not apply.
Validity Period Checks
The validity period defines the time window during which a subvention is active and can be applied to transactions. Both start and end dates are configured in the Details tab during subvention creation.
Start date validation
The subvention's start_date must be on or before the current date for the subvention to be eligible. A subvention with a future start date is not yet active and is excluded from eligibility evaluation.
This allows you to create subventions in advance and schedule them for future campaigns. The subvention exists in the system but does not apply to any transaction until the start date arrives.
End date validation
The subvention's end_date must be on or after the current date. A subvention whose end date has passed is considered expired and is excluded from eligibility evaluation.
Once a subvention expires, it stops applying automatically. You do not need to manually deactivate it -- the validity check handles this. However, the subvention remains in the system with its current status and can be viewed in the subventions list for reporting purposes.
Date validation logic
Both start date and end date are evaluated against UTC time at the moment the eligibility check runs. The comparison is inclusive on both ends -- a subvention is valid on its start date and on its end date.
The system applies the check as: start_date ≤ current_date ≤ end_date. If the current UTC date falls outside this window in either direction, the subvention is not eligible.
Because dates are evaluated in UTC, a subvention's effective start and end times may differ from your local time zone. If precise timing is important for your campaign, account for the UTC offset when setting start and end dates.
Priority and Discount Validation
Priority and discount validation ensure that subventions are correctly ordered for evaluation and that the configured discount values are logically valid against the EMI scheme's interest rate.
Priority requirements
Every active subvention must have a priority value greater than 0. A priority of 0 or a negative value is invalid and the subvention cannot be activated. Priority determines the order in which subventions are evaluated when multiple subventions are eligible for the same transaction.
Lower numeric values represent higher priority -- a subvention with priority 1 is evaluated before a subvention with priority 10. The system processes subventions in ascending priority order and applies the first one that passes all eligibility checks, unless the sub-merchant's tiebreak strategy specifies otherwise.
Priority uniqueness
Within the same sub-merchant, each active subvention must have a unique priority value. Two active subventions cannot share the same priority. This ensures deterministic evaluation order -- the system always knows which subvention to evaluate first.
If you attempt to activate a subvention with a priority that is already in use by another active subvention for the same sub-merchant, the system rejects the activation. You must either change the new subvention's priority or adjust the existing subvention's priority first.
Inactive subventions (those with Created or Disabled status) do not participate in priority uniqueness checks. Only active subventions are subject to this constraint. This means you can prepare multiple subventions with the same priority and then activate only one at a time.
Use priority values with gaps (for example, 10, 20, 30 instead of 1, 2, 3) so you can insert new subventions between existing ones without needing to renumber all priorities.
Discount cannot exceed scheme interest rate
The discount value configured on a subvention must be strictly less than the EMI scheme's interest_rate. This validation prevents a scenario where the discount exceeds the interest being charged, which would result in a negative effective interest rate -- an economically invalid outcome.
The system compares the subvention's discount percentage (or equivalent value) against the interest_rate field of the matched EMI scheme. If the discount is equal to or greater than the interest rate, the subvention fails this validation and is not applied.
For no-cost EMI subventions, this check ensures that the full interest amount is absorbed correctly. For low-cost EMI subventions, it ensures the customer's reduced rate remains a positive value.
Low-cost zero discount restriction
Low-cost EMI subventions cannot have a discount value of 0.0. A zero discount on a low-cost subvention is a logical contradiction -- low-cost implies a partial interest reduction, but a discount of zero means no reduction at all. The system rejects this configuration.
If you want a subvention with no interest reduction (effectively a pass-through), do not create a subvention at all. If you want the customer to pay zero interest, use a no-cost EMI subvention type instead of a low-cost type with a non-zero discount.
This restriction is enforced both during creation (in the Command Center UI) and during runtime eligibility evaluation.