Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Craft Conference 2015 - Evolution of the PayPal API: Platform & Culture


Published on

PayPal provides a faster, safer way to pay and get paid online, via mobile devices and in stores. With 143 million active accounts in 193 markets and 26 currencies around the world, PayPal enables global commerce, processing more than 9 million payments every day. From its initial product which enabled consumers to exchange money via PDA devices, PayPal has been enabling online merchants to accept secure payments via PayPal, helping users access money in their PayPal accounts via ATM machines and enabling consumers to pay at POS terminals in stores.
From enabling simple HTML buttons for the web, PayPal APIs evolved over the last 14 years, and enabled integrations across a variety of channels including mobile, POS, ATMs and other connected devices like televisions and gaming consoles. Through the years, PayPal’s external APIs became increasingly inconsistent, complex and difficult to use, and its internal SOA built on proprietary approaches became tightly coupled and was crippling development.
To address these issues, PayPal began developing a new API and Services Platform in 2012 basing it on principles such as API as a Product, API First and loosely coupled services. The new API Platform was initially launched in 2013 to external developers and partners, and is now being used by PayPal’s own developers to build PayPal’s new products and experiences in hours instead of weeks.
In this talk, you will learn about how PayPal’s API Platform has evolved both internally and externally, as well as how the company’s culture has changed along with the new API Platform.

In this presentation, you will learn about how PayPal’s API Platform has evolved both internally and externally, as well as how the company’s culture has changed along with the new API Platform.

Published in: Internet

Craft Conference 2015 - Evolution of the PayPal API: Platform & Culture

  1. 1. Evolution of the PayPal API: Platform & Culture Craft Conference April 23, 2015 Deepak Nadig Head of API Platform Engineering, PayPal @deepak_nadig
  2. 2. OUTLINE 2 • Context and Challenge • Goals and Target State • Evolution of Platform • Evolution of Culture
  3. 3. PAYPAL CONTEXT 3 – 162 million active digital wallets – 203 markets and 100 currencies – Serves 2M+ third-party developers – 2013: Total Payment Volume was $180 billion – Q4 2014 – Total Payment Volume was $64.3 Billion, $8083 / second – Growing 24% YoY – $12 Billion in mobile payments volume (20% of total) – 1.06 billion transactions, 11.5 million payments / day – 2014: Mobile – 20% of TPV, 25% of transactions – 25% cross border trade In a globally dynamic environment – 300+ features per quarter; 100K+ LOC every two weeks – 10K+ employees across the globe
  4. 4. PAYPAL EXTERNAL API EVOLUTION 4 PayPal External API PayPal Capabilities 2001 Instant Payment Notification 2004 Transaction, Mass Pay API 2005 Direct Payment API, Express Checkout, Payflow 2007 Payment APIs (NVP) 2009 Adaptive APIs (SOAP/XML, NV, JSON) 2013 Payment APIs (REST)
  5. 5. API PLATFORM CHALLENGES (2012) 5 External API • Multiple developer portals • Overlapping, inconsistent APIs • Learn from large documents • Complex sign-up process • Incomplete, unreliable Sandbox Internal SOA • Discovery through tribal knowledge • Overlapping, inconsistent APIs • Integrating with an API took weeks • Tight coupling; monoliths • Proprietary standards & technology
  6. 6. WHAT GOT US HERE WON’T TAKE US THERE 6 Social Mobile Local Digital Time Performance Limits reached High growth Kickoff
  7. 7. API PLATFORM – CURRENT (2012) & TARGET 7 API Definition Internal or External Universal API Discovery Painful Developer Portal API Design Project specific API as a Product Architecture Tightly coupled SOA Loosely coupled SOA Technology Proprietary Standards based Integration Expensive TTFHW1 < x min (1) Time to First Hello World – Time to make a simple call/application
  9. 9. PAYPAL API PLATFORM 9 Portfolio of APIs aligned by business capabilities, realized by isolated and encapsulated services, that can be used by internal and external developers to develop applications and integrations quickly and cost effectively
  10. 10. BUILDING A GOOD API AND (MICRO) SERVICE 10 API First API as a Product • Work back from the use cases • API Design Standards • API portfolio • Aligned by capabilities Developer Experience • Easy to learn, integrate, diagnose • Time To First Hello World API Quality Attributes • Response-time • Availability Service Implementation • Encapsulation • Isolation of code and data
  11. 11. Elements of API Design .. 1 11 • API Portfolio • Bounded context & Capabilities • Organize cohesive resources • Orthogonal and loosely coupled id id /invoicing /payments /risk Domain Model  API • Entities, Attributes • Verbs • Relationships • State machine, Domain events API  REST • Resources, Namespaces • Controller resources • Hypermedia links • Webhooks • API Design • Externalizable • Domain model – Problem space • Domain Events • REST • Pragmatic REST • Consistency is built in • Service granularity is easier
  12. 12. Elements of API Design .. 2 12 • Versioning • Version products /v1/payments • API Specification • Google Discovery Document • Generate language bindings • Loosely coupled specifications • No shared structures • Consistency • Data dictionary • Terminology GenioGDD SDK ISO 3166 codes, Invoice ID, Customer ID Invoice, Customer
  13. 13. Service Granularity 13 • Cohesive • Should realize a cohesive and loosely coupled capability • Adaptability • Should not mix functionality exposed to different rates of change • Scalability • Should not mix different levels of scalability • Security • Should not mix different levels of security • Environments • Should not mix constraints of different environment Service granularity is usually a function of company growth maturity and organization structure
  14. 14. TARGET STATE - RUN-TIME ARCHITECTURE 14 API Facade Payments Instruments Customer Credit Risk Compliance Invoicing Disputes PayPal Applications (Wallet, POS) 2nd-party Applications (eBay, Braintree) 3rd-party Server Applications (Online websites) PayPal Web Applications Experience APIs Capability APIs Event Bus Webhooks 3rd-party Mobile Applications (Uber, PhotoCard) Batch Processing External Notifications Batch APIsProtocol conversion OAuth, CORS Routing Orchestration
  16. 16. WHAT IS CULTURE? 16 A way of thinking, behaving, or working that exists in a place or organization - Merriam-Webster Organizational culture is the behavior of humans within an organization and the meaning that people attach to those behaviors. - Wikipedia Culture eats strategy for breakfast - Peter Drucker
  17. 17. DEVELOPMENT PROCESS 17 • Application development • Web Page design Process • Site design/Portfolio Management • API development • API Design Process • API Portfolio Management • Use existing metaphors App. Product Manager UED Application Engineering API Product Manager API Designer Service Engineering
  18. 18. HACKATHON 18 - Usability testing for APIs - Know your developers - Testing ground for overall DX - Developer advocacy
  19. 19. ORGANIZATION STRUCTURE 19 - Conway’s law - Reuse = Coupling - Agreements based on standards - Namespace != Organization - Teams mature at different rates How do committees invent?
  20. 20. FACILITATING CHANGE 20 • People do what leaders do, not what they say • Educate & evangelize • Make it valuable to conform. Make deviations very expensive • Enable evolution at different rates; competition helps! • Recognize success!
  21. 21. SHARED GOALS & MEASURING PROGRESS 21 Maturity Level Maturity Level Name Characteristics (Design, Functional, Operational) Level 1 Exists All services (classic & new) Level 2 Functional Complies with API standards, fully tested, basic documentation Level 3 Core API aligned with product structure, complete developer experience Level 4 Performant Complies with SLO (Service Level Objectives) Level 5 Ideal Fully encapsulated, isolated, meets all design and implementation principles Shared 2014 Goal for completing at least 75% of platform at Maturity Level 3+ Reported across functions and leaders
  22. 22. CUSTOMERS OF THE API PLATFORM 22 Customer Application: PayPal Web Application APIs: /v1/apis/applications Customer Application: PayPal Mobile Application APIs: /v1/oauth2/token, /v1/wallet/{user-id}/financial-instruments Customer Application: eBay Web Page APIs: /v1/oauth2/token, /v1/vault/token Customer Application: Third-party Mobile Application (based on mSDK) APIs: /v1/oauth2/token, /v1/payments/payment Customer Application: Third-party Web Application APIs: /v1/oauth2/tokens, /v1/payments/payment Customer Application: Samsung Wallet (Samsung Galaxy S5, Gear 2, Gear Fit) APIs: /v1/oauth2/tokens, /v1/wallet/activities Customer Application: PayPal Touch APIs: /v1/oauth2/tokens, /v1/payments
  23. 23. API EVOLUTION – THE JOURNEY 23 2016 NORM 2012 INITIATED President buy-in Company mandate Seed organization Right people 2013 EXTERNAL Launched externally Initiated internally Early adopters 2014 EXPANSION Complete majority Educate, evangelize Recognize success 2015 MANAGE LEGACY Retire internal legacy Transition to norm
  24. 24. TO CLOSE 24 • PayPal API & Services had internal and external challenges • Started with API first, API as a product and Developer Experience • Managed service granularity to fit our context • Allowed culture change to evolve; at different rates across company • Flexibility may be the most under-rated quality attribute!