Mobile payment giants such as WeChat Pay and Alipay have set the de facto industry standard for cashier interactions through long-term market education. This article provides an in-depth analysis of the "four-stage" process and the "circle-turning" interactive experience of checkout design, revealing the key elements and design principles that need to be considered in the process of achieving an efficient, stable, and user-friendly checkout desk.
Isn't payment just a cash register? Why do you have to work on a page for so long? This can be an embarrassing problem for everyone who makes a payment. In fact, this is the cashier payment experience of WeChat and Alipay is too good, giving ordinary people the illusion that the cashier is just a few pages. When you are obedient to the "wild cash register", you will find that the cash register is very particular.
This time, it's not nonsense, there is no scene and demand background, and it is directly about the design in principle.
1. Four-stage and circle-turning
With the promotion of mobile payments, and the long-term market education of WeChat/Alipay, their cashier interaction has become the de facto industry standard. As long as you master this standard process, you won't be dizzy when it comes to being a cash register.
To sum it up, it is "four-stage" and "circle-turning".
Figure 1: Cash register four-stage and circle
1. Four-stage
The payment process of the cashier is divided into four very atomic stages, which are mainly divided into "placing an order, jumping to the cashier, back-end callback, and returning to the result page". (That is, it cannot jump back to the order page, and the user needs to manually switch back).
2. Circle in circles
And these four interactions need to be very closely connected with parameters, so a local cashier is generally added as a transition page between "call cashier" and "return result page", on the one hand, it is to expand local payment methods such as express and balance; On the other hand, it is to better connect these three steps, that is, the loading page we usually see "going in circles".
3. Cashier parameters are concatenated
To be able to effectively connect the cashier, it is first necessary to understand the channel-side parameters of different payment products, which determine whether the cashier connection is smooth. Let's take WeChat Pay as an example to see the concatenation of data (Alipay is similar, and other cashiers are designed with reference to this standard).
Figure 2: Cashier parameters in series (WeChat as an example)
The key parameters of the cashier are divided into two types of data: configuration application and payment process.
- Configuration application: Before applying for the cashier, there must be some preset parameters as a guarantee, including "application parameters, security encryption, and application configuration", the first two are basic parameters, and the application configuration will directly affect the cashier docking and experience.
- Payment docking: Payment docking is divided into four processes, and each payment product has different return methods, which we will introduce in combination with four interactions.
(1) Pay for the order
Figure 3: The order interface is connected in series
Figure 4: Key parameters for placing an order
When a user enters the cashier and selects a payment method to submit, a prepaid order is created for the user to be redirected to the cashier and paid for the amount of the order.
At the same time, the order process, the order information, merchant number, and callback URL will also be transmitted to the channel synchronously. The channel will return the cashier address or prepayment ID (prepay_id) according to the request, and the merchant side can call the cashier based on these parameters. Once the order is placed, the status of the local trade order is "Initial", which means that no payment has been made.
(2) Call the cash register
Figure 5: There are several ways to call the cash register
According to the parameters returned by the order, the merchant will call the cashier to let the user jump to the channel side to pay, and set the order as "to be paid" to indicate that the user is making a payment.
Calling the cashier is a very important entry point for aggregating payments, and many payment methods can be aggregated together by calling different cashiers. Of course, if this packaging method is not handled in accordance with the specifications of the channel, it is easy to have the problem that the result page cannot be returned.
(3) Background callback
After the payment is completed, the user will notify the merchant's payment system of the payment result in the form of a callback. Callback parameters are a standard way to handle them by uploading notify_url when placing an order.
The callback notification is sent to the merchant background, and the transaction system records the payment result as "payment successful", at this time, the payment result is only known by the merchant background, and the user is still on the channel page, so it is also necessary to let the user jump back to the original transaction page.
(4) Return to the result page
Figure 6: How it is invoked and returned
After the user finishes paying, they will be redirected to the original payment page and view the payment result. The way it is returned here matches the way it is called.
- Preset address: Official Account, Mini Program, and H5 are the addresses to be pre-configured in the background of the channel, and the address must be reviewed by the channel party;
- In-app return: Native is a dynamic order code, which is returned in the wallet app where the user scans the code (e.g., WeChat and Alipay apps);
- SDK return: The app application needs to integrate the SDK provided by the channel side to return;
- Payment code: It belongs to the user's active code payment, and the result page is returned directly on the mobile phone. The return of the payment result page directly determines the closed-loop payment process and the good user experience, so the mismatch of the cashier call method can easily cause the situation that the return cannot be made.
Second, the structure of the cash register
Since the checkout is a layer of page wrapping, the architecture design is mainly to look at its functional views, use case integration relationships, and key interface elements.
1. Feature view
Figure 7: View of cashier functions
From the above figure, we can see that the overall interaction between WeChat and Alipay is basically the same, and the only difference is that the cashier counter of the call needs to adopt different calling methods due to the different terminals that are adapted.
The interaction between the two payment methods, express and account, is not handled in accordance with the four-stage formula, and the functional level is not consistent. Therefore, we unify these personalized payment methods according to the "four-segment interaction" standard and package them into the "aggregate cashier" in the form of "APP and H5", so that the overall interaction of payment is unified.
2. Use case model
How do these features integrate with the overall payment system? Let's take a look at the external boundaries and internal functional structure of the system.
Figure 8: Checkout counter use case
(1) External boundaries
1) Gateway Access:
The cashier provides a "cashier service interface" to receive payment requests from acquiring gateways and member gateways.
2) Customer system:
The cashier mainly accesses the "customer system" to access the "member authentication" and "merchant product" configuration. Among them, "member authentication" is used to verify the information of "bank card" and "account" corresponding to the user's payment method, and can also expand the operation of "card binding/account opening".
The checkout counter itself is part of the merchant's contracted product, so the checkout counter is configured to obtain information from the merchant's contracted product.
3) Payment system: In the process of payment at the cashier, it is necessary to interact with the transaction, channel and risk control system, and the specific interaction elements are shown in the figure above.
(2) Internal structure
1) Cashier interface: the cashier provides external service interfaces, including "address acquisition, page acquisition, callback processing, result query", etc.;
2) Cashier service: The main control service of the cashier service, which controls the page display and transaction processing process by reading the merchant's cashier parameters.
3) Payment method: In the form of interface or page, provide the query of the information of the payment method at the cashier, and the expansion of the card binding and account opening operations at the cashier.
4) Payment page: Operate the corresponding payment page according to the three steps of pre-payment, payment and post-payment.
2. Interface elements
We know that the personalization part of making a cashier is mainly in placing orders and calling the cashier, so let's start from here to make a unified cashier interface. In fact, this interface, we can form our own aggregate cashier interface with a little transformation of the interface elements of WeChat.
Figure 9: Checkout Interface Elements
1) Increase the type of payment
To do an aggregate cashier, it is not simply to copy WeChat, because although WeChat is standard, it is not an aggregate cashier. Therefore, we add a "payment type" to the message of unified ordering, so that merchants can choose what payment method to use, so that the new cashier counter can be infinitely expanded.
2) Define common features
We want the common part of each message to be the same, and the business elements can be supplemented according to specific scenarios. Therefore, we need to carefully study the interface documents of various cash registers and extract the common parts, which of course is quite time-consuming and labor-intensive. In order to save everyone's time, I will give you a set of standard solutions here, and change them directly.
The fields marked in red in the figure are used as common packet elements, and each packet is handled uniformly in this way. Other information can be added or decreased according to specific business scenarios.
3) Expand business information: The purpose of unified order is to create an order to record the transaction process, and then return to different types of cashiers according to different payment methods to provide the next step. Therefore, we also need to add an extended parameter to the return message, which supports the return of various cashier parameters and interactive business information, and provides data for the next transaction processing.
3. Cashier design
1. Front-end design of the cash register
As we mentioned earlier, in order to unify the integration of the four interactions, a local cashier page is generally added to achieve the transition, and it has two roles, one is to package the local payment method, and the other is to connect the interactive process of the cashier jump, that is, the circle we usually see.
There are four types of mainstream mobile payment forms: "bank card payment, balance payment, APP payment, and scan code payment", which all follow the "four-stage" payment method, and generally add a circle transition page (the app of large factories is generally an animated mask effect).
(1) Bank card payment
Figure 10: Quick payment by bank card
Bank card payment generally uses quick payment products, which is characterized by the need to sign a contract to bind the card, and the SMS verification code is generally required when paying. Therefore, the selection of the payment method here is followed by the call to the local express cashier, and the subsequent callback result can be completed very quickly because it is a local payment method, and then the result is synchronized to the merchant.
Figure 11: Bank card payment process
In order to prevent payment failures caused by invalid channels corresponding to bound bank cards, the valid bank cards can be displayed to users in a pre-routed way (invalid ones can be grayed out or folded).
As a local payment method, Quick Pay realizes the unification of interaction by packaging it into a local cashier for SMS verification and payment confirmation. If you pass the password verification locally, you can make a quick payment without sending an SMS verification code.
Generally, the payment result will be queried through round-robin, and the payment result page will be returned after success, and the order information will be queried and displayed to the user for confirmation. (In actual development, callbacks and polls are generally optional)
(2) Local balance payment
Figure 12: Payment account balance payment
Local balance payment mainly refers to payment through local payment accounts (payment accounts are also called member accounts and balance accounts). After selecting the payment method, the user will be redirected to the cashier of the balance account, confirm the order and account, enter the password to complete the payment, and return to the merchant page.
Figure 13: Local Balance Payment Process (Real-Time Return)
Since the account is local, the real-time deduction can be returned directly to the merchant page. Due to the large number of users in large factories, local balance deductions will also be processed in an asynchronous manner using MQ. Therefore, the overall interaction design still maintains the way callbacks are handled.
(3) Channel account payment
Figure 14: Channel account payment channels
Account payment mainly refers to access to products such as "WeChat, Alipay" or "bank digital account". These payment methods are where our four-stage approach comes into play, and the cashier part of the call needs to jump to the payment environment of the channel for payment.
Figure 15: Channel account payment process
As can be seen from the flow chart, the local cashier here is a flashing transition page, when the user completes the payment, it is necessary to add a poll to the returned result page to query the order result, and then return to the payment result page to display the order information.
(4) Scan the QR code to pay
Figure 16: Scan code payment interaction
Scan code payment mainly refers to the "static code card" or "website/self-service equipment commodity code", their feature is that you can make a two-dimensional code, after the user scans the code to place an order, judge the scan code APP to jump to a different cashier (generally the official account or service window) to complete the payment, and the return method also needs the payment channel to call the result page to return.
Figure 17: QR code payment process
As can be seen from the process, because it is an official account or service window interface, a self-operated Official Account/service window environment is required to embed an H5 page. When the user scans the code, the user obtains the HTTP packet header to determine the type of app to scan the code, and then selects the H5 page in the Official Account/Service window, and the user enters the amount to place an order with the channel to complete the payment. The callback and return handling is the same as in the previous case.
2. Backend configuration
With cashier payment products, they need to be flexibly configured for merchants to use, and the content displayed on the cashier can be flexibly configured to meet the needs of different products and different customers. Therefore, the cash register uses the following configuration process.
Figure 18: Cashier configuration relationships
After the merchant's application for network access is approved, the merchant will be configured with the "contracted product", which is generally set in advance, as long as the contracted product is associated in the "merchant subscription settings".
(1) Merchant information management
Figure 19: List of merchant information
After a merchant signs a contract to access the network, completes real-name authentication and pre-verification, the merchant operator will create a payment product for the merchant here, click Create will jump to the "Merchant Product Configuration" page to set up the product, and after the setting is completed, the contracted product will be associated with the merchant, so that the merchant can access and use it. Of course, each configuration creation and modification needs to be re-approved before it can take effect, so as to avoid improper configuration and improper configuration affecting the use of merchants.
(2) Merchant product configuration
The purpose of merchant product configuration is to associate the merchant with the contracted product, and modify the default parameters provided by the payment method to meet the customer's needs.
Figure 20: Merchant product configuration
As we can see from the diagram, a merchant can add multiple contracted products, and each contracted product can be set according to the parameters provided by the "Original Contracted Product" to meet the needs of different merchant transactions, accounts, and promotion participation.
(3) Contracted product configuration
Before you can provide a merchant configuration, you need to create a default payment method configuration. For a product like the aggregate cashier, it may be composed of multiple sets of payment methods, so here we refer to this group of payment methods as a "contracted product".
Figure 21: Contracted product setup
Creating a contracted product requires a lot of things to set up, including what gateway interface to use, the type of transaction, the receiving and receiving accounts, the default sub-party, and setting their transaction properties for each payment method.
As we can see from the figure above, the payment methods can be grouped at multiple levels, so that they can adapt to the classified display of multiple payment methods at the cashier, so that users can use them more clearly. At the same time, each payment method can also set its sorting, whether to expand, logo, marketing copy, binding cards are often displayed by default and a series of nuanced features.
Under normal circumstances, the contracted products are set in advance, and the merchant can choose them directly when signing the contract; If the merchant has special needs, we can create a new one for him according to the template to meet the needs of different merchants.
Again, it should be noted that the configuration of the contracted products here is based on the product settings in the "acquirer" scenario, which is different from the settings of ordinary non-licensed institutions in the account part. Because the acquirer has the qualification of clearing and settlement to do channel routing, it does not need to bind the corresponding channel to each payment method, as long as the merchant settlement account is set up.
If it is a non-licensed institution, it is enough to change the "Account Settings Section" to the "Payment Channel" setting.
Fourth, summary
That's the detailed implementation of the cashier, let's summarize, the main is "four-stage and circle"
1. Four-stage
In order to realize the atomic packaging of the cashier, the cashier now generally adopts the four steps of "unified ordering, calling the cashier, background callback, and page return", two of which need to be paid attention to.
1) Call the cash register: It is the entry point of the packaging of the aggregate cash register, and all kinds of strange and obscene skills of the cash register are shown here.
2) Return to the result page: It is a place where it is easier to drop the chain, and it needs to be closely coordinated with the parameters called by the cashier.
2. Circle in circles
In order to ensure the close connection of the process and the unity of the interactive experience, a local transition page will be added for cross-system payment, which is mainly used to connect the process and data processing between the invocation of the cashier and the return of the results.
This article is written by Everyone is a Product Manager Author [Brother Gang], WeChat public account: [Brother Gang Vernacular], original/authorized Published in Everyone is a product manager, without permission, it is forbidden to reprint.
Image from Unsplash, based on the CC0 license.