How Wise built the world’s first cloud-based card processing

Written By:
Chen Weiming
Akshay Menon
Valentin Kravtsov

Part 1: the why.

What is card processing?

Tapping our debit or credit card has become so commonplace for everyday spending that we often don’t think twice about it. But what happens to make the card machine go beep? Let’s break it down — as there are more than a few steps involved.

Figure 1: basic card authorisation flow

1. The card’s details are read by a terminal and are sent to the acquirer bank that (usually) supplied the terminal to a merchant
2. This bank forwards the request to the scheme (Visa/MasterCard/etc)
3. The scheme forwards the request to the card processor
4. Card processor strips secure data such as card number and CVV replacing it with a unique card id
5. The issuer receives the payment request, checks the available balance, performs various fraud and limit checks and approves or declines the transaction.
6. This approval or decline flows all the way back to the terminal

All within the space of seconds.

But because the flow relies on a chain of messages, it’s only as reliable as its weakest link. So smaller chains are often more robust. It’s also more expensive to have a longer chain. As each actor will take a slice of the payment, meaning costs passed on to consumers.

Before we look into what we’ve built at Wise to combat this, it’s worth noting the importance of the processing step (3 to 4). While it may seem trivial to replace card details with a unique ID, it’s super important for security — which is also super important to Wise.

The term PCI DSS has become a buzzword (or buzz double acronym) in the fintech industry. This Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements intended to ensure that all companies that process, store, or transmit credit/debit card information maintain a secure environment.

Enter the Wise debit card.

To prove we could properly secure customers’ card data, Wise also had to pass this PCI DSS audit. Which turned out to be a not so trivial task in the end. The fact that many processing companies exist (such as Carta, Paymentology, Galileo FT, GPS, etc) suggests that there is quite a big market for processing solutions. And that many banks are willing to pay for these services to avoid doing it themselves.

In a nutshell, the current model for card processing comes at a cost — which is more often than not paid by consumers in higher prices. Wise is all about the customer, and lowering prices too. So we saw this as an opportunity.

Wise account and card

Our mission at Wise is money without borders. We believe accessing and managing your finances across countries should be super simple, cheap and transparent. The Wise account allows you to hold your money in more than 50 global currencies, and spend it with a debit card. This card allows you to spend like a local no matter where you are with no foreign exchange markup, and the same transparency and convenience you’ve come to expect with sending money with Wise. It also auto converts to different currencies as you spend abroad, with the logic prioritising to convert from currencies you hold with the lowest fee.

As well as low fees and transparency, money without borders also means our card should be available to as many people in as many countries as possible. This came, and still comes with its own challenges. Namely, how do we set up card processing in so many different markets?

Card processing meets cloud

While some banks might choose a processing partner, there are banks that issue cards directly and do it in-house — as this reduces the longer chains, and therefore the risk. What was so special about Wise’s solution then? The answer is scale and cloud.

• Regional expansion (scale) — Most banks have regional setups. An Asian subsidiary of a typical large bank usually works very differently from a European one: it has a separate integration with Visa or Mastercard, supplies different cards and from the technology point of view there is relatively very little connection between them (some are even using completely different code bases). In such a setup adding a new region requires a large-scale joint project between a bank and a scheme with lots of engineering hours invested. At Wise because of a single unified interface with the schemes, launching a new country in most cases is a matter of a config change which can be done and tested very quickly.
• Cloud — Previously, every integration with Visa or Mastercard required a physical Hardware Security Module (HSM) machine which slows things down when expanding — and has associated costs. On the other hand, Wise, together with Visa engineers, built the world’s first processing without a single piece of hardware. And it can serve almost every region on top of AWS (Amazon Web Services cloud).

All other parts of the card processing flow were also built by Wise — by 3 teams of roughly 15 engineers.

The aforementioned processes were implemented and certified by a PCI DSS auditor partner that spent many weeks analysing Wise’s architecture, code, processes, policies, logs, inspecting databases and monitoring packets that flow on the network.

Building a secure and modular infrastructure for card data handling took Wise almost a year and we were lucky to have great support from Visa. However, with such a modular architecture in place, a similar integration with MasterCard took only a few months and required only a fraction of time from the involved teams.

Part 2: the tech.

Talk tech to me

In Wise, we have adopted a micro-service architecture and our services are running on AWS and managed by Kubernetes.

As mentioned in the previous article, Wise had already been issuing cards and processing card transactions with the help of third-partner payment processors even before starting the direct processing work. We have created multiple services to handle e.g. card ordering, payment authorisation and settlement with scheme.

With direct processing, Wise can skip the middleman and start processing sensitive card details in-house. However, this isn’t as simple as adding a few more services and changing the code to use Primary Account Number (PAN) instead of card IDs. We had to design and build a special Cardholder Data Environment (CDE) and pass the PCI DSS audit for our infrastructure processing card data. In the following sections, we will refer to the previously existing setup as “main cluster” (as opposed to the newly built CDE cluster).

Security, always our top priority

Undoubtedly security was our top priority when designing the new CDE cluster. We divided the cluster into 4 security groups (in addition to the existing non-PCI cluster which we called group 0). The services running in each group can only communicate with the service directly above or below its group. For example, a service running in group 2 can only communicate with group 1 or group 3, but not with group 0 or 4 directly. On top of this, we are also using SPIFFE to explicitly grant the access on each individual endpoint. This fine-grained access control is important for us to avoid any security or compliance risks.

Figure 2: Cardholder Data Environment (CDE) — Security Groups

In the following sections, we will briefly describe the reasoning for this architectural decision.

The top secure zone, as the name implies, needs the highest level of protection. The services running there are responsible for the actual storage of the encrypted PCI data and the encryption keys management. We can think about the service responsible for handling the encryption keys as the traditional Hardware Security Module (HSM) but as a purely software-based solution. Before diving deeper it is worth mentioning how we utilised the HashiCorp Vault.

HashiCorp Vault is an identity-based secrets and encryption management system that provides UI, CLI or HTTP API access to secrets and other sensitive data. The keys can be securely stored and managed, tightly controlled and all operations are auditable. HashiCorp Vault is following the plugin architecture and all its auth methods and secrets engines are considered plugins. It also allows us to develop our own additional plugins. The vault can be used by itself or in conjunction with Cloud Key Management Service (KMS) or even traditional HSM. The whole setup including self developed plugins needs to pass the audit to prove it is PCI DSS compliant.

We have developed a total of 4 Vault plugins for supporting SPIFFE and also managing secret keys exchanged with different partners including Visa and Mastercard. A plugin has access to the keys and it also implements cryptographic operations. For example, here is what happens when a new card is generated:

1. The card-generation plugin receives a request to generate a new card. The request contains card data populated by other services including PAN, PIN, expiry date and some other fields.
2. The plugin loads Card Verification Key (CVK) and PIN Verification Key into memory, derives the CVV and PVV values based on EMV specification.
3. All the sensitive card data is encrypted by another key and only the ciphertext is returned to the client.

Since all the steps can be performed within the same plugin, there is no need to leak the secret key value to other services.

Extensibility

During the integration with Visa one of our top priorities was an extensible design that will allow us future integrations with other schemes such as MasterCard, American Express, UnionPay, etc. Additionally, we did our best to unify our integration with various card manufacturers (such as Idemia and Thales) in order to secure the best deal for our customers in various regions.

We made a heavy use of the connector pattern in order to unify the communication with various external partners that provide similar services. The incoming messages from the partners are converted to a unified internal format which propagates across the Wise card processing infrastructure. Here are some examples of the connectors we use:

• Visa connector receives payment authentication and other types of messages from Visa and converts them to a unified Wise format.
• Mastercard connector receives payment authentication and other types of messages from Mastercard and converts them to a unified Wise interface
• Manufacturing connector sends card information to our partners for card manufacturing. Similar to the unified authorisation interface we also support an internal unified manufacturer’s interface that allows adding multiple card manufacturers with only minimal “at the edge” message changes. Today we are integrated with more than one manufacturer to minimise card production costs across the globe.

Securing the connectivity with CDE

Processing requests in the secure CDE cluster usually requires joint efforts from both the CDE and main cluster. We can take the same payment authentication as an example, in order to make a decision to either approve or reject the request, a list of checks need to be performed:

1. Whether PAN and other sensitive fields provided by the request are valid
2. Whether the customer owning the card has enough balance
3. Fraud, limits checks

The first check can only be done by the most secure services while the other checks need to be performed by services running in the main cluster. This is achieved by sharing a unique card ID across both clusters. Only the unique card ID and other non-sensitive information need to be forwarded to the main cluster.

In the demilitarised zone we are running both public and internal proxies for CDE to communicate with the public internet and main cluster respectively. The need for a public proxy may be obvious, but why do we need an internal proxy? The CDE cluster is a separate environment from the main cluster and cross cluster communication is prohibited by default. Since a service running in CDE may need to talk with a service running in main and vice versa, we have created a proxy service to explicitly define all the allowed routes. Only Internal Zone services can directly communicate with the main cluster through the internal proxy. This enforcement gives us much stronger control on what is entering or leaving the CDE cluster.

Part 3: was it worth it?

As mentioned in part 1, there were several reasons why we decided to build our own processing:

1. Growth — Make geographical expansion faster and easier
2. Risk — Improve reliability by cutting down links in the chain
3. Scale — Reduce cost by removing processor fees

So how have we fared on these three aspects?

Growth

Since directly integrating with Visa, we launched in new markets — Brazil, Canada, Malaysia. We were able to launch quickly in succession in these markets with just a couple of quarters of work (and most of this was licensing work — the technical work was very quick as it was mostly a config change) as having cloud processing freed us from lengthy testing back and forth with the processor. Without a direct connection, launching in these three markets would have taken a lot more time and effort. Similarly, we were also able to migrate all the 30+ countries to the direct connection and are planning to launch more countries in 2022.

Direct connection to the schemes also means we can cut out the intermediary and ship features much faster — such as launching digital cards, or support for Apple / Google Pay. Taking the launch of digital cards as an example. With processing outsourced to a partner, it would have required at least a quarter long project for us to get digital cards live. With direct processing, the change is now achieved with a config change, shortening the time from a whole quarter to a few hours.

Risk

One of the key objectives for doing direct processing was to reduce the risk of a failing link in the transaction flow chain. Being reliable is hugely important for a card product, and any declined transaction is very likely to erode customer trust which could lead to them churning away.

1. Acceptance rate — We obsess over reducing processing related declines during the card transaction authorisation process. Prior to direct processing, around 0.65% of auth requests were declined due to a processing error. Since we started processing in house, this has gone down to 0.15%, which translates to around £40M of transaction volume per year we unlock for our customers.
2. Clearing / Reconciliation — Reconciliation and Clearing are easier with a direct integration, since we don’t rely on reports provided by a processor and instead consume all of the information that a scheme provides in a real time. It typically takes months for processors to include new information that is needed.

Scale

Earlier we used to pay per transaction to our card processor. This has been entirely removed since we directly integrated with schemes. This translates to very significant savings that we are able to pass back to our customers.

What’s next?

For over a year Wise has been using the in-house processing system with direct integration to Visa and Mastercard. We’ve fixed many bugs and created a lot of internal tools for our operations and customer support teams. The obvious question is what can we do with the system we built besides its internal usage.

Our team’s decision was that since we believe that our system is reliable, modern and scalable enough, we can start providing it as a service to other companies as part of our Wise Platform offering. Wise has recently published the first set of cards APIs that exposes the card issuance product as a service. The next planned steps are to enrich this initial set of the issuance APIs and add authorisation API, better reporting tools and web support.