This document summarizes PayPal's history and capabilities for providing payment APIs at scale. It outlines PayPal's origins in 1998 facilitating online payments through various services. It describes PayPal's many API and integration options for developers. The document notes that PayPal processes over $5 billion in total payment volume per second and handles over 7.5 million payments daily at global scale across many markets and currencies. Lastly, it provides some tips for API design emphasizing easy integration, consistency, and open standards.
5. DIFFERENT METHODS TO INTEGRATE
• HTML Buttons
• API
• SOAP, json-rpc, nvp-rpc
• Batch APIs
• Instant Payment Notifications
• Native Mobile Libraries
• PCI compliant solutions
• Shopping carts
6. REALITY IS…
Async APIs
Client Apps
Client APIs
Mobile Apps
Backend Web APIs
PayPal
Platform
Other SOAP
Platforms APIs
Web Apps
Batch
APIs
Shopping
Carts Hosted
Solutions
7. SCALE IT FOR
• 190 Markets
• 25 currencies
• 123 million active users
• 81 localized web sites
8. LAST HOLIDAY SEASON
$5,217 TPV / sec
7.5 million payments / day
2012:
• $145 billion in TPV
• $97 billion through merchant services
• $14 billion in mobile payment volume
• 0.28 % loss rate
• https://www.paypal-media.com/about
9. THE NOT SO SEXY SIDE
• PCI DSS
• Network, Storage, Systems, Access, Policies
and Monitoring
• Regulatory Obligations & Card Association rules
• AML
• Aggregation
• Country specific policies
10. A FEW TIPS…
• “Integration” is the primary
• an awesome API makes “integration” a
breeze
• “Consistency” is very important
• Don’t try to “educate” your developers - let them
“explore”
• Use “open” web standards
• API and Product
Not many people realize that PayPal has always been an API company. We were doing APIs for a really really long time. It all began with money transfers between PDAs and email payments, but pretty quickly we started opening up APIs to enable merchants collect payments from various ecommerce applications.
Over years we added API on top of another to enable a variety of payment functionality to address the merchant needs.
Payments domain might sound simple – after all it’s all about moving money between two entities. But the context in which they are made, and various scenarios & use-cases that they play in is just amazing. Over years through the APIs we have built, we did enable quite a large set of payment capabilities that probably no other payment provider supports today.
If we look back and see what kind of integration methods we have enabled – again you will see a wide range of methods. This of course could have been done in a better way establishing some consistency and using some open standards, but again as I said earlier – when we were building these, the API ecosystem did not even exist! Yeah our buttons are so web 1.0 but keep in mind no one even knew that web has versions at that point
So with all those APIs providing several capabilities and enabling different integration methods – you can imagine what kind of a complex env/infrastructure we have to internally deal with and of course we all know what external developers feel when they see our APIs – nothing to hide here!
You might ask, why didn’t you guys start from scratch again ? Well the reality is the business was expanding faster than what it takes to rebuild/rationalize.
As you guys might have seen these #s from the last holiday season – our traffic/TPV grew over 23%. A lot of focus was on scaling and operational improvements.
Unlike other domains like Social, Local, etc. that most of the developers deal with – Payments unfortunately are driven by a lot of regulations and federal policies.
Here are few lessons learned from us that might help you while going through your journey of building APIs. Integration is the new API – so don’t just focus on your API alone but also on how some one would use your API. Another important aspect that you should really think about is “when is the right time to rationalize/redesign/start from scratch again?” – that I think is a very important aspect that every API provider should think about and how to handle it when the time comes.