WO2020093279A1

WO2020093279A1 - Methods and systems for determining payment method for rendering payment for online-to-offline service

Info

Publication number: WO2020093279A1
Application number: PCT/CN2018/114394
Authority: WO
Inventors: Kai Yang; Ke GAO
Original assignee: Beijing Didi Infinity Technology And Development Co., Ltd.
Priority date: 2018-11-07
Filing date: 2018-11-07
Publication date: 2020-05-14
Also published as: CN111417973A

Abstract

Systems and methods for providing online-to-offline (020) services to a user. The method includes: receiving, from a first user, a request for a service (302); determining location information (304) associated with a terminal device associated with the first user; determining at least one payment method based on the location information (306); providing a depiction of the at least one payment method on a display of the terminal device (308).

Description

METHODS AND SYSTEMS FOR DETERMINING A PAYMENT METHOD FOR RENDERING A PAYMENT FOR AN ONLINE-TO-OFFLINE SERVICE

TECHNICAL FIELD

The present disclosure relates to online-to-offline (O2O) services, and more particularly, to methods and systems for automatically determining a payment method for rendering a payment for an O2O service.

BACKGROUND

An online-to-offline (O2O) service platform (e.g., DiDi ^TM online) can receive a service request, such as a ride-hailing (also referred to as ride-sharing or rideshare) service request, from a passenger and then route the service request to at least one service provider (e.g., a taxi driver, a private car owner, or the like) . Upon completion of the service, the passenger needs to make a payment to the service provider for the service received.

Some online hailing platforms require the passenger to associate at least one valid credit card with the passenger’s ride-hailing account before he or she can make the ride-hailing service request. However, in many countries or regions, depending on the local traditions and customs, the cashless payment use rate is low, comparing to other countries and regions. Meanwhile, in some countries or regions, one or more payment methods may be forbidden depending on the requirements of local laws, regulations, or policies. Mandating using credit card and/or cash as the only payment methods in a worldwide scale may deter the use of the rideshare service in some countries and regions. While in some countries and regions, some online hailing platforms provide all possible payment methods for the passenger to choose from, upon the passenger making a service request, the passenger needs to click at least twice for selecting a payment method to pay for the service, prolonging the average time consumed for rendering the payment. As a result, current systems face the dilemma between providing diversified payment methods and streamlining the process of making payments. Further, current systems lack the ability to automatically adapt payment method (s) to different countries or regions when a user roams to such areas.

Embodiments of the disclosure address the above problems by methods and systems for automatically determining an appropriate payment method for rendering a payment for an online-to-offline service.

SUMMARY

Embodiments of the disclosure provide an exemplary method for determining a payment method for rendering a payment for a service provided via an online-to-offline service platform. The method may include receiving, from a first user, a request for the service. The method may further include determining location information associated with a terminal device associated with the first user. The method may also include determining at least one payment method based on the location information and providing a depiction of the at least one payment method on a display of the terminal device.

Embodiments of the disclosure further provide a system for determining a payment method for rendering a payment for a service provided via an online-to-offline service platform. The system may include a communication interface, at least one memory, and at least one processor coupled to the communication interface and the at least one memory. The communication interface may be configured to receive, from a first user, a request for the service. The at least one processor may be configured to determine location information associated with a terminal device associated with the first user. The at least one processor may also be configured to determine at least one payment method based on the location information. The at least one processor may also be configured to provide a depiction of the at least one payment method on a display of the terminal device.

Embodiments of the disclosure further provide a non-transitory computer-readable medium. The non-transitory computer-readable medium may store a set of instructions, when executed by at least one processor of an electronic device, cause the electronic device to perform a method for determining a payment method for rendering a payment for a service provided via an online-to-offline service platform. The method may include receiving, from a first user, a request for the service. The method may further include determining location information associated with a terminal device associated with the first use. The method may also include determining at least one payment method based on the location information. In addition, the method may include providing a depiction of the at least one payment method on a display of the terminal device.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a schematic diagram of an exemplary system for determining a payment method for rendering a payment for a service provided via an online-to-offline service platform, according to embodiments of the disclosure.

FIG. 2 illustrates a block diagram of an exemplary terminal device, according to embodiments of the disclosure.

FIG. 3 illustrates a flowchart of an exemplary method for determining a payment method for rendering a payment for a service provided via an online-to-offline service platform, according to embodiments of the disclosure.

FIG. 4 illustrates an exemplary user interface showing a set of available payment methods, according to embodiments of the disclosure.

FIG. 5 illustrates an exemplary user interface showing that an account balance is used as a preferred payment method, according to embodiments of the disclosure.

FIG. 6 illustrate an exemplary work flow of determining a payment method, according to embodiments of the disclosure.

FIG. 7 illustrates an exemplary work flow of using account balance as a preferred payment method, according to embodiments of the disclosure.

FIG. 8 illustrates an exemplary work flow of using account balance as a payment method based on location information, according to embodiments of the disclosure.

DETAILED DESCRIPTION

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

Embodiments of the disclosure provide systems and methods for rendering a payment for a service provided via an online-to-offline (O2O) service platform. Services provided via the O2O service platform may include transportation services such as ride-hailing services, delivery services (e.g., food delivery and/or goods delivery) , bike-sharing services, or other services that facilitate offline interactions among users using online service tools. In the following, the ride-hailing service is used as an example in the description of various embodiments. However, technical solutions disclosed in the disclosure are not limited to rendering payments for a ride-hailing service. Rather, the technical solutions may be applicable to payment for any services provided via an O2O service platform, including payment for services provided off-line.

In some embodiments, the system may be configured to receive from a first user (e.g., a passenger) , a request for a ride-hailing service. The first user may use a terminal device to make the request. The terminal device may include, e.g., a mobile phone, a wearable device, a GPS device, etc. used by a passenger requesting the service. In some embodiments, upon receiving the ride-hailing service request, the system may also be configured to determine location information associated with the terminal device. For example, the location information may include a geographical location of the terminal device, such as a country, region, city, etc., which may correspond to where the passenger makes the ride-hailing service request.

In some embodiments, after receiving the ride-hailing service request, the system may be configured to determine at least one payment method based on the location information. For example, the system may determine the at least one payment method based on regulations of a predetermined geographical area after determining that the geographical location of the terminal device falls within the predetermined geographical area, such that the using the at least one payment method within the predetermined geographical area complies with the regulations.

In another example, the system may determine the at least one payment method based on one or more payment methods custom to users in a predetermined geographical area. For example, if the system determines that the terminal device associated with the first user is located within a country or region where cash is the most popular payment method, then the system may include cash payment in the at least one payment method.

In a further example, the system may determine the at least one payment method based on the currency used in the predetermined geographical area. For instance, the system may be configured to provide a wallet feature to hold an account balance associated with the first user, and the wallet may contain multiple currencies in separate sub-accounts. Based on the location information, the system may determine the geographical area (e.g., country, region, etc. ) the terminal device is located, and determine a payment method that uses the currency corresponding to the determined geographical area.

After determining at least one payment method based on the location information, the system may be configured to provide a depiction of the at least one payment method on a display of the terminal device. For example, the system may provide all or part of the at least one payment method to the terminal device, and the display of the terminal device may depict all or part of the at least one payment method (e.g., presenting a list of available payment methods on the display of the terminal device) .

In some embodiments, the system may be configured to determine a preferred payment method based on the location information. For example, the preferred payment method may be one of the at least one payment method discussed above. The preferred payment method may be provided to the first user, for example, by depicting the preferred payment method on a display of the terminal device as a default payment method. The first user may then use the default payment method to pay for the service fare.

The preferred payment method may be determined in various ways. For example, the system may be configured to determine whether the first user has at least one pre-registered payment method registered on the O2O service platform. For instance, the first user may have registered a credit card as the payment method before making the ride-hailing service request. If one or more pre-registered payment methods exist, then the system may choose from the pre-registered payment methods as the preferred payment method. For example, if the pre-registered payment method (s) include a payment card, such as a credit card or debit card, then the system may choose the payment card as the preferred payment method.

In some embodiments, the system may choose the account balance (e.g., an electronic wallet associated with the first user) as the preferred payment method. Depending on an available balance in the account balance, the system may choose to use the account balance the pay for the entire service fare when the available balance is equal to or higher than the service fare, or use the account balance and a secondary payment method to pay for the service fare together. For example, the system may first exhaust the account balance, and then charge the remaining portion of the service fare to the secondary payment method.

In another example, the system may determine the preferred payment method based on at least one past payment method used by the first user for the last one or more prior ride-hailing trips. For example, the first user may use credit cards for eight times during the last ten transactions and a non-card-based online payment method, such as Alipay ^TM, for the rest two transactions. The system may choose, for example, the most recently used payment method as the preferred payment method. In some embodiments, the system may choose the most frequently used payment methods as the preferred payment method.

In some embodiments, the system may further be configured to determine one or more acceptable payment methods associated with a second user (e.g., a ride-hailing service provider) . For example, the system may determine that the second user can only accept cash and credit card as acceptable payment methods. The system may further be configured to determine the at least one payment method based on the one or more acceptable payment methods associated with the second user. For example, the system may choose a payment method that is both available to the first user and acceptable to the second user.

In some embodiments, the system may receive input from the first user indicating a confirmation of payment for the ride-hailing service, and use the determined at least one payment method or the determined preferred payment method to pay for the ride-hailing service.

FIG. 1 illustrates a schematic diagram of an exemplary system 100 for providing transportation services, according to embodiments of the disclosure. System 100 may include a payment method management server 102 (also referred to as server 102 for simplicity) . Server 102 can be a general-purpose server, or a proprietary device specially designed for providing transportation service. It is contemplated that, server 102 can be a stand-alone system (e.g., a server) or an integrated component of a stand-alone server. Because processing transportation service may require significant computation resources, in some embodiments, server 102 may be preferably implemented as a stand-alone system. In some embodiments, server 102 may have different modules in a single device, such as an integrated circuit (IC) chip (implemented as an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA)) , or separate devices with dedicated functions. In some embodiments, one or more components of server 102 may be located in a cloud or may be alternatively in a single location (such as inside a terminal device 110) or in distributed locations. Components of server 102 may be in an integrated device or distributed at different locations but communicate with each other through a network (not shown) .

In some embodiments, as shown in FIG. 1, server 102 may include a communication interface 104, a processor 106, and a memory/storage device 108. Although FIG. 1 shows communication interface 104, processor 106, and memory/storage device 108 all within one server 102, it is contemplated that these components may be distributed among multiple devices located close to or remotely from each other. In some embodiments, server 102 may be implemented in a cloud computing environment, or on a separate computer/server.

Communication interface 104 can be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection. As another example, communication interface 104 can be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links can also be implemented by communication interface 104. In such an implementation, communication interface 104 can send and receive electrical, electromagnetic or optical signals that carry digital data streams representing various types of information via a network. The network can typically include a cellular communication network, a Wireless Local Area Network (WLAN) , a Wide Area Network (WAN) , or the like.

Communication interface 104 may be configured to receive a ride-hailing (also referred to as ride-sharing or rideshare) service request from terminal device 110. A passenger terminal 110 may include any suitable device that can interact with a user, e.g., a smart phone, a tablet, a wearable device, a computer, or the like. The ride-hailing service request may include passenger information data 122 that may include a geographical location and historical payment methods of the passenger, a destination of the requested transportation service, a request time or the like. Generally, passenger position can be the same or substantially close to a location of the terminal device 110. However, it is contemplated that, passenger position can also differ from the location of the terminal device 110, even if the transportation service request is sent from terminal device 110. For example, a user can request a service from a computer for a friend, who is distant from this user. In that case, the user may manually provide passenger position on terminal device 110.

In some embodiments, the ride-hailing service request may be accepted by or otherwise matched with a service vehicle 130. Service vehicles 130 may include taxi cars or private cars enrolled with the O2O service platform. In some embodiments, service vehicles 130 may also include autonomous-driving vehicles. A service provider (e.g., a driver of vehicle 130) , through a driver terminal device, may choose whether to accept the request and confirm the transaction arrangement with terminal device 110. Communication interface 104 may be further configured to receive rider-hailing service provider information data 126 that may include acceptable payment methods of the rider-hailing service provider. In some embodiments, rider-hailing service provider information data 126 may also include service vehicle information such as service vehicle 130’s position, capacities, current driving directions, vehicle makers and models, as well as other features or characteristics associated with service vehicle 130. In some embodiments, service vehicle 130 may be associated with terminal devices such as navigation devices or mobile devices used by their drivers (e.g., smart phones, tablets, wearable devices, computers, or the like) . These terminal devices may communicate with server 102 and provide rider-hailing service provider information data 126 to server 102 via communication interface 104.

Processor 106 may include any appropriate type of general-purpose or special-purpose microprocessor, digital signal processor, or microcontroller. Processor 106 may be configured as a separate processor module dedicated to determining a payment method for rendering a payment for a ride-hailing service. Alternatively, processor 106 may be configured as a shared processor module for performing other functions unrelated to providing transportation service. Processor 106 may include one or more hardware units (e.g., portions of an integrated circuit) designed for use with other components or to execute part of a program. The program may be stored on a computer-readable medium, and when executed by processor 106, it may perform one or more functions relating to determining payment methods for rendering a payment for a ride-hailing service.

In some embodiments, processor 106 may be configured to decide one or more payment methods for rendering a payment for the ride-hailing service. For example, processor 106 may receive or determine the location information of a passenger (e.g., the pick-up location for the ride-hailing service) . In some embodiments, a payment method may be determined based on the geographical location associated with the pick-up request. For example, a payment method may be decided based on regulations pertinent to where the pick-up request is made (e.g., a city where the pick-up request is made may mandate ride-hailing service to be paid only by credit card or third-party payment platform) . If there are regulations about permissible payment methods, processor 106 may further be configured to determine if the geographical location of the ride falls within a predetermined geographical area subject to the governance of the regulations (e.g., the predetermined geographical area may correspond to the jurisdiction of local authority for enforcing the local regulations) . The determination may be made based on the pick-up point, the substantial part of the ride, the drop-off point, or the registration information of the passenger and/or service provider. The criterion used for determining whether the ride falls within the predetermined geographical area may be determined based on interpretation of the regulations (e.g., appropriate authorities may indicate that the criterion for determining whether the ride falls within a city’s jurisdiction depends on where the substantial parts of the ride happens) . In some embodiments, if the ride is determined to be not within the predetermined geographical area, processor may apply a different criterion to determine a payment method (e.g., to decide a payment method based on local custom, historical payment information of the passenger and/or acceptable payment methods of the service provider) .

In another example, a payment method may be decided based on local custom with respect to payment methods (e.g., people in a country or region may be used to pay for ride-hailing service by cash) . Available payment methods may include payment methods custom to local users. For instance, processor 106 may determine that a service request is made in country A based on passenger location information data 122. In country A, payment cards such as credit cards and debit cards may not be ubiquitous and most of the transactions may be made using cash payment. In this case, processor 106 may determine to choose cash payment as a payment method, or even prioritize the cash payment as the preferred payment method over other forms of payment methods. In another example, in country B, non-card-based online payment platforms such as Alipay ^TM may be ubiquitous despite a relatively low adoption rate of payment card-based payment methods. In this case, processor 106 may determine to choose such as non-card-based online payment method as an available payment method.

In some embodiments, a payment method may be decided based on historical payment information of the passenger. For example, processor 106 may determine if the historical payment information includes at least one pre-registered payment method. In some embodiments, if the historical payment information includes at least one pre-registered payment method and the pre-registered payment method include information of only one credit card, then processor 106 may select the credit card as an available payment method and provide the credit card as the preferred payment method to the passenger. If the pre-registered payment includes information of more than one credit cards, processor 106 may provide multiple credit cards as available payment method and may further choose the credit card most recently used by the passenger as the preferred payment method. If the pre-registered payment method includes no credit card information, processor 106 may choose a non-card-based pre-registered online payment method (e.g., the passenger may associate his or her Alipay ^TM account with the application) as an available payment method or use it as the preferred payment method. In another example, if there is no pre-registered payment method for the passenger, available payment methods may be determined based on one or more prior ride-hailing trips of the passenger (e.g., using point-of-service payment or cash payment) . If there is no prior ride-hailing trip for the passenger (e.g., the passenger is a new user or is using a new account) , processor 106 may decide using cash as an available or a preferred payment method for the passenger, or, provide no suggested payment method and leave it to the passenger to set up a payment method.

In another embodiments, processor 106 may dynamically adjust the payment method (s) for the passenger. For example, processor 106 may determine acceptable payment methods of the service provider (e.g., the service provider may only accept credit card and Alipay ^TM) based on ride-hailing service provider information data 126. The payment method depicted to the user may be determined or adjusted based on the acceptable payment methods of the service provider. For example, paying by credit card will be removed from the available payment method list if it is not one of the acceptable payment method (s) of the service provider. In another example, cash payment may be determined to be the payment method when the service provider (e.g., driver) only accepts cash.

In some embodiments, processor 106 may determine a payment method and/or a preferred payment method using learning models trained based on sample historical payment information and/or geographical information that are known to be associated with certain payment method preferences. For example, processor 106 may use transaction history data, such as sample users’ recently used payment methods e.g., during the last 20 payments or during the last month, types of payments method used, frequency of each type of payment method, the average consumption of the user on the ride-hailing service during a predetermined time period, such as per month, the location, duration, and/or starting time of each ride, etc. These sample features and any combination of the features with certain payment method preferences can be used as training data. Processor 106 may then train learning models (e.g., rule-based machine learning models) based on the training data. The trained model can then be applied to determine one or more payment methods and/or a preferred payment method.

Memory/storage device 108 may include any appropriate type of mass storage provided to store any type of information that processor 106 may need to operate. Memory/storage device 108 may be a volatile or non-volatile, magnetic, semiconductor-based, tape-based, optical, removable, non-removable, or other type of storage device or tangible (i.e., non-transitory) computer-readable medium including, but not limited to, a ROM, a flash memory, a dynamic RAM, and a static RAM. Memory/storage device 108 may be configured to store one or more computer programs that may be executed by processor 106 to manage and coordinate transportation service disclosed herein. For example, memory/storage device 108 may be configured to store program (s) that may be executed by processor 106 to determine suitable pick-up locations for the passenger.

Memory/storage device 108 may be further configured to store information and data used by processor 106. For instance, memory/storage device 108 may be configured to store the various types of data (e.g., ride-hailing service request, vehicle information, historical payment information, training models, etc. ) received by communication interface 104. Memory/storage device 108 may also store intermediate data such as available payment methods, acceptable payment methods, preferred payment method, etc. The various types of data may be stored permanently, removed periodically, or disregarded immediately after each frame of data is processed.

FIG. 2 is a block diagram depicting an exemplary terminal device 110. Terminal device 110 may include a communication interface 202, a processor 204, a memory/storage device 206, and a display 208. Communication interface 202 may be configured in a manner similar to communication interface 104. Communication interface 202 may facilitate communications between terminal device 110 and server 102. Processor 204 may have similar hardware structures as processor 106, and may include design features that focus on mobile usage. For example, processor 204 may include one or more hardware units (e.g., portions of an integrated circuit) designed for use with other components or to execute a part of a program. The program may be stored on a computer-readable medium (e.g., memory/storage device 206) , and when executed by processor 204, it may perform one or more functions that facilitate determination of payment methods for rendering a payment for a ride-hailing service. Memory/storage device 206 may also have similar structures as memory/storage device 108, and may include design features that focus on mobile usage.

Display 208 may include a display such as a Liquid Crystal Display (LCD) , a Light Emitting Diode Display (LED) , a plasma display, or any other type of display, and provide a Graphical User Interface (GUI) presented on the display for user input and data display. The display may include a number of different types of materials, such as plastic or glass, and may be touch-sensitive to receive commands from the user. For example, the display may include a touch-sensitive material that is substantially rigid, such as Gorilla Glass ^TM, or substantially pliable, such as Willow Glass ^TM.

In some embodiments, communication interface 202 may be configured to send or receive a ride-hailing service request made by a user (e.g., a passenger may use a passenger terminal device to send a request and a driver may use a driver terminal device to receive the request) . The ride-hailing service request may include passenger information 122. In some embodiments, passenger information 122 may include geographical location of the passenger which may be captured by positioning device such as a Global Positioning System (GPS) receiver built into terminal device 110. In some embodiments, passenger information 122 may also include historical payment information stored in memory/storage device 206 or memory/storage device 108 (e.g., historical payment information associated with the user’s account which may be stored in the cloud) . In some embodiments, communication interface 202 may provide the ride-hailing service request including passenger information 122 to server 102. In some embodiments, communication interface 202 may receive one or more payment methods and/or a preferred payment method from server 102, where processor 106 may determine the payment method (s) and/or preferred payment method. In some embodiments, terminal device 110 may determine the payment method (s) and/or preferred payment method using processor 204. In some embodiments, the payment method (s) and/or preferred payment method may be determined jointed by

processors

106 and 204. After the payment method (s) and/or preferred payment method is received or determined, processor 204 may control display 208 to depict the payment method (s) /preferred payment method as option (s) to the user on display 208.

When no preferred payment method is provided, the user may select a payment method from the available payment method (s) depicted on display 208, and confirm payment using the selected payment method. When a preferred method is provided, the preferred payment method may be selected automatically as a default option. The user may proceed directly to confirm the payment using the default payment method. If the user decides to use a payment method other than the preferred payment method, the user may select a different payment method. Communication interface 202 may provide the payment method used for rendering the payment to server 102. In some embodiments, communication interface 202 may further communicate with server 102 and/or a payment processing server (not shown) to render payment for the ride-hailing service using the selected payment.

In some embodiments, processor 204 may determine one or more payment methods and/or preferred payment method based on the geographical location and/or historical payment of the passenger. Processor 204 may also perform functions similar to processor 106, as described above. For example, processor 204 may be configured to perform one or more steps of determining the payment method (s) and/or preferred payment method, similar to processor 106.

FIG. 3 is a flowchart illustrating an exemplary method 300 for providing transportation service payment method determinations, consistent with disclosed embodiments. Method 300 may be implemented by server 102 and/or terminal device 110, each including at least one processor. In the description below, server 102 is used as an example for implementing method 300. It is contemplated that method 300 can also be implemented by terminal device 110, or jointly by server 102 and terminal device 110. Consistent with the present disclosure, method 300 determines at least one payment method and/or a preferred payment method for rendering a payment for a ride-hailing service request that has been matched with a service vehicle. Method 300 may include several steps as described below, some of which may be optional.

As shown in FIG. 3, method 300 may include steps 302-312. In step 302, server 102 may receive a service request (e.g., a ride-hailing service request) from a user (e.g., a passenger) . For example, the service request may be entered by the user on terminal device 110 and sent to server 102 through communication interface 202. Service vehicle 130 may be matched to the request to provide the service to the user.

In step 304, server 102 may determine location information associated with the user who requests the service. For example, server 102 may receive information that includes geographical information from terminal device 110 and determine the geographical location of the user. The geographical location may be the position of terminal device 110 as captured by a positioning device embedded therein, or a position provided by the user. For example, the user may use terminal device 110 or a personal computer to order a ride for a friend and set the pick-up location other than using the ordering device’s location. In some embodiments, the location information associated with the user may be determined based on the pick-up location of a ride-hailing service. In some embodiments, the location information associated with the user may be determined based on the drop-off location of a ride-hailing service. In some embodiment, the location information may be determined based on where the substantial part of a ride locates.

In step 306, server 102 may determine at least one payment method based on the location information. For example, server 102 may determine the location information of a user (e.g., the pick-up location for a ride-hailing service) . In some embodiments, a payment method may be determined based on geographic location of the pick-up request. For example, a payment method may be determined based on the regulations of where the pick-up request is made (e.g., a city where the pick-up request is located may mandate ride-hailing service to be compensated using only credit card or third-party payment platform) . If there are regulations about payment methods, server 102 may determine if the geographical location of the ride falls within a predetermined geographical area (e.g., the jurisdiction of local authority for enforcing the local regulations) . The determination may be made based on the pick-up point, the substantial part of the ride, the drop-off point, or the registration information of a passenger or service provider. The criterion used for determining whether the ride falls within the predetermined geographical area may be determined based on interpretation of the regulations (e.g., authorities may indicate that the criterion for determining whether the ride falls within the city’s jurisdiction depends on determining where the substantial parts of the ride happens) . In some embodiments, if the ride is determined to be not within the predetermined geographical area, server 102 may apply a different criterion to determine one or more payment methods (e.g., to decide a payment method based on local custom, historical payment information of the passenger and/or acceptable payment methods of the service provider) .

In another example, a payment method may be determined based on local custom of payment method (e.g., a city where most of the ride-hailing service is paid by cash) . The determined payment method (s) may include payment methods custom to local users.

In some embodiments, a payment method may be determined based on historical payment information of the user. For example, server 102 may determine if the historical payment information includes at least one pre-registered payment method. In some embodiments, if the historical payment information includes at least one pre-registered payment method and the pre-registered payment method include only one credit card information, then server 102 may select the credit card as a payment method. In some embodiments, server 102 may provide the credit card as the preferred payment method to the user. In some embodiments, if the pre-registered payment includes information of more than one credit cards, server 102 may choose the credit card that the user most recently used as the preferred payment method. In some embodiments, if the pre-registered payment method includes no credit card information, server 102 may choose a non-card-based pre-registered online payment method (e.g., the passenger associated his or her Alipay ^TM account with the application) as an available payment method. In another example, if there is no pre-registered payment method for the user, a payment method may be determined based on one or more prior ride-hailing trips (e.g., the user used point-of-service or cash for the last ride) . In some embodiments, if there is no prior ride-hailing trip for the user (e.g., the user is a new user or is using a new account) , server 102 may determine using cash payment as a payment method for the user.

In another embodiments, server 102 may acquire or otherwise receive acceptable payment methods of the service provider (e.g., the service provider may only accept credit card and Alipay ^TM) based on ride-hailing service provider information data 126. Server 102 may dynamically adjust the payment method (s) and/or the preferred payment method based on the acceptable payment method (s) of the service provider (e.g., paying by credit card will be removed from the available payment method list if it is not one of the acceptable payment method of the service provider) .

In some embodiments, the at least one payment method and/or preferred payment method may be determined using learning models trained based on sample historical payment information and/or geographical information that are known to be associated with certain payment method preferences. For example, sever 102 may use transaction history data such as sample users’ payment methods used in recently payments, types of payments methods used, frequency of each type of payment method used, the average consumption of the user on the ride-service within a predetermined time period, the location, duration, and/or starting time of each ride, etc. Such information can be used as sample features. Server 102 may combine the features with certain payment method preferences as training data. Server 102 may then train learning models (e.g., rule-based machine learning models) based on the training data. The trained model (s) can then be applied to determine a payment method and/or a preferred payment method.

In step 308, server 102 may provide a depiction of at least one payment method on a display of the terminal device. In the example shown by FIG. 4, display 208 may include two parts: detailed trip information 402 and available payment methods 404. In some embodiments, detailed trip information 402 may include the pick-up location, drop-off location, the route of the ride, the distance of the ride, estimate cost of the ride, estimate time of the ride, etc. In some embodiments, display 208 may present one or more payment methods 404 for the passenger to choose from (e.g., display 208 may present the one or more payment methods in a bar list as illustrated in FIG. 4) . It is contemplated that display 208 may present payment method (s) 404 in other forms (e.g., a chart or using icons to represent different available payment methods) . In some embodiments, display 208 may present a preferred payment method on the top of the bar list. For example, the preferred payment method may be set as the default payment method and presented in a “selected” state such that the passenger may render the payment by confirming the selection (e.g., by clicking “Pay, ” “Confirm, ” or similar indicators) without bringing up the list of the available payment methods.

In step 310, server 102 may receive or otherwise acquire input from the user indicating a confirmation of payment using a selected payment method. The selected payment method may be one of the available payment methods depicted on the display of the terminal device. For example, in the example shown by FIG. 4, the user may choose one of the available payment methods from the bar list to render the payment for the ride-hailing service. In some embodiments, where a preferred payment method is determined by server 102, the preferred payment method may be presented on the top of the bar list and the preferred method may be used as a default payment method for the service if the user does not select otherwise.

In step 312, server 102 may render the payment for the ride-hailing service using the selected payment method. Server 102 may send an instruction to a payment module (not shown) instructing the payment to be made using the selected payment method. In another embodiments, server 102 may render the payment for the ride-hailing service using the default payment method. For example, if server 102 determines to use a pre-registered credit card as the default payment method for the ride and the user does not select otherwise, server 102 may send an instruction to the payment module instructing using the pre-registered credit card as the payment method for the ride. It is contemplated that the payment module may or may not be part of the system 100. For example, the payment module may be integrated with server 102 or terminal device 110, or, as a stand-alone system independent from system 100.

In some embodiments, an account balance feature may be provided as an available payment method. For example, the account balance may be built in to a ride-hailing service application to allow a user to deposit fund into his/her account balance using other payment methods, such as credit/debit cards and online payment platforms (e.g., Alipay ^TM, Paypal ^TM, etc. ) . The user can then use the account balance to pay for a ride. In some embodiments, the user can deposit fund into the account balance using different currencies according to the local currency being used. For example, frequent user in China where the local currency is Chinese Yuan may choose to deposit fund into the account balance using Chinese Yuan. In this way, the account balance may be in Chinese Yuan. In another embodiment, a user may frequently use the ride-hailing service in different countries and/or regions where the local currencies are different (e.g., a frequent international traveler may frequently use the ride-hailing service in United States of America and China) . The user may have different account balances presented in different currencies (e.g., the traveler may have an account balance in US dollar and another account balance in Chinese Yuan in the above example) .

In some embodiments, processor 106 may, based on the location information, choose an account balance that uses a currency matching the location of the user. For example, when a passenger uses the ride-hailing service at his/her home country, the account balance using the home country currency may be selected. When the passenger travels to a foreign country, processor 106 may, based on the location information, choose the account balance using the currency of the foreign country as the payment method. In some embodiments, the location of the passenger may be determined based on the roaming status of the terminal device. For example, when the terminal device, such as a mobile phone, enters a roaming mode, the location information (e.g., country or region) may be determined based on telecommunication information associated with the roaming mode.

In some embodiments, the account balance in the local currency may be determined as the preferred payment method (e.g., account balances in other currency may be marked as unavailable when selecting a preferred payment method for the user) .

In some embodiments, the user may find it advantageous to use the account balance as a preferred payment method because promotions may be available rewarding the user to use the account balance. For example, when the user deposit fund into the account balance, additional credits may be issued to the account balance as an incentive (e.g., paying $100 to add $120 worth of credits) . In another example, when the frequency of use of an account balance is higher than a predetermined threshold (e.g., 20 times a month) , additional credits may also be issued to the account balance as an incentive. In another example, rewards and incentives may be provided as part of advertisement or promotions. For instance, the user may receive vouchers from the O2O service platform or third-party business partners (e.g., shopping portals, stores, entertainment providers, etc. ) and deposit fund into the account balance using the vouchers. In some embodiments, the vouchers may be provided in the form of a bar code or two-dimensional code that the user may scan to deposit fund into the account balance. In some embodiments, the vouchers may be provided in the form of a passcode combination, and the user may input the combination into the ride-hailing application to deposit fund into the account balance. In some embodiments, credits may be issued to a user who frequently uses the ride-hailing service (e.g., by accumulating a certain number of mileages, or reach a certain number of requests or payments) . Other forms of promotional means may also be used to provide incentives for the user to use the account balance as the preferred payment method.

In some embodiments, the account balance may be selected as the preferred payment method for rendering a payment for a ride-hailing service. FIG. 5 shows an exemplary user interface depicting that the account balance 504 is being selected as a default payment method when making a payment to the ride-hailing service provider. The user may confirm the payment using the account balance by clicking the confirmation button 506, without making additional selection of payment methods. This streamlined process reduces the time required to make payments, improves the efficiency and user experience. In addition, as discussed above, using account balance as the payment method makes it possible to incentivize users for using the ride-hailing service, providing enhanced value to the users.

In some embodiments, the account balance may be treated similarly to other payment methods discussed above, such as payment card-based, online payment platform-based, point-of-service-based, and cash-based payment methods. In making a determination as to which payment method (s) are selected to be the available payment methods and/or preferred payment methods, account balance may be equally or more favorably considered compared to other payment methods. In some embodiments, account balance may also be used in combination with one or more other forms of payment methods. For example, when the available credit in the account balance is less than the requirement service fare, the remaining credit may be applied first to render the payment, with the remaining portion paid by, for example, a credit card or an online payment platform-based payment method.

FIG. 6 illustrate an exemplary work flow 600 of determining a payment method, according to some embodiments. Flow 600 starts from step 602, in which the determination of a payment method commences. Step 602 may be triggered by a passenger’s selection of a destination before requesting a ride-hailing service, by a driver’s acceptance of the request, by a confirmation of picking up, by a indication of arrival of the destination, by a display of payment interface, or the like. As shown in FIG. 6, step 602 proceeds to step 604, in which processor 106/204 may determine if the passenger has a pre-registered online payment method, including a payment card-based payment method (e.g., a credit card or debit card) , an online payment platform-based payment method (e.g., Paypal ^TM, Alipay ^TM) , etc. If so, then flow 600 proceeds along the “Yes” branch to step 606, in which processor 106/204 further determines if the pre-register online payment method is payment card-based. If so, then flow 600 proceeds along the “Yes” branch to step 608, in which processor 106/204 select the most recently added payment card as the default payment method for providing to the passenger. Otherwise, flow 600 proceeds along the “No” branch to step 610, in which processor 106/204 select an online payment platform-based payment method as the default payment method.

Returning to step 604, if processor 106/204 determines that no pre-registered online payment method is available, then flow 600 proceeds along the “No” branch to step 612, in which processor 106/204 further determines whether a record of the last used payment method exists. If so, flow 600 proceeds along the “Yes” branch to step 614, in which the last used payment method is selected as the default payment method. The last used payment method may include cash payment, POS payment, etc. Otherwise, flow 600 proceeds along the “No” branch to step 616, in which processor 106/204 determines if the location of the ride (e.g., request location, pick-up location, drop-off location, location of a substantial part of the trip, etc. ) falls within a no-cash zone (e.g., Mexico City) . If so, flow 600 proceeds along the “Yes” branch to step 618, in which processor 106/204 provides no default payment method selection. Instead, it is left to the passenger to decide which payment method should be used. If the location of the ride does not fall within the no-cash zone, then flow 600 proceeds along the “No” branch to step 620, in which cash payment method is selected as the default payment method.

FIG. 7 illustrates an exemplary work flow 700 for using account balance as a preferred payment method, according to some embodiments. Flow 700 starts at step 702, which may be triggered by, for example, a user requesting a ride-hailing service. Flow 700 then proceeds to step 704, in which processor 106/204 determines if the user is new to the account balance feature. If so, flow 700 proceeds along the “Yes” branch to use the account balance for the first time. If it is determined that the user is not a new user, then flow 700 proceeds along the “No” branch to step 706, in which processor 106/204 determines if the user used the account balance as the payment method to pay for the last trip. If so, then flow 700 proceeds along the “Yes” branch to use the account balance, which leads to step 710. In step 710, processor 106/204 determines if the available balance in the account is equal to or larger than the service fare (e.g., an estimated or actual service fare) . If so, then flow 700 proceeds along the “Yes” branch to step 712, in which the account balance is used as the preferred payment method. Returning to step 710, if it is determined that the balance in the account is less than the service fare, then flow 700 proceeds along the “No” branch to step 714, in which processor 106/204 determines if there is any pre-registered payment cards. If so, then flow 700 proceeds along the “Yes” branch to step 716, in which a combined payment method is used. For example, the combination may include the available balance in the account and a last used/recently added payment card to pay for the remaining portion of the service fare. Returning to step 714, if there is no pre-registered payment card, then flow 700 proceeds along the “No” branch to step 718, in which processor 106/204 determines if the ride falls within a no-cash zone, similar to step 616. If not, then flow 700 proceeds along the “No” branch to step 720, in which an off-line payment method is used, such as cash payment or POS payment. If it is determined that the ride falls within a no-cash zone at step 718, then flow 700 proceeds along the “Yes” branch to step 722, in which processor 106/204 requires the user to register a payment card or an online payment platform-based payment method.

Returning to step 706, if it is determined that the user did not use the account balance as the payment method in the last trip, then flow 700 proceeds along the “No” branch to step 708, in which the most recent payment method is used as the preferred payment method.

FIG. 8 illustrates an exemplary work flow 800 for using account balance as a payment method based on location information. Flow 800 starts at step 802. Step 802 may be triggered by, for example, a user opening a payment interface. In step 804, processor 106/204 determines whether a terminal device associated with the user is roaming. For example, the terminal device (e.g., a mobile phone) is roaming when it is operating outside its home country/region. Therefore, based on the roaming status, processor 106/204 may determine if the terminal device is operating in its home country/region or a foreign country/region. If it is determined that the terminal device is roaming, then flow 800 proceeds along the “Roaming” branch to step 806, in which it is determined if an account balance corresponding to the country/region where the terminal device is currently roaming in exists or is available. If not, then flow 800 proceeds along the “No” branch to step 808, in which the account balance is not displayed to the user. Otherwise, flow 800 proceeds along the “Yes” branch to step 810, in which the account balance is displayed. For example, the account balance may hold a balance in a currency corresponding to the foreign country/region currently roaming in. In another example, account balance (s) in other currencies may not be displayed or may be displayed in a non-selectable manner. Returning to step 804, when it is determined that the terminal device is not roaming, then flow 800 proceeds along the “No roaming” branch to step 812, in which processor 106/204 determines if an account balance exists. If no, then flow 800 proceeds along the “No” branch to step 814, in which the account balance is not displayed. Otherwise, flow 800 proceeds along the “Yes” branch to step 816, in which processor 106/204 determines if the available balance is greater than zero. If not, then flow 800 proceeds along the “No” branch to step 818, in which a zero balance is displayed. Otherwise, flow 800 proceeds along the “Yes” branch to step 820, in which processor 106/204 determines if the user is new to the account balance feature (e.g., the user hasn’ t used the account balance to pay for any ride) . If so, then flow 800 proceeds along the “Yes” branch to step 822, in which the account balance or a combination of account balance and one or more online payment methods is used, similar to the sub flow of flow 700 starting at step 710. If, on the other hand, the account balance is not a new payment method, then flow 800 proceeds along the “No” branch to step 824, in which a last used payment method is selected.

In some embodiments, processor 106/204 may determine a payment method from a variety of payment methods, such as payment card-based methods (e.g., credit card payment, debit card payment, etc. ) , online payment platform-based payment methods (e.g., Paypal ^TM, Alipay ^TM, etc. ) , account balance (e.g., one or more payment accounts registered with the O2O service platform) , POS payment (e.g., offline payments using a POS terminal) , cash payment, etc.

Another aspect of the disclosure is directed to a non-transitory computer-readable medium storing instructions which, when executed, cause one or more processors to perform the methods, as discussed above. The computer-readable medium may include volatile or non-volatile, magnetic, semiconductor-based, tape-based, optical, removable, non-removable, or other types of computer-readable medium or computer-readable storage devices. For example, the computer-readable medium may be the storage device or the memory module having the computer instructions stored thereon, as disclosed. In some embodiments, the computer-readable medium may be a disc or a flash drive having the computer instructions stored thereon.

It will be apparent to those skilled in the art that various modifications and variations can be made to the disclosed system and related methods. Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice of the disclosed system and related methods.

It is intended that the specification and examples be considered as exemplary only, with a true scope being indicated by the following claims and their equivalents.

Claims

A computer-implemented method for determining a payment method for rendering a payment for a service provided via an online-to-offline (O2O) service platform, comprising:

receiving, from a first user, a request for the service;

determining location information associated with a terminal device associated with the first user;

determining at least one payment method based on the location information; and

providing a depiction of the at least one payment method on a display of the terminal device.
The method of claim 1, wherein:

the location information comprises a geographical location of the terminal device; and

the method further comprises:

determining whether the geographical location falls within a predetermined geographical area; and

in response to a determination that the geographical location falls within a predetermined geographical area, determining the at least one payment method based on a first criterion corresponding to the predetermined geographical area.
The method of claim 2, wherein:

the first criterion comprises regulations in the predetermined geographical area; and

the method further comprises determining the at least one payment method based on the regulations such that using the at least one payment method within the predetermined geographical area complies with the regulations.
The method of claim 2, wherein:

the first criterion comprises one or more payment methods custom to users in the predetermined geographical area; and

the method further comprises determining the at least one payment method based on the one or more payment methods custom to the users in the predetermined geographical area.
The method of claim 2, wherein:

the first criterion comprises a currency used in the predetermined geographical area; and

the method further comprises determining the at least one payment method based on the currency used in the predetermined geographical area.
The method of any of claims 1 to 5, wherein:

the at least one payment method includes a preferred payment method; and

the method further comprises:

determining the preferred payment method based on the location information; and

providing a depiction of the preferred payment method as a default payment method on the display of the terminal device.
The method of claim 6, further comprising:

determining whether the first user has at least one pre-registered payment method registered on the O2O service platform;

in response to a determination that the first user has at least one pre-registered payment method, determining the preferred payment method based on the at least one pre-registered payment method.
The method of claim 7, further comprising:

determining whether the at least one pre-registered payment method includes information of one or more pre-registered payment cards; and

in response to a determination that the at least one pre-registered payment method includes information of one or more pre-registered payment cards, selecting a most recently registered payment card as the preferred payment method.
The method of claim 6, further comprising:

determining whether the first user has an account balance associated with the O2O service platform;

in response to a determination that the first user has an account balance, determining the preferred payment method based on an available balance in the account balance.
The method of claim 9, further comprising:

selecting the account balance as the preferred payment method when the available balance is equal to or higher than a service fare of the service.
The method of claim 9, further comprising:

selecting the account balance and a secondary payment method as the preferred payment method when the available balance is lower than a service fare of the service, wherein the secondary payment method is used to pay for a difference between the service fare and the available balance of the account balance.
The method of any of claims 6 to 11, further comprising:

determining whether the first user used at least one past payment method in one or more prior services;

in response to a determination that the first user used at least one past payment method in one or more prior services, selecting a most recently used past payment method as the preferred payment method.
The method of any of claims 1 to 12, further comprising:

determining one or more acceptable payment methods associated with a second user, the second user providing the service to the first user; and

determining the at least one payment method based on the one or more acceptable payment methods associated with the second user.
The method of any of claims 1 to 13, further comprising:

receiving input from the first user indicating a confirmation of payment for the service; and

rendering the payment for the service using the at least one payment method.
A system for determining a payment method for rendering a payment for a service provided via an online-to-offline (O2O) service platform, comprising:

a communication interface configured to:

receive, from a first user, a request for the service;

at least one memory; and

at least one processor coupled to the communication interface and the at least on memory, wherein the at least one processor is configured to:

determine location information associated with a terminal device associated with the first user;

determine at least one payment method based on the location information; and

provide a depiction of the at least one payment method on a display of the terminal device.
The system of claim 15, wherein:

the location information comprises a geographical location of the terminal device; and

the at least one processor is further configured to:

determine whether the geographical location falls within a predetermined geographical area; and

in response to a determination that the geographical location falls within a predetermined geographical area, determine the at least one payment method based on a first criterion corresponding to the predetermined geographical area.
The system of claim 16, wherein:

the first criterion comprises regulations in the predetermined geographical area; and

the at least one processor is further configured to determine the at least one payment method based on the regulations such that using the at least one payment method within the predetermined geographical area complies with the regulations.
The system of claim 16, wherein:

the first criterion comprises one or more payment methods custom to users in the predetermined geographical area; and

the at least one processor is further configured to determine the at least one payment method based on the one or more payment methods custom to the users in the predetermined geographical area.
The system of claim 16, wherein:

the first criterion comprises a currency used in the predetermined geographical area; and

the at least one processor is further configured to determine the at least one payment method based on the currency used in the predetermined geographical area.
The system of any of claims 15 to 19, wherein:

the at least one payment method includes a preferred payment method; and

the at least one processor is further configured to:

determine the preferred payment method based on the location information; and

provide a depiction of the preferred payment method as a default payment method on the display of the terminal device.
The system of claim 20, wherein the at least one processor is further configured to:

determine whether the first user has at least one pre-registered payment method registered on the O2O service platform;

in response to a determination that the first user has at least one pre-registered payment method, determine the preferred payment method based on the at least one pre-registered payment method.
The system of claim 21, wherein the at least one processor is further configured to:

determine whether the at least one pre-registered payment method includes information of one or more pre-registered payment cards; and

in response to a determination that the at least one pre-registered payment method includes information of one or more pre-registered payment cards, select a most recently registered payment card as the preferred payment method.
The system of claim 20, wherein the at least one processor is further configured to:

determine whether the first user has an account balance associate with the O2O service platform;

in response to a determination that the first user has an account balance, determine the preferred payment method based on an available balance in the account balance.
The system of claim 23, wherein the at least one processor is further configured to:

select the account balance as the preferred payment method when the available balance is equal to or higher than a service fare of the service.
The system of claim 23, wherein the at least one processor is further configured to:

select the account balance and a secondary payment method as the preferred payment method when the available balance is lower than a service fare of the service, wherein the secondary payment method is used to pay for a difference between the service fare and the available balance of the account balance.
The system of any of claims 20 to 25, wherein the at least one processor is further configured to:

determine whether the first user used at least one past payment method in one or more prior services;

in response to a determination that the first user used at least one past payment method in one or more prior services, select a most recently used past payment method used as the preferred payment method.
The system of any of claims 15 to 26, wherein the at least one processor is further configured to:

determine one or more acceptable payment methods associated with a second user, the second user providing the service to the first user; and

determine the at least one payment method based on the one or more acceptable payment methods associated with the second user.
The system of any of claims 15 to 27, wherein the at least one processor is further configured to:

receive input from the first user indicating a confirmation of payment for the service; and

render the payment for the service using the at least one payment method.
A non-transitory computer-readable medium that stores a set of instructions, when executed by at least one processor of an electronic device, cause the electronic device to perform a method for determining a payment method for rendering a payment for a service provided via an online-to-offline (O2O) service platform, the method comprising:

receiving, from a first user, a request for the service;

determining location information associated with a terminal device associated with the first user;

determining at least one payment method based on the location information; and

providing a depiction of the at least one payment method on a display of the terminal device.
The non-transitory computer-readable medium of claim 29, wherein:

the location information comprises a geographical location of the terminal device; and

the method further comprises:

determining whether the geographical location falls within a predetermined geographical area; and

in response to a determination that the geographical location falls within a predetermined geographical area, determining at least one payment method based on a first criterion corresponding to the predetermined geographical area.
The non-transitory computer-readable medium of claim 29 or 30, wherein:

the at least one payment method includes a preferred payment method; and

the method further comprises:

determining the preferred payment method based on the location information; and

providing a depiction of the preferred payment method as a default payment method on the display of the terminal device.
The non-transitory computer-readable medium of any of claims 29 to 31, wherein the method further comprises:

determining one or more acceptable payment methods associated with a second user, the second user providing the service to the first user; and

determining the at least one payment method based on the one or more acceptable payment methods associated with the second user.
The non-transitory computer-readable medium of any of claims 29 to 32, wherein the method further comprises:

receiving input from the first user indicating a confirmation of payment for the service; and

rendering the payment for the service using the at least one payment method.