Sweep Accounts

The remittance process is always accompanied by a reconciliation process, which involves comparing the bank and gateway reports. As a rule, bank reports do not contain information about each individual transaction but provide aggregated information about all transactions performed in a day. There are two transaction groups in the gateway: transactions processed on behalf of merchants and transactions processed on behalf of a ayment facilitator. Considering that it is difficult to find any possible match in the bank reports, it is helpful to divide them into two groups at the bank level as well.

To have transactions divided into two groups, it is recommended to have two accounts: an account for processing, into which the funds are deposited as a result of transaction processing, and an account for remittance that is used as a remittance source. If two accounts are used, the funds are deposited in one account and remitted from another. To avoid manual transfers from one account to another, it is recommended to use these two accounts as sweep accounts. If sweep accounts are used, there is no need to manually transfer the funds from one account to another for performing subsequent remittance.

Individual Remittance Configurations

Individual settings allow for configuring remittance settings for a particular merchant and its accounts. Let’s review what individual remittance settings are available within the system and how to manage them in the section below.

Negative Balance Handling Modes

Traditionally, funds for processed transactions are transferred to a merchant. Typically, these transactions are sales, but there may be refunds covering sales that have been previously made. Additionally, transactions with a negative balance can be generated: chargebacks, returns and fees. If this is the case, there may be a problem with how to offset a debt resulting from the transactions of this kind. Within the gateway, there are two models for dealing with a negative balance: deduction and withdrawal.

Deduction - a fees withholding model under which fees and debts a merchant owes to the gateway are withheld from the merchant’s deposit as the result of remittance.

Advantages of the deduction model:
 

• The payment facilitator receives the funds a merchant owes to it right away.
• When the deduction is done, the merchant balance is always clear.

Disadvantages of the deduction model:

• For the merchant, the reconciliation process is more complicated due to a mismatch between the amount deposited to its account and the amount that was processed as per accounting records.

Withdrawal - a fees withholding model under which fees and debts a merchant owes to the gateway are withheld as a separate transaction from the merchant’s account the day the remittance cycle is initiated. Typically, this is done on the 1st of the subsequent month.
  
Advantages of the withdrawal model:

• For the merchant, the reconciliation process is simplified because the transaction amount that was processed as per accounting records gets aligned with a deposit amount. The fees and debts are withheld via a separate transaction. As a rule, this occurs once a month.

Disadvantages of the withdrawal model:
 

• Since withdrawal is typically done via a direct debit transaction, for the moment the fees are being withheld from the merchant's account, a payment facilitator has to assume that the operation is successful. There is always a risk that during the 60-days period a direct debit return, which the merchant will be unable to cover, can be received and the payment facilitator will not receive its funds.
• The withdrawal attempt can be unsuccessful due to incorrect input of the bank details or when a transaction gets declined by a bank for some reason. For example, there may be cases when depositing is allowed for the merchant’s account but withdrawal is forbidden. To learn more about deposit settings, review Deposit Settings section of this guide.
• If a payment facilitator receives the processed funds of the merchants net of fees, it is required to pledge its own funds for some time to cover the fee amount collected by the processor.

There are cases when the system is not able to collect a required debt amount from a merchant that works under the withdrawal model. For such cases, the merchant can be temporary switched to the deduction model. This mode is called “deduction conditional”.

Deduction conditional - a fees withholding model that is automatically activated for some period of time in cases when fees cannot be collected from a merchant as a withdrawal transaction. In this case, the withdrawal model is switched to deduction. After the merchant pays off its debt to the gateway, the payment facilitator manually switches deduction to withdrawal.

Deduction conditional is activated after two unsuccessful attempts to withdraw fees from the merchant, which technically results in two direct debit returns with a response code indicating that subsequent retries may be successful or after receiving one direct debit return with a response code indicating that a subsequent retry will be unsuccessful. To learn more details, review Remittance Hold section.

Responsible For Fees

Remittance settings allow selecting the entity that is responsible for fees (merchant or reseller) and whether the processing cost is included in the total fees amount. Merchant is set as responsible for fees by default. According to the settings in the Remittance Form, fees (and processing cost, if it is not ignored) are enabled either in the Merchant statement or in the reseller statement.
The entity responsible for fees can be selected on either of the two forms:

Merchant Perspective -> Details -> Funding -> Settings -> Funding section

Reseller Perspective -> Defaults -> Merchant Funding section. You need to activate the lamp component.

You can change the responsible for fees at any time.

The processing costs can be whether included in the total fees amount or not. The processing costs is calculated as the total of the following fees for both payment cards and direct debit transactions:

• Interchange
• Assessments
• Provider Fees.

The processing costs configuration defines the processing cost is deposited:

• Ignore - the processing cost is not included in the statement;
• Include - the processing cost is included in the statement as a separate item;
• Include Convenience Fee - convenience fee is included in the statement.

Processing Costs can be configured on either of the two forms:

Merchant Perspective -> Remittance -> Fees -> Cost section

Portfolio Perspective -> Remittance -> Pricing Template List -> Add button –> Policy tab -> Cost section

Remittance Models

One of the main issues a payment facilitator faces is organizing remittance for its merchants in the most effective and reasonable way. To allow for this, it has to consider carefully its own interests and the merchants’ interests. Before making a decision, two main factors should be taken into account:

1. A merchant wants to receive its funds as soon as possible as a gross amount in order to make reconciliation easier.
2. A payment facilitator wants to avoid the risk of not receiving its fees and not covering potential chargebacks/returns.

Therefore, when organizing remittance, a payment facilitator has to decide on the approach to funds depositing and fees withholding. Funds depositing can be organized following one of two principles: in a fixed number of days after funds have been processed according to the demand model or on certain calendar days according to the cycle model. Additionally, fees withholding can be organized following one of two principles: at the moment of depositing (on demand) or on a certain cycle (on cycle). Consequently, four remittance models are formed:

Demand-demand - a model in which a merchant receives funds in a fixed number of days after being processed and fees/negative balance is withheld at the time funds are deposited to the merchant. Based on this model, a deposit statement gets generated, which is followed by the deposit (link to a “statement” section). Any fees/negative balance are withheld according to the deduction model. If a merchant has recurring fees, they are withheld at the time of the first deposit of the month. If a merchant has insufficient funds in the account, the amount of the debt is recorded as a positive balance for the merchant. In the subsequent merchant statement, the debt is withheld as a negative balance.

To understand how the demand-demand model works, let’s review the following example:

Advantages of the demand-demand model:

• High probability for the payment facilitator to receive its fees
• The merchant does not need to wait for a particular calendar day to receive its funds. Funds are available to the merchant in a predetermined number of days after being processed.

Disadvantages of the demand-demand model:

• Merchant’s reconciliation process is complicated because funds are transferred to the merchant net of fees.

Demand-cycle - a model in which a merchant receives its funds in a fixed number of days after processing and in which fees/negative balance are withheld on a certain cycle. Based on this model, a deposit statement gets generated. To withhold all types of fees, a reconciliation statement gets generated for every remittance cycle (a link to “statement” section). Fees are withheld according to the withdrawal model. After two failed attempts to withhold fees, the deduction conditional mode is activated. To learn more about deduction conditional mode, review Remittance Hold section of this guide.
To understand how the demand-cycle model works, let’s review the following example:

Advantages of the demand-cycle model:

• The merchant does not need to wait for a particular day to receive its funds. Funds are available to the merchant in a predetermined number of days after processing.
• The merchant’s reconciliation process is simplified because funds are transferred as a gross amount.

Disadvantages of the demand-cycle model:

• The payment facilitator risks not receiving its fees if a withdrawal from the merchant’s account is not successful.
• If a payment facilitator receives the processed funds of the merchants net of fees, it is required to pledge its own funds for some time to cover the fee amount collected by the process.

Cycle-cycle - a model in which a merchant receives its funds on a certain calendar day following a particular cycle and in which fees are withheld at the time of depositing. To make a deposit to a merchant and withhold fees/negative balance, a reconciliation statement gets generated (link to “statement” section). Fees are withheld according to the deduction model. After two failed attempts to withhold fees, the deduction conditional mode is activated. To learn more about deduction conditional mode, review Remittance Hold section of this guide.

To understand how a cycle-cycle model works, let’s review an example below:


Advantages of the cycle-cycle model:

• For the merchant, the reconciliation process is simplified. Since funds are deposited one or two times a month, it is only necessary to do reconciliation one or two times a month. This is not a problem for the merchant even though funds are deposited net of fees.
• High probability for the payment facilitator to receive its fees.

Disadvantages of the cycle-cycle model:

• Since funds are available for the merchant one or two time a month, it must wait for some time to receive its funds.

Cycle-demand - a model in which funds are deposited to the merchant on a certain cycle and fees are withheld in a given number of days after being processed. This model is not practical and not used in real world.

How a Remittance Model and Other Remittance Settings Affect Statement

A remittance model determines the overall behavior of the remittance process. However, there are two additional parameters affecting the basic behavior of the chosen remittance model:

• Negative Balance Handling Modes
• Statement Policy

By default, funding policy is set as deduction and statement generation policy is set as positive only for all remittance models. However, these default settings can be changed upon the request of a client. Depending on the remittance model, negative balance handling mode and statement policy, the statement and remittance amount can change. To understand how the behavior of the remittance model changes depending on the above-mentioned parameters, let’s review the use case below representing how they interact.


Depending of the remittance settings set for the merchant, the possible funding scenarios are the following:

Remittance Basis/Remittance Period

From the time a transaction is processed until the payment facilitator receives funds in its account, it usually takes 24 hours. This period is called a funding delay and is established by the processor/acquirer. Due to this funding delay, funds are also transferred by the payment facilitator to the merchants with a certain delay. In particular cases, this delay is additionally extended in order to minimize risk from potential chargebacks/returns that may be received well after a transaction has been processed. To configure the remittance process according to the funding delay of the acquirer, specific configurations - remittance period and remittance basis - are used.

Remittance basis - the period when money will be deposited to a merchant. This period can be calculated based on the two dates - a response date and funding date.

Response date - the date when the gateway receives the response for a transaction from the processor. If a remittance period is calculated from this date, then funds will be in the account of the merchant in a certain number of days after a transaction response is received.

Funding date - the date when a payment facilitator receives money from the processor/acquiring bank. If a remittance period is calculated starting from this date, the funds will be in the account of the merchant in a certain number of days after funds are received by the payment facilitator.

Remittance period - the number of days from the response/funding date until the funds for the processed transactions are in the account of the merchant. Within the gateway, this value can be specified for direct debit, credit card and Amex transactions. This period affects only date of the actual deposit to the merchant account; it does not affect direct debit returns as return transactions are created after being received from a processor and are included in the next merchant statement.

As a rule, funds from processed credit card/direct debit transactions can be in the payment facilitator’s account no earlier than in 24 hours. Funds from processed Amex transactions can be transferred in 24 hours if OptBlue option, which allows for receiving money in 24 hours, is used. But there are cases when funds may not be transferred for 72 hours - for example, when Amex transactions are processed and OptBlue service is not available. In this case, the payment facilitator has to decide how to transfer funds to its merchant. For this purpose, three options are available:

1. To postpone the date of merchant depositing until funds are received by the payment facilitator. Thus, there will be a single deposit, but there will a need to hold the merchant’s funds in the payment facilitator’s account. In this case, the payment facilitator uses the response date as the remittance basis and a remittance period is calculated from this date.


2. To transfer all funds to the merchant even though a part of them has not been received by the payment facilitator from the processor/acquirer. This means the payment facilitator deposits its own money to the merchant. This option works only if the payment facilitator has enough money. In this case, the payment facilitator uses the response date as the remittance basis and a remittance period is calculated from this date.


3. To transfer funds in parts once the merchant’s funds are available in the payment facilitator’s account. In this case, there will be multiple deposits. For that reason, it is necessary to pay attention to the processing frequency of the merchant. To understand how the number of deposits effects merchants, see Remittance Source section of this guide. In this case, the payment facilitator uses the funding date as the remittance basis and the remittance period is calculated from a funding date.


A payment facilitator may work with different processors and these processors may transfer funds to a payment facilitator at different times. Since the processors may transfer funds at different times, the payment facilitator can remit funds to the merchant in either of two ways - via several deposits (when funds become available) or via one deposit as it is described above. To learn how depositing options effect merchants, see [ /guide_content?id=24#Remitter Remittance Source] section of this guide.

Deposit Period

In addition to a remittance basis, a deposit period is required to be set within remittance period settings.

Deposit period - a period necessary for a banking system of a particular country to process a transaction. It is used to indicate how many days until the actual deposit date a payment facilitator needs to submit a remittance file to the bank. In the USA, the deposit period is one day.


The US banking system requires 24 hours for payment processing by a processor and another 24 hours to transfer funds from a payment facilitator to a merchant. For that reason, the merchant receives its money not earlier than two days after the transactions have been submitted for processing. Within the gateway, the number of days it takes for the merchant to receive its funds from the payment facilitator is referred to as the remittance period and is set separately for direct debit, credit card and Amex transactions via the DD/CC/Amex fields on the user interface. The behavior of these fields depends on both the deposit period and the remittance basis:

• If the remittance period is calculated from the response date, then the values in the DD/CC/Amex fields are influenced by the period it takes for the processor to process transactions and the period it takes to transfer funds to the merchant (deposit period). If the minimum required period for transaction processing by the processor is 1 day and the minimum period to transfer funds to the merchant is also 1 day, then the minimum value to specify within the DD/CC/Amex fields is “2”.
• If the remittance period is calculated from the funding date, then the period required for transaction processing by the processor does not influence the values that should be set within the DD/CC/Amex fields. In this case, the values within these fields are influenced only by the deposit period. If the deposit period is 1 day, then the value to specify within the DD/CC/Amex fields is “1” . Thus, funds will be in the merchant’s account the next day after being received by the payment facilitator.

To understand how the settings of the remittance period mechanism work together, let’s review the following two examples:

Deposit Information

After transaction processing is done and a merchant’s funds are processed, the payment facilitator needs to transfer them to the merchant as a result of remittance. The payment facilitator has to withhold its fees from the processed transactions. The fees can be withheld as a deduction, during the remittance process or as a withdrawal from the merchant’s account to which funds are deposited – the deposit account.



Deposit account - the account of a merchant to which its funds are deposited by a payment facilitator. The account can be also used for processing fees withholding. Once the transactions are processed, the merchant needs to do the reconciliation between the gateway and its accounting system.

When fees are withheld from a deposit account following the deduction model, money is deposited as a net amount, net of fees. This makes the reconciliation process more complicated because it is easier to handle reconciliation when money is transferred as a gross amount with fees included.

When fees are withheld from a deposit account following the withdrawal model, money is deposited as a gross amount with fees included. As a result, reconciliation is simplified, but if one account is used for income, fee payment and settlement with the payment facilitator as well, distribution and classification of money flow by an object of expenditure gets complicated.
Note that zero statement files are not submitted to the bank.


If a merchant wants to have separate accounts for income and covering any negative balance, it can use an additional account for settling payment obligations with a payment facilitator - a charge account.

Charge account - an account which can be used in addition to a deposit account to withhold fees or potentially cover any negative balance (returns, chargebacks, adjustments).

Within the gateway, the following options for using a charge account are available:
1. Fee only - used to withhold fees. Fees are withheld from a separate account when:


• A merchant wants to facilitate reconciliation by using a separate account for a deposit remitted as a net amount and an account for fee payment.


• Fees are paid by a third-party company. For example, when a merchant pays directly to the software platform for having transactions processed.



2. Negative Balance - used to cover any negative balance (chargebacks, returns, fees, adjustments). Any negative balance is withheld from a separate account when:

• A merchant wants to simplify reconciliation. For example, according to the corporate policy, a merchant should have a separate account to which a net amount is deposited and a separate account to cover any negative balance.

• It is prohibited to withdraw funds from the merchant's deposit account.


There can be situations when a merchant changes a deposit and/or charge account information. In this case, a payment facilitator receives a notice of change (NOC) about the merchant's account number being updated to its email. The notification is always sent to the payment facilitator regardless of whether the account information had been previously manually updated in the gateway or not. If the information wasn't updated by the payment facilitator, the gateway automatically updates the account number where the old one was indicated. For example, if the same account was for both merchant and account, it would be changed to a new one in two places. If the accounts differ, only one place where the old account number was would be updated.

Reserves

Chargebacks and returns can be received within a 60-day period from the time when an original transaction was processed. By the time they come, there is a chance that a merchant has no funds in the account to cover the expenses from these types of transactions or may even be out of business. Additionally, when a merchant issues refunds, the funds are first withheld from the payment facilitator’s account and then from the merchant’s account. And by that time, the merchant may already have no funds to cover the expenses resulting from these transactions. To protect itself, a payment facilitator needs to make sure that the merchant can pay for incoming chargebacks/returns/refunds. One of the tools allowing for protection of the payment facilitator is Reserves.

Reserves - a fixed amount or percentage of a merchant’s turnover which is withheld by a payment facilitator and not transferred to the merchant during the remittance process. Reserves are used to cover potential chargebacks, direct debit returns and refunds if the merchant is not able to pay for them from its own balance.

A reserve can be calculated as a rate or a fixed amount.

Rate

  Rate - a percentage of an amount which is withheld by the payment facilitator from the merchant as a result of remittance. The rate is used to cover chargebacks and returns.

Additionally, in the reserves calculation two fields are used: required amount and collected amount. A required amount is a percentage of the remittances amounts over a certain period of time. It is calculated automatically by the system as an amount that should be withheld from the merchant.  A collected amount is an amount which actually has been withheld over the previous reporting month.   

Minimum Amount

If a merchant goes out of business, processing volume drops and the number of the chargebacks and returns increases. If reserves are calculated as a percentage, the reserve amount and the processing amount drop in proportion. Thus, there may be a situation where the reserve amount is not enough to cover the expenses resulting from the received chargebacks and returns. For that reason, to protect itself, a payment facilitator can set a minimum amount that will be always withheld from a merchant, regardless of the processing volume.

Minimum amount - a fixed amount withheld and kept by a payment facilitator in the reserve as a result of remittance, regardless of the merchant's processing volume.

Reserve Calculation for Chargebacks/Returns

The calculation mechanism for the reserves is as follows:
1. A period represented as a number of days is set via the Period field. This period covers a certain number of sales made over the specified period.

2. A percentage is set manually via the Rate field. A received amount is multiplied by the percentage. A percentage is calculated as follows: (1) when remittance is being done, a number of days, set as period, is counted down from today; (2) a total amount of the successful sale transactions included in a merchant statement excluding the amount of fees is multiplied by the indicated percent.

3. A received result is compared with the minimum amount: 

• If the result is higher than the minimum amount, then an amount, calculated as a percentage, is set as a required amount.

• If the result is less than the minimum amount, then the minimum amount is set as a required amount.


4. To understand when reserves are collected from a merchant, see the funds distribution priority section.

5. Required amount is an amount that always should be kept in reserves. It depends on the processing volume of a merchant. If processing volume changes, the required amount gets changed as well. Thus:

• If processing volume of a merchant drops, then the gateway automatically recalculates the required amount and reduces it.

• If processing volume of a merchant increases, then the gateway automatically recalculates the required amount and increases it.


There are three scenarios of how the system behaves with respect to the reserves collected based on the required amount (Required Amount field):
1. The reserve is empty at the moment. In this case, the required amount equals the amount that should be deducted from the statement as a percentage over a specified period of time.

2. There are funds in the reserve at the moment (collected amount), but the amount exceeds the required amount. In this case, the collected amount is more than the required amount. The differenc e between the collected and the required amount is returned to the merchant in the current statement. 

3. There are funds in the reserve at the moment (collected amount), but the amount is less than the required amount. In this case, the collected amount is less than the required amount. The difference between the collected and the required amount is deducted from the current statement.

6. If a merchant does not have enough money to cover a required amount, the system collects the available amount.  The amount of the debt will be deducted from a subsequent statement.

Maximum Amount

Since refunds are first withheld from a payment facilitator’s account and then from a merchant’s account, there is a risk that the merchant, having issued a large number of the refunds, may commit fraud or go out of business. For that reason, to protect itself from such situations, a payment facilitator can use a refund reserve. The refund reserve allows for setting a fixed amount upper limit amount for which a merchant may issue refunds. This is done via a maximum amount. For refunds, only maximum amount reserve is used.

Maximum amount - a limit which cannot be exceeded by a merchant when issuing credits or refunds to the clients.

Reserve Calculation for Refunds/Credits

The mechanism of the maximum amount is as follows:
1. An amount up to which credits/refunds can be issued by a merchant is set manually (Maximum Amount field).

2. The amount for which credits/refunds have been already issued by the merchant is calculated automatically by the system (Collected Amount field).

3. The amount that is left to reach the limit is calculated. This amount is the difference between a collected and a required amount (Remaining Amount field). 

4. If a total amount of the issued credits/refunds exceeds the configured limit amount, the ability to issue refunds is blocked and a respective error is returned by the system for every credit/refund attempt.

   

Amount Limits

In some cases, a merchant or payment facilitator needs to limit some amounts associated with remittance - for example, the reserve amount or deposit amount. This can be done via the amount limits mechanism.

The following limits are available within the gateway:

Minimum Remittance - the minimum amount accumulated on the merchant balance for subsequent remittance. It is used to ensure that a fee amount constitutes a reasonable percentage of the money transfer cost.  


Max Withholding - the maximum amount that goes to a merchant’s reserve within one statement. It allows for minimizing the risk of not receiving the profit by the merchant for a long period of time due to a high reserve requirement.


Max Reserve Adjustment - the amount of a merchant's reserve, for which a statement goes to review to be subsequently manually approved. It allows for minimizing the risk of not receiving the profit by the merchant for a long period of time due to a high reserve requirement.


Max Statement - the maximum amount for a merchant statement to be automatically approved. If an amount is higher than a specified value, then a statement is put on manual review and is required to be manually approved by the payment facilitator. This is used as a fraud prevention tool and when a payment facilitator wants to make a decision individually on every statement that deviates from the amounts that are normal for a particular merchant.

Min Statement - the minimum amount for a merchant statement to be automatically approved. If an amount is less than a specified value, then a statement is put on manual review and is required to be manually approved by the payment facilitator. If the amount is less than it is specified within the field or it is negative, this can be a signal of either fraud or merchant’s financial problems. This is used as a fraud prevention tool and when a payment facilitator wants to make a decision individually on every statement that deviates from amounts that are normal for a particular merchant.  

Fees

Fees withholding is a substantial part of the remittance process. Let’s review what fee types and fees settings are available within the system and how to manage them in the sections below.

Processing Cost Handling

 
A payment facilitator charges fees for providing its services. One of the merchant fee types the payment facilitator charges is a processing fee. It can be represented as a fixed amount for transaction processing or a surcharge over the processing cost. The processing fees are applied according to a fee policy. The fee policy is applied only to processing fees and depends on the pricing model: blended rate or cost plus. If the fees are collected as a fixed amount, the blended rate pricing model is used by the payment facilitator. If the fees are collected as a surcharge over the processing cost, the cost plus pricing model is used by the payment facilitator. What pricing model to choose depends on the specific business needs of the merchant, payment facilitator and reseller.
 
Blended rate - a pricing model, in which a fixed amount (percentage and/or per item) is withheld from the merchant for all types of transactions. This amount is a typical average processing cost. When the blended rate is used, the information on the processing cost is not available to the merchant and not included to the statement.


Cost plus - a pricing model in which a fixed amount (percentage and/or per item) is collected from the merchant as a surcharge over the processing cost charged by the processor for all types of transactions. When this model is used, the information on the processing cost is available to the merchant and included in the merchant statement. However, in order to provide this pricing model to merchants, a payment facilitator needs to implement a processing cost integration that allows for accepting this information from the processor.


In cases where the payment facilitator works with a reseller, it may pass the cost to the reseller if desired. The payment facilitator and the reseller may agree to cooperate under the following conditions:

1) The payment facilitator offers the reseller a processing fee as blended rate, for example, 2.5%. The reseller, in turn, marks it up by its rate and also resells as a blended rate, for example, for 3%. In this case, the payment facilitator is responsible for covering the processing cost since it is already included in the processing fee offered to the reseller.
2) The payment facilitator offers the reseller a processing fee as cost plus, for example, cost+0.5%. The reseller, in turn, marks it up by its rate and resells as cost plus, for example, cost+0.7%. In this case, the processing cost is passed to the merchant, and the merchant becomes responsible for covering the processing cost.
3) The payment facilitator offers the processing fee as cost plus, for example, cost+0.5%. The reseller, in turn, marks it up by its rate and resells as blended rate, for example, for 3%. In this case, a reseller becomes responsible for covering the processing cost. Because the reseller is paying the processing cost, the processing cost is deducted from its commissions in the reseller’s statement. To configure the reseller as responsible for covering the processing cost within the gateway, contact gateway support. To learn more about commissions calculation, review the Commissions section of this guide. With regard to the information outlined above, let’s review the models of interaction between the parties (the merchant, the reseller, and the payment facilitator) in the table below:




When deciding which pricing model to choose, the following conditions have to be considered:
 

1. When the blended rate model is used, then if the processing cost is higher than expected, the income tends to be less. If the processing cost is less than expected, the income tends to be higher. In other words, when the blended rate model is used, the income can be uncertain, except for cases when the blended rate is high enough to result in a guaranteed income.
2. When the cost plus model is used, then the income of the payment facilitator falls within certain limits. The reason is that the processing fee is added as a surcharge over the processing cost, which means that the payment facilitator is guaranteed to receive its income. In other words, the cost plus pricing model proves to be safer. However, when the cost plus model is used, the payment facilitator needs to have cost plus integration in place allowing for accepting this information from the processor.

A processing cost can be set for credit cards (Visa, MС, Discover), Amex and direct debit payments. For cases when Amex transactions are processed directly through Amex, the fees for this type of transactions can be set separately from other card brands. The gateway provides three options for processing cost configuration: ignore, include merchant and convenience fee:
 

• Ignore. This option allows for indicating that the information about the processing cost is not included in the merchant statement. This option is used when the blended rate model is used.
• Include merchant. This option allows for indicating that the processing cost is withheld from the merchant and is included in the merchant statement. This option is used when the cost plus model is used and fees are withheld as a surcharge over a processing cost.
• Convenience fee. This option allows for indicating that the processing cost is going to be withheld from the amount accumulated by the merchant on the convenience fee balance using a corresponding mechanism. If there are not enough funds to cover a required convenience fee amount, the outstanding amount gets included in the merchant statement. To learn more about the convenience fee functionality, review this guide.

Deposit Policy

 
After having been processed, funds are transferred to the merchant via a deposit as a result of remittance. Funds can be deposited to the merchant either by a payment facilitator or by a processor. When funds are deposited to the merchants by the payment facilitator, processed funds are first transferred to the payment facilitator's account by the processor. After that, the payment facilitator, using the remittance process - which implies statement generation and fees withholding - conveys transactions to the bank for the subsequent deposit to be made. When funds are deposited by the processor, merchants’ processed funds are first accumulated in the processor's account, then funds are transferred to the merchants via its remittance mechanism. Thus:
 
1. If funds from the processed transactions are deposited by the payment facilitator, it does both: conveys transactions to the processor and deposits funds from these transactions using the gateway’s remittance mechanism remittance. In this particular case:

• Fees are always withheld by the payment facilitator.



  2. If funds from the processed transactions are deposited not by the payment facilitator but by the processor, the payment facilitator functions as a gateway. This means that it only conveys transactions to the processor for subsequent remittance to be done by the processor. In this particular case:

• Fees can be withheld by the payment facilitator.
• Fees can be withheld by the processor.

There are cases when funds from one payment type are deposited by the gateway and funds from the other one are deposited by the processor. Consequently, the gateway provides an option to set depositing at the level of a particular card brand or a direct debit deposit. For example, funds from credit card transactions are deposited by the processor and funds from direct debit transactions by the payment facilitator. In order to specify the payment which is going to be deposited three options are available within the gateway:
 

• Deposit. Set for a particular payment type if funds are deposited to the merchant by the payment facilitator via the remittance mechanism. Thus, transactions are populated in the merchant statement as financial transactions and the funds from these transactions are deposited to the merchant. When it comes to sales, transactions are shown with a plus (+) symbol in the merchant statement. When it comes to credit/refunds/chargebacks/returns, transactions are shown with a minus (-) symbol in the merchant statement (link to a ‘merchant statement’ section).
• Info. Set for a particular payment type if funds are deposited to the merchant by the processor and the payment facilitator wants to provide details about such transactions in the merchant statement. In this case, the transactions are populated in the statement as non-financial, for information purposes only.
• Skip. Set for a particular payment type if funds are deposited to the merchant by the processor and the payment facilitator does not want to provide details on these transactions in the merchant statement.

Fees Withholding Mechanism

In the gateway, processing fees can be withheld as a rate, per item or a combination of rate and per item.

Rate - a way to withhold fees as a percentage of a transaction amount.
Per item - a way to withhold fees as a fixed amount charged on every processed transaction regardless of the transaction amount.
 
The system allows users to choose the transaction types from which processing fees are withheld and the way they are withheld. Processing fees can be charged from the following types of transactions:

• real-time transactions: payments, declines, voids, blacklists and errors;
• batch transactions: payments (regular/rebill), decline (regular/rebill/retry), blacklists (regular/rebill) and errors.

 
Typically, the volume and number of processed transactions across the merchants is nearly the same. However, there may be two non-typical scenarios for transaction processing by the merchant:
 

• The merchant may process a small number of large-value transactions.
• The merchant may process a large number of small-value transactions.

To understand which fees withholding option is better, let’s review how the fee amount charged by the payment facilitator changes depending on the scenarios outlined above and the fee settings applied.
 

When choosing between the options for fees withholding, it is necessary to pay attention to the following:
 
1. The policy of the fees calculation changes based on the number and volume of the processed transactions. When the merchant processes a large number of small-value transactions, a combination of a rate and per item fee is the most cost-effective option for the payment facilitator. And when the merchant processes a small number of large-value transactions, a high rate is the preferable option for the payment facilitator.
2. A combination of a rate and per item fee or a high rate is typically applied to payments: the transactions that have been authorized and subsequently captured (sales, credits and refunds).
3. A per item fee is typically charged from the transactions that have been attempted to be authorized (declines, voids, errors). The reason is that the processor charges for every operation, and an unsuccessful authorization is not an exception. However, there may be other options as well.
4. If the merchant processes a large number of small-value transactions, the payment facilitator has to pay for every transaction that is authorized. The problem is that the cost of the transaction may easily exceed the rate amount if it is not additionally compensated by the per item fee. In other words, if fees are charged as a rate of the processed transactions, the payment facilitator risks not receiving its revenue or suffering loss. Moreover, to provide technical support for these merchants, the payment facilitator wastes its resources, which results in extra expenses. For that reason, to compensate for the risk of dealing with these transactions, it is recommended that the payment facilitator use a combination of a rate and per item fee.
5. If the merchant processes a small number of large-value transactions, there is a risk of receiving direct debit returns or chargebacks, for which the payment facilitator is responsible. For that reason, when a merchant of this kind is charged a per item fee, the payment facilitator receives nothing for the risk it takes. Consequently, to compensate for the risk dealing with these transactions, a high rate is the recommended option in this case.

Fee Types

A payment facilitator has to cover the processing cost and receive its revenues. To allow for this, there are three types of fees provided within the gateway - processing, flat and recurring fees.

Processing fees - the fees that are applied to a merchant for the processing of each sale/credit/refund transaction. The processing fees withdrawal policy depends on the pricing model that is used - cost plus, or blended rate.

If the blended rate model is used, the processing fee is represented as a fixed rate. If the cost plus model is used, the processing fee is represented as a surcharge over the processing cost. In fact, the processing fees can be applied separately to each particular card brand and direct debit transactions.

As a rule, the main costs for the processing of these transactions are covered at expense of the processing fees. However, there are certain transaction types and their respective services which may not be covered by these fees. For that reason, in addition to the processing fees, flat and recurring fees outlined below can be charged.

Flat fees - fees that are applied as a fixed amount for processing specific transaction types. These fees may be charged for the following reasons:

• Banks may apply additional charges for processing certain transaction types (for example, chargebacks, direct debit returns, or depositing costs) and these charges have to be compensated.
• There may be additional services provided in association with certain administrative processes related to the previously mentioned transactions For example: chargeback resolution - a service allowing for the disputing of chargebacks; notification service - a service employed to inform the merchant that a direct debit return/chargeback has been received; decline recycling - a service allowing for decline attempts.

Recurring fees - the fees that are applied to cover services such as:

• Equipment costs, PCI compliance; cases when the transaction flow of the merchant is too low in volume or there is no transaction processing for certain periods of time due to business specifics, etc;
• Additional services, for example, rental of equipment such as POS terminals.
• Usage of the software platform; or fee withholding on behalf of the partners. For example, POS system use that is integrated with the gateway.

To understand how the above-mentioned fees are applied, refer to the “Use Case” section below.
 

Recurring Fees

There are three types of recurring fees:

• One-time fee - a fee collected from the merchant on a one-time basis. For example, software setup or the freezing of payments (freeze flat fee). There can be up to 6 types of one-time fees set up.
• Monthly fees - a fee collected from the merchant on a monthly basis. Instances may include tech support or the rental of a terminal. There can be up to 10 types of monthly fees set up.
• Annual fee - a fee collected from the merchant on a yearly basis for services. Typical examples include software use or PCI compliance. There can be up to 4 types of annual fees set up. Annual fees are typically withheld during the same month each year. To learn more about annual fees, review the “Annual Fees” section of this guide.

In some cases, it is easier to configure the merchant with all fee types together at once. By default, the fees are charged from a processing start date. However, sometimes, depending on the business context, the fees have to be charged starting on a future date. For example, in order to begin withholding the recurring terminal fee, the merchant needs to receive the terminal first.

For some cases, when a delay is required to be set for recurring fee withholding, the following settings are available within the gateway:

1. Billing begins on. Allows to set the actual processing start date. Thus, the recurring fees are charged from this date. The setting indicates from which date transactions are included in the statements. The transactions that were generated prior to the indicated date are not taken into account when the merchant statements generated.
2. Recurring Fees begin on. Allows to set the date when recurring fees collection starts after transaction processing begin date. Thus:

• If a processing begin date is the date when the fees are set according to a specific remittance model, then the date for the recurring fees withholding is calculated from this date.
• If a processing begin date is the date set as the value of the Billing begins on field, then the date for the recurring fees withholding is calculated from this date.

Let’s review the three merchant types with different recurring fees settings:
1. A new merchant begins processing transactions. In this case:

• Remittance settings are configured. Thus, the merchant starts processing and the recurring fees are charged from the processing begin date, which is immediately after the remittance model is set up.

2. A new merchant begins processing transactions. However, as a marketing hook, the recurring fees are waived for a pre-determined period of time. In this case:

• Remittance settings are configured
• Recurring Fees begin on date is set. Thus, fees withholding is going to be delayed.
• If a payment facilitator wants to explicitly show that a discount is distributed, then a scheduled adjustment can be applied instead of the Recurring Fees begin on setting. Thus, the recurring fees are set to zero via the adjustment when the statement is generated. Note that scheduled adjustments can be applied only for active merchants/accounts.

3. A merchant has been processing for some time, but the remittance was not done through the gateway. In this case:

• The remittance settings are configured;
• The Billing begins on setting is configured to specify from which date transactions are included in the merchant statement. The transactions processed prior to this date are not taken into account when a statement is generated;
• The Recurring Fees begin on date is set for cases when the recurring fees collection has to be delayed.

Recurring fees withholding depends on the remittance model - demand-demand, demand-cycle, or cycle-cycle. To learn more about remittance models, review Remittance Models section of this guide.
The first word in the names of these models corresponds to how funds are deposited:
1. On demand means that funds are deposited within a certain number of days after being processed.
2. Cycle means that funds are deposited on a certain cycle.
The second word in the names of these models corresponds to how fees are withheld:
2. Сycle means that fees are withheld on a certain cycle in a reconciliation statement.
3. Demand means that fees withholding depends on the type of recurring fees:

• A one-time fee is charged in the first deposit statement from the processing begin date (either the date set as the billing begins on setting, or the date when a remittance model was configured).
• The monthly fee for a current month is charged in the first merchant statement of the subsequent month.
• The annual fee is charged in the first statement of the month corresponding to the month set in the annual fee policy, with regard to the processing begin date (either the date set as the billing begins on setting, or the date when a remittance model was configured).

Delay Period

If necessary, a payment facilitator can withhold recurring fees, not immediately, but with a certain delay. To allow for this, when recurring fees are being configured, a delay period can be set. The delay period is calculated from the processing begin date (either the date set as the billing begins on value, or the date when a remittance model is configured). After the fees settings are configured and saved, the delay period cannot be changed. Let’s review the format of the delay period to be set for each particular recurring fee type and how it influences fees withholding:

• A delay period for one-time and monthly fees is set as a number of months and calculated from the processing begin date. For example, if the delay period is set as “2”, it means that the fee is going to be charged with a 2-month delay from the processing begin date (either the date set as the billing begins on value or the date when a remittance model is configured). The period is required to be set as integer values.
• A delay period for the annual fees is set as a number of years and calculated from the month the fee is required to be withheld (set within annual fee policy) with regard to the processing begin date. For example, if the delay period is set as “1”, the fee is going to be charged with a 1-year delay from the month the fee is required to be withheld (set within annual fee policy). This period is required to be set as integer values.
• If the delay period is set as “0”, the fee is charged right from the processing begin date.

Setting Up Recurring Fees

The overall set-up mechanism for the recurring fees is as follows:

1. A remittance model is configured with regard to the fees to be withheld. To learn more about remittance models, review Remittance Models section.
2. The policy for fee withholding is set (link to “Processing cost handling”).
3. Processing fees are configured (if present).
4. Flat fees are configured (if present).
5. Recurring fees are configured. There are three options provided for the recurring fees:

• The Billing begins on date is configured:
  • For new merchants in order to delay a processing begin date;
  • For existing merchants that have not used the gateway’s remittance mechanism before, in order to specify the processing begin date from which the transaction data is included in the merchant statements. Transactions processed before this date are not considered when the statements are generated;
  • If the date of Billing begins on setting is not specified, the recurring fees are withheld immediately after the remittance model is set.
• The “Recurring Fees begin on” date is configured:
  • If there is a need for the recurring fees withholding to be delayed not starting from the processing begin date.
• The delay period is configured:
  • If there is a need to specify a delay for recurring fees withholding at the time the remittance model is being configured.
  • If the delay period and the recurring fees begin on date are configured, the delay period is calculated from the date specified within the Recurring Fees begin on setting.
  • If the “Recurring Fees begins on” date is not configured, the delay period is calculated from the date the remittance model is set.
  • Once configured and saved, the delay period cannot be changed.

If a payment facilitator decides not to work with the merchant/account and have it deactivated within the gateway, the fees must be manually deactivated. Recommendations for the fees deactivation are as follows:

Annual Fees

To increase its earnings, or for other reasons, a payment facilitator may withhold annual fees from its merchants. Annual fees are a part of the recurring fees mechanism. For example, annual fees can be charged for joining the software platform or for help with PCI compliance. Typically, annual fees are charged during particular months of the year. The gateway allows for the configuration of annual fees withholding for specific months in the following way:

• At the portfolio level, a payment facilitator configures the months when the fees are withheld. One or more months may be selected during setup.
• When configuring remittance at the merchant level, one of the months set at the portfolio level can be chosen. This is the month when the annual fee is going to be charged.
• If a month for annual fee withholding is not set, the closest month to when the merchant’s account was created is automatically selected. This month becomes the assigned month for annual fee withholding. For example, if October and March are configured for the annual fee policy, and the merchant is created in August, then October is automatically selected as the month when the annual fee is going to be charged.
• If necessary, a delay period can be specified for annual fees. To learn more about the delay period, review this (delay period section).
• The dеlay period for annual fee withholding is set in years. For example, if the delay period is one year, the merchant is created in January, and the month predefined for annual fee withholding is March. Thereafter, the annual fee is charged in March of each subsequent year.
• The merchant can configure only one month for annual fee withholding. If a list of annual fee withholding months is changed at the portfolio level, and it is needed to change annual fee settings for existing merchants, contact gateway support.

Fee Types Use Case

Having familiarized yourself with all fee types and their configuration specifics, let’s review the use case explaining how to configure all fee types in the most optimal way with regard to the merchant type and its needs, accordingly:

Association Fees

Context:
The amount of processing cost, in addition to interchanges, assessments, and fees charged by a processor, may include an additional fee from a card brand (Visa, MC), which it imposes upon individual merchants for transaction processing. These fees are called a Fixed Acquirer Network Fee (FANF) for Visa and a Location Fee for MasterCard. Once received by the gateway, these fees are called by the generalized name - Association Fees.

Definition:
Association fees - FANF / Location fees charged by the card brand to the merchants for processing transactions of this brand.

Principle of Work for Association Fees

1. Card brands assign the association fees according to their individual patterns; however, the brands periodically change those calculation patterns. For these reasons, the card brands independently calculate the amount of fees applied to merchants, and pass this information through a processor. The gateway obtains this information as part of the processing cost.
2. Association fees are included in the processing cost amount, which is available in a merchant statement.
3. If a statement is retrieved from the gateway’s user interface, the association fees are included in the processing cost total.
4. If a statement is retrieved in PDF format, the association fees are included in the processing cost breakdown.

Configuration Specific for Association Fees

1. Only merchants working under the cost plus model receive information about the association fees included in the processing cost. To receive the processing cost, and have it present in the statements, the Processing Cost checkbox should be checked off in the Fees settings.
2. Visa imposes association fees upon merchants through the processors. The amount of the association fees depends on the number of transactions processed by merchants and the industry they operate in. In the report, Visa provides a list of merchants and the amounts imposed upon each merchant from the list.

3. MasterCard imposes association fees upon merchants through the processors. The amount of the association fees is fixed once per year. MasterCard provides a report with a list of merchants, but the amount of the association fees is not specified. Therefore, to allow for the fee withdrawal from each merchant, its amount has to be specified on the Association Fees form on the user interface. Thanks to this form, the MasterCard fees will be included in the processing cost imposed upon a merchant. The form is available at the Portfolio perspective=>Remittance=>Association Fees.

3.1. You can specify the following values for each record under the Association Fees form:

• Code - identifier of an association fee. Currently, the only available value is MasterCard Location Fee.
• Effective Date - date when an association fee is going to be applied. In most cases, an effective date is the last day of a calendar year.
• Amount - amount of an association fee.

3.2. Before the effective date is reached, the fee amount can be modified if necessary. For example, a user has mistakenly input the amount of $15.08 instead of $15.00. In this case, the user can edit the amount via the user interface. Please note, we strongly discourage you from modifying the association fee records that have already become effective. If a correction is needed, we recommend that you create a new record to store a complete history of withdrawing fees from the merchants.

3.3. After the effective date is reached, the record cannot be deleted. Before the effective date, the record may be deleted. However, we strongly discourage you from doing that, as all association fees have to be stored in the gateway for historical reference.

Pricing templates

To simplify Merchant fees configuration process, the gateway allows creating fee templates at Portfolio level and apply them to the merchants associated with this Portfolio. Fee templates can be configured on the following forms: Portfolio -> Remittance -> Pricing Template.
Portfolio/Reseller -> Onboarding -> Application -> Pricing Template.


A unique code consisting of the Portfolio code and the template sequential number is assigned to each Pricing template by the gateway. The Pricing template code has the following structure:

XXXnn,

where XXX is the Portfolio code, nn is the sequence number of the template

For example, for Portfolio 901:

Taxes

In some regions (for example, in Canada), merchant services fees are subject to the federal or municipal taxes. Therefore, they have to be configured, applied, and included in the merchant statement to be charged from the merchants.

Minimum Fees

There may be seasonal or inactive merchants within the gateway that negatively impact the profits of the payment facilitator. If a payment facilitator has many of these merchants, its profit could fall because of the expenses for maintaining these accounts and because they waste its resource to provide technical support, for example.

Some maintenance obligations are carried out by the resellers as well. A reseller gets compensated for fulfilling its obligations with a percentage of the processed transactions of the merchant. For that reason, it is necessary for the payment facilitator, cooperating with a reseller, to secure for itself a minimum required profit from every merchant associated with the reseller. This can be achieved via minimum fees.
  
Minimum fees - 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 define the amount of a minimum fee, it is necessary to consider which pricing model is used – cost plus or blended rate. To learn more about the blended rate and the cost plus pricing models, review the Processing Cost Handling section of this guide. Even though a commission rate is typically lower when the blended rate is used, rather than cost plus, the final amount of minimum fees (minimum amount) is higher when the blended rate is used, rather than cost plus. The reason is that the processing cost under the terms of a blended rate is covered at the expense of the rate including both - the processing cost and the surcharge of the payment facilitator. Under the terms of cost plus, the processing fee includes the surcharge of the payment facilitator only, which is charged over the processing cost. For that reason, the total amount of the processing fee is lower. The minimum fee amount is compared to the amount of the processing fee charged. To understand the interdependence between the minimum fee amount and the pricing model, let’s review the table below:


To activate the minimum fees mechanism, the following settings are required to be set:

1. Policy. A user can choose what fees are included in the calculation of minimum (gross) profit of the payment facilitator from every merchant associated with the reseller:


• processing fees (link to a respective section)

• flat fees (link to a respective section)

• recurring fees (link to a respective section)


2. Minimum fee basis. Depending on the agreement between a payment facilitator and a reseller, minimum fees can be calculated either on individual basis or an average basis.  

• Individual basis - an option allowing for calculating the amount of profit a payment facilitator gets from each particular merchant (on an individual basis). It is applied when a reseller’s portfolio includes merchants of roughly the same size.
• Average basis - an option allowing for calculating the amount of profit a payment facilitator gets as a simple average across the reseller’s portfolio. It is applied when a reseller’s portfolio includes merchant of different sizes.  

3. Minimum amount. An amount of minimum fees set for the merchants.
 
The minimum fees mechanism works as follows:

1. Once a policy and basis, based on which way a minimum profit amount is calculated, are set, the received amount is compared to the amount set as the minimum amount within the reseller’s settings.

2. If some merchant fails to reach the required minimum amount, then the difference is deducted from the reseller’s commissions.

3. Information about applied minimum fees is available in the reseller statement, which lists all merchants of the reseller and their respective minimums.  If there is a need to review why a merchant has a particular amount of fees, it is possible to drill through and review detailed information on a particular merchant in the breakdown.  


Commissions

A payment facilitator may work with merchants directly or via resellers/software platforms through which merchants are connected to the payment facilitator’s platform. If the payment facilitator works with the merchants directly, integration with each particular merchant is required, which is a rather expensive option. When working through software platforms, the costs associated with adding new merchants are minimized for the payment facilitator. The reason is that each particular integration creates a channel for new merchants, which originally the clients of the reseller/software platform. The reseller also benefits from working with the payment facilitator since it receives compensation in the form of commissions for bringing the merchants onboard and servicing them. As a rule, a compensation for the processed transactions of one merchant is paid to one reseller. However, there can be additional agreements with other platforms, which also on a regular or permanent basis, may receive compensation. To calculate and deposit a reseller’s compensation, the Commissions mechanism is used within the gateway.

Commissions - a compensation deposited by a payment facilitator to a reseller as a percentage of its revenue for bringing new merchants on board and their further maintenance. Commissions are paid on a regular or permanent basis as a part of the collected fees, which can be represented as a rate or per item value.

In most cases, the terms of an agreement with the reseller regarding the fees paid by the merchants and commissions charged to the reseller are the same for all merchants associated with the reseller. For this reason, commissions are configured within the gateway at the reseller level. As a result, the configured commissions are applied to all merchants under the reseller. In some cases, the terms of cooperation may vary depending on a merchant group. For example, the reseller has two platforms and brings two merchant groups on board with different pricing policies and different terms for commissions payouts accordingly. As a result, in this particular case, the commissions are configured at the merchant level, for each merchant individually.

The rate of the processing cost charged to the merchant depends on two agreements - between the payment facilitator and reseller, and between the reseller and merchant. When the payment facilitator agrees with the reseller, the cost offered to the reseller by the payment facilitator is called a buy rate and can be represented as a blended rate (for example, 5 percent) or cost plus (for example, cost + 0.5 percent). When information about the processing cost is not available, the payment facilitator uses the blended rate pricing model. When information about the processing cost is available, the payment facilitator uses the cost plus.

Buy rate - a processing cost the reseller pays the payment facilitator for transaction processing. It can be represented as a rate or per item value. If the transaction volume of a merchant is high, then the processing cost is compensated by the rate. If the transaction volume of the merchant processes is low, the processing cost is compensated by the per item amount. To learn more about the interdependence between the processing volume and the fee rate, review the Fees Withholding Mechanism section of this guide.

For various business reasons, it may be more reasonable for the payment facilitator to offer its fee (buy rate) to the reseller as a percentage and per item amount rather than just a percentage. At the same time, for the reseller, it may be more convenient to offer its fee to the merchant as a percentage. In this particular case, the reseller becomes responsible for the per item fee. To withhold fees not from the merchant but from the reseller, the fee settings must be set as “0” and the buy rate has to be set as a per item value. In other words, when there is a buy rate, but it is not covered by the fee amount, a residual between the buy rate and the fee represented by the negative value is actually deducted from the reseller’s commissions. The reseller, in turn, covers the costs at the expense of the sufficiently high rates charged to the merchant for other fees. To understand this principle in action, let’s review the example below:

Commission Basis

In order for the reseller to receive its commissions, they must first be calculated. Commission calculation is influenced by three factors:

1) who is responsible for the processing cost;
2) commissions rate;
3) which part of the fees is a subject of the commission calculation.

A part of the fees, which is a subject of the commission calculation, is called a basis. There are two types of a basis available within the gateway:

Residual - the basis for the commission calculation, which means that the commissions are calculated from the residual between the fee amount collected from the merchant and the buy rate. To understand how commissions are calculated based on the residual, let’s review the use case below:


Total - a basis for commission calculation, which means that the commissions are calculated from the total amount of fees collected from the merchant. When the total basis is used, the buy rate is skipped.

To understand how the commissions are calculated when the total basis is used, let’s review the use case below:


As arule, there is a certain correlation between the basis and the pricing model. In most cases:

1. The residual basis is used for:

• processing fees represented as blended rate;

2. The total basis is used for:

• processing fees represented as cost plus;
• flat and recurring fees.

Remittance in Action

When a payment facilitator has remittance settings configurations listed above set, remittance can be provided to the merchants. In this section we will review certain aspects of remittance in progress.

Merchant Charges

Some companies that interact with groups of merchants need to withhold fees from their merchants. The typical example of such a company is a corporate office and the franchisees/merchants it interacts with. The franchisees pay the corporate office for the ability to run a ready-to-use business model. Traditionally, they made these payments via bank withdrawal. In this case, there could be problems with an account, like insufficient funds. Moreover, a large number of merchants makes it difficult for the business to monitor how much any particular merchant owes. For that reason, a merchant charges mechanism is used within the gateway. It allows the business, which is represented within the gateway as a reseller, to withhold fees from their merchants directly.

Merchant Charges - a mechanism allowing for submitting a list of charges which are the basis for a subsequent funds withholding as a result of remittance. Charges are withheld from the merchants in favor of the entity that has submitted the charges. Charges are withheld as deductions but may be used for merchants that work under both the deduction and withdrawal models.

The charges mechanism within the gateway works as follows:

1. A reseller has to submit information about the charges that are required to be withheld from the merchants through the gateway. For this purpose, a charge file batch format is used.
2. To identify a charge and receive the payment information associated with it, an indicator of the charge within a reseller’s system - chargeCode - is used.
3. If a reseller needs to set a specific date for a charge to be collected, a dedicated field within the batch file - expectedEffectiveDate - is used. If effectiveDate is not set, then a charge becomes effective by default once the file has been processed. 

4. Charges withheld from the merchant are included in the merchant statement and are populated in the Charges section.
5. Information about the payments that have been collected on behalf of the resellers goes to the reseller statement along with reseller commissions and are populated as merchant charges in the Charges section.
6. The reseller statement results in a physical deposit to the reseller. This deposit contains the payments collected for charges. To facilitate reconciliation of a deposit, the reseller needs to receive the information about the payments that have been collected from all merchants associated with the reseller. For this purpose, a charge file batch format is used. If a reseller statement contains nothing but charges, then the deposit amount will match with the amount specified in the charge payments file. If a reseller statement contains any other activity in addition to charges - for example, residual revenue from processing fees or adjustments - the deposit amount differs from the amount specified in the charge payments file, which, in fact, is the same as the Charges section within the given reseller statement.
7. If a merchant does not have sufficient funds to pay for a charge during the previous remittance, the remaining amount is collected during the next remittance. As a result, a reseller can face difficulties in understanding which payment corresponds to which charge and how much a merchant owes to the reseller. To help the reseller understand that a given payment is collected for a given charge, two fields are used - sequenceNumber and remainingAmount. These fields are generated automatically by the reseller’s system. The sequenceNumber field specifies the sequence number of the charge that has been withheld; the remainingAmount field specifies the outstanding amount that has to be covered by the merchant. Consequently:

• If a charge is collected in one remittance, then the sequenceNumber field value is specified as “1” and remainingAmount field value is specified as  “0” accordingly.

• If the value of  sequenceNumber is  “1” and remainingAmount is any value exceeding “0”, this means that there will be future payments against this charge.

• If the value of sequenceNumber exceeds “1” and remainingAmount value is “0” or more, the payment is a partial amount for a specific charge which has already been submitted before.

8. Charges can obtain the following statuses:

• Active - the charge is created but no payment has been processed yet.
• Processed - at least one payment associated with the charge has been processed.
• Canceled - the charge has been canceled. Only charges, which are in Active status, can be canceled.

8. When it comes to funds distribution, there is a certain priority determining which party (gateway, payment facilitator or merchant) receives its funds first. See section Funds distribution priority to understand the mechanism.

Remittance Hold

There are cases when a payment facilitator needs to temporary stop remitting funds to a merchant. In this case, the remittance hold mechanism can be used.

Remittance hold - a mechanism that blocks funds from being physically transferred to a merchant and results in their accumulation on the merchant’s balance (as a negative balance).

Typical cases when remittance hold is used:

1. A merchant owes money to the gateway
2. There are issues with fees withholding from the merchant’s account
3. A merchant is suspected of fraud, for example, unusual activity in the merchant's account or deviating from normal behavior such as a dramatic increase/decrease in the processing volume or an increase in the number of the chargebacks/returns.

The remittance hold mechanism works as follows:

• The hold mode can be activated manually on the user interface.
• The hold mode can be activated automatically in the following cases:
  • The return of a transaction that was created based on a statement being received with a response code indicating that a subsequent attempt makes no sense. Typically, this occurs when attempting to withhold fees from a merchant with bank account details have been entered incorrectly or the account is closed.
  • Two returns of a transaction that was created based on the statement received with a response code indicating that a subsequent attempt may be successful. Typically, this occurs when attempting to withhold fees from a merchant that has insufficient funds in the account.
• If the remittance hold has been activated automatically due to inability to withhold fees, the mode of negative balance handling gets shifted from withdrawal to deduction conditional. Thus, fees are withheld via the subsequent statement, but funds are held in the account of the payment facilitator and not remitted to the merchant. To learn more details about negative balance handling modes (deduction/withdrawal/deduction conditional, see Negative Balance Handling Modes section of this guide.
• The remittance hold mechanism can be deactivated manually on the user interface.

Funds Distribution Priority

Once processed, funds are deposited to the merchant. In the context of the merchant statement, the gateway has several mechanisms as a result of which money can be either withheld or deposited due to the following reasons:

1. The gateway/payment facilitator needs to withhold its fees as well as any negative balance resulting from chargebacks/direct debit returns.
2. A reseller/software platform needs to receive its fees via the merchant charges mechanism. To learn more about merchant charges, review Merchant Charges section of this guide.
3. An amount required to cover potential chargebacks, direct debit returns and refunds has to be reserved. To learn more about reserves, review Reserves section of this guide.
4. Affiliates need to receive their funds via split-out/split-in transactions as a result of the split payments mechanism. To learn more about split payments, review Split Payments Management guide.

The common priority mechanism works as follows:

1. The amount of the original transaction is calculated.
2. Fees a merchant owes to the gateway are withheld.
3. The amount required to cover merchant reserves is withheld.
4. The amount required to cover merchant charges is withheld on behalf of the reseller.
5. The amount of a split-out transaction is withheld (based on the split balance).
6. The amount of a split-in transaction is transferred (based on the split balance).
7. The split balance is calculated. If a merchant/affiliate does not have enough funds to cover a split-out transaction amount, the outstanding amount is recorded as a debt in the statement and added to the split balance.
8. The merchant receives the rest of the input amount.

To understand how the scenario outlined above affects amounts in the statement, let’s review the following example:

Merchant Statement

When depositing funds to a merchant, a payment facilitator needs to have a detailed breakdown of the deposit, which would show how funds received by the payment facilitator on behalf of the merchant are distributed. This breakdown includes information about what kind of transactions the merchant receives money for, how much fees, processing cost, and taxes were paid, what amount was withheld in reserves, etc. This document, which accompanies every deposit and withdrawal associated with the merchant is a merchant statement.

Merchant statement - a summary of a merchant’s activity over a certain period of time. It provides information about a number of the processed transactions (sales, refunds, chargebacks, returns, etc.), splits, fees and charges collected and adjustments applied. Depending on the statement policy (described in the Merchant Statement Setting section), statements can generate either for positive or any balance.

Merchant statements can be of two types - deposit statement and reconciliation statement:

• Merchant 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 or weekend. Basically, deposit statements enable merchants to understand the deposits in their bank account resulting from transaction processing. Available for demand-demand and demand-cycle remittance models.
• Merchant reconciliation statement - a summary statement that explains a merchant’s remittance activity and shows all of the associated processing fees over a set time period, typically a month. Basically, reconciliation statements help merchants understand how much money they receive as a result of remittance and what merchant fees are charged and why. Available for demand-cycle and cycle-cycle remittance models.

Merchant Statement Settings

For merchant statements to be generated correctly, the following settings must be configured:

1) Merchant fees (required setting) - fees that are collected from the merchant as a result of transaction processing. To learn more about fees and their settings, review this section of the guide.
2) Negative balance handling mode (required setting) - models (deduction/withdrawal) controlling how a merchant’s negative balance (fees, chargebacks, returns, etc.) are charged. To learn more about negative handling modes, review this section of the guide.
3) Statement view policy (required setting) - used to control what information is included in the merchant statement. This setting is available at four levels - merchant, reseller, portfolio, and system. To define at which level the setting is effective, the overriding mechanism is used. The following options are available:

• Activity Summary - indicates whether information about the merchant's transactional activity is included in the statement.
• Rejects Summary - indicates whether information about rejects is included in the statement.
• Returns/Chargebacks Summary - indicates whether information on Returns/Chargebacks is included in the merchant statement.
• Fees Processing - indicates whether information about charged processing fees is included in the statement.
• Fees Flat - indicates whether information about charged flat fees is included in the statement.
• Passthrough Fees - Interchange - indicates whether information about interchanges included in the processing cost is shown on the statement.
• Passthrough Fees – Assessment - indicates whether information about assessments included in the processing cost is shown on the statement.
• Split Payout Summary - indicates whether information about the merchant's split-out transactions is included in the statement.
• Reserves - indicates whether information about the merchant's reserves is included in the statement.
• Adjustments - indicates whether information about the adjustments applied to the statement is included in the statement.
• Statement Summary - indicates whether information about the summary is included in the statement.
• Submissions Summary - indicates whether information about submissions made by the merchant is included in the statement.
• Splits Summary - indicates whether information about the merchant's split transactions is included in the statement.
• Transactions Summary - indicates whether information about transactions made by the merchant is included in the statement.

4) Generation policy (required setting) - used to control, for which balance a statement is generated. This setting is available at four levels - merchant, reseller, portfolio, and system. To define at which level the setting is effective, the overriding mechanism is used. These options are available:

• Positive only - means that the statement is generated only for positive balance i.e., the amount of the statement is above 0. This option is set for all merchants by default.
• Any balance - means that the statement is generated regardless of the balance i.e., the amount of the statement can be both positive (sales) or negative (chargebacks, returns).

5) Remittance currency (required setting) - currency in which funds are deposited to the merchant. Even though transactions are processed in a different currency indicated in a provider profile, remittance will still be done in the currency set in the funding settings of the merchant. USD is set for all merchants by default.
6) Statement review - used to control how statement approval is executed. Approval can be performed manually or automatically. By default, statements are approved and submitted to the bank automatically. In cases where the payment facilitator wants to reconcile the statements’ numbers with their accounting department before submitting statement to the bank, it can set review to manual. When set, manual approval is required after review.
7) Mailing policy - used to control in what form statements are delivered to the merchant via email. The content differs between deposit and reconciliation statements. This setting is available at four levels - merchant, reseller, portfolio, and system. To define at which level the setting is effective, the overriding mechanism is used.

• No action - merchant does not receive any information about statements.
• Notification only - merchant receives only a notification indicating the period for which the statement is generated, and its amount.
• Notification and statement - merchant receives a notification indicating the period, for which the statement is generated, and its amount. It additionally includes the statement in PDF format.
• Notification and statement details - merchant receives a notification indicating the period, for which the statement is generated, and its amount. It includes the statement in PDF format, which additionally lists transactions included in the statement. The list of transactions is limited to 100 and is available for deposit statements only.
• Notification and returns details - merchant receives a notification indicating the period, for which the statement is generated, and its amount. It includes the statement in PDF format, which additionally lists direct debit returns, chargebacks, declined and blacklisted transactions included in the statement. The list of transactions is limited to 100 and is available for deposit statements only.

8) Recipient list - a list of people who will receive merchant statements. By default, the statements are sent to the person indicated in the merchant’s contact details. This field may contain additional recipients separated by commas.
9) Export - if for some business reason merchant statements must be uploaded to the FTP, this setting activates that option. The statements are uploaded in PDF format.
10) Archive - if for some business reason merchant statements must be archived to a separate folder, this setting activates that option. The statements are uploaded in CSV format. Depending on the settings configured at the system level, statements can be uploaded to the FTP or the $app-home/resources/archive located on the server.

Deposit Statement and Monthly Statement Mailing

Statement emailing policy is configured on the Remittance form. By default (when the “Send to contact email” checkbox is active), statements are delivered to an email address indicated in the Merchant´s contact information. A merchant can also indicate additional email recipients that will receive Deposit and Monthly Statements. For this purpose, activate Deposit/Monthly Statement (or both) recipients textboxs by ticking the corresponding checkbox(es) in Emailing Policy section and enter the email addresses separated with coma.

Merchant Statement Columns

• General - general information about a statement. This section includes the following fields:
  • ID - identifier of the statement
  • Create Date - date when the statement was generated.
  • Start Date - beginning of a period, for which the statement was generated.
  • End Date - end of a period, for which the statement was generated.

The start/end date for a deposit statement is defined as follows:

• When the first deposit statement is generated for a merchant, the start date is the first day the merchant began processing transactions (under the condition of remittance to be).
• A deposit statement is generated only under the condition that the merchant has had transaction activity. The statement covers the period from the end date of the last statement to the moment of generation for the current one.
• The end date of the previous statement is the start date of the next statement.
• On weekends and holidays, deposit statements are not generated, because on these days banks don’t operate or transfer money between accounts. Therefore, start/end dates can only be a business day.
• If the Positive Only mode is selected in the remittance settings for generating deposit statements, and there are no successful sales transactions in the transaction selection that the statement is based on, a deposit statement is not generated. Negative transactions (chargebacks/returns/refunds) are included in the next statement generated for a positive balance. The date of the generation will be the start date of both sales and chargebacks/returns/refunds.

The start/end date for a reconciliation statement is defined as follows:

• Reconciliation statements are generated regardless of the merchant's activity. The statement covers the period from the end of the last statement to the moment of generation of the current one.
• Start/end dates depend on the configured remittance cycle. The start date of the statement is the cycle remittance date, and the end date is the day preceding the cycle remittance date.

• Status - status of a statement. May be one of the following:
  • Pending - statement is waiting for manual approval. Note that you can apply adjustments only for statements with a status of Pending.
  • Approved – statement is approved and, if there are any adjustments, is waiting for adjustments to be applied. Usually, statements with an Approved status are not displayed on the user interface.
  • Canceled - statement is canceled; all the information from this statement will be included in the next generated statement.
  • Adjusted – statement is approved, adjusted and ready to be submitted to the bank.
  • Posted – statement is submitted to the bank.

• Reconciliation State - status of the statement’s reconciliation between the gateway and a processor. The mechanism is only available for Vantiv Lowell.
  • Auto Verified – the gateway has checked the statement with the processor’s report, and there are no discrepancies.
  • Mismatch – the gateway has checked the statement with the processor’s report, and there are some discrepancies.
  • Verified - reconciliation was performed manually by a user after receiving a mismatch notice, the discrepancies are checked and are now absent.
  • Unverified - no reconciliation was made.

• Reconciled By - name of the user who made a reconciliation. If reconciliation was automatic, then the name is system. If it was performed manually, then the name is the username of a user.
• Note – user’s note added when either a wire or manual reconciliation is being made.
• User - user that managed the statement.
  • Approver - user who confirmed/canceled the statement. If approval/cancellation was made after manual review, the approver’s name is a user’s name. If approval/cancellation was made automatically, the approver’s name is system.
  • Remitter - user who submitted remittance data to a bank. If the gateway submitted remittance data, the remitter’s name is system. If a wire transfer took place, the remitter’s name is a user’s name.