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.

Paypal Platform: Evolving for simplicity and reach - IBM Silicon Valley Lab


Published on

  • Be the first to comment

Paypal Platform: Evolving for simplicity and reach - IBM Silicon Valley Lab

  1. 1. PAYPAL PLATFORM EVOLVING FOR SIMPLICITY AND REACH IBM May 13, 2014 Deepak Nadig Head of Platform Engineering
  2. 2. PayPal … – 148 million active accounts – 193 markets in 26 currencies – 2013 – 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
  3. 3. PAYPAL PLATFORM HAS EVOLVED TO SUPPORT NEW INTEGRATION NEEDS PayPal API PayPal Capabilities 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)
  4. 4. BACK TO 2012 CHALLENGES • Inconsistent APIs • Complex developer experience • Not designed for mobile • Tightly-coupled internal SOA • Long product development cycle time
  5. 5. 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?
  6. 6. WHO ARE THE END USERS? segments experiences expectations
  7. 7. WHO ARE THE DEVELOPERS? tools and processes technology preferences role of our api
  8. 8. HOW SHOULD WE DESIGN OUR API? internal api vs. external api api portfolio vs. api capability api vs. experience api API Design Team
  9. 9. HOW SHOULD WE EASE LEARNING? good documentation sdk and code samples sandbox
  10. 10. HOW SHOULD WE SIMPLIFY INTEGRATION? familiar integration model api call dashboard customer support
  11. 11. 11 PLATFORM PRINCIPLES API First API Design • Think API before experience • API is a product • Externalize-able • Domain model & Integration scenarios Developer Experience • Easy to learn, integrate, diagnose • Be the ‘developer’ API Quality Attributes • Response-time • Availability Service Architecture • Encapsulated, Isolated • Craftsmanship
  12. 12. 12 INTEGRATION ARCHITECTURE API Facade Payments Wallet Customer Credit Risk Compliance Invoicing Disputes PayPal OODC* Applications (Wallet, POS) 2nd-party Applications (eBay, Braintree) 3nd-party Server Applications (Uber, PhotoCard) PayPal Web Applications (Falcon, Hawk) Experience APIs Capability APIs Event Bus Webhooks 3nd-party Mobile Applications (Uber, PhotoCard) Batch Processing Notification APIs Batch APIs
  13. 13. SUMMARY • 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
  14. 14. @deepak_nadig