Whenever we talk about Payments, we often think off what I perceive as the “Front-End” part of Payments. The Gateway, which is the way the way that merchants integrate and are able to accept payments or the User Interface where we are able to see which transactions have been processed and some analytics. But on the “Back-End”, the part that merchants never get to see, a PSP has to be able to perform several crucial components to ensure that everything runs smoothly. From the Integrations into Acquirers and Alternative Payment Methods, to Fraud Solutions, but maybe most importantly the Billing & Settlements.
The Billing and Settlement Process is how a Payment Service Provider retrieves the settlements that have been submitted to the Acquirer, calculates the fees, generates the invoices and statements, and finally pays out the merchants.
Current Situation
Discussing Billing & Settlements with mostly large incumbent Payments companies, confirms that a change is needed. As with many older companies who were providing services before the age of cloud computing and API’s, most of them have build a Financial Operation based out of multiple separated data sources that contain a piece of the data needed to provide the information users are looking for. This data consists out of financial data (e.g. Transaction Amount, Fees, etc.) as well as non-financial transactional data (Merchant ID, Issuer Country etc.).
Looking at a typical large Payment company, which processes millions of transactions on a daily basis, the steps would look as followed:
- The Gateway provided by the Payments Service Provider (PSP) is integrated with a Merchant and processes Cards as well as Alternative Transactions.
- Processed Transactions are handed off to a Third-Party Acquirer (or Acquirer Processor), which is integrated with the actual Card Schemes or Alternative Payment Methods, which can lead to an Authorization or Decline.
- Authorized Transactions are either directly submitted for Settlement or based on the input of the Merchant/PSP by the Acquirer.
- Settled Transactions are collected and the Data (status, amount, fees, etc.) are provided in large CSV or XML files to the PSP.
- The PSP uses the Data from the original Authorized Transactions and matches the Data with the received Settlement Files.
- Using large spreadsheets which contain the Settled Transactions per Merchant together with Fee Contract information are used to calculate fees that need to be applied.
- With an overview of the Aggregated Settled Amounts and the Calculated Fees the Data is used to create the Invoices and provide the Amounts that need to be Paid Out to the Merchants (Remittance).
- As a final step of the Financial Operations Process, Risk Exposure is applied by checking for each merchant if any Rolling Reserves, Delayed Remittance, Collateral or Bank Guarantees need to be taken into account.
- The Funds are Transferred from the PSP Bank Account (if Collecting, an order to Transfer is submitted to the Acquirer if not Collecting) to the Merchants Bank Account
Like most processes that use multiple sources of data (Gateway Transactions, Settlements, Spreadsheets, Pivot Tables, Fee Contracts etc.), which also involve manual involvement, the likelihood of errors increases with each new data source, each manual step and especially bringing everything back together. This can lead to miscalculations in Processed Revenue, Transactions, Fees and eventually Remittance, which for any company that is expecting their Payments to be handled perfectly can be very frustrating.
Having worked in an International Payments company, which focused on large enterprise companies, I was fortunate enough to experience the impact of each one of these components and especially figuring out how to improve them. From building Business Intelligence to provide accurate and reliable information on Processed Revenue, Transactions as well as creating a framework to calculate Fees as complex as Interchange and Scheme Fees. So when I got the opportunity to build a White-label Billing & Settlement Engine from the ground up I knew exactly the impact it could have on both starting as well as established Payments companies.
Dimebox Billing & Settlement Engine
What is the Billing & Settlement Engine?
The Billing and Settlement Engine, provides PSP (Payment Service Providers) and Acquirers with a fully integrated solution to retrieve settlements, display statements, bill fees, generate invoices and administer payout clients for transactions, refunds, chargebacks and additional services, all controlled and configurable within the Dimebox UI.
For each transaction that has been processed through the Dimebox API, either connected to a Third-Party Processor or an Acquirer using the Dimebox Card Processor, the Billing & Settlement Engine stores the Settlement Data, Fee Data and applies Fee Contract Logic to calculate Fees, create Settlement Overviews, Statements, Invoices and a Merchant Funding Overview.
What are the features of the Billing and Settlement Engine?
Fee Contract
Create Fee Contracts and apply fees to each transaction, based on the payment method, the acquisition mode or status.
Settlements
Review the Settled transaction in a day-to-day overview broken down by processor.
Invoices
Invoices are generated daily to provide an overview of the applied fees, settled funds and to be expected payout.
Statements
The Statements provide an aggregate of the financial data of the day, including net settlements, sales, transactions and the fees associated.
Merchant Funding
As a PSP the Merchant Funding provides an overview of the amounts that need to be paid out to the merchants, including rolling reserves and accrues.
How does the Billing and Settlement Engine work?
The Billing & Settlement Engine, is connected to the Dimebox Gateway, to provide PSPs and Acquirers with the ability to have a fully integrated Financial Reconciliation tool. Even though transactions are processed, by one or more processors, it is the PSP, who controls which fees are billed to the Merchant. Having full control over the Invoice, Statements and Settlement overviews, all consolidated to fit the Merchants expectations.
Third Party Processor Transaction Data regarding Interchange, Scheme Fees and Settlements are stored in our database. This gives us the ability to join together multiple processor fee data.
Based on the Fee Contract that has been created through the UI, the final fees are calculated.
For example: An Interchange++ Fee Contract, collects the applied interchange and scheme fees, but uses the configured Acquirer Markup to calculate the Acquirer Markup Fee, based on the Settlement Result Data.
The Calculated fees are stored based on their type in a new database. Each transaction connects the fees through a Primary Key (i.e. ID). This gives us the ability to aggregate settlements, deduct the interchange, scheme fees and commissions. We are able to provide Statements, based on the Aggregated Settlements. And finally, we can generate Invoices on a Daily, Weekly, Bi-Weekly or Monthly basis.
Dimebox has been acquired by Verifone in December 2018.