Dec 21, 2020 08:00:00

How has Stripe, a payment service with millions of users, responded to diversifying payment methods?

With the spread of the Internet and smartphones, online payments have become widely used in the last few years. Launched in 2011,

Stripe is an online payment service introduced by millions of companies that offers an easy-to-use API and claims to be 'Developer First.' Michelle Bu , Stripe's technology leader in payment products, talks about how Stripe's API has changed with the diversification of payment methods.

Stripe's payments APIs: the first ten years
https://stripe.com/blog/payment-api-design

From 2011 to 2015, when Stripe was born in the United States, credit cards were the primary payment method. At that time, the basic concept of the JavaScript library ' Stripe.js ' provided by Stripe for implementing payment functions was the 'Token' object and the 'Charge' object. First, the client uses a publicly available API key to communicate with Stripe and generate a Token. The client sends the generated Token, API key, and payment-related information to the server. The server queries Stripe to generate a Charge based on the Token and secret API key sent by the client. The Stripe side had a structure in which the actual credit card payment and payment results were transmitted via each object.

At the time of its establishment, Stripe was only compatible with credit cards, but in 2015 it will be compatible with

ACH debit and Bitcoin, which are widely used in the United States. However, these payment methods are very different from credit cards in that 'payment is not completed immediately'.

First, for ACH debit, we added a state called 'pending' to Charge so that the server can handle payment failures. We've improved the API so you can see if payments have been completed on the server and Stripe.

Bitcoin didn't fit well into Stripe's API design, so Stripe decided to separate credit card and ACH debit payments from Bitcoin payments. Added a new 'Bitcoin Receiver' object to separate the processing,
In the case of Bitcoin payment, it is said that the server uses Bitcoin Receiver instead of Token. However, the separation of processes has complicated the client-side implementation.

From 2015 to 2017, Stripe will continue to expand its range of payment methods. As with Bitcoin, adding processing for each payment method would make the implementation more complex, so another solution was sought.

So Stripe abstracts various payment methods with 'Source' objects and integrates Token and Receiver. Source acts as a temporary receiver of funds, indicating the status as 'chargeable' if payment is possible, 'pending' if immediate payment is not possible, and the server responds to the status of the Source sent by the client. You can now process it.

The structure has been simplified, but there was a problem that if the client made a payment using a payment method that cannot be settled immediately, the server could not proceed until the payment was completed. In addition, with payment methods that require authentication on a separate page at the time of payment, there seems to be a problem that Charge cannot be generated on the server side because the session ends.

The characteristic point in designing a payment form is that 'processing may be synchronous or asynchronous depending on the payment method'. For payment methods that allow instant payments, such as credit cards and bank accounts, Source quickly becomes chargeable and can generate Charges on the server side. However, with payment methods that do not allow immediate payment, such as Bitcoin and debit, it is necessary to wait in pending until payment is possible. The developer had to have payment status on the client side and the server side respectively.

Looking at Stripe's supported payment methods as of 2017, we can see that credit cards are the only payment method that 'does not require the action of the payer' and 'immediate payment'. The API architecture, which was designed based on credit card payments in 2011, became an inefficient architecture in 2017. 'It's like assembling a spaceship by adding parts to a car,' Bu said of the situation.

So from the second half of 2017 to the first half of 2018, Stripe started designing a new API architecture. The five-member team stayed in the meeting room for three months, 'closing the PC during the meeting,' 'starting the meeting with questions,' 'drawing diagrams with colorful markers,' 'inviting experts,' and 'as soon as possible.' He talked about the new API with a unique rule such as 'decide.'

The new API completed after such discussions is as follows. The basic concept of the new API is the 'Payment Methods' object and the 'Payment Intents' object. PaymentMethods, like Token, contains basic information about payment methods, but unlike Source, it does not include payment status. Payment Intents, on the other hand, holds all transaction-specific information such as payment amount and payment status.

Also, in the past, the client sent Tokens and Sources containing payment information to the server, but with the new API, the payment method including the payment methods that can be used by the server is sent to the client, and the payment method selected by the client. Is now obtained via Stripe. As a result, the client side does not need to branch the processing by the payment method, and the server side has been improved so that the payment status can be confirmed together with the payment method.

However, API does not end with design, but there are various things to do such as code implementation and deployment to developers. Stripe has been working to popularize the new API from 2018 to 2020, but 'Stripe's insights, choices, and efforts have helped launch and disseminate the new API,' Bu said. Mr. says.