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.
DDoS In Oceania and the Pacific, presented by Dave Phelan at NZNOG 2024
Craft Conference 2015 - Evolution of the PayPal API: Platform & Culture
1. Evolution of the PayPal API:
Platform & Culture
Craft Conference
April 23, 2015
Deepak Nadig
Head of API Platform Engineering, PayPal
@deepak_nadig
2. OUTLINE
2
• Context and Challenge
• Goals and Target State
• Evolution of Platform
• Evolution of Culture
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. 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. 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. WHAT GOT US HERE WON’T TAKE US THERE
6
Social
Mobile Local
Digital
Time
Performance
Limits
reached
High
growth
Kickoff
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. 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. 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. 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. 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. 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. 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. 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. 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
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. 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. 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. 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. 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. 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!
Editor's Notes
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.
Evolution in PayPal brand image
Evolving the platform as the company continues to grow