“I came across this portion of code and everyone avoids it, it’s called payments.”
-Joel Taylor, Where’s My Money? Presented at PaymentsFN 2020
The more I watch engineers present on payments, the more abundantly clear it becomes to me that engineers view payments not as a boring mystery but in fact, a super high-risk assignment. Thanks to more merchant engineers presenting on their experiences with payments, it’s clear how little anyone wants to touch the code associated with the function on first blush.
Before the flourishing of eCommerce marketplaces, merchants commonly transmitted their authorization requests through one service (a payment gateway) and initiated bank transfers out to vendors or sub-merchants through another service (a separate ERP gateway under the direct control of Treasury or Finance). Maintaining two separate payment services that each interacts with the outside world is risky and demands attention. To add further complexity, data generated from both services need to reconcile but the data from both may not even have a linking mechanism prior to reconciliation! That would be unacceptable for a marketplace configuration if it were to be made anew. Running pay-ins and pay-outs through the same service prevents three detrimental effects that payments can incur on a business:
- The risks and costs of maintaining multiple payment initiation services
- Inherent visibility issues born from maintaining multiple services
- Inhibited speed to market.
The risks and costs associated with maintaining a payments service are high because if something goes wrong or offline, funds can be irretrievably lost. A second service that handles payment requests increases the risk of failure. Robust tools and sophisticated notification systems can identify settlement files missing scheduled delivery, but that work requires engineers to build the technical reporting. Time and costs for technical reporting and maintenance will increase dependent on the number of systems that handle PCI data and initiate payment requests.
By conducting pay-ins and pay-outs from the service, you can greatly enhance reporting visibility and the timing of funds transfers. Because engineers are scarcer than access to capital there’s a limited number of payments projects that a merchant will undertake. Often times we find payments reconciliation to be a labor-intensive activity when it is cost-effective to automate. When the engineers aren’t available and because PayOps spends its time compiling reports, opportunities aren’t sufficiently investigated. If a merchant can capture the metadata of credits, debits, refunds, reversals, chargebacks, and Original Credit Transfers (OCTs) they generate in a single report then they can reconcile with external providers faster.
A good payments reporting environment is also a massive aid in minimizing FX risk. When the treasury department is dynamically aware of how much money is coming in and going out for a given currency, treasurers get to “net” pay-ins and pay-outs without any FX expenses and project their liquidity in near real-time. With such visibility, reducing revenue leakage by netting in foreign currencies becomes an easier task.
Speed to market can be a difficult concern to quantify. I personally like Nate Hilger’s position from How do Marketplaces Compete? The View from Stripe Connect. He polled the first two years worth of transaction data across the 212 online marketplaces within Stripe’s portfolio and concluded that:
While network effects do not appear to determine winners in these markets, we do find some evidence of first-mover advantage…. We reconcile these findings by documenting that first-mover advantage only affects platform revenue levels as opposed to growth rates.
In other words, the delivery date matters, but it isn’t the final word on a marketplace’s success. Launching a marketplace one month earlier in calendar time is worth an additional 7% of monthly revenue two years post-launch. But the key ingredient for success is a marketplace’s average revenue per seller. Why? When Hilger evaluated his model with month-over-month estimates for marketplaces with seller retention rates set 10% higher, he claims that those marketplaces will “exhibit 40% higher monthly revenue after two years.” Speed to market is valuable, but properly servicing the supplier side of a marketplace is critical.
***
One way to reduce the complexity of effectively servicing suppliers is using a single API to access one payment service for both pay-ins and pay-outs. The API should be able to handle multiple payment formats going in various directions. This approach achieves both speed to market and the necessary infrastructure to dynamically service clients.
Services like Cybersource unlock a lot of connections quickly, allowing its clients to transmit transactions going in and out. Smart implementation of either reduces the cost of duplicative integrations, simplifies maintenance, and reduces the surface area that can be attacked. Cybersource supports OCTs and eCheck credit through its Simple API or its SCMP API.
Spreedly, in addition to being able to send OCTs and eCheck transfers, also supports sending tokenized payment credentials to non-gateway PCI Level 1 compliant receivers through its Payment Method Distribution API. Receivers are any third party Spreedly’s client does business with, as long as the receiver is PCI Level 1 compliant themselves.
Both services give merchants a means of fast access to the market while reducing complexity that comes from interacting with a fluctuating ecosystem. To learn more about these companies download the full Payment Vendor Report here: http://paladinfraud.com/mrc-paladin-payment-report/.