WePay

Platform Payments 101

Your service connects buyers and sellers, and you want to learn more about payments. WePay's Platform Payments 101 is written to help you discover the realities of facilitating payments on your platform.

Chapter 6 Technical Complexities

Even before a platform or a payment facilitator has to worry about fraud, they have to figure out how to process payments from a technical perspective.

For developers, the act of processing payments has been relatively simple for quite some time. Payment-specific APIs have existed since before the advent of PayPal, though they’ve grown in sophistication and reliability over the past 15 years. Processing thousands of payments into one single merchant account isn’t very complicated. For a payment facilitator, it is routing thousands of payments to a variety of merchant accounts that introduces the real challenge.

Coding the Payments Stack

Ideally, a payments facilitator would only have to interact with one API: that of their payment gateway. Gateways exist specifically to reduce the number of technical endpoints that a processor is required to interact with. Instead of making API calls to every card-issuing bank, card association and ACH network, a payment facilitator can simply communicate with a gateway that will take responsibility for routing information to the appropriate institutions.

If a payment facilitator is interested in processing payments directly to their end merchants, a payment gateway’s basic offerings may not be sufficient.

Almost all payment gateways, however, are optimized to process credit cards into a single account. If a payment facilitator is interested in processing payments directly to their end merchants, a payment gateway’s basic offerings may not be sufficient. Here, the payment facilitator may have to make sure that these merchants can be uniquely identified within a higher-level financial network, which may involve registering (boarding) them with an acquiring bank. This would probably require integration with another API.

A good integration with these two APIs (payment gateway and acquiring bank) should allow a platform to process transactions and onboard merchants effectively. The question still remains, though – how should these transactions be redirected to the merchants themselves? For this problem, the platform will need to interact with a third API for merchant settlement.

When a merchant/user requests their money be withdrawn to their own bank account, the platform will need to send instructions to the bank where that merchant’s money is being held. This ‘on-behalf-of’ bank is not always the same thing as the acquiring bank. A payment facilitator may aggregate its merchants’ money in an account at a separate institution – this is an operational decision. Regardless, in order to withdraw on behalf of a merchant, the platform will need to send instructions to their aggregating bank and monitor the status of the withdrawal.

Accounting and Reconciliation Requirements

These overlapping API integrations present a huge back-office/accounting challenge to the payment facilitator. The key problem is one of reconciliation: at any given point of time, how do debits and credits balance out?

Even though a payment facilitator ‘only’ has to interact with a few APIs, money is arriving into its accounts from a variety of financial institutions. American Express, for example, operates its own network. When a platform charges an AmEx card, AmEx sends the money directly to that platform’s account via the AmEx network. Other card networks may settle their transactions through the payment facilitator’s acquiring bank. ACH payments may arrive through yet another channel.

The key problem is one of reconciliation: at any given point in time, how do debits and credits balance out?

Payments that arrive in a payment facilitator's account will probably belong to a various merchants. Small pieces of the payments, however, may belong to parties that assisted in facilitating the transaction. Card networks, acquiring banks and payment facilitators themselves all take a small slice of transactions. This practice is central to their business model. Standardizing how these small slices are taken is a huge headache for the facilitator. Should the card network ‘net-out’ their fees before the transactions arrive? Or should they charge the facilitator on a monthly basis?

When making this decision, a payment facilitator has to consider how they will eventually calculate their overall costs. This task is complicated by the fact that card networks and acquiring banks extract wildly different costs per payment. If a customer makes a purchase with a rewards credit card, for example, that per-payment cost will be much higher then if they make the same purchase with a simple debit card. The payment facilitator must keep track of these per payment differences in fees, and they must make sure the fees are withdrawn from the correct segment of their funds – funds that are by definition constantly being facilitated from payers to recipients.

Chargebacks once again make life difficult. As chargebacks and refunds are forcibly withdrawn from a payment facilitator’s accounts, the facilitator must choose how to fund those charges. In the process of fighting the chargeback, at what point should it be considered a loss and written-off? How can this loss be tracked effectively in order to better combat it? At a certain level, these fundamental questions become accounting problems as well.

Timing and Payment Failures

Because a payment facilitator takes responsibility for so much of the payments stack – the technology layers separating buyers and sellers – errors can arise from all kinds of interactions outside of their control. Payments can fail in dozens if not hundreds of different ways, including after a system has indicated one has succeeded.

Traditional gateways do little, if anything, to insulate a facilitator from this complexity. As a result, developing against a payment gateway means that much of a payment facilitator’s code exists to handle different error scenarios, rather than actually process payments. Building appropriate fail-safes takes much iteration to get right, and constant monitoring to ensure nothing new has come up.

Even the simplest credit card transaction involves three sets of API interactions: authorization, capture, and settlement. Authorization and capture are often built to fire simultaneously, but if a payment facilitator wants to analyze the transaction with its own proprietary risk systems, authorization/capture can be separated by a period of time. This means individual transactions are exposed to failures at three separate times during their life cycle.

Transactions are exposed to failures at three separate times during their life cycle.

Since the payment facilitator and/or platform assumes responsibility for communicating these failures to the user, it becomes a huge exercise in user experience design to do so effectively.

This challenge is compounded by additional questions – how much of the failure does the customer need to understand, and how much information would assist a malicious user? After all, fraudsters stand to gain from any piece of information that helps them design more effective attacks.

Ordinary Worries, Higher Stakes

Payment facilitators also have to worry about the same technological challenges that plague most internet companies: data integrity and connectivity in particular. When dealing with payments, however, the consequences of failures are always financial losses. These possibilities require the most stringent preventative measures.

Data integrity is particularly crucial to a payments facilitator because so many of its core functionalities (payment processing, merchant onboarding, etc.) involve reliance upon external APIs. This creates a data layering issue – a facilitator must track processes in both its proprietary data and also in data generated by its partners.

When settling funds to merchants, for example, a facilitator must record a withdrawal request within its own databases. Whether that request is ultimately successful can only be determined by the facilitator’s partner bank, and this request may take days to process. If it ultimately fails, this too must be recorded and communicated.

Reconciling proprietary data with externally generated data is a constant headache.

For a single merchant’s withdrawal, three pieces of information might exist in the payment facilitator’s database (initial withdrawal request, initial withdrawal authorization, eventual withdrawal failure). When looking at the partner bank’s records, however, this line item may only appear once (withdrawal attempt – failed), or it may never appear at all. Reconciling proprietary data with externally generated data is a constant headache.

As any developer knows, networked computers very frequently have connectivity issues. Most modern browsers and applications do a good job hiding this, but API integrations are low-level communication that don't get such friendly abstraction layers. While no software solution can prevent these connectivity issues, many older payment gateways only magnify problems of idempotence (the idea that a function, or API call in this case, can be fired many times with only one eventual result). Idempotence is a hugely important concept in online payment APIs because multiple, unintentional charges can destroy a payment company’s reputation.

Idempotence is a hugely important concept in online payment APIs because multiple, unintentional charges can destroy a payment company’s reputation.

When connectivity issues make it difficult to see if a charge or withdrawal has gone through, it’s up to the payment facilitator to make a judgment call. These situations can be even more tricky than communicating a high-level error message to a user, because the problem is really the absence of information. Fail-safes and protections against these problems are a hugely important piece of any payment facilitator’s payment processing code.

Some modern payment gateways embrace new developments in hiding these problems, and are better about, for example, not charging a card a second time when re-submitting after a network error left the originating system unsure of whether the payment was authorized.

Download the PDF