One argument that is often made in discussions around the design of payment systems is that “a payment is a payment”. The implication being that a single payment engine should be able to handle all payments, while giving big scale benefits.
I am not so sure. Yes, at the end of the day each payment involves the transfer of money from one account to another. But I would argue that a payment includes more than that. It includes a number of aspects that can differ by payment
Finality. How irrevocable is a payment? Most direct debits, for example, can be revoked by the payor for a number of weeks. In addition, many countries have a zero hour rule, which means that if a company goes bust during the day all commitments made earlier during that day are wound back. Hence its credit transfers are not final. For that reasons many RTGS systems generally required a legal change exempting RTGS payments form this zero-hour rule, making them truly final and irrevocable.
Remittance information. The transfer of money is generally accompanied by some information to facilitate reconciliation by the payee and/or payor. This could be a simple reference to an invoice-number for example, but for corporate payments could include information around partial payments etc.
Foreign exchange. Many cross-border payments involve a currency component. This is often handled by the payment processor, although it can also be handled by others. In credit card payments, for example, it can be done by the bank of the payor (typically at standard rates set by Visa or MasterCard) or by the bank of the payee through a practice called direct currency conversion.
Compliance. Increasingly, payments are subject to rules regarding Know Your Customer (KYC), Anti-Money-Laundering (AML) and Sanctions restrictions. Payments processors have to check whether payments comply with these rules and regulations. And obviously these differ by type of payment: domestic versus international, large value versus small value, cash versus electronic (e.g. AML) and for international by countries involved (sanctions), etc.
Timeliness. Some payments require execution in seconds, for example at the point of sale (including online shopping), others tolerate delays of minutes or longer, for example salary and bill payments. Since many settlement systems are not real-time and or available 24/7, authorization is often separated from settlement.
Size. It may seem obvious, but in payments size matters. Large payments for example require liquidity: parties involved need to have sufficient funds in their account. The order of execution becomes important. This is why large value transfer systems have algorithms for optimizing the execution to use liquidity most efficiently. With large payments, exposure between initial authorization and settlement become important. In credit cards, for example, the merchant gets an approval in seconds, which allows him to receive the goods, but settlement takes place later. If the cardholder’s bank defaults in the meantime, either the merchant or his bank is exposed. For small payments this may be manageable, for larger payments it is a real risk.
These differences have implications for the design of systems. If a single system has to cater for all these differences the complexity costs will likely outweigh the scale benefits. Players may be better off with different systems for High value (e.g. RTGS), low value (ACH), point of sale (cards), etc. Instead of replacing than with a single new solution it is probably better to look for innovations within each of these.