Paypal Platform: Evolving for simplicity and reach - IBM Silicon Valley Lab
EVOLVING FOR SIMPLICITY AND REACH
May 13, 2014
Head of Platform Engineering
– 148 million active accounts
– 193 markets in 26 currencies
– Total Payment Volume was $180 billion
– $27 billion in mobile payments
– Q1 2014
– Total Payment Volume of $52 Billion
– At $6688 TPV / second
– 834 million payments, 9+ million every day
– $1 in every $6 spent on e-commerce
– 25% spent on cross-border trade
THE PAYPAL CONTEXT
In a dynamic environment
– 300+ features per quarter
– We roll 100,000+ lines of code every two weeks
PAYPAL PLATFORM HAS EVOLVED
TO SUPPORT NEW INTEGRATION NEEDS
2001 Instant Payment Notification
2004 Transaction, Mass Pay API
2005 Direct Payment API, Express Checkout
2007 Payment APIs (NVP)
2009 Adaptive APIs (SOAP/XML, NV, JSON)
2013 Payment APIs (REST)
BACK TO 2012
• Inconsistent APIs
• Complex developer experience
• Not designed for mobile
• Tightly-coupled internal SOA
• Long product development cycle time
RETHINKING API AND DEVELOPER EXPERIENCE
Who are the end users?
Who are the developers?
How should we design our API?
How should we ease learning?
How should we simplify integration?
WHO ARE THE END USERS?
WHO ARE THE DEVELOPERS?
tools and processes
role of our api
HOW SHOULD WE DESIGN OUR API?
internal api vs. external api
api portfolio vs. api
capability api vs. experience api
API Design Team
HOW SHOULD WE EASE LEARNING?
sdk and code samples
HOW SHOULD WE SIMPLIFY INTEGRATION?
familiar integration model
api call dashboard
• Think API before experience
• API is a product
• Domain model & Integration scenarios
• Easy to learn, integrate, diagnose
• Be the ‘developer’
API Quality Attributes
• Encapsulated, Isolated
• PayPal has grown phenomenally since its inception
• PayPal APIs have evolved to support this growth
• We revisited the basics to create a real platform
• That is founded on principles around ‘API as a product’
• We are rethinking integration with focus on simplicity and reach