Learning payment processor system design from credit card receipts
Actively learning system design in a systematic way!
We use an example of approaching the design of a credit card processing system by retroactively mapping items on credit card receipts to system design artifacts. We believe that to grasp the major concepts of system design fully, it is crucial to see them in action. Fortunately, major cloud providers such as AWS, Azure, and GCP have built many large-scale systems for us to learn. We argue that this way of learning system design is akin to teaching you how to fish versus handing you a few fish (that most system design books and courses do). This post is the first one on these lines.
This post is about learning system design by mapping the real world to the computational world and asking the right questions. Unlike a typical system design article, we do not hand out a design but rather learn how to attack a new design problem lest you encounter one in a job interview or at work.
Power of learning from the real world
This morning I put gas in my car, paid by my credit card, and got a printed receipt for my records. I quickly skimmed through the stub to ensure that the dollar amount matched what was shown on the pump display. Suddenly it occurred to me that by learning about a lot of info on the stub (such as TID, which I thought would be some transaction ID, though it is not!) and mapping it to a standard system design of a processing system is a great way to connect real-world to an abstract design. Doing so can deepen our understanding and appreciation of a system. Also experiencing something has an impact on us.
This is no different than learning to drive in the USA. If you were aspiring to apply for a driving license for the first time, learning by observing what is happening on the road and asking specific questions can make it so easy. Understanding the nature of traffic during rush hours compared to quieter periods helps reveal how the time of day affects a driver's psychology on the road. Learning this way is easier and more impactful than reading the DMV handbook alone.
Therefore this post is not just about mapping credit card stub information to a payment processor system design, but encouraging you to find a way to interact with a system you want to design.
You might be thinking that it is totally upside down! You design a system first, then you implement it, and so it is mostly a mental thinking exercise. Right? Wrong! Even the folks who build large-scale systems start small and iteratively improve their product. Doing a small scale brain storming initially but then to comparing it with some real product to ground your understanding is necessary. You can always simplify and scope down your problem for an interview. But doing so will be so much more easier once you have better understanding of a real design.
Stakeholder in the system
Let’s start by identifying the stakeholders in the processing system. Two stakeholders are readily visible—you as a buyer, and the seller (or merchant). There are others such as credit card issuers (for example, MasterCard and your bank), and the merchant’s payment processor or bank. A typical flow of this system looks like the following.
A detailed stub/receipt
You get a digital (for example via email) or a paper receipt on a successful transaction with your credit card. This receipt has quite a lot of information. Probably you only paid attention to the dollar amount mentioned on it. You will find some of the following information on your receipt. Your stub might be less or more detailed than this. Please let me know if your receipt has something that we didn’t discuss here.
1. MID: Merchant ID
MID tells about the type of merchant. This ID is unique within the merchant’s processor system and does not necessarily have to be unique globally. Usually, it is between 8 to 15 digits long. It will be reasonable to assume that this identifier is issued when a new merchant registers with its bank/processor and acquires a credit card processing terminal and an associated account.
2. TID: Terminal ID
The unique identification of the device used to process your credit card information. It’s usually 8 to 16 digits long. For a merchant it is unique. (For example in a large place like a Costco or Walmart, there might be 10s of such devices per store and probably thousands across the country.) It might be the case that each such device is geo-tagged to a certain location to guard against any stolen device for some illicit transaction.
3. Batch
It is a unique number issued by the merchant’s processor. At a set time automatically, or manually the merchant combines many transactions (for example at the close of the day or at a shift change), and sends them in a batch to the processor for settlement. Once a batch is settled, the process of actual movement of the money from the client’s account to the merchant’s account happens (minus any fees). A batch is usually 6 digits long. Usually, there are small fees to process transactions, and batching might help to reduce certain fees for the merchant.
Probably batching might also help reducing delays for the customer (because a merchants requests clearing offline at the close of the business day for example). Batching might also help achieve better scalability for the processor and it might have incentivize it by reduced fees.
4. Auth
It is the authorization by the credit card issuers, effectively promising to pay the said money later. The issuer first verifies that the client has sufficient funds, then puts a hold on the transaction amount, and provides a unique authorization token to the merchant’s processor. It is usually 6 to 8 digits long. These tokens are later used for fund settlement.
5. Invoice
It is a unique ID that is attached specifically to your purchase. It only has significance for the merchant and for the client. Effectively this number encapsulates what goods or services were sold to you for which you are being charged.
6. PRN: Payment reference number
A unique ID to refer to this sale (for example for disputes). You might ask how PRN is different from an invoice. Invoicing is a pre-step that is done on the merchant end, effectively saying here is what I am selling to person x for $y. If everything goes well, and the transaction is approved, PRN is generated by the merchant’s processor to refer to this specific sale.
7. AID: Application ID
Chip-enabled credit cards encode who is the issuer of the card (such as Mastercard, visa, etc.). It tells the merchant terminal machine how to process a specific credit card. There might be major differences in how a card is processed between, for example, American Express (that has its own processing network and card issuing business model) as compared to Visa/Mastercard (that has a multi-party, tiered system to issue and process cards).
There are so many numbers floating around. With millions of transactions happening at any time, correctly generating these numbers is in itself important. We often use sequencers for this purpose, that is an example of a distributed system with specific characteristics.
8. TVR: Terminal verification code
It tells the status of all the security checks and the final result of the transaction. An “approved” is usually written on some stubs if a transaction is successful.
9. Partial credit card number
Digits 1 to 6 of a credit card are related to the issuer. Digits 7 to 15 are unique account IDs, while the last digit is a check digit for validating a credit card number. Receipts often obfuscate your unique account ID part for privacy/security reasons.
10. Merchant or customer copy
The merchant’s copy might have additional information as compared to the customer’s copy. Some software uses the same information for both parties for simplicity. But a merchant might be leaking too much information. For example, as a customer, you might guess how many orders were processed in a day by looking at invoice numbers (if invoice numbers monotonically increase). We might demand from a sequencer system to generate non-monotonically increasing numbers to avoid leaking such information.
If you want to learn system design for something, ask youeself how you can interact with such a system as a user, and as a developer. Then reverse engineer your understanding to think how such a system might have been designed.
You might ask what about scalability? Can you test that out as well without spending too much money on the cloud? Probably. You might like to choose tens of the most cheapest VMs to experiment a bit with scalability and then take a leap of faith to assume it will just work out after that (extrapolation).
11. Miscellaneous info
Merchants and their processor’s logos, the address of the merchant where the transaction took place, date and time are common information that is usually included on all stubs.
Similarly, some receipts also indicate if the sale was contactless (with a CL) or not (with a C).
You might also have experienced that depending on the merchant, type, and amount of transaction, you might be asked to enter your credit card PIN. All modern financial systems have complex fraud detection and prevention systems that work in real time. For example, if you put gas in your car every Monday morning around 7:30 a.m. from the same fuel station, you might not be asked to enter your PIN. But if you suddenly want to spend $500 at a fuel station that will trigger alerts from the fraud detection system.
12. Other mysterious info such as SN: Serial number?
I had a receipt that had another number with the initials SN. Probably that is another serial number but it was not clear to me for what purpose. Did any of your receipts have something on it that is not obvious to understand?
Exercise: Can you map where each of the above numbers would have generated and could find a workflow in the stakeholder diagram we have above?
Put on a system designer’s hat: Points to ponder
We realize that a large part of the credit card system depends on secure processing of the transaction end-to-end (starting from the credit card processing machine to the payment processor over the network). Buyers provide strong authentication that they are the owners of their cards and they are authorizing a certain amount of payment. There is less or no authentication for a buyer that is a merchant legit other than that we should use credit cards at reputable merchants. There is a certain degree of risk.
Many parts of the processing system are executed offline. Offline means when a customer is not waiting on a merchant to complete the transaction. Some work is done online to reduce the wait time for the customer, and so that credit card processing does not become a bottleneck for a business.
A multi-party processing system (as employed by Visa and Mastercard) seems to divide the load on multiple partners. However, it might add more delays because for a transaction to process, we might need to go to the card networks (Visa for example) and the issuing bank. For systems like the American Express, latency might be lower (because Amex is both issuer and processor) but it might have been more costly to build the processing network as a single party. Which of the ways might be more fault-tolerant? Both models have their pros and cons.
For multi-party methods, financial information is split between the processor and the issuing bank. Who will take the burden of fraud detection? One of the parties or both? For a single-party model, one entity might be getting a wealth of financial information that it could harness to its benefit.
Next steps: You might like to try out a credit card processor such as Stripe that provies sandboxes for you to learn.
Conclusion
So here you have it—we mapped our credit card stub information to a simple design. We speculatively thought through each item appearing on the receipt and its use in the workflow. The next level of understanding will be to get a developer account for Mastercard or Striple and to use Postman to understand their API. Or maybe selling something to be on the other end of the spectrum (to be a merchant) and to see how things work there.