Use \transactionCategory endpoint to create a transaction category and provide values for the following parameters:

• code
• attrKey
  
• attrVal
  
• txnCategoryComparator

You can view the sample request payload for reference.

Transaction Categories can be created at various entity-levels like Account Holder, Product, Program, Program Family and Product Family.

Use \transactionPolicies endpoint to create a transaction policy and provide values for following below parameters:

• policyViolationAction
• Action
• allowedTransactionCategoryCodes
• disallowedTransactionCategoryCodes
• allowedTimeSlices
• disallowedTimeSlices
• errorCode

You can view the sample request payload for reference.

Transaction Policies can be created at different entity levels like Product, Product Family, Program, Program Family and Account Holder.

Periodic and Aggregate policies are applied to an Account or an Account Holder at a Product Family, Product, Program or Account level.

Possible values for txnCategoryComparator are EQUALS and CONTAINS.

Maximum transaction limit for:

• Min KYC User: Rs. 10,000 per transaction (debit/credit)
• Aadhaar OTP KYC User: Rs. 1,00,000 per transaction (debit/credit)

Yes. You can use /transactionPolicies/enabled and /transactionPolicies/disabled endpoints to enable and disable the policy respectively using the policy ID.

No. Transaction limits are always enforced within the scope of Accounts and Account Holders.

Blocking merchants/aggregators is an issuer’s call and hence, can be done only post approval from the issuer.

Aggregate limits are applied across daily, weekly, monthly, quarterly and yearly caps.

Fusion provides the following two categories of error codes to indicate when transaction limits are violated:

• User-defined error codes defined during policy creation
• System defined legacy error codes.

In the absence of any user-defined error codes, the system throws one of the relevant System defined error codes.

When the user's limit is breached, funds aren’t added to their ledgers (credits can be made up-to that specific limit, unless it's reversal transaction), and thus, users are not debited. In case the users are debited, the payment gateway will initiate the reversal of funds back to the source account (Issuing bank).

For example, user added Rs. 7,000 first and then tried adding Rs. 4,000. The second transaction of adding Rs. 4,000 will fail as it breaches the set limit for minimum KYC users.

No. Being a minimum KYC'ed user, you can add up-to Rs. 10,000 (Credit limit) and spend up-to Rs. 10,000 (Debit limit) separately.

This depends on the user's spend limit left for that month.

For example, if the user received a refund of Rs. 300 and has a spend limit of Rs. 300 or more left for that particular month, then yes, user can spend the amount.

It is according to the calendar (January - December).

For example, user added Rs. 7,000 first and then tried adding Rs. 4,000. The second transaction of adding Rs. 4,000 will fail as it breaches the set limit for min KYC'ed users (Daily and Monthly). User can only add up-to Rs. 3,000 here. Same applies to debit transaction limits as well.

Reversals are not included in limit calculations.
For example, a user has added Rs. 8,000 and spent Rs. 2,000. If a user receives the reversal for Rs. 1,000, then this Rs. 1,000 won't be counted in the credit limit.