By Chandan Mukherjee
PayCube Inc.
Over the past year, the aggregator model has gained prominence in the payment acquiring space. Organizations like Square Inc. have successfully leveraged the concept and extended it to their customer bases.
To fuel further growth, Visa Inc. launched the expanded framework for merchant aggregation in July 2011, thereby consolidating the role of payment service providers (PSPs) beyond e-commerce and into brick-and-mortar and mobile points of sale and services.
A merchant aggregation model allows PSPs to enroll and manage their merchants and present the transactions to acquiring processors as a single entity. This liberates the acquirer from managing merchants directly.
The PSP enrolls and manages the merchant. And many ISOs and payment gateways are now seeking to become PSPs, because this gives them greater flexibility in servicing their merchants.
So, what are some of the technology impacts that an ISO or a payment gateway must consider before moving to a PSP model? This article discusses several factors to carefully consider before charging ahead: risk assessment, transaction switching, funds settlement, and reporting and business intelligence.
Migrating an ISO or gateway to the PSP model necessitates a shift in risk models, which change as the PSP becomes liable for the risk profiles of its merchants. Likewise, acquirers will evaluate the PSP and its business for the appropriate risks.
The aggregator or PSP model means that acquirers will assess or scrutinize the risk of a PSP more thoroughly than it would the risk of any individual merchant. While the process of risk assessment for a PSP is relatively easier, it is surely different than assessing a merchant.
Acquirers are going to demand a whole set of documentation and will want to understand the nature of the merchants the PSP proposes to service.
Of course, the PSP model targets small merchants, who generally have higher risk profiles. Acquirers are under the limitations put forth by the card networks regarding the aggregator model, and these limits are narrow.
Certain merchant category codes are not eligible for the aggregator model. Furthermore, monetary limits of about $100,000 in annual sales per merchant are imposed. A PSP is allowed to do its own merchant funding, as long as its annual volume remains below $50 million.
The PSP will be required to obtain a merchant identification number (MID) for identifying all of its transactions. (And perhaps that MID should be called PSP ID.) This MID is assigned by the acquirer as part of boarding the PSP. A review of the PSP, its target merchant segment and its types of transactions will eventually get the PSP an MID.
In addition, the gateway must generate its own MID for every merchant it boards. This process, which may already exist in some gateway implementations as a way of identifying the merchant for internal systems and reports, now has to be expanded for use with transactions that come into the gateway from merchant systems.
An internal translator table is required in all gateways to switch code to map the gateway-generated MID to its processor MID in request messages, and back to the gateway-generated MID in response messages.
The gateways must create velocity-based systems that trigger alerts when merchants approach their annual limits, as defined under the PSP program by the networks and the acquirers.
As mentioned above, the gateway will do better to deny or reject transactions with invalid or prohibited merchant category codes (MCCs) that are submitted. The MCC prohibition tables are likely to be updated periodically, and the systems will have to be capable of handling that.
Generally speaking, ISOs get paid via residuals, while gateways are paid from the monthly service fees. The actual settlements for goods and services are transferred from acquirers' bank accounts directly to merchant banks.
This area will see some changes. In most cases, acquirers will settle with a settlement entity, as defined using the MID. Since a PSP has its own MID and shields all its merchants from the acquirer, the acquirer settles with the PSP.
The funds received by the PSP will be disbursed by the PSP into individual merchant accounts. Most ISOs or
gateways do not have systems for this; creating such a system is perhaps the most important and critical change an aspiring ISO or gateway must consider before becoming a PSP. Hundreds of third-party companies provide settlement services and engines. If an ISO or gateway is not prepared to handle settlement in-house, it can consider using third-party settlement services for the initial running of its PSP business.
Today, data is a valuable asset that every company generates in the course of doing business. The natural product of our reporting and information-warehousing databases, business intelligence is manifested in the reports and dashboards we use to get snapshots of our businesses at points in time.
This area of the ISO/gateway business will be greatly affected during a transition to a PSP model. Most ISOs have reporting capabilities that show the residuals and transaction volumes. But these reports are generally driven off the data that acquirers provide to ISOs and gateways.
Merchants also have accounts through acquirer-created merchant portals for a variety of reports. An ISO/gateway will have to recreate this merchant portal inside its systems and provide the same level of data access to its merchants in the aggregation pool. Merchants' need for data will not change due to migration from a direct acquirer relationship to a PSP. These should be provided by the PSP to all of its merchants.
A gateway or ISO will have to make a number of critical changes during the migration to becoming a PSP. Some of these changes will consume both time and resources. But knowing what changes to the infrastructure will be required allows for better understanding of the PSP business model and better prepares the ISO/gateway for the process.
Chandan Mukherjee is the co-founder of PayCube Inc., a San Francisco Bay Area-based payment consulting and IT services company providing custom software solutions and custom gateways for acquirers, ISOs, retailers and varied organizations in the world of payments and consumer transactions, including prepaid and gift card program, loyalty and promotion, payment start-up, POS solution, mobile payment and e-commerce players. PayCube uses a blend of on-site and offshore delivery capabilities, with a staff of retail and payments-focused software engineers, systems architects, project managers, tech leads and systems analysts. For more information, email cm@paycubeinc.com, call 510-545-6854 or visit www.paycubeinc.com.
The Green Sheet Inc. is now a proud affiliate of Bankcard Life, a premier community that provides industry-leading training and resources for payment professionals. Click here for more information.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.
Prev Next
