Building Stripe's API

How we built the Stripe API: lessons learned, and things we did to make the API as easy to use as possible.

Transcript

1. BUILDING STRIPE'S API AMBER FENG @amfeng
2. STRIPE: PAYMENTS FOR DEVELOPERS
4. WE CARE ABOUT API DESIGN
5. PAYMENTS API CREDIT CARD PAYMENTS TOKENIZED & STORED CARDS RECURRING BILLING > curl https://api.stripe.com/v1/charges \ -u sk_test_mkGsLqEW6SLnZa487HYfJVLf: \ -d amount=400 \ -d currency=usd \ -d "card[number]=4242424242424242" \ -d "card[exp_month]=12" \ -d "card[exp_year]=2014" \ -d "card[cvc]=123"
6. DESIGNING THE API
7. RPC ORIENTED ◦ method=list_charges ◦ All calls are POST, and return 200 POST /v0?method=list_charges &key=KEY v0 API (2010, beta)
8. DESIGN GOALS: CONSISTENCY, SIMPLICITY, POWER
9. HTTP ORIENTED ◦ GET, POST, DELETE ◦ HTTP status code to indicate result GET /v1/charges?count=60 -u KEY: v1 API
10. GET /v1/charges GET /v1/charges/CHARGE_ID POST /v1/charges POST /v1/charges/CHARGE_ID DELETE /v1/charges/CHARGE_ID v1 API
11. SUPPORTING THE API
12. MAKE IT EASY TO GET STARTED
15. LANGUAGE-SPECIFIC LIBRARIES & DOCS
18. FOCUSED API THAT ALLOWS FLEXIBILITY
19. LET USERS BUILD EXTENSIONS WEBHOOKS ◦ Posted events to a webhook URL ◦ charge.succeeded, charge.refunded, etc. CONNECT ◦ OAuth2 API ◦ Users can authorize access to their Stripe accounts ◦ Full access to Stripe API
20. PROVIDE A TESTING ENVIRONMENT
23. HELP YOUR USERS DEBUG
25. { "error": { "message": "You must provide an integer value for 'exp_year'.", "type": "card_error", "param": "exp_year" } }
26. >> Stripe::Customer.create Stripe::AuthenticationError: No API key provided. (HINT: set your API key using "Stripe.api_key = <API-KEY>". You can generate API keys from the Stripe web interface. See https://stripe.com/api for details, or email support@stripe.com if you have any questions.)
27. >> Stripe.api_key = TEST_KEY => ... >> Stripe::Charge.retrieve(LIVE_CHARGE_ID) Stripe::InvalidRequestError: (Status 404) No such charge: ch_17SOe5QQ2exd2S; a similar object exists in live mode, but a test mode key was used to make this request.
30. DEALING WITH CHANGE
31. BACKWARDS INCOMPATIBLE CHANGES ◦ Per-user version, set on first API call ◦ Allow upgrading versions and detailed changelog ◦ Pass version override in headers FEATURE GATING ◦ Experimental or one-off ◦ shows_applications VERSIONING
32. MANY DEFINITIONS OF A "GOOD API"
33. THANKS! (: AMBER FENG @amfeng