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.

Payments Integration at Uber: a (Short) Case Study

21 views

Published on

Uber supports 10+ ways to pay via different payment integrations: from credit cards through Venmo to more regional payment methods like Paytm in India or iDEAL in the Netherlands. This talk goes through the engineering process of building and rolling out a new payment method for Uber.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Payments Integration at Uber: a (Short) Case Study

  1. 1. Payments Integration: a Short Case Study Gergely Orosz Engineering Manager, Amsterdam
  2. 2. Effortlessly pay for Uber Rider Payments Team We build best in-class payment methods and a magical digital payments experience for riders. We enable the rest of Uber to leverage this payments experience on the mobile and the web.
  3. 3. ● Let’s Build building the payments integration ● Let’s Go testing & rolling out ● Let’s Harden then the Real World happened Agenda
  4. 4. Google Pay: Client Side Add Flow If Google Pay is setup on the phone, this step is low friction.
  5. 5. Google Pay: Client Side Charge (Exact Amount) Flow When riders owe a specific amount of money for Uber, they need to settle that amount before they can take a new trip.
  6. 6. Google Pay: Client Side Authorize Flow Before taking a new trip with Google Pay, riders need to authorize the estimated price for the trip. This ensures the money will be available for Uber to collect, once the trip finishes.
  7. 7. Google Pay: Client Side Delete Flow Riders can remove Google Pay from their list of payment methods.
  8. 8. ● Data for each type of payment a user has added ● Fields ○ User ID ○ Type ○ Custom fields per payments type ■ Display information ■ Metadata used for processing/charging Payments Profile
  9. 9. Void Refund a previous authorization to the user. This can happen e.g. when the rider cancels shortly after requesting. Delete Remove the payment profile from the rider’s account. While it sounds straightforward, can lead to interesting edge cases when doing this e.g. while still on a ride. Add When adding Google Pay on the client side, create a payment profile with all necessary data for use. Auth Guarantee that a specific amount of funds will be available for charging later by authorizing this amount. Authorization is done by the card issuer and funds can be held up to seven days. Google Pay: Backend Operations Charge Move a specific amount of money from the user’s Google Pay account to Uber. Capture Collect a previous authorization and move the money from the user’s Google Pay account to Uber.
  10. 10. Google Pay: Auth Flow Mobile Google SDK Uber.com Braintree Get payment data Nonce Pickup request (with nonce) Exchange nonce Payment token Auth with token Auth result Pickup result
  11. 11. Google Pay: Auth Flow (in Detail) Uber.com API Risk Engine Payments Profile Service Braintree Pickup request (with nonce) Exchange nonce Payment token PSP Gateway Decide trip risk Risk check Verify payment profile (with nonce) Create (with nonce) Payment token Persist token Payment profile verified
  12. 12. Google Pay: Auth Flow (in Detail) Uber.com API Risk Engine Payments Profile Service Braintree Operation result PSP Gateway Auth with token Standardized auth data Persist auth data Payment profile verified Auth Decide trip risk Sale operation with token Auth complete Trip request approved Fetch token
  13. 13. Systems to Modify a Payment Flow Risk Engine Payments Profile Service Go Python Core Systems (Current) Uber.com API NodeJS PSP Gateway Python User Profile Service Go
  14. 14. ● Switch payment on-trip ● Tipping ● Scheduled rides ● EATS order flow ● Promotions ● Uber for Business ● Default payment method fallback/selection ● Scheduled dunning of unsettled payments ● Uber Cash Additional Use Cases
  15. 15. Move fast by unblocking ourselves - most teams at Uber, 2009-2017
  16. 16. Systems to Modify a Payment Flow Risk Engine Payments Profile Service Go Python Core Systems (Current) Uber.com API NodeJS PSP Gateway Python User Profile Service Go Other Systems with Payments Business Logic Tipping Service Go Promotions Service Python Customer Support NodeJS Marketplace Matching Service Go … and more! Mostly Go, Java
  17. 17. Let’s do the right thing and pay down our tech & architecture debt. - most teams at Uber, 2017 onwards
  18. 18. Systems to Modify a Payment Flow Risk Engine Payments Profile Service Go Python Core Systems (Current) Uber.com API NodeJS PSP Gateway Python User Profile Service Go Other Systems with Payments Business Logic Tipping Service Go Promotions Service Python Customer Support NodeJS Marketplace Matching Service Go … and more! Mostly Go, Java Nextgen Systems (WIP) Payments Profile Service v2 Java Payments Auth Service Java Uber.com API Go PSP Gateway v2 Java
  19. 19. Building a Payment Flow ● Adopting the API of the PSP is not the most difficult ● Systems fragmentation is the biggest challenge
  20. 20. ● Let’s Build building the payments integration ● Let’s Go testing & rolling out ● Let’s Harden then the Real World happened Agenda
  21. 21. Sandbox Testing Most PSPs have this (including Braintree). Makes development faster/easier. Testing Testing with Real Cards Once we think it’s ready, time to give it a test with a real card/payment method. Debugging There are many systems where payments data/results need to be tracked. Dedicated tooling helps.
  22. 22. Develop Against Prod Data (Cerberus) Send requests from a dev machine to production. Do this in a guarded, transparent and easy way. Initial version: supporting only read only endpoints. Route Prod Traffic to Dev (Deputy) The “reverse” of Developing Against Prod. Route production messages to local dev machines. Requires installing a middleware on the service (aka “deputize”) Production Service Access Control Gateway Proxy Client Dev Service Virtual machine Cerebus Dev Service Access Control Gateway Proxy Client Forwarding Service Virtual machine Cerebus Prod Service Deputy Middleware Develop in Production* * Safely
  23. 23. Everything is an Experiment We measure how changes affect key business metrics. Things we typically care about are rate of trip taking, first paid trips. Rollout Choosing the First Experiment Region Not too large, not too small. Business requirements (upfront pricing & previously no Android Pay) And the first country is... Rollout Plan Decide well in advance One city, 1%, 10%, 50%, 90% Decide key metrics to track. For Google Pay: core metrics + Acceptance Rate, Uncollected Rate
  24. 24. Rollout: Acceptance Rate
  25. 25. Rollout: Uncollected Rate
  26. 26. ● Cautious rollout paid off. Data was worse than expected. ● Double checked sampling & hypothesis. ● Rolled back. ● Investigated root cause with with Google Pay. Fixed the issue on both ends. ● Resumed rollout. Rinse & repeat. Rollout
  27. 27. ● Let’s Build building the payments integration ● Let’s Go testing & rolling out ● Let’s Harden then the Real World happened Agenda
  28. 28. Anything that can go wrong, will go wrong. - Murphy
  29. 29. Monitoring See what is going on with the system, at any given time. We built monitoring dashboards segmented by: ● payment type ● operation ● city/region Our monitoring dashboards are based on Grafana. Monitoring & Alerting Alerting When something is out of the ordinary, fire a pager. We use machine learning for anomaly detection and alerting. We have global, as well as local (country level) alerts setup. Mitigation & Production Logs Once an alert fires, we quickly determine if there is a likely outage happening. We have tools to see the latest changes and mitigate to roll back We use Elasticsearch and Kibana dashboards to visualize/browse our (scrubbed) prod logs.
  30. 30. Monitoring & Alerting
  31. 31. Let’s talk about fraud.
  32. 32. Fraud is a problem that never keeps us up at night. - said no one everyone building a payments system
  33. 33. Real-world fraud: a story Cast ● Location Spoofing ● Unsupported Region ● Silent Failure Error ● Untested Edge Case ● Whatsapp Economy ● Youtube ● Human Creativity ● Blameless Postmortem
  34. 34. Operational Monitoring vs Fraud Monitoring They are very different concepts. Need different tools and approaches. Real-world fraud learnings
  35. 35. ● Let’s Build building the payments integration ● Let’s Go testing & rolling out ● Let’s Harden then the Real World happened Summary Gergely Orosz @GergelyOrosz

×