Home > Guides

Guide Contents

Remittance Management Guide v1.13

Added on:  11/13/17     Updated on:  03/21/24
Table of Contents

Introduction


The purpose of this guide is to explain the concept of funding and remittance, how remittance works in the gateway and what configuration options are available to meet different needs.

Intended Audience


This guide will be useful for the PSPs and software platforms that are going to become or already are payment facilitators and provide remittance for their merchants using the gateway functionality.

Overview


Traditionally, a major part of the work on providing the opportunity for merchants to process credit card transactions was carried out by processors/acquirers. In addition to transaction processing, the processors/acquirers issued accounts, which involved complicated and bureaucratic procedures. They also provided ongoing management. Partially, these responsibilities were facilitated by Value-Added resellers (VARs). VARs specialized in a specific software for allowing merchants to process transactions. However, as the merchant industry developed, the software got complicated, and the number of those who wanted to process transactions increased. As a result, the number of problems dealing with the performance of the processors/acquirers increased.
To resolve these problems, VARs needed greater control over the process of underwriting and ongoing management. To ensure this control, the processors/acquirers needed to facilitate the underwriting process and delegate the ongoing management to an entity closer to merchant. Thus, a payment facilitator concept appeared with the role of taking responsibility for merchant underwriting, associated risks (chargebacks, returns, etc.) and ongoing management.
Since a payment facilitator is responsible for merchant underwriting and associated risks, the need for a meticulous check of a merchant’s background by a processor has disappeared. As a result, the underwriting process has been simplified. And since payment facilitators took responsibility for the ongoing management process, merchants have gotten greater support around the funding process. Merchants now receive transparent control over the remittance process and the possibility to use advanced functionality, including, for example, split payments.

Real World Context


Funding - a business process determining funds transfer to a merchant for the transactions processed over a certain period of time. Within the gateway, funding is implemented through the remittance mechanism.  
 
The funding/remittance process can involve the following participants:
 
Merchant - a company/person processing transactions either through a software platform or gateway and receiving the processed funds as a result of the remittance process. Within the gateway, a merchant is represented as a separate entity called merchant.  
Merchants are divided into the following types:
     
    • High-processing frequency  - a group of merchants processing transactions with high frequency, which means transaction processing on daily basis, several times a day and with a minimum interval.
    • Low-processing frequency - a group of merchants processing transactions with low frequency, which means transaction processing once or twice per month with a big interval.  
Affiliate - a company/person that is a partner of the merchant and receives commissions for promoting its products/services via blogs, portals, websites and similar mechanisms. Within the gateway, an affiliate is represented as a separate entity called affiliate.
Software platform - software integrated with the gateway and through which a merchant processes transactions. To allow for transaction processing, the gateway issues accounts to the clients of the software platform. A software platform is represented as a reseller within the gateway bringing clients to it.  For providing its services as a reseller, a software platform normally receives commissions – that is, part of the fees collected from its merchants.
Payment facilitator - a PSP, which does transaction processing and remittance.  To do remittance, a PSP receives to its account the funds processed by a merchant from a processor and aggregates merchants under its account. To be in a position to receive the funds and perform merchant aggregation, the PSP takes responsibility for the risk of a possible negative balance of any of its merchants from returns and chargebacks. Within the gateway, a payment facilitator is represented as a separate entity called portfolio.
Acquirer - a bank that issues accounts either directly to the merchants or through a PSP and does funding to the payment facilitator.
Processor - a company serving as a technical platform for an acquirer and processing transactions, which means performing authorizations for card brands and further technical settlement.
Gateway - a service based on the software used to facilitate communication with an acquirer and processor. The gateway receives payment messages through the advanced API and converts them into more complicated messages for various acquirers and processors.

Settlement of payments between the participants of funding/remittance can be done as follows:
Fee - an amount withheld by the payment facilitator from a merchant as a processing cost. Fees can be withheld either as a deduction or withdrawal:
    • Deduction implies that the fees are collected during the process of depositing.  

    • Withdrawal implies that the fees are collected as a separate transaction, on a given day of a month, after the funds has been deposited.

Commissions - a part of the fees that a payments facilitator shares with a software platform for its assistance in management of the merchants that process transactions via the software platform.

Use Case

There are 2 classical variants of remittance. We will use the following parameters in the examples below:
  • 5 percent processing cost 

  • 48-hour funding period


1. Risk minimization (payment facilitator wants to receive its fees in the shortest term possible and with minimum risk)


Merchant A processes $100 on Monday, wants to have the funds processed on Wednesday and a payment facilitator wants to transfer the funds to Merchant A, net of fees.  During transaction processing with deduction funding policy set, $5 is deducted from $100 as a processing fee and goes to the payment facilitator. As a result of the remittance process, $95 is transferred to Merchant A on Wednesday as a net amount.

2. Reconciliation simplification (payment facilitator wants to facilitate the reconciliation process for a merchant realizing that there is a risk of not receiving its fees)

Merchant B processes $100 on Monday, wants to have funds processed on Wednesday and a payment facilitator wants to transfer the funds to Merchant B in order to facilitate the reconciliation process for the merchant even though there is a risk of not receiving its fees.  After transaction processing and as a result of remittance with withdrawal funding policy set, $100 is transferred to Merchant B on Wednesday as a gross amount. The $5 processing fee is withdrawn as a separate transaction at the beginning of the next month.

Gateway Context

Remittance - a process that occurs after transactions have been processed and the funds have been received by a payment facilitator. As a result of this process, the gateway calculates what amount is going to be received by the merchant. After calculated, money is transferred to the merchant’s deposit account.
To configure remittance, it is necessary to understand how the following concepts work:
Remitter - a type of merchant with an account that contains the settings for connection with a bank and the account that is used for the remittance process.
Statement is a document given to a merchant or reseller providing a detailed breakdown of the merchant’s/reseller’s revenue received and different types of fees charged. Statements are divided into two principal categories – merchant statements and reseller statements.
Merchant statement is a summary of merchant’s activity over a certain period of time. It provides the information about a number of the processed transactions, splits, fees and charges collected and adjustments applied.
Merchant statements can be of two types - deposit statement 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. Basically, deposit statement enables merchant to understand the deposits in their bank account that result from transaction processing.
  • Merchant reconciliation statement - a summary statement that explains merchant’s remittance activity and shows all of the associated processing fees over a defined time period, usually a month. Basically, reconciliation statement helps a merchant understand what merchant fees are charged and why.
Reseller statement - a summary of reseller’s activity over a certain period of time, providing an aggregated view of the commissions and payments collected for the charges processed on behalf of a reseller, and any possible deductions caused by minimum fees requirements across all merchants within a reseller’s portfolio with the ability to drill through the existing statements.

Remittance Life Cycle


Remittance has its own life cycle which is different for a merchant/affiliate and a reseller. Let's review both these processes in detail.

Merchant/Affiliate Remittance Life Cycle


Remittance is a process that is done separately from transaction processing. It occurs not right away after a transaction has been processed, but after settlement is done on a processor’s side. As a result of this process, funds are transferred to the merchant from the account of the payment facilitator. Consequently, until the moment of the actual transfer, merchant funds are kept on the PSP’s account for some time. To understand how merchant/affiliate remittance is done, let’s review the diagram below representing the remittance process step-by-step.



  • Transactions are processed. Transactions are processed by the merchant through the gateway. The transactions are considered as ready for funding after settlement is done on a bank’s side.
  • Settlement is done. The transactions are ready to be funded to the payment facilitator. Consequently, the payment facilitator should prepare for remittance, which means that the data should go through pre-processing on the gateway’s side for a subsequent statement generation.
  • Money is transferred to the payment facilitator’s account. The funds for the processed transactions are transferred from an acquirer to the payment facilitator’s account.

  • Transactional data is prepared for remittance. The data has been prepared for statement generation. A merchant statement is generated based on the statistics. The statistics are calculated once per day, after the transactions have been settled on the bank’s side. The funds are transferred to the merchant after being transferred to the payment facilitator’s account. 

  • Merchant statements are generated. The processed transactions go on the merchant statement the next day at the earliest depending on the settings of remittance period. Transactions go on the merchant statement the next day under the condition of being made before a cut-off time on the bank’s side. Once a statement is generated, it is put on review.

Note that statement won't be generated for a merchant account if there is any unconfirmed (pending) statement associated with this account.
  • Merchant statement is generated.  A merchant statement is represented as a summary of all the transactions processed over a certain period of time, particularly the number of transactions processed, adjustments, processing and monthly fees, etc. 

  • Split payments balance is calculated. The funds are distributed as a result of the split transactions.

  • Merchant statements are reviewed/approved. The payment facilitator does internal reconciliation of the transactions included in the statement. If reconciliation is completed successfully, the payment facilitator approves the statement. Once the statement is approved, a transaction is generated and gets included in the remittance file, which is subsequently submitted to the bank.
Note that both deposit and reconciliation statements will be approved automatically if the Statement Review is disabled in Remittance settings.
  • Remittance file is generated. The transactions processed over a day go in the direct debit remittance file, which is submitted to the bank of the payment facilitator by the end of a banking day.
  • Remittance transactions are submitted to the bank.  The gateway submits a direct debit remittance file to the bank. To submit a remittance file to the bank, a remitter’s settings are used. The remittance file is actually processed on the bank’s side.

  • Merchant statement is sent to the merchant by email. A statement is sent to the merchant’s email so the merchant can know how much funds are going to be received as a result of remittance and how much is paid for transaction processing.

  • Merchant funds are received. The funds are deposited to the merchant’s account.

Reseller Remittance Life Cycle


Reseller remittance is done separately from transaction processing and merchant/affiliate remittance. Funds are transferred to a reseller from a payment facilitator's account once per month. To understand how merchant/affiliate remittance is done, let’s review the diagram below representing the remittance process step-by-step.


  • Current processing month is closed. The month-end closing process takes place at the end of the calendar month. For the remittance process to be done, transactions go through pre-processing on the gateway’s side.
  • Merchant statement data is prepared for commissions calculation. The data has been prepared for reseller statement generation.  A reseller statement will be generated based on the statistics.
  • Reseller statements are generated. The reseller statement shows a summary and calculation of reseller commissions. Once a reseller statement is generated, it is put on review.    

  • Reseller statements are reviewed/approved. The payment facilitator does internal reconciliation of the transactions included in the statement. If reconciliation is completed successfully, the payment facilitator approves the statement. Once the statement is approved, a transaction is generated and gets included in a remittance file, which is subsequently submitted to the bank.
Note that both deposit and reconciliation statements will be approved automatically if the Statement Review is disabled in Remittance settings.
  • Commissions remittance file is generated. Transactions go to a direct debit remittance file, which is submitted to the bank of the payment facilitator by the end of the banking day.

  • Remittance transactions are submitted to the bank. A remittance file is submitted to the bank. The remittance file is processed on the bank’s side and, as a result of this process, the funds are transferred to the reseller.
  • Reseller is funded. The commissions for the processed transactions are deposited to the reseller’s account.

General Remittance Configurations


There are two types of the remittance settings - general and individual. General settings allow to activate the remittance mechanism in the system and are applied to all merchants. Let’s review what general settings are available within the system and how to manage them in the section below.

Remitter


Skills

Be sure that you have familiarized yourself with the following tutorials:


To make bank transfers to merchants, a payment facilitator needs to have an entry point for the banking system. The entry point is a bank, which has to be integrated with the gateway. For the subsequent funds distribution between the merchants to occur, a file with corresponding transactions must be submitted to the bank. These transactions are actually the remittance instructions specifying the merchant and an amount it is supposed to receive.

To submit these instructions, the settings providing for communication with the bank should be set within the gateway. The settings and an account where funds are transferred by a processor/acquirer and which is used by the payment facilitator for remittance are configured on a remitter. The remitter configuration enables remittance within the gateway, so remittance configuration should start with the remitter configuration. The number of remitters available within the system depends on the number of banking systems the payment facilitator works with.

Use case
 
The payment facilitator PaySolutions processes transactions in the USA. The USA has its own banking system, Fedwire. To connect with the banking system, the payment facilitator needs to have an entry point. To allow for this, PaySolutions gets integrated with the bank X. It also creates a remitter within the gateway, which contains settings providing for communication with the bank X and the details of an account through which the payment facilitator receives processed funds of the merchants from the processor/acquirer Y. To ensure that funds are transferred to the merchants by the bank X, the payment facilitator submits remittance instructions to the bank in the form of direct debit transactions.  After that, the merchants receive their funds.
Later, PaySolutions decides to process transactions in Italy and Spain. These countries have their own banking system, different from the one in the USA. For this reason, a different entry point should be used for communication between the gateway and the banking system. Since these countries belong to the Eurozone, which has its own banking system - SEPA, operating throughout the territory, the payment facilitator does not require more than one entry point. So, PaySolutions integrates with the European bank Z, through which merchants will receive their processed funds following the scheme outlined above.  
 
Remittance transactions, sent by a remitter to a bank, have descriptors that include information about who initiates the transaction (a name of the remitter) and who is going to receive the funds after remittance is done (a name of the merchant). The length of the descriptor is required to correspond to the NACHA format, which is 25 characters: 15 characters for a remitter’s name (specified within the Company Name field in the processing profile) and 10 characters for a merchant/account’s name (specified within the Description field in the processing profile) . As merchants’ names may be longer, the gateway automatically removes all spaces from the merchant’s name in the descriptor. For example, a descriptor is MYREMITTERSUPERSHOP, where MYREMITTER is a name of the remitter and SUPERSHOP is a name of the merchant, which is going to receive funds as a result of the remittance process.

Note that funding, billing, and processing configurations (limits, convenience fees, pre-processing and post-processing rules) are not available for merchants of remitter type.


Remittance Source


Skills

Be sure that you have familiarized yourself with the following tutorials:

Some processors that have a relationship with a certain bank can deposit funds for processed transactions faster to the account of a payment facilitator that uses this particular bank than to the account of a payment facilitator that uses different bank that a processor has no relationship with. As a result, there may be a situation when funds for processing particular payment types, for example, credit cards, are deposited to one account and funds for processing direct debit transactions are deposited to a different account. A payment facilitator’s account that is used for remittance is called a remittance source. If the payment facilitator processes different types of transactions via one or several processors and the processed funds are deposited to one account, it is enough to configure one remittance source under one remitter.  And if funds are deposited to different accounts, there are two possible scenarios:

1) Without gateway participation: money processed by a processor/acquirer should be transferred to one account via, for example, wire transfer and then remitted to the merchants.


Use case

Payment facilitator PaySolutions works with two processors, processor A and processor B. The processor A deposits the processed money to an account in bank X and the processor B deposits funds to an account in bank Y.  These accounts are used as remittance sources and funds are transferred to the merchants from them. But if for some reasons there is a need to do remittance from one account, for example from the account in bank Y, it is necessary to make a wire transfer of funds from bank X to the bank Y.

2) With gateway participation: there is a concept called remittance source within the gateway. It allows for specifying which payment type should be transferred from which remittance source. Remittance source is a bank account from which funds for specific types of transactions will be remitted. Gateway supports four types of remittance sources: direct debit deposits, credit and debit card deposits, American Express deposits and commission remittances.
The last two digits of the remitter’s account number must coincide with the remitter source code:
  • 01 - АСН
  • 02 - ВС (Bank cards)
  • 03 - Amex
  • 04 - Commissions
  • 11 - ACH withdrawal
  • 12 - ВС withdrawal
  • 13 - Amex withdrawal



Example:
Merchant ID = 9000. If the remitter deposits funds to ACH account, it account number will be ID = 9001.
If remitter deposits funds to BC (Bank cards), its account number will be ID = 9002.
If remitter deposits funds to American Express deposits, its account number will be ID = 9003.
If remitter deposits funds to Commission deposits, its account number wiil be = 9004.

The decimal digit (account numbers ending with 11 and above) indicates that the current account can process withdrawals.

In case the remitter is going to deposit transactions of all types to a single bank account, you can enable Ignore Source checkbox on the Remittance Form.



Use case

Payment facilitator PaySolutions works with processor B. This processor deposits funds from credit card transactions to an account in bank X, and funds from direct debit transactions are deposited to an account in bank Y. PaySolutions specifies both accounts (X and Y) as two separate remittance sources within the gateway. Thus, funds for processed transactions are transferred to the merchants as two separate deposits coming from separate accounts.    

Note that it is easier for merchants to do reconciliation when money is received in one deposit within a given period of time. Reconciliation is more difficult if the amount processed on a certain day is split into several deposits. And if these deposits are transferred on different days, it is the most complicated scenario for the reconciliation process. To learn more about the options for depositing and situations when each option is used, see Remittance Basis/Remittance Period section of this guide.

It is not recommended for merchants with high-processing frequency to receive split deposits or deposits on different days. Since the merchant processes a great number of transactions per day, there may be an overlap between the deposit dates and amounts of the processed transactions. This makes the reconciliation process more complicated because the merchant has to manually reconcile each amount deposited to their bank account.  

Use case

A merchant with high processing frequency that receives several deposits from separate remittance sources processes $100 on Monday. Once processed by a processor, $80 from the credit card transactions are received by the merchant on Wednesday. On Wednesday, the merchant processes another $100. On Friday, it receives $20 from the Amex transactions and $100 from the credit transactions processed on Wednesday. Thus, reconciliation becomes more complicated, since Monday’s processing total does not match with the amounts deposited on Wednesday and Friday. So, the merchant has to manually reconcile the records.

For merchants with low processing frequency, split deposits or deposits that are transferred on different days are not a problem. Since the merchant processes transactions on certain days of a month, there is no overlap in the deposit dates and amounts of the processed transactions. Moreover, if the merchant knows the account that funds have been deposited from, the reconciliation process is simplified to a large extent.

Use case 


A merchant with low processing frequency that receives several deposits from several separate remittance sources processes batch transactions two times per month: every first and fifteenth day of a month. On Monday, the first day of the month, the merchant processes $100. On Wednesday, the merchant receives $80 from the credit card transactions and on Friday the merchant received $20 from Amex transactions. Thus, it is not a problem for the merchant to sum up two amounts ($80+$20) and reconcile the amount received with Monday’s processing total. 


If a merchant accepts both ACH and Payment card payments, the funds can be deposited in either of the two ways for Remittance:
- merchant can deposit ACH and credit card payments to two separate bank accounts and track two balances;
- merchant can deposit all payments from different sources to a single bank account.

Ignore Source parameter on the Merchant Perspective/Details/Funding/Settings/Remittance form is used to configure how the funds are deposited:
  • if the parameter is enabled, the ACH and Payment card payments are accumulated in the same account (first merchant’s account).
  • if the parameter is disabled, the ACH and Payment card payments are deposited in two separate accounts (first and second merchant’s accounts):

ACH Account Cards Account
ACH Balance Cards Balance
ACH Deposit Cards Deposit
ACH Processing Fees Cards Processing Fees
Return Reserves Chargeback Reserves
Returns Chargebacks/Reversals
Adjustments


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.
Use case
 
In the merchant’s remittance settings, the following values are set:
  • 5 percent processing cost
  • 48-hour funding period
 
The merchant, which is set to withhold fees as a deduction, processes $100 on Monday. On Wednesday, the merchant receives a deposit for $95. A total of $5 is withheld from the merchant’s deposit as a fee during the remittance process. When reconciliation is being done, the amount in the merchant’s bank account does not get aligned with 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.
Use case

In the merchant’s remittance settings, the following values are set:
  • 5 percent processing cost
  • 48-hour funding period
  • Remittance day: 1st of the month
  
A merchant, which is set to withhold fees as withdrawal, processes $100 on Monday. On Wednesday, it receives a $100 deposit to its account. When reconciliation is being done, the amount on the merchant’s bank statement gets aligned with the amount processed as per accounting records. A total of $5 is withheld as a fee via a separate transaction on the 1st of the subsequent month.  
 
In 40 days after the transaction has been processed, a chargeback for $100 is received. By that time, the merchant has no money in its account. As a result, the payment facilitator covers the amount of the chargeback and fees from its own funds.

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.
Recommendations
 
For low-risk merchants, it is recommended to use the withdrawal model for fees withholding. Since the merchant is presumed reliable, the payment facilitator does not have to worry about not getting its fees. For high-risk merchants, it is more reasonable and safer for the payment facilitator to choose the deduction model for fees withholding.


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


    Skills

    Be sure that you have familiarized yourself with the following concepts:
    • Withdrawal
    • Deduction
    To learn about these concepts, review Negative Balance Handling Modes section of this guide

    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:
    Use case

    In the merchant’s remittance settings, the following values are set:
    • 5 percent processing cost
    • 48-hour funding period
    • Demand-demand remittance model
     
    A merchant processes $200 on Monday. On Wednesday, it receives $190 from the payment facilitator as a result of the remittance process. A total of $10 is withheld as a fee during money depositing according to the deduction model. This complicates the merchant’s reconciliation because the amount that was processed as per accounting records does not align with the amount that was transferred as a result of remittance ($200$190).

    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:
    Use case

    In the merchant’s remittance settings, the following values are set:
    • 5 percent processing cost
    • 48-hour funding period
    • Demand-cycle remittance model
    • Remittance day - 1st of the month

    A merchant processes $200 on Monday. On Wednesday, it receives $200 from the payment facilitator as a result of the remittance process. A total of $10 will be withheld on the 1st of the next month as a fee according to the withdrawal model. The merchant will not have any problems with reconciliation because the amount that was processed as per accounting records aligns with the amount that was transferred as a result of remittance ($200=$200).

    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:

    Use case

    In the merchant’s remittance settings, the following values are set:
    • 5 percent processing cost
    • Cycle-cycle remittance model
    • Cycle-based funding (every 1st and 15th of the month)

    A merchant processes $200 on the 7th of the month. On the 15th of the month, it receives $190 from the payment facilitator. A total of $10 is withheld as a fee according to the deduction model at the moment of depositing. Thus, the merchant receives the processed funds in a week. However, it does not have issues with reconciliation. Since funds are deposited two times a month, doing reconciliation two times a month is not an issue for the merchant.

    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.

    Recommendations:

    1. When it comes to high-risk merchants, the demand-demand model is most commonly used. Thus, the payment facilitator avoids the risk of not receiving its fees.
    2. When it comes to low-risk merchants, the demand-сycle or cycle-cycle models are most commonly used and recommended. In these cases, the payment facilitator is not concerned about not receiving its fees since the merchant is reliable.
    3. The choice between the demand-cycle and cycle-cycle models depends on the merchant’s processing frequency. If the merchant processes transactions with high frequency, then the demand-cycle model is commonly used and recommended since funds availability is highly important for this kind of merchant. If the merchant processes transactions with low frequency, it is not an issue for the merchant to receive its funds once or twice a month.
    4. There can be cases when a payment facilitator needs to change a remittance model for a merchant. Regardless of the used remittance model, the switch can be done only on the last day of the month after all generated merchant statements are approved. If you change the model on the other day, this will affect remittance of the merchant with the possible loss of the data.


    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:


    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.

    Use case

    In the merchant’s remittance settings, the following values are set:

    • 5 percent processing fee
    • 48-hour funding

    On Monday, the merchant receives a direct debit return for $100. There was no transaction processing for the merchant on that day and the day after. On Wednesday, the merchant processes $200 that is going to be transferred as result of remittance.

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




    Remittance Basis/Remittance Period


    Skills

    Be sure that you have familiarized yourself with the following tutorials:
    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.

    Use case
    A payment facilitator receives funds from the direct debit transactions on Wednesday, and funds from Amex transactions are received on Thursday. The payment facilitator holds the funds from direct debit transactions in its account until the funds from Amex transactions are received, Thursday. Once funds from Amex are received, the payment facilitator transfers funds to the merchant via a single deposit, which includes funds from direct debit and Amex transactions.

    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.

    Use case
    A payment facilitator receives funds from the credit card transactions on Wednesday and funds from the Amex transactions on Thursday. The payment facilitator transfers funds from the credit cards transactions and Amex transactions to the merchant on Wednesday, pledging its own funds. On Thursday, when funds from Amex transactions are transferred to the account of the payment facilitator, it receives its funds from the processor/acquirer.

    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.

    Use case

    A payment facilitator receives funds from the direct debit transactions on Wednesday and funds from the Amex transactions on Thursday. The payment facilitator remits funds from the direct debit transactions on Wednesday and funds from the Amex transaction on Thursday. Thus, a merchant receives two deposits.

    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.

    • If there is a need to avoid multiple deposits, a response date remittance basis is often used and recommended.
    • If there is no need to avoid multiple deposits, a funding date remittance basis is a more convenient option.

    Deposit Period

    Skills

    Be sure that you have familiarized yourself with the following tutorials:

    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.

    Use case

    A payment facilitator which operates in the USA, receives $100 for the processed direct debit transactions from the processor to its account on Wednesday. The same day, a merchant statement is generated within the gateway. The statement is approved by the payment facilitator and a remittance file is generated. The file is submitted to the bank and is processed by the USA banking system in 1 day. Thus, a merchant receives its $100 on Thursday. The period from the time the remittance file is submitted to the bank until the $100 is actually deposited to the merchant’s account is the deposit period.

    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:

    Use case

    1. In the merchant’s remittance settings, the following values are set for the remittance period and deposit period:

    Remittance basis - response date (24-hour funding for DD/CC and Amex under the condition that OptBlue functionality is used)
    Deposit period - 1
    DD - 2
    CC - 2
    Amex - 2


    Once the merchant has processed the transactions, remittance is done within the following time frame:
    A merchant that has the remittance basis set as response date has processed $100 on Monday. Since the DD/CC/Amex fields are set as “2” and the remittance period is calculated from the response date, funds are transferred to the payment facilitator’s account in 24 hours after being processed, Tuesday. The same day, a merchant statement gets generated. After the payment facilitator approves the statement, a remittance file is generated and submitted to the bank. It is done one day before the actual depositing to the merchant’s account (deposit period). The next day, Wednesday, in two days after the response date, the funds will be in the merchant’s account.

    2. In the merchant’s remittance settings, the following values are set for the remittance period and deposit period:

    Remittance basis - funding date (24-hour funding for DD/CC; 72-hour funding for Amex under the condition that OptBlue functionality is not used)
    Deposit date - 1
    DD - 1
    CC - 1
    Amex - 1


    Once the merchant has processed the transaction, remittance is done within the following time frames:
    A merchant that has a remittance basis set as the funding date has processed $100 on Monday. This amount includes $40 from credit card transactions, $40 from direct debit transactions and $20 from Amex transactions. Since the processed credit card and direct debit transactions are funded in 24 hours and the remittance period is set as “1” and calculated from the date the funds are actually received by the payment facilitator from the processor, $80 from the credit card/direct debit transactions are deposited to the payment facilitator’s account on Tuesday. The same day, a merchant statement gets generated. After the payment facilitator approves the statement, a remittance file is generated and submitted to the bank. It is done one day before the actual depositing to the merchant’s account (deposit period). The next day, Wednesday, in two days after the funding date, $80 from credit cards/direct debit transactions is in the merchant’s account.

    Since processed Amex transactions are funded in 72 hours and the remittance period is set as “1” and calculated from the date the funds are actually received by the payment facilitator from the processor, $20 from the Amex transactions is deposited to the payment facilitator’s account in 72 hours (3 days), on Thursday. The same day, a merchant statement gets generated. After the payment facilitator approves the statement, a remittance file is generated and submitted to the bank. It is done one day before the actual depositing to the merchant’s account (deposit period). The next day, Friday, one day after the funding date, $20 is in the merchant’s account.

    Stuff You Should Know

    Depositing is made only on business days because banks don’t operate or transfer money between accounts on weekends and holidays. Keep this in mind when investigating issues with merchant funding being delayed.


    Deposit Information

    Skills

    Be sure that you have familiarized yourself with the following concepts:
    To learn about these concepts, review the Processing Cost Handling and Remittance Models sections of this guide

    Be sure that you have familiarized yourself with the following tutorials:

    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.


    When merchant deposit information is modified (either manually via the user interface or due to Notice Of Change (NOC) received from the merchant's bank), the administrator is notified about the changes via email.

    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.
    Use case

    Merchant A has processed $100. A total of $5 of the amount goes to the fees and $95 of the amount goes to the merchant as a net amount. Fees are withheld from Merchant A as a deduction during the remittance process. In this case, Merchant A is going to have problems with reconciliation because the transaction amount submitted for processing does not match with the amount deposited as a result of remittance.

    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.

    Use case

    Merchant B has processed $100. A total of $5 of this amount goes to fees that are withheld as withdrawal at the end of the month. In this case, reconciliation is simplified, because the amount submitted for processing is equal to the amount deposited as a result of remittance. At the end of the month, Merchant A balances its income and expenditure. But since it uses one account for income and expenditure, the process gets complicated.

    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.

    Use case

    A merchant has processed $100. A total of $5 of this amount goes to fees. Since the merchant works under the withdrawal model and uses a charge account, it receives $100 to its deposit account. The $5 will be withdrawn separately from its charge account as a fee.

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

    A merchant that processes transactions via a software platform has processed $100. From this amount, $5 is the fee for transaction processing and $5 for using the software platform. These fees are withheld by the software platform directly. For settling payment obligations with the gateway, a separate account is used. The account belongs to the software platform, and the payment facilitator withholds its fees from this account. As a result, the merchant receives $90 to its deposit account; the $5 processing fee is withheld from the software platform’s account by the gateway and the remaining $5 is left to the software platform as a fee for the use of its mechanism by the merchant.

    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.

    Use case

    Merchant A and Merchant B have processed $100 each. Each of them is required to pay a $5 processing fee and $10 for the received chargebacks. Since the corporate policy of Merchant A requires using a separate account for covering any negative balance (to simplify reconciliation) and Merchant B is not allowed to withdraw funds from a deposit account, each merchant receives $100 to their accounts. The $5 processing fee and $10 for the received chargebacks/returns will be withheld from their charge accounts accordingly.

    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

    Skills

    Be sure that you have familiarized yourself with the following tutorials:
    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.
    Use case
     
    A merchant that has reserves set as 5 percent of the profit received over a 30-day period has processed $10,000, and 5 percent of $10,000 is $500. Thus, the payment facilitator deducts $500 from the merchant and the amount goes to the reserves.

    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.
    Use case
     
    Merchant settings for chargebacks/returns reserves are set as follows:
    Minimum amount - $500
    Rate - 5 percent
    Period - 30 days

    a) A merchant processed $20,000 over a 30-day period. The system calculates 5 percent of $20,000, which is $1,000 ($20,000*5 percent=$1000). The amount, calculated as a percentage, is higher than the configured minimum amount ($1,000>$500). Thus, $1,000 goes to the reserve and is automatically populated in the Collected Amount field.

    b) A merchant processed $5,000 over a 30-day period. The system calculates 5 percent of $5,000, which is $250 ($5,000*5%=$250). The amount, calculated as a percentage, is less than the configured minimum amount ($250<$500). Thus, $500 goes to the reserve and is automatically populated in the Collected Amount field.  

    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.
    Use case

    1. Reserve is empty
     
    A merchant has “0” in the reserve (collected amount). The merchant is required to provide $400 to the reserve. Since there is no money reserved, the amount to be withheld equals the required amount. $400 is deducted from a current statement.

    2. Collected amount exceeds required amount
     
    A merchant keeps $500 in the reserve (collected amount). The processing volume of the merchant has decreased and the merchant is required to keep only $250 in the reserve (required amount). Since there is $500 in the reserve withheld as a collected amount over the previous month, the difference of $250 ($500 - $250 = $250) is provided to the merchant.

    3. Collected amount is less than required amount
     
    A merchant keeps $500 in the reserve (collected amount). The processing volume of the merchant has increased and the merchant is required to keep $1,000 in the reserve (required amount). Since there is $500 in the reserve withheld as a collected amount over the previous month, the difference of $500 ($1000 - $500 = $500) is withheld from the merchant.

    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.

    Use case
     
    A merchant that has a maximum amount for the refunds reserve set at $2,500 has refunded $1,800. The amount $1,800 is displayed in the Collected Amount field, and $700 ($2,500-$1,800=$700) is automatically populated in the Remaining Amount field. Then, the merchant attempts to issue a refund for $750. The system blocks this attempt because the total amount of refunds exceeds the limit ($750+ $1,800=$2,550 => $2,550>$2,500).  
       

    Amount Limits

    Skills

    Be sure that you have familiarized yourself with the following tutorials:
    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.  

    Use case
     
    A merchant that processes transactions in several countries has processed $10. The international cost of money transfer to the merchant’s bank account is $10. Thus, it makes no sense to transfer an amount that does not align with the cost of transfer. For that reason, a payment facilitator sets a Min Remittance field value as $100. As a result, an amount less than the one specified within the Min Remittance field is recorded to the merchant’s balance. When the amount across all statements reaches $100, the payment facilitator remits the amount to the merchant.

    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.

    Use case
     
    A merchant has processed $1,000, having $200 in reserve. As per the reserves setting, the system calculates that it is required to have $1,200 in reserve. For that reason, the full amount processed by the merchant should go to the reserve. However, the merchant has Max Withholding set as $500, so the system withholds $500 instead of the required $1,000. As a result, the merchant receives $500 as profit.

    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.

    Use case

    A merchant has processed $1,000, having $200 in reserve. As per the reserves setting, the system calculates that it is required to have $1,200 in reserve. For that reason, the full amount processed by the merchant must go to the reserve. However, the merchant has Max Reserve Adjustment set as $500, so the system doesn't approve the statement automatically allowing a payment facilitator to review the statement and adjust the amount of it, so the system withholds $500 instead of the required $1,000. As a result, the merchant receives $500 as profit.

    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.  
    Use case

    A merchant with a processing volume up to $1,000 has processed $10,000, which potentially raises suspicion of fraud. Since the merchant has the Max Statement value set as $1,200, the system puts the statement on manual review because the processed amount is higher than the amount specified within the field ($10,000>$1,200). Once the statement is approved by the payment facilitator, it is submitted to the bank.
     
    After some time, negative statements start to be generated. Negative statements are the statements that result from chargebacks and returns. Since the merchant has Min Statement value set as $100, the system puts all statements that do not reach this amount on manual review because the processed amount is less than the minimum specified within the field. Once the statement is approved, it is submitted to the bank.

    Fees

    Skills

    Be sure that you have familiarized yourself with the following tutorials:
    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.

    Use case
     
    The merchant works under the following terms:
     
    • 3 percent processing fee
    • 48-hour funding period
    • Demand-demand remittance model
     
    The merchant processes a $50 transaction on Monday. On Tuesday, a merchant statement gets generated. A total of $1.50 is withheld as a processing fee from the merchant and populated in a separate section of the merchant statement. The payment facilitator’s fees are included in this amount. On Wednesday, the merchant receives $48.50, net of fees ($50-$1.50=$48.50).

    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.

    Use case
     
    The merchant works under the following conditions:
     
    • 0.5 percent processing fees
    • $2.20 processing cost
    • 48-hour funding period
    • Demand-cycle remittance model: (remittance day is 1st of the month)
     
    The merchant processes a $100 transaction on Monday. On Tuesday, a merchant statement gets generated. On Wednesday, the merchant receives $100 to its account. The processor has reported that a total of $2.20 has been withheld as the processing cost. On the 1st of the subsequent month, both amounts, $2.20 and $0.50, are withheld as the processing cost and processing fee of the payment facilitator accordingly. Each amount is populated in separate sections of the statement.

    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:









    Pricing Model Processing Fee Structure Party Responsible for Processing Cost
    Fee Charged to Merсhant Reseller's Revenue Fee Charges by Payment Facilitator
    blended rate-blended rate 3% 0.50% 2.50% Payment Facilitator
    cost plus-cost plus cost+0.7% 0.20% cost+0.5% Merchant
    cost plus-blended rate 3% 2.5%-cost cost+0.5% Reseller

    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.
     
    Use case
     
    Merchant A processes a large number of small-value transactions. Merchant B processes a small number of large-value transactions. Both merchants have the remittance settings set as follows:
    Processing cost (either of the following options):
    a) $0.25 (per transaction)
    b) 5 percent
    c) 5 percent+$0.25
    48-hours funding
    demand-demand remittance model
     
    Merchant A processes 1,000 transactions for $2 each on Monday. The scenarios are the following:
     
    • If the merchant is charged a fee of $0.25 per transaction, it receives $1,750 on Wednesday. A total of $250 is withheld as a fee by the payment facilitator as a result of remittance.
    • If the merchant is charged a fee of 5 percent, it receives $1,900 on Wednesday. A total of $100 is withheld as a fee by the payment facilitator as a result of remittance. But for this amount, the payment facilitator pays $200 extra for the authorization of these transactions. Thus, the payment facilitator suffers a loss rather than getting any revenue ($100-$200=-$100).
    • If the merchant is charged a fee of 5 percent +$0.25, it receives $1,650 on Wednesday. A total of $350 is withheld as a fee by the payment facilitator as a result of remittance.
     
    Thus, a combination of a rate and per item fee proves to be the most cost-effective option for fees withholding for the payment facilitator. If the merchant processes a large number of small-value transactions, the largest part of the payment facilitator’s revenue is made up of fees collected per item.
     
    Merchant B process 5 transactions for $1,500 each on Monday. The scenarios are the following:

    • If the merchant is charged a fee of $0.25 per transaction, it receives $6,998 on Wednesday. A total of $1.25 is withheld as fees by the payment facilitator as a result of remittance.
    • If the merchant is charged a fee of 5 percent it receives $6,650 on Wednesday. A total of $351 is withheld as fees by the payment facilitator as a result of remittance.
    • If the merchant is charged a fee of 5 percent +$0.25, it receives $6,648. A total of $351 is withheld as fees by the payment facilitator as a result of remittance.
     
    Thus, a rate or a combination of a rate and per item fee proves to be the most-effective options for fees withholding for the payment facilitator. If the merchant process a small number of large-value transactions, the largest part of the payment facilitator’s revenue is made up by the fees collected as a rate.

    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


    Skills

    Be sure that you have familiarized yourself with the following concepts:
    • Blended Rate
    • Cost Plus
    To learn about these concepts, review the Processing Cost Handling section of this guide

    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.
    Use case
    The merchant started processing in April. The monthly recurring fee is applied with the delay period set in Remittance => Recurring Fees configurations.
    • if the delay period is "0", the monthly fee is included in the first merchant statement generated in April and charged in April accordingly.
    • if the delay period is "1", the monthly fee is included in the first merchant statement generated in May and charged in May accordingly.

    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:
    Recommendations

    1. After a merchant/account is deactivated within the gateway, the merchant-initiated transactions are no longer generated. However, it is not recommended to disable the merchant fees as it implies remittance deactivation. Remittance deactivation is not recommended at this time due to the following reasons:

    • The merchant has to cover the cost of the potential chargebacks/returns;
    • A payment facilitator has to pay processing cost to a processor if the merchant operates on a cycle-based model, which implies fees withholding at the end of the month;
    • If the payment facilitator works with a reseller, reseller’s commissions have to be paid.
    2. It is recommended to wait until a reconciliation statement is generated, in case the merchant operates on a cycle-based model. Additionally, it is recommended to wait for possible chargebacks/returns, which may be received within a 60-day period.
    3. If a merchant, operating on the demand-demand model is deactivated, it does not have positive activity, meaning that no merchant-initiated transactions are generated. However, chargebacks/returns may still be received. To ensure that deposit statements with negative transactions (chargebacks/returns) are generated, the statement policy is required to be set as “Any Balance” (link to “Statement” section)
    4. To disable recurring fees, a “0” is set as a value for the recurring fees settings.
    5. Once negative statements are no longer generated, merchant fees can be disabled.

    Annual Fees

    Skills

    Be sure that you have familiarized yourself with the following concepts:
        
    • Recurring fees
     
    Be sure that you have familiarized yourself with the following tutorials:
     

    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:

    Use case

    “Soft Ice Cream” is a company selling ice cream in parks during the summertime. It is a seasonal merchant that is going to process terminal transactions. To allow for this, the merchant needs a terminal. Let’s review the typical recurring fees settings for this type of merchant to better understand their use:
     
    • Setup fee ($60). Prior to terminal transaction processing, a series of calls are required to be made in order to explain how to use the terminal, and how transactions are going to be processed by a bank. Additionally, the initialization, shipment, and activation of the terminal are required. For providing these services, the payment facilitator charges a Setup fee (one-time recurring fee).
    • Processing fee (3%). The merchant is going to operate on the blended rate pricing model. To process sales, credits, and refunds, classic processing fees are applied.
    • Flat fee ($10/$5) which is charged when chargebacks/returns are received. Even though chargebacks/returns are unlikely for a business of this type, there is a certain risk that they may still occur. For that reason, the flat fee is set up.
    • Monthly fee ($5.99). Because the merchant is seasonal, there can be months of inactivity. For that reason, and to ensure that it is profitable for the payment facilitator to work with this merchant, maintaining its account, the monthly recurring fee is charged to the merchant.
    • Annual fee ($10). To help with PCI compliance, a merchant is charged the annual recurring fee.

    Since the merchant is just about to begin processing, its processing volume may be low. For that reason, there is a risk that the merchant would consider these fees to be too expensive with regard to the processing volume it initially operates with. Consequently, to make sure that the merchant will not cancel the service, the payment facilitator offers, as a marketing hook, not to charge the recurring fees immediately the following configuration and applies a delay period for each particular recurring fee type:
    • Setup fee: 1-month delay period
    • Monthly fee: 3-month delay period
    • Annual fee: 1-year period

    Association Fees


    Skills


    Be sure that you have familiarized yourself with the following concepts:

    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:





    Portfolio code Pricing template sequence number Pricing template code
    901 01 90101
    901 99 90199

    Taxes

    Skills

    Be sure that you have familiarized yourself with the following tutorials:

    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

    Skills

    Be sure that you have familiarized yourself with the following tutorial:
    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:










    Merchant Pricing Model Rate Amount Processed by the Merchant Fee Amount Owed to Payment Facilitator Reseller's Commission Rate Commission Amount Owed to Reseller Difference between Fees Amount and Reseller Commission Reasonable Minimum Amount
    Merchant A Blended Rate 3% $1000 $30 (1,000*3%) 30% $9 ($30*30%) $21 $40
    Merchant B Cost Plus cost+0.5% $5 (1,000*0.5%) 50% $2.50 ($0.5*50%) $2.50 $5

    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


    Skills

    Be sure that you have familiarized yourself with the following tutorials:

    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:

    Use case

    As agreed between the payment facilitator and reseller, the processing cost for the reseller (its buy rate) constitutes 2.5% and $0.1. The reseller offers to its merchants the processing cost at 4%. To avoid losses associated with unsuccessful authorizations on the merchants’ side and, at the same time, not withhold fees from the merchants, the reseller sets the decline processing fee as “0” and the buy rate as $0.1. Let’s review the calculation below:

    The payment facilitator works with the reseller on the following conditions:

    • Processing fee (charged to the merchant) = 4%
    • Buy rate (charged to the reseller) = 2.5% (rate) and $0.1 (per item)
    • Basis - residual
    • Commissions = 80%

    The merchant has processed 3 transactions for $1,000 and received 10 declines for $200. Thus:

    1. The processing fee charged to the merchant is calculated: ($1,000-$200)*4% = $32
    2. The buy rate amount is calculated (rate and per item):

    а) $32*2.5% = $0.8
    b) (0-0.1)*10 = $-1

    3. The residual amount is calculated: $32-$0.8 = $31.2
    4. The commission amount owed to the seller is calculated: $31.2 *80% = $24.96
    5. The decline fee amount withheld from the reseller is calculated: $-1*30% = $-0.3

    As a result:

    1. The payment facilitator receives: $7.34 ($32-$24.96+$0.3 = $7.34)
    2. The reseller receives: $24.66 ($24.96-$0.3 = $24.66)
    3. The merchant receives: $768 ($800-$32 = $768)

    As seen from the calculation above, the reseller not only covers the processing cost associated with the decline fee but also receives a profit at the expense of the 4% charged to the merchant. In other words, it is not a problem for the reseller to pay the decline fee ($0.3) out of the commission amount ($24.96).



    Commission Basis


    Skills

    Be sure that you have familiarized yourself with the following concepts:
    • Blended Rate
    • Cost Plus
    To learn about these concepts, review the Processing Cost Handling section of this guide

    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:


    Use case

    The payment facilitator works with the reseller on the following conditions:

    • Processing fee (charged to the merchant) = 3%
    • Buy rate (charged to the reseller) = 2.5%
    • Basis - residual
    • Commissions = 80%

    The merchant has processed $100. Thus, the commissions are calculated as follows:
    1. The fee amount is calculated from the transaction amount ($100*3%=$3)
    2. The buy rate amount is calculated ($100*2.5%=$2.5)
    3. The residual between the fee amount and the buy rate amount is calculated ($3-$2.5=$0.5)
    4. The commission amount is calculated ($0.5*80%=$0.4)

    As a result:
    1. The merchant receives $97 ($100-$3=$97)
    2. The payment facilitator receives $2.6 $3-$0.4= $2.6)
    3. The reseller receives $0.4


    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:

    Use case

    The payment facilitator works with the reseller on the following conditions:
    • Processing fee (charged to the merchant) = 5%
    • Buy rate = 0
    • Basis - total
    • Commissions = 30%

    The merchant has processed $100. Thus, the commissions are calculated as follows:
    1. A fee amount charged to the merchant is calculated (5%*$100 = $5).
    2. A commission amount is calculated ($5*30 = $1.5).

    As a result:
    1. The merchant receives: $95 ($100-5% = $95)
    2. The payment facilitator receives: $3.5 ($5-$1.5)
    3. The seller receives: $1.5

    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

    Skills

    Be sure that you have familiarized yourself with the following tutorials:
    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.

    Use case
     
    A reseller needs to collect a $2,000 charge from a merchant. The reseller submits information about the charge via the charge file. Within the reseller’s system the charge is assigned with a chargeCode “003845”. Once the charge has been collected from the merchant and a reseller statement has been generated, the reseller receives a processed file with payments (charge payments file). In this file, the reseller can see that $1,500 was withheld from the merchant instead of $2,000. The sequence number assigned to the $1,500 payment is “1” and the reseller sees $500 in the remaining amount field. In the subsequent charge payments file, the reseller sees that the missing $500 payment has been collected from the merchant. The reseller sees this by the chargeCode “003845” that is assigned, the sequence number that is “2” and the remaining amount that is “0”.

    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


    Skills

    Be sure that you have familiarized yourself with the following tutorials:
    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:

    Use case

    Input data for merchant remittance settings and split payments scenario looks as follows:

    • 5 percent processing fee
    • 48-hours funding period
    • Demand-demand remittance model
    • A total of $100 merchant owes to affiliate A
    • A total of $75 affiliate B owes to the merchant

    With regard to the conditions outlined above, let’s review the following three scenarios:

    1. The merchant receives enough funds to cover all expenses and receive its revenue.

    The merchant processes $1,000 on Monday. On Tuesday, a merchant statement gets generated. In the statement, the merchant sees:
    -$50 withheld as fees
    -$100 withheld as reserves
    -$200 withheld as charges
    -$100 split-out in favor of affiliate A
    +$75 split-in from affiliate B

    The merchant receives $625 as a result of remittance ($1,000-$50-$100-$200-$100+$75=$625) on Wednesday.

    2. The merchant receives the revenue under the condition that affiliate B pays off the debt.

    The merchant processes $300 on Monday. On Tuesday, a merchant statement gets generated. In the statement, the merchant sees:
    -$15 withheld as fees
    -$70 withheld as reserves
    -$130 withheld as charges
    -$100 split-out in favor of affiliate A and adjustment for +$15; - $15 is added to the merchant split balance.
    +$75 split-in from affiliate B and adjustment for -$15.

    The merchant receives $60 as a result of remittance ($75-$15=$60) on Wednesday.

    3. The merchant does not have enough funds to cover charges.

    The merchant processes $200 on Monday. On Tuesday, a merchant statement gets generated. In the statement, the merchant sees:
    -$10 withheld as fees
    -$60 withheld as reserves
    -$175 withheld as charges and adjustment for +$45; -$45 is added to the merchant split balance as a debt
    -$100 split-out in favor of affiliate A and adjustment for +$100; - $100 is added to the merchant split balance as a debt.
    +$75 split-in from affiliate B and the following adjustments:
    -$45 withheld as charges
    -$30 withheld in favor of affiliate A; +$70 as a debt owed to affiliate A

    -$70 is added to the merchant slit balance as a debt to affiliate A.

    Merchant Statement



    Skills

    Be sure that you have familiarized yourself with the following tutorials:


    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.