Merchant Fee UML


Added On:  03/16/12 
SQL Table:  IAPP_MERCHANT_FEE 
Module:  UniCore 
Type:  Entity  Status:  Active 
Java Class:  MerchantFee 
Represents fee structure (processing rates, service fees, etc) configured for this merchant. Contains information about how deposits and fees should be calculated based on transaction processed.
Added On:  03/16/12
SQL Column:  ID
Java Field:  id
Status:  Active
SQL Type:  bigint(20)
Java Type:  Long
Identifier / Primary Key
Attributes: Required
Identifier of the object used for references; auto-incremented integer value.
Added On:  03/16/12
SQL Column:  NAME
Java Field:  name
Status:  Active
SQL Type:  varchar(255)
Java Type:  String
Attributes:
Name of the merchant fee.
Added On:  03/16/12
SQL Column:  TEMPLATE_CODE
Java Field:  templateCode
Status:  Active
SQL Type:  varchar(100)
Java Type:  String
Attributes:
Reference to the java class, which provides definition of the fee schema.
Added On:  03/16/12
SQL Column:  MERCHANT_ACCOUNT_CODE
Java Field:  merchantAccountCode
Status:  Active
SQL Type:  int(11)
Java Type:  Integer
Attributes:
Code of Merchant Account to which instance of this object is attributed to.
Depending on the context, Merchant Account Code field may contain either Merchant Code or Merchant Account Code.
The field is primarily used for data partitioning and data management, to make it easy to determine the ownership of a record within the database.
Added On:  01/31/13
SQL Column:  REALTIME_FEE_POLICY
Java Field:  realtimeFeePolicy
Status:  Active
SQL Type:  varchar(40)
Java Type:  String
Attributes:
Defines, what fees are charged on different transaction types under real-time processing.
The value is a mask, consisting of 35 characters divided into 5 groups. Each group consists of a letter, specifying the outcome of transaction (A for approval, D for decline, V for void, B for blacklist, E for error), followed by 6 boolean characters (0 for false, 1 for true).
First 3 out of 6 boolean characters concern processing fees, while the last 3 concern per-item fees.
Characters 1-3 out of these 6 boolean values specify, whether processing fees are charged on this type of transaction during regular processing rebill, and retry. Characters 4-6 specify whether per-item fees are charged during regular processing, rebill, and retry or not.
Processing and per-item fees are not charged for transactions comming back as errors (under real-time processing), so the last 6 charachters in the value (following the letter E) are always zeros.
Example
the value A100100D100100V100100B100100E000000 means that
approvalProcessing = true
approvalItem = true
declineProcessing = true
declineItem = true
voidProcessing = true
voidItem = true
blacklistProcessing = true
blacklistItem = true
errorProcessing = false (always)
errorItem = false (always).
Added On:  01/31/13
SQL Column:  REALTIME_DEPOSIT_POLICY
Java Field:  realtimeDepositPolicy
Status:  Active
SQL Type:  varchar(10)
Java Type:  String
Attributes:
Defines what types of cards are getting deposited through remittance process in case of real-time processing.
The value is a mask consisting of 9 characters.
Each position in the mask is reserved for a specific account type:
1-Visa, V if deposited, else 0
2-MasterCard, M if deposited, else 0
3-Discover, D if deposited, else 0
4-ACH, X if deposited, else 0
5-Amex, A if deposited, else 0
6-Visa PINdebit, 1 if deposited, else 0
7-MasterCard PINdebit, 2 if deposited, else 0
8-EBT, E if deposited, else 0
9-bankCard, B if deposited, else 0.
For example, if all cards except Amex, Visa PINDebit and EBT are deposited, the field will look as follows: VMDX0020B.
Added On:  01/31/13
SQL Column:  BATCH_FEE_POLICY
Java Field:  batchFeePolicy
Status:  Active
SQL Type:  varchar(40)
Java Type:  String
Attributes:
Defines what fees are charged on different transaction types under batch processing.
The value is a mask, consisting of 35 characters divided into 5 groups. Each group consists of a letter, specifying the outcome of transaction (A for approval, D for decline, V for void, B for blacklist, E for error), followed by 6 boolean characters (0 for false, 1 for true).
First 3 out of 6 boolean characters concern processing fees, while the last 3 concern per-item fees.
Characters 1-3 out of these 6 boolean values specify, whether processing fees are charged on this type of transaction during regular processing rebill, and retry. Characters 4-6 specify whether per-item fees are charged during regular processing, rebill, and retry or not.
Fees on Void transactions are not charged during batch processing, so the 6 characters following the letter V are always zeros.
Example
The value A111111D111111V000000B110110E100100 means that
1 approvalRegularProcessing = true
2 approvalRebillProcessing = true
3 approvalRetryProcessing = true
4 approvalRegularItem = true
5 approvalRebillItem = true
6 approvalRetryItem = true

declineRegularProcessing = true
declineRebillProcessing = true
declineRetryProcessing = true
declineRegularItem = true
declineRebillItem = true
declineRetryItem = true

void - all boolean values in the group are always false

blacklistRegularProcessing = true
blacklistRebillProcessing = true
blacklistRegularItem = true
blacklistRebillItem = true

errorProcessing = true
errorItem = true
Added On:  01/31/13
SQL Column:  BATCH_DEPOSIT_POLICY
Java Field:  batchDepositPolicy
Status:  Active
SQL Type:  varchar(10)
Java Type:  String
Attributes:
Defines what types of cards are getting deposited through remittance process in case of batch processing.
The value is a mask consisting of 9 characters.
Each position in the mask is reserved for a specific account type:
1-Visa, V if deposited, else 0
2-MasterCard, M if deposited, else 0
3-Discover, D if deposited, else 0
4-ACH, X if deposited, else 0
5-Amex, A if deposited, else 0
6-Visa PINdebit, 1 if deposited, else 0
7-MasterCard PINdebit, 2 if deposited, else 0
8-EBT, E if deposited, else 0
9-bankCard, B if deposited, else 0.
The last four digits are always 0000, since the four respective card types are never deposited during batch processing.
For example, if all card types (except for the last four) are deposited, the value looks as follows: VMDXA0000.
Added On:  05/05/16
SQL Column:  DESCRIPTION
Java Field:  description
Status:  Active
SQL Type:  varchar(255)
Java Type:  String
Attributes:
Any additional information (or short descrition) provided by the merchant.
Added On:  05/09/16
SQL Column:  IS_ACTIVE
Java Field:  isActive
Status:  Active
SQL Type:  tinyint(1)
Java Type:  Boolean
Attributes:
Indicates whether the record is active in the system.
Added On:  05/13/16
SQL Column:  PARAMETERS
Java Field:  parameters
Status:  Active
SQL Type:  varchar(255)
Java Type:  String
Attributes:
Parameters applied to the merchant fee.
Added On:  06/17/16
SQL Column:  FEE_TEMPLATE_CODE
Java Field:  feeTemplateCode
Status:  Active
SQL Type:  bigint(20)
Java Type:  Long
Attributes:
Code of the fee template selected for the portfolio.
Added On:  08/31/16
SQL Column:  FEE_SCHEMA_FK
Java Field:  feeSchema
Status:  Active
SQL Type:  int(11)
Java Type:  Integer
References Fee Schema
Attributes:
Reference to the entity that represents fee schema information.
Added On:  08/31/16
SQL Column:  MERCHANT_FEE_DETAIL_FK
Java Field:  merchantFeeDetails
Status:  Active
SQL Type:  bigint(20)
Java Type:  Long
References Merchant Fee Detail
Attributes:
Reference to the entity that represents merchant fee details information.
Added On:  08/31/16
SQL Column:  MERCHANT_CYCLE_FK
Java Field:  merchantCycle
Status:  Active
SQL Type:  bigint(20)
Java Type:  Long
References Merchant Cycle
Attributes:
Reference to the entity that represents merchant cycle information.
Added On:  01/20/17
SQL Column:  REF_CODE
Java Field:  refCode
Status:  Active
SQL Type:  varchar(20)
Java Type:  String
Attributes:
Secondary identifier which can be used to cross-reference records between UniPay and integrated systems.