Just last month, Synapse’s native card processor celebrated its first birthday. This effort to develop our own native card processor started in late 2018 and required many months of building a datacenter presence, testing failover scenarios, and certifying our codebase. Once we were satisfied with the stability of the product we began migrating platforms off of our legacy processor. In April we successfully migrated the last platform to the new processor.
Every payments company strives to have the most control over the rails used for sending and receiving transactions. At Synapse, to optimize control, we’ve invested time working with different payment networks on direct integrations rather than going through third-party vendors.
- From Q1 to Q3 we saw a 600% increase in transaction volume.
- We introduced many additional features in February 2020 including:
- Mobile wallet support for Apple Pay / Google Pay / Samsung Pay.
- Direct integration with Mastercard’s Automatic Billing Updater platform to notify merchants when a card has been closed or reissued, thus reducing declines for recurring transactions.
- We enhanced data enrichment to provide more detail on the merchant.
Why build it?
Each interchange transaction usually has three players: the issuing bank (“issuer”), the acquiring bank (“acquirer”), and the card network itself. Issuers give cards to their members and acquirers partner with merchants to accept cards — the card networks provide the routing infrastructure between issuers and acquirers.
Building our own card processor allows us to assume the role of issuer and/or acquirer for any of our partner banks with very little friction. We also gain the flexibility to rapidly build out new features without needing to wait for a third-party to offer them.
Under the Hood
Each card transaction starts as a “message” sent from the merchant to the issuing bank for authorization. The issuer usually responds with an approval if the account is in good standing and the authentication values (like CVV) are correct, otherwise the transaction is declined.
Nearly all major networks use some derivative of the ISO 8583 standard as the basis for their message specifications. Processors connect through “interfaces” that validate (or reject) incoming messages to ensure they conform to the published tech specs before routing to the issuer or acquirer. But creating and consuming these messages is the easy part. Let’s explore some of the more challenging aspects of being an issuer processor.
- Architecting for Speed: Design a system with an emphasis on fast processing
- Security: Authenticate cardholders to minimize fraud
- Reconciliation: Balance the book and maximize cardholder balances
Architecting for Speed
Card issuers typically have 8–10 seconds to approve or decline a transaction before the network concludes they have “timed out” and either declines the transaction or it falls back to “stand in” processing where preset rules are used to determine the outcome. This means that Synapse needs to authenticate the transaction and apply all cardholder controls in under 5 seconds so platforms utilizing “just-in-time” decisioning can respond before we hit the network timeout.
Our hosts connect to Mastercard’s interfaces through traditional TCP sockets, receiving authorization requests as raw bytes that are passed to a message broker for routing within our infrastructure. We then have several dozen “worker” processes that constantly pull from the message brokers, forward to Synapse’s CORE for a decision, and finally compose the response bytes that will be sent back over the network to the merchant.
By having the workers pull from the message brokers, we are able to minimize the amount of time a request is waiting. We also don’t need to worry about pushing a message to a worker that is already busy, since only available workers are pulling from the broker.
One of the most important responsibilities of a card issuer is authenticating the cardholder. This involves PIN verification, CVV verification, and computing EMV cryptograms.
A hardware security module (HSM) is a specialized server that holds cryptographic keys for encrypting / decrypting data. The idea is that all operations take place within the HSM so the keys are never exposed. Like most major processors, we generate new keys through “key ceremonies”; two key custodians within Synapse each randomly generate half of the key and record it on paper. Then, each custodian inputs their half in the HSM where the full key is derived and stored. The paper copies are retained as a backup and stored in separate locations. The principle of dual control helps prevent a single party from having access to a full key.
While the HSM concept is nothing new, we’ve taken it a step further. For redundancy and speed we rely on a cluster of HSMs and load balance traffic between them. This ensures all transactions are correctly authenticated without sacrificing overall processing speed.
Synapse runs its own reconciliation cycle each night to confirm our totals match the network totals. The cycle consists of a dozen tasks that assert every transaction is in the expected state (e.g. ‘settled’) and identifies any outliers that require manual intervention. Once all transactions are reconciled, the cycle concludes by generating a series of reports that are delivered to our partner banks.
A separate series of tasks are responsible for assigning interchange fees / revenue to every transaction. Each network has their own interchange rates and criteria for applying the rates to a given transaction, but in most cases, the issuer only receives the bulk amount without an itemized breakdown. To overcome this challenge, we work backward from the bulk amount by determining the most accurate rate for each transaction.
In the coming months we plan to move our acquirer processor into production and bring our Visa endpoint live. Both efforts kicked off earlier this year and are now in their final stages.
After the success of our issuer processor we are confident in the resilience of our infrastructure and our ability to quickly originate new transactions as the acquirer while also authorizing transactions as a card issuer. We intend to bring our acquirer processor live and then migrate platforms off our legacy integration.
We’ve partnered with Visa to expand the card schemes available to our platforms. While most of the underlying infrastructure is the same, Visa does have their own flavor of ISO 8583 messages. For a seamless integration we’ve expanded our processor to support Visa’s message definitions and clearing files, rather than start from scratch on a separate processor. This abstract approach allows us to quickly add additional networks, especially as we expand internationally.