Management Terminology

Posted by admin at 04 Feb, 2017

Management

Affiliate   

An affiliate is a company or a person that is represented as a separate entity within the gateway and is a partner of the merchant that promotes its products. The most common examples of affiliates are marketplaces, bloggers, journalists, etc.

Affiliates do not process transactions and can participate only in split transactions. Affiliates must have separate accounts created for them. Because they cannot process transaction other than for split payments, they do not need to have fees and provider profiles configured for them like traditional merchants. Under the context of remittance, the only settings an affiliate needs are deposit settings.

Branding Module   

Branding module is the mechanism that allows users to create a unique visual representation of a company in the gateway. The gateway allows branding of the following resource groups:
— Web resources - web pages that can be customized using branding functionality.
— Print resources - documents such as statements and receipts that can be customized using branding functionality.
— Notification resources - email notification templates that can be customized using branding functionality.

Web, print and notification resources can be customized via a branding profile of a particular entity (merchant, reseller or portfolio). By means of the branding profile, users that have access to the entity can communicate with lower entities.
 

Branding Profile   

Branding profile is a set of forms, associated with a particular merchant, reseller or portfolio, that allows for configuring of particular branding elements. A branding profile is used to create a unique visual representation for communicating between entities that are familiar with each other. For example, merchants need to see a logo and colors of a reseller they are associated with. The gateway provides the ability to override settings of a default system branding profile. This can be done via the overriding mechanism that allows for creation of a unique branding profile at the corresponding level within the gateway. The branding profile can consist of branding elements set at a particular level only or it can combine these elements with those set at a higher level.

Fee Schema   

A meta structure defining basis for a Merchant Fee and a Reseller Commission. It encapsulates fee structure, while merchant fees and reseller commissions define specific values to be used within the structure.

Fee Schema is comprised of an ordered list of fee schema detail records, which are subdivided into groups based on their meaning. Each detail has a description and formula associated with it. The formula is defined using statistical variables calculated daily off operations data. The formula serves as the basis for fees and commissions calculation.

Merchant   

Merchant represents a customer (tenant) within the gateway. Serves as a logical grouping of data and configuration settings.
 

Account   

Account is a subunit of a merchant that represents a unit of a business (location, club, store, department). Used to subdivide data and override global processing settings defined at the merchant level.
 

Account Group   

A set of configuration settings that can be defined at either merchant or account level. Includes settings related to remittance and commissions.
 

Account Profile   

A set of configuration settings that can be defined at either merchant or account level. Includes settings related to transaction processing.

Account profile groups different provider profiles that define processing policy with a corresponding provider.
 

Merchant Cycle   

A set of days within a month (1-28) when a reconciliation process for a merchant has to be run. The Reconciliation Merchant Statement is generated at this time. Multiple days per cycle can be selected, but only one day will be used to process monthly fees.

Merchant cycle is used in two fee types: demand-cycle and cycle-cycle. See Fee Type for more information.
 

Merchant Fee   

Merchant fee is a fee (processing rates, service fees, etc) associated with a merchant. Defines how deposits and fees should be calculated based on the transactions processed. Fees can be paid to the gateway or a software platform/reseller.

1) Gateway fees:
— Processing fees - fees charged for transaction processing. They are subsequently subdivided into volume fees and per item fees. Volume fees are charged based on total volume (total amount) of transaction processed, while per item fees are charged on per transaction basis (total count). When blended rate pricing model is used, these fees reflect the actual processing fees charged to the merchant; when cost-plus pricing model is used, these fees represent the surcharge, which is applied on top of the processing cost.
— Flat fees - additional charges applied to certain types of transactions, usually either to cover corresponding processing cost (chargebacks, direct debit returns) of these transactions or to cover additional services rendered specifically for these transaction types (decline, recycle).
— Monthly fees - recurring fees charged on a monthly basis to cover various types of service charges, hardware cost and support.
— Annual fees - recurring fees charged on a yearly basis to cover various types of service charges, hardware cost and support.

2) Software platform/reseller fees:
— Charges - fees charged on a regular basis to cover specific types of services, most typically franchising fee. See integration notes for more information.
 
Fee Type   
Fee Type determines the timing on remittance deposits associated with processing. It determines when the funding of transactions happen and then, based on which schedule, processing fees are taken out.
The name of fee type consists of two parts. The first part of the name relates to deposits of a merchant, whereas the second part of the name relates to fees.

Possible fee types are:
— Demand-demand - first part demand means that deposit is made fixed numbers of business days (waiting period) after processing happens, and the second part demand means that fees are taken out at that particular time (deposit is made net of fees). For example, $100 is processed on Monday with 5% processing fee and two-day waiting period, thus funds are deposited back to the merchant on Wednesday net of fees in the amount of $95. The idea is that deposit and fee are both made two days after the processing where fee (5%) has already been taken out as a result deposit equals $95. The advantage of demand-demand is that PSP/TPP is guaranteed to always be able to collect processing fees.
— Demand-cycle - first part demand means that deposit is made fixed numbers of business days (waiting period) after processing happens, and the second part cycle means that fees are taken out on the specific day of the cycle. For example, $100 is processed on Monday with 5% processing fee, the waiting period is two days and cycle day is the first of the month, thus funds are deposited back to the merchant on Wednesday in the amount of $100, while fees ($5) will be taken out on the first of the subsequent month.The advantage of demand-cycle is that it simplifies the reconciliation process for a merchant because the amount of funds processed equals the amount of funds received. However, it introduces potential risk for PSP/TPP which is an inability to collect processing fees due to Merchant's lack of funds at that particular time.
— Cycle-cycle - both parts of the name imply that Merchant gets funds net of fees on the predefined day of the cycle despite the processing time of a given transaction. It's often used in collections industry so that regardless of when funds are processed, deposits happen on the first and the fifteenth of the month net of fees. For example, assuming 5% processing fee and cycle day is the first of the month regardless of when $100 is processed, $95 will be deposited on the first of the subsequent month.
 
Pricing Model   
Pricing model is a way to organize and charge Merchant Fees to a merchant.

The system supports two fundamental pricing models:
— Blended rate - fees are determined by averaging of processing cost across different interchanges and transaction types. For example, Visa Debit card might cost 0.6% to process and Visa Reward card might cost 2.8%, so the blended rate might be set at 2.7%. Processing cost is not defined as an exact amount and is included in total processing cost in the statements. In the settings, processing cost is set as Ignore.
— Cost-plus - processing cost is passed along to a merchant with an additional surcharge on desirable transaction types on top of the actual cost. For example, assuming surcharge of 0.5%, Visa Debit transaction qualifying for 0.6% will be charged at 1.1% and Visa Reward transaction qualifying for 2.8% will be charged 3.3%. Processing cost is defined as an exact amount that is paid to a processor and is displayed in the statements along with processing fees for certain transactions. In this case, processing cost should not be set as Ignore.
 

Merchant Profile   

Merchant profile is a set of parameters that are used to govern the setup of a merchant with the respect to its accounts, merchant IDs, descriptors and deposit accounts. It includes five parameters, defining of which determines how the merchant/account should be configured.

Accounts - defines whether it is a multi-location/multi-terminal or single-location/single-terminal merchant.
— Single - settings are configured at the merchant level.
— Multiple - settings are configured at the level of each account that is set up.

Underwriting - defines whether a single federal tax ID is going to be used for all locations of the merchant or each location is going to use a separate tax ID.
— Single - the legal entity owning the tax ID is represented by a merchant. Underwriting (background verification) is done at the merchant level.
— Multiple - the legal entity owning the tax ID is represented with an account. Underwriting (background verification) is done at the account level.

Processing - defines whether a single provider profile is going to be used for all locations of a merchant or each location is going to use a separate provider profile.
— Single - one provider profile is used for all accounts under a merchant, i.e. the provider profile is set at the merchant level.
— Multiple - different provider profiles are used for each account under a merchant, i.e. the provider profile is set at the account level.

Remittance - defines the number of deposit accounts to use for remittance.
— Single - remittance settings are configured at the merchant level. All money are funded to a single deposit account regardless of the number of accounts used.
— Multiple - remittance settings are configured at the account level. Money processed by each account is funded separately in separate deposit accounts.

Recurring fees - defines how the monthly fees are charged.
— Per Merchant - monthly fees are only charged once regardless of the number of the accounts under a merchant.
— Per Account - monthly fees are charged per each of the account created under a merchant.
 

Merchant Settings   

In order to process transactions and do remittance, the following configuration sets are available within the system:
— Processing settings - define how transactions are going to be processed. These settings include configurations of provider profiles as well as various types of settings around the settlement, cut-off time, etc that are going to be used for transaction processing.
— Remittance settings - define how remittance and merchant funding are going to be done. These settings include deposit account information, reserves, merchant fees, etc.

Depending on the business context, both groups of settings can be configured at either merchant or account level.
 

Merchant Statement   

Merchant statement is a summary of merchant’s activity over a certain period of time. It provides the information about a number of the processed transactions, splits, fees and charges collected and adjustments applied.

Merchant statements can be of two types:
— Deposit statement - a type of merchant statement that accompanies and explains remittances associated with all of the merchant’s transactions processed on a given business day. Deposit statement helps the merchant to understand the deposits in its bank account that result from transaction processing.
— Reconciliation statement - a summary statement that explains merchant’s remittance activity and shows all of the associated processing fees over a defined time period, usually a month. Reconciliation statement helps a merchant to understand what merchant fees are charged and why.
 
Adjustment   
Adjustment is an element of a merchant statement that allows manual adjustments to the current statement balance. It can be used to rectify statement errors that resulted from exceptional business behavior, waive fees or withhold additional fees that do not generally appear on the statement.
 
Scheduled Adjustment   
Scheduled adjustment is used to manually adjust amounts within the future merchant statements. Scheduled adjustment has a fixed date in the future when it is applied to the newly generated statement.

It can be created for cases when a gateway owner desires to make a planned adjustment to a merchant statement. For example, if a merchant requests an advance, the gateway owner can provide it and create a scheduled adjustment to withdraw it back in two weeks.

If there is no statement generated on the date of the created adjustment, this adjustment will be applied to the next generated statement.
 

Merchant Tier Structure   

From the transaction processing perspective, a business of a merchant can be organized as a single-tier, two-tier and three-tier hierarchy. The configuration of the given merchant in the system is going to depend on the tier structure of the merchant’s business:
— Single tier - an example of a single-tier merchant would be a single-location store with one cashier and one terminal. Another example is a website or an online store, which handles all of the processing in the same way.
— Two tier - an example of a two-tier merchant would be either a single-location store with multiple cashiers and terminals or a multi-location store with a single cashier and terminal in each of them.
— Three tier - an example of a three-tier hierarchy would be a multi-location supermarket with multiple cashiers and terminals in each location.

There are two objects within the system used to represent various tiers of the merchant’s business:
— Merchant - parent entity that groups several accounts together.
— Account - child of a merchant, representing a unit of a business (location, store, department) or a terminal.

In the one-tier scenario, the merchant is going to represent both the business itself and its single terminal (when applicable).

In the two-tier scenario, the merchant/account combination can be the following:
  • the merchant represents a store/location and the account represents a cashier/terminal
  • the merchant represents a corporate entity owning the stores and the account represents each of the stores/locations.

In the three-tier scenario, the merchant is going to represent a corporate entity owning the stores and the account is going to represent both stores/locations and terminals within these stores. For example: if there are three stores each having 4 terminals, there will be a total of 12 accounts set up.
 

Merchant Type   

The following merchant types are supported within the system:
— Remitter - reserved/system merchant; used to define direct debit settings for fund remittance in cases when an aggregate model is used.

Minimum Fees   

Minimum fees is a mechanism that allows a payment facilitator to pay compensation to a reseller only when the reseller has earned a minimum amount on its merchants. The minimum amount is calculated from the total amount of fees across all merchants associated with the reseller. Which fee types are required to be included in the calculation should be communicated beforehand. The reseller commissions are deducted from the total amount of fees collected from a merchant. If the residual amount is less than the required minimum amount, then the difference is compensated by the reseller from its commissions. To learn more about minimum fees, review Minimum Fees section of the Remittance Management Guide.

Onboarding Application   

Onboarding application is a specific form that allows onboarding of a merchant within the gateway via the onboarding API. The application is designed for external companies to board associated merchants. The application collects all necessary information that is further submitted to a processor that performs onboarding. The response to the onboarding request can be delivered in real-time or via a callback, which is subject to the processor.
 

Underwriting   

As part of the onboarding process, a series of checks is performed. These checks allow a merchant to obtain a MID and/or a merchant account, and is called underwriting. During underwriting, the merchant is verified whether there are any issues with the business or its owners, such as bad credit history, previous bankruptcy, law issues, presence on the federal terrorist list of OFAC (Office of Foreign Assets Control) and/or the Visa/MasterCard MATCH list. As a result of underwriting, a response determining whether the merchant can process transactions and receive money in its account is returned. Underwriting can be performed either by a processor during onboarding or by outside services.

Perspective   

Perspective is the core element of User Interface. It's a set of forms and actions designed to simplify the work process within a specific business context. A perspective is designed to group together related fuctionality and to allow user to perform different actions in minimum number of clicks. There are several perspectives available.
 

Administration   

Administration is a group of perspectives designed to manage the application by system and software administrators.
 
Audit Perspective   
Audit perspective is an arrangement of forms and actions used by technical administrators of the system. The purpose of this perspective is to monitor activity on the server. It groups together most common forms that are necessary to analyze different types of activity in the system, to review errors, to detect changes to merchant, reseller, user information, etc.
 
Monitoring Perspective   
Monitoring perspective is an arrangement of forms and actions used by non-technical administrators of the system. The purpose of this perspective is to simplify diagnostics of various remittance and processing related issues. It groups together most common forms that are necessary to diagnose various problems that may occur within them.
 
Setup perspective   
Setup perspective is an arrangement of forms and actions used by non-technical (business-oriented) administrators of the system to manage setup of various system-wide settings.
 
System perspective   
System perspective is the arrangement of forms and actions used by technical administrators to manage setup of various system-wide settings (these settings are more software and hardware-related than business-related).
 

Console perspective   

Console is a perspective that is designed to function as a virtual terminal for merchants. The purpose of this perspective is to provide easy access to the information that merchants most commonly require for their business, such as access to transactions, chargebacks, batches, statements, as well as recurring billing functionality (if the recurring module is activated within the system).
 

Management   

Management is a group of perspectives designed to streamline back-office operations. It is generally used by the employees of the payment service provider that maintains the gateway. It provides easy access to functionality for the management of mer
 
Distributions Perspective   
Distributions perspective is an arrangement of available forms and actions that are needed to provide access to the common functionality of distribution recipients such as vendor or holding account.
 
Fulfillment Perspective   
Fulfillment Perspective is an arrangement of available forms and actions that are needed to set up terminal configurations, work with users' terminal orders, control and modify shipping conditions, set up injection keys and regulate terminal modules available for fulfillment.
 
Merchant Perspective   
Merchant Perspectiveis an arrangement of available forms and actions that are needed to work efficiently with Merchants and Accounts. In this perspective availability of actions changes based on Merchant Selection. User can work either with Merchant or one of its Accounts. For more information see Merchant Selection.
 
Merchant Selection   
Merchant Selection is a group of Merchants or Accounts("Submerchants") against which operations can be performed under Merchant Perspective. It operates using three modes:
— Multiple - mode that allows user to work with selected Merchants and their Accounts at the same time.
— Merchant"M:" - mode that encompasses actions that can be carried out only with one selected Merchant.
— Account"A:" - mode that allows user to work only with particular Account("Submerchant").
In addition, modes influence availability of functions on the Merchant Perspective. The full availability is accessible while using Merchant mode.
 
Portfolio perspective   
Portfolio perspective is an arrangement of available forms and actions that are needed for managing information about resellers, merchants, documentation, etc.
 
Reseller Perspective   
Reseller Perspective is an arrangement of available forms and actions that are needed to work efficiently with Reseller records.
 
Terminal Perspective   
Terminal perspective is an arrangement of available forms and actions that are needed for storing of the information, parameters and resources associated with terminals owned by a particular merchant, managing updates (Terminal Management System), and monitoring and saving logs.
 
User Perspective   
User Perspective is an arrangement of available forms and actions that are needed to work efficiently with User records.

 

Reporting perspective   

Reporting perspective provides access to the reports available within the system.

Reference Field Type   

While working with API, various entities within the system, such as merchants, resellers, etc, need to be referenced. API fields that correspond to the references to these entities are of the Reference type (for example, accountId, terminalId, etc). Each of these entities has two identifiers:
— Internal identifier (represented as ID) - numeric value, provided by the gateway; unique within the system.
— External identifier (represented as code) - alphanumeric value up to 60 characters, provided by an integrated external system for cross-referencing; preferably unique within the scope that makes sense to an integrator.

When an API call with reference to an entity has to be submitted, this entity can be referenced by either internal or external identifier. By default, the system expects an internal identifier to be submitted (e.g. accountId/merchantAccountCode=1234). To let the system know that an external identifier is submitted, its value must be preceded by an asterisk (e.g. accountId/merchantAccountCode=*1234). This is applicable to all fields of Reference type.

For example, an account has an internal ID, generated by the gateway (e.g.5678), and an external ID, provided by an integrated POS system (e.g. pos8765). If an internal ID should be used in the API calls, it is submitted via accountId field as it is: accountId=5678. If an external ID is used should be used in the API calls, it is submitted with an asterisk as a prefix: accountId=*pos8765.

Remittance   

Remittance is the process during which the funds are disbursed back to a merchant.

After all transactions are processed and settled for a given time period, statistics is calculated capturing the processed volume as well as transaction counts by type (e.g. Sale, Credit) and by payment source (e.g. Visa, Amex, direct debit). During the remittance process, a fee structure (Merchant Fee) is applied to the calculated statistics to obtain specific charges that the merchant owes for processing and support services. The resulting fees, as well as any appropriate reserves, are subtracted from the total volume processed and the net amount is remitted to the Merchant as either an direct debit transaction (when done automatically) or as a check (when done manually).

Depending on the specific business needs, remittance may occur on all transactions or only on a subset of transactions (e.g. batch only or real-time only).
 

Remittance Basis   

Remittance mechanism is necessary to transfer funds from the intermediary 3rd party processor account into deposit accounts belonging to the actual merchants. Because of the processor-dependent funding delays and because of the necessity for reconciliation and auditing procedures as part of the whole process, arbitrary time delays may be introduced in the remittance process (e.g. funds can be remitted back to a merchant one or two days after the 3rd party card processor receives the funds). These time delays can be defined based off different remittance basis, with a starting date as the date of approval response (response date basis) or the date when funds arrive (funding date basis).

Working off of the response date, remittance of funds occurs pre-defined number of days after approval is received from the processor, while working off of the funding date, remittance of funds occurs pre-defined number of days after funds are received from the processor. The pre-defined, fixed number of days is called remittance period.

Depending on remittance basis used, values for direct debit, Credit Card and Amex remittance periods may vary. They may be used to provide additional time for reconciliation and auditing, as well as, to delay or advance certain types of deposits (e.g. delay direct debit or advance Amex) to unify all remittances into a single deposit.
 

Remittance Source   

Remittance source is a bank account from which funds for specific types of transactions will be remitted. The notion of remittance source is designed to accommodate scenarios when single merchant processes through multiple processors and each of the processors deposits to a separate bank account. For such cases, when remittance process occurs money has to be pulled from different accounts.

Gateway supports four types of remittance sources (bank accounts that could be used as the source of funds): one for credit and debit card deposits, one for direct debit deposits, one for American Express deposits and one for commission remittances.
 

Remitter   

Remitter is a specifically configured merchant that performs remittance processes. Remitter's account contains settings of particular bank accounts. Funds are deposited to these bank accounts during the remittance.

If different remittance sources are used, several remitter accounts have to be configured: for payment card, direct debit, American Express and commissions transactions.

Security Mechanism   

Security mechanism is a system of elements allowing to control how users can access the system as well as perform different tasks. User access is defined through three aspects:
— Actions - deals with actions that a user can perform within the system. For example, access different perspectives and forms and perform tasks within these forms. This is controled by privileges, permissions and access levels.
— Data access - deals with data that a user has access to, for example, data associated with particular merchant, reseller, etc. This is controlled by data access policy.
— Functions - deals with functions that a user can fulfil within the various business processes implemented in the system. This is controlled by function policy.
 

Permission   

Permission represents a user’s ability to perform a particular action within the system on the lower level. A user can view or modify the elements of the system or access different forms and do different actions within these forms. Permissions are associated with the security roles, allowing to control the access level of a particular user. They are also assigned to various elements of the user interface, defining what permissions will be nessesary for a user to have access to the forms and be able to execute the actions on the user interface or within the API.
 

Privileges   

Privilege represents a user’s ability to access a part of the system that shares an API or user interface. Now, there are seven privileges in the gateway:
— User Interface – allows a user to access functionality of the user interface. By default, this privilege is assigned to the human users only.
— Processing API - allows a user to access functionality related to transaction processing. This privilege can be assigned to the service users only.
— Management API - allows a user to access functionality related to the settings setup of merchants, portfolios, etc. This privilege can be assigned to the service users only. In addition, along with this privilege, a security role must be set up.
— Billing API - allows a user to access functionality related to reccuring billing. This privilege can be assigned to the service users only.
— Onboarding API - allows a user to access functionality related to the onboarding application. This privilege can be assigned to the service users only and is available only to the users that have an access to Processing API.
— TMS API - allows a user to access functionality related to the terminal management system: configuration changes, activation of the terminals, parameters setup, etc. This privilege can be assigned to the service users only.
— Detokenization - allows a user to access functionality related to detokenization of the tokenized data present within the system. Although the privilege can be assigned to the service users only, the detokenization process involves both API and the user interface. Therefore, both service and human users are involved in the process.
 

Security Role   

Security role is a level of user access that regulates forms and actions that are available to a user.

Security role is a combination of permissions. In the gateway system, there are twelve security roles that can be shown as a hierarchy - from System 2 (which is the highest security level with the biggest number of permissions) to Customer 1 (which has the least number of permissions). To learn more about permissions based security mechanism, review this guide.

Statement   

Statement is a summary of merchant’s or reseller’s activity, including transaction processed, reserves withheld and fees applied. Statements are divided into two principal groups – merchant statements and reseller statements. Reseller statement is a breakdown and explanation of reseller’s commissions. Merchant statement is a breakdown of merchant's fees and explanation of deposits that are sent to a merchant. Merchant statements can be of two types:
— Deposit statement - a merchant statement that accompanies and explains remittances associated with all of the merchant’s batches processed on a given business day. Basically, deposit statement enables merchant to understand the deposits in their bank account that result from transaction processing.
— Reconciliation statement - a summary statement that explains remittance activity and shows all of the associated processing fees over a defined time period, usually a month. Basically, reconciliation statement helps merchant to understand what merchant fees are charged and why.