How Stripe Copes with Diversification of Payment Methods

With the spread of the Internet and smartphones, online payments have become popular over the past few years. Starting in 2011, Stripe emphasizes developer first by developing an easy-to-use API as an online payment service introduced by millions of companies. How has this stripe API changed with the diversification of payment methods?

Between 2011 and 2015, when Stripe was born, credit cards were the main payment method in the United States. Stripe.js, a JavaScript library for implementing payment functions provided by Stripe, was the basic concept of a token object and a charge object at the time. First, the client uses a publicly available API key to communicate with Stripe to generate a token. The client sends the generated token, API key, and payment-related information to the server. The server transmits payment-related information to the server based on the token and secret API key sent from the client. The server creates a charge that queries Stripe based on the token sent from the client and the secret API key. The Stripe side was a structure to deliver actual credit card payments and payment results through each entity.

At the beginning of the stand, it only supported credit cards, but in 2015, it responded to ACH debit and bitcoin, which are widely used in the United States. However, these payment methods were very different from credit cards in that payments were not completed immediately.

First, for ACH debit, a pending status was added to the charge so that the server side can respond to payment failure. The API was improved so that you can check whether payment has been completed on the server and stripe.

Since Bitcoin didn’t fit the Stripe API well into the design, Stripe decided to split the credit card and ACH debit payments and payment processing by Bitcoin. In order to separate the processing, a new bitcoin receiver object has been added, and in the case of bitcoin payment, the server can process using a bitcoin receiver instead of a token. However, due to the separation of processing, the client-side implementation has become complicated.

Between 2015 and 2017, Stripe will gradually expand its payment methods. As with Bitcoin, each payment method added processing and the implementation became increasingly complex, so a different solution was needed. Stripe abstracted various payment methods into Source objects and integrated tokens and receivers. The source acts as a temporary vessel for funds, and when payment is possible, the status is indicated by chargeable, and when the payment cannot be made immediately, the status is indicated by pending, and the server can process according to the status of the source transmitted from the client.

Although the structure has been simplified, there remains a problem that when a client pays with a payment method that cannot be paid immediately, the server cannot process it until the payment is completed. In addition, it is said that there is a problem that a charge cannot be created on the server side because the session is terminated for a payment method that requires authentication on another page when making a payment.

A distinctive feature of the design of the payment form is that processing can be synchronous or asynchronous by means of payment. For example, a payment method that allows direct payment, such as a credit card or a bank account, can be directly charged to the source and generate a charge on the server side. However, payment methods that cannot be paid immediately, such as bitcoin and debit, must wait in pending until payment is possible. The developer had to hold the payment status on the client side and the server side respectively.

As of 2017, if you look at the payment method, Stripe can see that the only payment method that can be paid straight away without the need for a payer operation is a credit card. The API architecture designed based on credit card payment in 2011 was inefficient in 2017. This situation could be said to be the same as assembling a spacecraft by adding parts to a car.

For this reason, from late 2017 to throughout 2018, Stripe started designing a new API architecture. The five-member team said they discussed the new API for three months. The new API, which was completed after discussion, uses the PaymentMethods object and the PaymentIntents object as the basic concepts. Like a token, the payment method contains basic information about the payment method, but unlike the source, it does not contain the payment status. Meanwhile, Payment Intents holds all transaction-related information such as payment and payment status.

In addition, in the past, tokens and sources including payment information were transmitted from the client to the server, but in the new API, the server sends payment intents including available payment methods to the client, allowing the client to obtain the payment method selected by the client through Stripe. This eliminates the need for the client to process branches by the payment method, so that the server side can check the payment status together with the payment method.

However, the API does not end only with design, but there are many things to do, such as code implementation and developer deployment. Stripe is working on distributing new APIs from 2018 to 2020. Related information can be found here.