Evolution of the PayPal API: Platform & Culture

Craft ConferenceApril 23, 2015

Deepak NadigHead of API Platform Engineering, PayPal

@deepak_nadig

OUTLINE

2

• Context and Challenge

• Goals and Target State

• Evolution of Platform

• Evolution of Culture

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

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)

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

WHAT GOT US HERE WON’T TAKE US THERE

6

Social

Mobile Local

Digital

Time

Perf

orm

ance Limits

reached

Highgrowth

Kickoff

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

EVOLUTION OF

PLATFORM

8

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

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

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

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

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

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)

BatchProcessing

External

Notifications

Batch

APIsProtocol conversion

OAuth, CORS

Routing

Orchestration

EVOLUTION OF

CULTURE

15

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

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

ManagerUED

Application

Engineering

API Product

Manager

API

Designer

Service

Engineering

HACKATHON

18

- Usability testing for APIs

- Know your developers

- Testing ground for overall DX

- Developer advocacy

ORGANIZATION STRUCTURE

19

- Conway’s law

- Reuse = Coupling

- Agreements based on standards

- Namespace != Organization

- Teams mature at different rates How do committees invent?

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!

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 IdealFully 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

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/paymentCustomer 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

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

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!