Mission critical systems generally have more testing than others, and PayPal is no different. In addition, PayPal has built-in redundancy and fault-tolerance to prevent bad code, a bad machine, network connection, router, data center, etc. from harming the service we provide to our customers. We have many layers of testing and alerting, so that if something goes wrong, we know almost immediately. If something does make it past all those layers, we have a Site Reliability Engineering (SRE) team and bug tracking system to ensure any customer issue gets the highest attention possible.

Great question! To refactor is to apply what you've learned today for the problems of both today and tomorrow. Since we write lots of code and are always learning, we constantly take a step back, clean up, write (and rewrite) frameworks, and throw away huge portions of our tech stack for better stuff. Naturally we have to produce functionality too, so as with any software team, it is a balancing act to know when to stop and revisit some code, or produce new features or bug fixes. Since PayPal's codebase is so huge, you could confidently say that a significant portion of it is being refactored at any given time.

This is a broad question that can be answered by lots of industry standard information on API development. PayPal is a leader in this space, and is an active member in the OpenAPI Initiative . We have all the same concerns as many other API developers: building developer-friendly APIs with consistent standards, onboarding new users, authentication, app management, SDKs, documentation, sandbox, dashboards, up-time and other *ilities, partners, community engagement, and sunsetting old APIs. All of these require attention to ensure the developer experience is pleasant and meets the needs of your business. Specifically regarding security concerns: as a financial company, we have to ensure extra effort is placed on ensuring APIs and data behind them are safe and secure behind a solid authentication mechanism. You can read more about it on our REST APIs Getting Started documentation .

This is actually quite a common question from friends and relatives alike! Honestly, those two, as well as others from the PayPal Mafia, have been absent from the company for many years. Speaking to the tech stack, vestiges include ancient code, names of frameworks, databases, files, etc. Most of this has since been gutted and replaced with new platforms that fit the changing needs of the business.

Our team's code review process is mostly similar to Kent Dodds. We take advantage of GitHub's Pull Request Templates to ensure our developers fill in the right details of their change. These vary across projects, but generally include: Problem Solution Verification (screenshots, or steps the submitter did to reproduce the issue) Concerns Relevant links Required reviewers Naturally some changes don't require this much paperwork, and only number 1, 2, are 6 mandatory. For simple or focused projects, we may require only one code reviewer.

Hi there, thanks for the question! This is mostly a duplicate of the tech stack question above, which Poornima provided a pretty comprehensive answer to the unit test frameworks in use here at PayPal. However, I will also clarify that APIs are mostly written in Java, while the the front-end stack is written in Node.js. Outside of standard unit testing, there are functional tests, sandbox tests, and live tests, using a combination of off the shelf Java or Python frameworks and our own scripts.