CN111417973A - 用于确定支付线上到线下服务的支付方法的方法和系统 - Google Patents

用于确定支付线上到线下服务的支付方法的方法和系统 Download PDF

Info

Publication number
CN111417973A
CN111417973A CN201880043896.8A CN201880043896A CN111417973A CN 111417973 A CN111417973 A CN 111417973A CN 201880043896 A CN201880043896 A CN 201880043896A CN 111417973 A CN111417973 A CN 111417973A
Authority
CN
China
Prior art keywords
payment method
payment
user
determining
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201880043896.8A
Other languages
English (en)
Inventor
杨凯
高珂
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Didi Infinity Technology and Development Co Ltd
Original Assignee
Beijing Didi Infinity Technology and Development Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Didi Infinity Technology and Development Co Ltd filed Critical Beijing Didi Infinity Technology and Development Co Ltd
Publication of CN111417973A publication Critical patent/CN111417973A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3224—Transactions dependent on location of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4015—Transaction verification using location information

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

用于向用户提供线上到线下(O2O)服务的系统和方法。所述方法包括：从第一用户接收对服务的请求(302)；确定与所述第一用户的关联终端设备相关联的位置信息(304)；基于所述位置信息确定至少一种支付方法(306)；在所述终端设备的显示器上提供所述至少一种支付方法的描述(308)。

Description

用于确定支付线上到线下服务的支付方法的方法和系统
技术领域
本申请涉及线上到线下(O2O)服务，更具体地，涉及用于自动确定用于支付O2O服务的支付方法的方法和系统。
背景技术
线上到线下(O2O)服务平台(例如，DiDiTM在线)可以接收来自乘客的服务请求，例如约车(也称为共乘或拼车)服务请求，然后将服务请求路线发送到至少一个服务提供者(例如，出租车司机、私人车主等)。在完成服务后，乘客需要为所获得的服务向服务提供者付款。
一些网约平台要求乘客在他或她可以提出约车服务请求之前，将至少一张有效信用卡与乘客的约车帐户相关联。然而，在许多国家或地区，根据当地的传统和习俗，与其他国家和地区相比，无现金支付使用率较低。同时，在某些国家或地区，根据当地法律、规定或政策的要求，可能禁止使用至少一种支付方法。要求使用信用卡和/或现金作为全球范围内唯一的支付方法，可能会阻止在某些国家和地区的拼车服务的使用。在一些国家和地区，一些网约车平台提供所有可能的支付方法供乘客选择，在乘客提出服务请求时，乘客需要至少点击两次以选择支付服务的支付方法，从而延长进行支付的平均时间。因此，当前的系统面临着提供多元化支付方法和简化支付流程之间的两难选择。此外，当用户漫游到这样的区域时，当前系统缺乏自动地使支付方法适应于不同国家或地区的能力。
本申请的实施例通过用于自动确定支付线上到线下服务的适当支付方法的方法和系统来解决上述问题。
发明内容
本申请的实施例提供了用于确定支付方法的示例性方法，该支付方法用于支付经由线上到线下服务平台提供的服务。该方法可以包括从第一用户接收对所述服务的请求。该方法还可以包括确定与所述第一用户的关联终端设备相关联的位置信息。该方法还可以包括基于所述位置信息确定至少一种支付方法，并在终端设备的显示器上提供所述至少一种支付方法的描述。
本申请的实施例还提供了一种系统，用于确定支付经由线上到线下服务平台提供的服务的支付方法。该系统可以包括通信接口、至少一个存储器，以及连接到所述通信接口和所述至少一个存储器的至少一个处理器。所述通信接口可以被配置为从第一用户接收对所述服务的请求。所述至少一个处理器可以被配置为确定与第一用户的关联终端设备相关联的位置信息。所述至少一个处理器还可以被配置为基于所述位置信息确定至少一种支付方法。所述至少一个处理器还可以被配置为在终端设备的显示器上提供所述至少一种支付方法的描述。
本申请的实施例还提供了一种非暂时性计算机可读介质。非暂时性计算机可读介质可以存储一组指令，当电子设备的至少一个处理器执行所述指令时，使所述电子设备执行一种方法，用于确定支付经由线上到线下服务平台提供的服务的支付方法。该方法可以包括从第一用户接收对所述服务的请求。该方法还可以包括确定与第一用户的关联终端设备相关联的位置信息。该方法还可以包括基于所述位置信息确定至少一种支付方法。另外，该方法可以包括在终端设备的显示器上提供所述至少一种支付方法的描述。
应当理解，前面的一般性描述和下面的详细描述都只是示例性和说明性的，并不是对要求保护的本发明的限制。
附图说明
图1示出了根据本申请的实施例的用于确定支付通过线上到线下服务平台提供的服务的支付方法的示例性系统的示意图；
图2示出了根据本申请的实施例的示例性终端设备的框图；
图3示出了根据本申请的实施例的用于确定支付通过线上到线下服务平台提供的服务的支付方法的示例性方法的流程图；
图4示出了根据本申请的实施例的示例性用户界面，其示出了一组可用支付方法的；
图5示出了根据本申请的实施例的示例性用户界面，其示出了账户余额被用作首选支付方法；
图6示出了根据本申请的实施例的确定支付方法的示例性工作流程；
图7示出了根据本申请的实施例的使用账户余额作为首选支付方法的示例性工作流程；以及
图8示出了根据本申请的实施例的使用账户余额作为基于位置信息的支付方法的示例性工作流程。
具体实施方式
现在将详细参考示例性实施例，其示例在附图中示出。只要有可能，在整个附图中将使用相同的附图标记来表示相同或相似的部分。
本申请的实施例提供了用于支付通过线上到线下(O2O)服务平台提供的服务的系统和方法。通过O2O服务平台提供的服务可以包括运输服务，例如约车服务、递送服务(例如，食品递送和/或货物递送)、自行车共享服务或促进使用在线服务工具的用户之间的离线交互的其他服务。在下文中，约车服务用作各种实施例的描述中的示例。然而，本申请中披露的技术方案不限于为约车服务提供支付。相反，技术解决方案可适用于通过O2O服务平台提供的任何服务的支付，包括离线提供的服务的支付。
在一些实施例中，系统可以配置为从第一用户(例如，乘客)接收对约车服务的请求。第一用户可以使用终端设备来发出请求。终端设备可以包括例如由请求服务的乘客使用的移动电话、可穿戴设备、GPS设备等。在一些实施例中，在接收到约车服务请求时，系统还可以配置为确定与终端设备相关联的位置信息。例如，位置信息可以包括终端设备的地理位置，例如国家、区域、城市等，其可以对应于乘客进行约车服务请求的位置。
在一些实施例中，在接收到约车服务请求之后，系统可以配置为基于位置信息确定至少一种支付方法。例如，系统可以在确定终端设备的地理位置属于预定地理区域之后，基于所述预定地理区域的规定确定至少一种支付方法，使得在所述预定地理区域中使用所述至少一种支付方法符合所述规定。
在另一示例中，系统可以基于所述预定地理区域中的用户习惯的一种或以上支付方法确定所述至少一种支付方法。例如，如果系统确定与第一用户相关联的终端设备位于现金是最流行的支付方法的国家或区域内，则系统可以在所述至少一种支付方法中包括现金支付。
在另一示例中，系统可以基于所述预定地理区域中使用的货币确定所述至少一种支付方法。例如，系统可以被配置为提供钱包功能以持有与第一用户相关联的账户余额，并且钱包可以在单独的子账户中包含多种货币。基于位置信息系统可以确定终端设备所位于的地理区域(例如，国家、区域等)，并确定与所确定的地理区域中使用的货币对应的支付方法。
在基于位置信息确定至少一种支付方法之后，系统可以被配置为在终端设备的显示器上提供至少一种支付方法的描述。例如，系统可以将至少一种支付方法的全部或一部分提供给终端设备，并且终端设备的显示器可以描绘至少一种支付方法的全部或部分(例如，在终端设备的显示器上呈现可用支付方法的列表)。
在一些实施例中，系统可以被配置为基于位置信息确定首选支付方法。例如，首选支付方法可以是上面讨论的至少一种支付方法之一。例如，可以通过在终端设备的显示器上描绘首选支付方法作为默认支付方法，将第一支付方法提供给第一用户。然后，第一用户可以使用默认支付方法来支付服务费。
可以以各种方式确定首选支付方法。例如，系统可以被配置为确定第一用户是否具有在O2O服务平台上登记的至少一个预先登记的支付方法。例如，在作出约车服务请求之前，第一用户可能已经将信用卡登记为支付方法。如果存在一个或以上预先登记的支付方法，则系统可以从预先登记的支付方法中选择作为首选支付方法。例如，如果预先登记的支付方法包括支付卡，例如信用卡或借记卡，则系统可以选择支付卡作为首选支付方法。
在一些实施例中，系统可以选择账户余额(例如，与第一用户相关联的电子钱包)作为首选支付方法。根据账户余额中的可用余额，当可用余额等于或高于服务费时，系统可以选择使用账户余额支付整个服务费，或者使用账户余额和第二支付方法一起支付服务费。例如，系统可以首先耗尽账户余额，然后将服务费的剩余部分向第二支付方法收费。
在另一示例中，系统可以基于第一用户针对最后一个或以上先前的约车行程所使用的至少一个历史支付方法确定首选支付方法。例如，第一用户可以在最近十次交易期间使用信用卡八次，并且对于其余两次交易，可以使用非基于卡的在线支付方法，例如AlipayTM。例如，系统可以选择最近使用的支付方法作为首选支付方法。在一些实施例中，系统可以选择最常用的支付方法作为首选支付方法。
在一些实施例中，系统还可以被配置为确定与第二用户(例如，约车服务提供者)相关联的一个或以上可接受的支付方法。例如，系统可以确定第二用户只能接受现金和信用卡作为可接受的支付方法。系统还可以配置为基于与第二用户相关联的一个或以上可接受的支付方法确定至少一种支付方法。例如，系统可以选择第一用户可用且第二用户可接受的支付方法。
在一些实施例中，系统可以从第一用户接收指示确认支付约车服务的输入，并使用所确定的至少一种支付方法或所确定的首选支付方法来支付约车服务。
图1示出了根据本申请的实施例的用于提供运输服务的示例性系统100的示意图。系统100可以包括支付方法管理服务器102(为简单起见，也称为服务器102)。服务器102可以是通用服务器，或专门设计用于提供运输服务的专有设备。可以设想，服务器102可以是独立系统(例如，服务器)或独立服务器的集成组件。因为处理运输服务可能需要大量计算资源，所以在一些实施例中，服务器102可以优选地实现为独立系统。在一些实施例中，服务器102可以在单个设备中具有不同的模块，例如集成电路(IC)芯片(实现为专用集成电路(ASIC)或现场可编程门阵列(FPGA))，或具有专用功能的单独设备。在一些实施例中，服务器102的一个或以上组件可以位于云中，或者可以在单个位置(诸如在终端设备110内)或在分布式位置中。服务器102的组件可以在集成设备中或分布在不同位置，但是通过网络(未示出)彼此通信。
在一些实施例中，如图1所示，服务器102可以包括通信接口104、处理器106和内存/存储设备108。尽管图1示出了在一个服务器102内的通信接口104、处理器106和内存/存储设备108，但是可以预期这些组件可以分布在彼此靠近或远离的多个设备之间。在一些实施例中，服务器102可以在云计算环境中实现，或者在单独的计算机/服务器上实现。
通信接口104可以是综合业务数字网(ISDN)卡、电缆调制解调器、卫星调制解调器或调制解调器，以提供数据通信连接。又例如，通信接口104可以是局部区域网络(LAN)卡，以提供与兼容LAN的数据通信连接。无线链路也可以由通信接口104实现。在这样的实现中，通信接口104可以发送和接收电信号、电磁信号或光信号，该信号携带表示经由网络的各种类型信息的数字数据流。网络通常可以包括蜂窝通信网络、无线局部区域网络(WLAN)、广域网络(WAN)等。
通信接口104可以配置为从终端设备110接收约车(也称为共乘或拼车)服务请求。乘客终端110可以包括可以与用户交互的任何合适的设备，例如智能电话、平板电脑、可穿戴设备、计算机等。约车服务请求可以包括乘客信息数据122，其可以包括乘客的地理位置和历史支付方法，所请求的运输服务的目的地、请求时间等。通常，乘客位置可以与终端设备110的位置相同或基本接近。然而，可以设想，即使从终端设备110发送运输服务请求，乘客位置也可以与终端设备110的位置不同。例如，用户可以为朋友(远离该用户)从计算机请求服务。在那种情况下，用户可以在终端设备110上手动提供乘客位置。
在一些实施例中，约车服务请求可以由服务车辆130接受或以其他方式与服务车辆130匹配。服务车辆130可以包括在O2O服务平台上登记的出租车或私家车。在一些实施例中，服务车辆130还可以包括自动驾驶车辆。服务提供者(例如，车辆130的司机)通过司机终端设备可以选择是否接受该请求，并用终端设备110确认交易安排。通信接口104可以进一步配置为接收约车服务提供者信息数据126，其可以包括约车服务提供者可接受的支付方法。在一些实施例中，约车服务提供者信息数据126还可以包括服务车辆信息，例如服务车辆130的位置、运力、当前驾驶方向、车辆制造商和型号，以及与服务车辆130相关联的其他特征或特性。在一些实施例中，服务车辆130可以与终端设备相关联，诸如导航设备或其司机使用的移动设备(例如，智能电话、平板电脑、可穿戴设备、计算机等)。这些终端设备可以与服务器102通信，并且经由通信接口104向服务器102提供约车服务提供者信息数据126。
处理器106可以包括任何适当类型的通用或专用微处理器、数字信号处理器或微控制器。处理器106可以配置为单独的处理器模块，专用于确定用于支付约车服务的支付方法。或者，处理器106可以配置为共享处理器模块，用于执行与提供运输服务无关的其他功能。处理器106可以包括设计用于与其他组件一起使用或执行程序的一部分的一个或以上硬件单元(例如，集成电路的部分)。程序可以存储在计算机可读介质上，并且当由处理器106执行时，它可以执行与确定用于为约车服务呈现支付的支付方法有关的一个或以上功能。
在一些实施例中，处理器106可以配置为确定用于支付约车服务的一种或以上支付方法。例如，处理器106可以接收或确定乘客的位置信息(例如，约车服务的接送位置)。在一些实施例中，可以基于与接送请求相关联的地理位置确定支付方法。例如，可以基于与接送请求的位置相关的规定来确定支付方法(例如，提出接送请求的城市可能要求仅通过信用卡或第三方支付平台支付约车服务)。如果有关于允许支付方法的规定，处理器106还可以配置为确定该行程的地理位置是否属于所述规定管辖的预定地理区域(例如，预定地理区域可以对应于执行本地规定的地方当局的管辖区域)。可以基于乘客和/或服务提供者的接送点、大部分的行程、下车点或登记信息来进行确定。用于确定行程是否落入预定地理区域的标准可以基于规定的解释确定(例如，有关当局可能会指出用于确定行程是否属于城市管辖区域的标准取决于大部分的行程发生的位置)。在一些实施例中，如果确定行程不在预定地理区域中，处理器可以应用不同的标准确定支付方法(例如，基于本地习惯、乘客的历史支付信息和/或服务提供者的可接受的支付方法来确定支付方法)。
在另一个示例中，可以基于关于支付方法的本地习惯来确定支付方法(例如，某国家或区域中的人可以习惯通过现金支付约车服务)。可用的支付方法可以包括本地用户习惯的支付方法。例如，处理器106可以基于乘客位置信息数据122确定服务请求在国家A中做出。在国家A中，信用卡和借记卡等支付卡可能无处不在，大多数交易可以使用现金支付进行。在这种情况下，处理器106可以确定选择现金支付作为支付方法，或者甚至将现金支付优先于其他形式的支付方法作为首选支付方法。在另一示例中，在国家B中，尽管基于卡支付的支付方法的采用率相对较低，但是诸如AlipayTM的非基于卡的在线支付平台可能是普遍存在的。在这种情况下，处理器106可以确定选择诸如非基于卡的在线支付方法作为可用的支付方法。
在一些实施例中，可以基于乘客的历史支付信息来确定支付方法。例如，处理器106可以确定历史支付信息是否包括至少一种预先登记的支付方法。在一些实施例中，如果历史支付信息包括至少一种预先登记的支付方法，并且预先登记的支付方法仅包括一张信用卡的信息，然后，处理器106可以选择信用卡作为可用的支付方法，并将信用卡作为首选支付方法提供给乘客。如果预先登记的支付包括多于一张信用卡的信息，则处理器106可以提供多张信用卡作为可用支付方法，并且可以进一步选择乘客最近使用的信用卡作为首选支付方法。如果预先登记的支付方法不包含信用卡信息，处理器106可以选择非基于卡的预先登记的在线支付方法(例如，乘客可以将他或她的AlipayTM账户与应用程序相关联)作为可用的支付方法或者将其用作首选支付方法。在另一示例中，如果没有针对乘客的预先登记的支付方法，则可以基于乘客的一个或以上先前的约车行程确定可用的支付方法(例如，使用服务点支付或现金支付)。如果乘客没有先前的约车行程(例如，乘客是新用户或正在使用新帐户)，处理器106可以确定使用现金作为乘客的可用或首选支付方法，或者，不提供建议的支付方法并让乘客建立支付方法。
在另一个实施例中，处理器106可以动态地调整乘客的支付方法。例如，处理器106可以基于约车服务提供者信息数据126确定服务提供者的可接受的支付方法(例如，服务提供者可以仅接受信用卡和AlipayTM)。可以基于服务提供者可接受的支付方法确定或调整向用户描述的支付方法。例如，如果信用卡不是服务提供者可接受的支付方法之一，则将其从可用的支付方法列表中删除。在另一个示例中，当服务提供者(例如，司机)仅接受现金时，可以确定现金支付是支付方法。
在一些实施例中，处理器106可以使用基于样本历史支付信息和/或已知与某些支付方法偏好相关联的地理信息训练的学习模型，确定支付方法和/或首选支付方法。例如，处理器106可以使用交易历史数据，例如样本用户最近使用的支付方法，例如，在最近20次支付期间或在上个月期间，使用的支付方法的类型、每种支付方法的频率、用户在预定时间段内(例如每月)的约车服务的平均消费、每次位置、持续时间和/或每次行程的开始时间等。这些样本特征以及具有某些支付方法偏好的特征的任何组合可以用作训练数据。然后，处理器106可以基于训练数据训练学习模型(例如，基于规则的机器学习模型)。然后，训练的模型可以应用于确定一种或以上支付方法和/或首选支付方法。
内存/存储设备108可以包括任何适当类型的大容量存储器，其被提供以存储处理器106可能需要操作的任何类型的信息。内存/存储设备108可以是一种易失性或非易失性、磁性、半导体、基于磁带、光学、可移动、不可移动或其他类型的存储设备或有形(即非暂时性)计算机可读介质包括但不限于ROM、闪存、动态RAM和静态RAM。内存/存储设备108可以配置为存储一个或以上计算机程序，其可以由处理器106执行以管理和协调本申请披露的运输服务。例如，内存/存储设备108可以配置为存储程序，其可以由处理器106执行以确定乘客的合适的接送位置。
内存/存储设备108可以进一步配置为存储信息和处理器106使用的数据。例如，内存/存储设备108可以配置为存储由通信接口104接收的各种类型的数据(例如，约车服务请求、车辆信息、历史支付信息、训练的模型等)。内存/存储设备108还可以存储中间数据，例如可用的支付方法、可接受的支付方法、首选支付方法等。在处理每个数据帧之后，可以永久地存储、周期性地移除或忽略各种类型的数据。
图2是描绘示例性终端设备110的框图。终端设备110可以包括通信接口202、处理器204、内存/存储设备206和显示器208。通信接口202可以以与通信接口104类似的方式配置。通信接口202可以促进终端设备110和服务器102之间的通信。处理器204可以具有与处理器106类似的硬件结构，并且可以包括关注移动使用的设计特征。例如，处理器204可以包括设计用于与其他组件一起使用或执行程序的一部分的一个或以上硬件单元(例如，集成电路的部分)。程序可以存储在计算机可读介质(例如，内存/存储设备206)上，并且当由处理器204执行时，它可以执行一个或以上的功能，这些功能有助于确定用于支付约车服务的支付方法。内存/存储设备206也可以具有与内存/存储设备108类似的结构，并且可以包括关注移动使用的设计特征。
显示器208可以包括诸如液晶显示器(LCD)、发光二极管显示器(LED)、等离子显示器或任何其他类型的显示器，并提供在显示器上呈现的用于用户输入和数据显示的图形用户界面(GUI)。显示器可以包括许多不同类型的材料，例如塑料或玻璃，并且可以是触敏的以接收来自用户的命令。例如，显示器可以包括实质上刚性的触敏材料，例如GorillaGlassTM，或实质上柔性的触敏材料，例如Willow GlassTM。
在一些实施例中，通信接口202可以配置为发送或接收用户做出的约车服务请求(例如，乘客可以使用乘客终端设备发送请求，并且司机可以使用司机终端设备来接收请求)。约车服务请求可以包括乘客信息122。在一些实施例中，乘客信息122可以包括乘客的地理位置，其可以由定位设备捕获，例如内置于终端设备110中的全球定位系统(GPS)接收器。在一些实施例中，乘客信息122还可以包括存储在内存/存储设备206或内存/存储设备108中的历史支付信息(例如，与可以存储在云中的用户帐户相关联的历史支付信息)。在一些实施例中，通信接口202可以向服务器102提供包括乘客信息122的约车服务请求。在一些实施例中，通信接口202可以从服务器102接收一种或以上支付方法和/或首选支付方法，其中处理器106可以确定支付方法和/或首选支付方法。在一些实施例中，终端设备110可以使用处理器204确定支付方法和/或首选支付方法。在一些实施例中，支付方法和/或首选支付方法可以由处理器106和204确定。在接收或确定支付方法和/或首选支付方法之后，处理器204可以控制显示器208将支付方法/首选支付方法描述为在显示器208上给用户的选项。
当没有提供首选支付方法时，用户可以从显示器208上描绘的可用支付方法中选择支付方法，并使用所选择的支付方法确认支付。当提供首选方法时，可以自动选择首选支付方法作为默认选项。用户可以使用默认支付方法直接进行确认支付。如果用户决定使用除首选支付方法之外的支付方法，则用户可以选择不同的支付方法。通信接口202可以向服务器102提供用于支付的支付方法。在一些实施例中，通信接口202还可以与服务器102和/或支付处理服务器(未示出)通信，以使用所选择的支付来为约车服务提供支付。
在一些实施例中，处理器204可以基于乘客的地理位置和/或历史支付，确定一种或以上支付方法和/或首选支付方法。如上所述，处理器204还可以执行类似于处理器106的功能。例如，处理器204可以配置为执行确定支付方法和/或首选支付方法的一个或以上步骤，类似于处理器106。
图3是示出了与所披露的实施例一致的用于确定运输服务支付方法的示例性方法300的流程图。方法300可以由服务器102和/或终端设备110实现，服务器和/或设备包括至少一个处理器。在以下描述中，服务器102用作实现方法300的示例。预期方法300也可以由终端设备110实现，或者由服务器102和终端设备110共同实现。与本申请一致，方法300确定至少一种支付方法和/或首选支付方法，用于支付已经与服务车辆匹配的约车服务请求。方法300可以包括如下所述的若干步骤，其中一些步骤可以是可选的。
如图3所示，方法300可以包括步骤302至312。在步骤302，服务器102可以从用户(例如，乘客)接收服务请求(例如，约车服务请求)。例如，服务请求可以由用户在终端设备110上输入并通过通信接口202发送到服务器102。服务车辆130可以与所述请求匹配以向用户提供服务。
在步骤304，服务器102可以确定与请求服务的用户相关联的位置信息。例如，服务器102可以从终端设备110接收包括地理信息的信息，并确定用户的地理位置。地理位置可以是终端设备110的位置，由嵌入其中的定位设备捕获或用户提供位置。例如，用户可以使用终端设备110或个人计算机来为朋友请求用车，并且除了使用请求用车设备的位置之外还可以设置接送位置。在一些实施例中，可以基于约车服务的接送位置确定与用户相关联的位置信息。在一些实施例中，可以基于约车服务的下车位置确定与用户相关联的位置信息。在一些实施例中，可以基于行程的主要部分所在的位置确定位置信息。
在步骤306，服务器102可以基于位置信息确定至少一种支付方法。例如，服务器102可以确定用户的位置信息(例如，用于约车服务的接送位置)。在一些实施例中，可以基于接送请求的地理位置确定支付方法。例如，可以基于接送请求的位置的规定确定支付方法(例如，接送请求所在的城市可能要求仅使用信用卡或第三方支付平台来支付约车服务)。如果存在关于支付方法的规定，则服务器102可以确定该行程的地理位置是否落入预定地理区域(例如，执行本地规定的地方当局的管辖区域)。可以基于乘客或服务提供者的接送点、大部分的行程、下车点或登记信息来进行确定。用于确定行程是否落入预定地理区域的标准可以基于规定的解释确定(例如，当局可能会指出用于确定行程是否属于该市管辖区域的标准取决于确定大部分行程发生的位置)。在一些实施例中，如果确定行程不在预定地理区域中，服务器102可以应用不同的标准确定一种或以上支付方法(例如，基于本地习惯、乘客的历史支付信息和/或服务提供者可接受的支付方法来确定支付方法)。
在另一个示例中，可以基于支付方法的本地习惯确定支付方法(例如，通过现金支付大部分约车服务的城市)。所确定的支付方法可以包括本地用户习惯的支付方法。
在一些实施例中，可以基于用户的历史支付信息确定支付方法。例如，服务器102可以确定历史支付信息是否包括至少一种预先登记的支付方法。在一些实施例中，如果历史支付信息包括至少一种预先登记的支付方法并且预先登记的支付方法仅包括一张信用卡信息，则服务器102可以选择信用卡作为支付方法。在一些实施例中，服务器102可以将信用卡作为首选支付方法提供给用户。在一些实施例中，如果预先登记的支付包括多于一张信用卡的信息，则服务器102可以选择用户最近使用的信用卡作为首选支付方法。在一些实施例中，如果预先登记的支付方法不包括信用卡信息，服务器102可以选择非基于卡的预先登记的在线支付方法(例如，乘客将他或她的AlipayTM账户与应用程序相关联)作为可用的支付方法。在另一个示例中，如果没有针对用户的预先登记的支付方法，则可以基于一个或以上先前的约车行程确定支付方法(例如，用户最近一次行程使用服务点或现金)。在一些实施例中，如果用户没有先前的约车行程(例如，用户是新用户或正在使用新帐户)，则服务器102可以确定使用现金支付作为用户的支付方法。
在另一个实施例中，服务器102可以基于约车服务提供者信息数据126来获取或以其他方式接收服务提供者可接受的支付方法(例如，服务提供者可以仅接受信用卡和AlipayTM)。服务器102可以基于服务提供者的\可接受的支付方法动态地调整支付方法和/或首选支付方法(例如，如果不是服务提供者的可接受的支付方法之一，则通过信用卡支付将其从可用的支付方法列表中删除)。
在一些实施例中，可以使用基于样本历史支付信息和/或已知与某些支付方法偏好相关联的地理信息训练的学习模型，确定至少一种支付方法和/或首选支付方法。例如，服务器102可以使用交易历史数据例如样本用户最近支付中使用的支付方法、使用的支付方法的类型、所使用的每种支付方法的频率、预定时间段内用户在约车服务上的平均消费、位置、持续时间和/或每次行程开始时间等。此类信息可用作样本特征。服务器102可以将特征与某些支付方法偏好组合作为训练数据。然后，服务器102可以基于训练数据训练学习模型(例如，基于规则的机器学习模型)。然后，训练的模型可以用于确定支付方法和/或首选支付方法。
在步骤308，服务器102可以在终端设备的显示器上提供至少一种支付方法的描述。在图4所示的示例中，显示器208可以包括两个部分：详细行程信息402和可用的支付方法404。在一些实施例中，详细的行程信息402可以包括接送位置、下车位置、行程路线、行程距离、行程的估计成本、行程的估计时间等。在一些实施例中，显示器208可以呈现一种或以上支付方法404供乘客选择(例如，显示器208可以在条形列表中呈现一种或以上支付方法，如图4所示)。预期显示器208可以以其他形式呈现支付方法404(例如，图表或使用图标来表示不同的可用支付方法)。在一些实施例中，显示器208可以在条形列表的顶部呈现首选支付方法。例如，可以将首选支付方法设置为默认支付方法并以“选择”状态呈现，这样乘客可以通过确认选择(例如，通过点击“支付”、“确认”或类似指示符)来提供支付，而无需提出可用支付方法的列表。
在步骤310，服务器102可以使用所选择的支付方法从用户接收或以其他方式获取指示支付确认的输入。所选择的支付方法可以是终端设备的显示器上描绘的可用支付方法之一。例如，在图4所示的示例中，用户可以从条形列表中选择一种可用的支付方法来为约车服务提供支付。在一些实施例中，在服务器102确定首选支付方法的情况下，如果用户没有另外选择，则首选支付方法可以呈现在条形列表的顶部，并且首选方法可以用作服务的默认支付方法。
在步骤312，服务器102可以使用所选择的支付方法支付约车服务。服务器102可以向支付模块(未示出)发送指令，指示使用所选择的支付方法进行支付。在另一个实施例中，服务器102可以使用默认支付方法为约车服务提供支付。例如，如果服务器102确定使用预先登记的信用卡作为行程的默认支付方法，并且用户没有另外选择，服务器102可以向支付模块发送指令，指示使用预先登记的信用卡作为行程的支付方法。预期支付模块可以是或可以不是系统100的一部分。例如，支付模块可以与服务器102或终端设备110集成，或者作为独立于系统100的独立系统集成。
在一些实施例中，可以提供账户余额功能作为可用支付方法。例如，账户余额可以内置于约车服务应用中，以允许用户使用诸如信用卡/借记卡和在线支付平台(例如，AlipayTM、PaypalTM等)的其他支付方法将资金存入他/她的账户余额。然后，用户可以使用账户余额来支付车费。在一些实施例中，用户可以根据所使用的本地货币使用不同的货币将资金存入账户余额。例如，在当地货币为人民币的中国的频繁用户可以选择使用人民币将资金存入账户余额。这样，账户余额可以是人民币。在另一个实施例中，用户可能频繁在当地货币不同的不同国家和/或地区使用约车服务(例如，频繁的国际行程者可能频繁在美国和中国使用约车服务)。用户可能具有以不同货币呈现的不同账户余额(例如，在上述示例中，行程者可以具有美元账户余额以及具有另一中国人民币账户余额)。
在一些实施例中，处理器106可以基于位置信息选择使用与用户的位置匹配的货币的账户余额。例如，当乘客在他/她的祖国使用约车服务时，可以选择使用本国货币的账户余额。当乘客前往外国时，处理器106可以基于位置信息使用外国货币作为支付方法选择账户余额。在一些实施例中，可以基于终端设备的漫游状态确定乘客的位置。例如，当终端设备(例如移动电话)进入漫游模式时，可以基于与漫游模式相关联的电信信息确定位置信息(例如，国家或地区)。
在一些实施例中，本地货币的账户余额可被确定为首选支付方法(例如，当为用户选择首选支付方法时，其他货币的账户余额可被标记为不可用)。
在一些实施例中，用户可能发现使用账户余额作为首选支付方法是有利的，因为促销活动可用于奖励用户使用账户余额。例如，当用户将资金存入账户余额时，可以向账户余额发放额外的金额作为奖励(例如，支付100美元以增加价值120美元的金额)。在另一个示例中，当账户余额的使用频率高于预定阈值(例如，每月20次)时，还可以向账户余额发放额外的金额作为激励。在另一个示例中，奖励和激励可以作为广告或促销活动的一部分来提供。例如，用户可以从O2O服务平台或第三方商业伙伴(例如，购物门户、商店、娱乐提供者等)接收优惠券，并使用优惠券将资金存入账户余额。在一些实施例中，可以以条形码或二维码的形式提供优惠券，用户可以扫描该优惠券以将资金存入账户余额。在一些实施例中，可以以密码组合的形式提供优惠券，并且用户可以将该组合输入到约车应用程序中以将资金存入账户余额。在一些实施例中，可以向频繁使用约车服务的用户发放金额(例如，通过累积一定数量的里程，或达到一定数量的请求或支付)。其他形式的促销手段也可用于为用户提供使用账户余额作为首选支付方法的激励。
在一些实施例中，可以选择账户余额作为首选支付方法，用于为约车服务提供支付。图5示出了示例性用户界面，其描绘了当向约车服务提供者做出支付时，账户余额504被选择作为默认支付方法。用户可以通过点击确认按钮506使用账户余额确认支付，而无需另外选择支付方法。这种简化的流程减少了支付所需的时间，提高了效率和用户体验。另外，如上所述，使用账户余额作为支付方法使得激励用户使用约车服务成为可能，从而为用户提供增强的价值。
在一些实施例中，可以类似于上面讨论的其他支付方法来处理账户余额，例如基于卡支付、基于在线支付平台、基于服务点和基于现金的支付方法。在确定哪种支付方法被选择为可用支付方法和/或首选支付方法时，与其他支付方法相比，可以同等或更有利地考虑账户余额。在一些实施例中，账户余额还可以与一种或以上其他形式的支付方法结合使用。例如，当账户余额的可用金额小于要求服务费用时，剩余金额可首先用户支付，剩余部分由例如信用卡或基于在线支付平台的支付方法支付。
图6示出了根据一些实施例的确定支付方法的示例性工作流程600。流程600从步骤602开始，其中开始确定支付方法。步骤602可以由乘客在请求约车服务之前选择目的地、司机接受该请求、确认接驾、指示到达目的地、显示支付界面等来触发。如图6所示，步骤602进行到步骤604，其中处理器106/204可以确定乘客是否具有预先登记的在线支付方法，包括基于卡支付的支付方法(例如，信用卡或借记卡)，基于在线支付平台的支付方法(例如，PaypalTM、AlipayTM)等。如果是，则流程600沿“是”分支前进到步骤606，其中处理器106/204进一步确定预登记在线支付方法是否是基于卡支付的。如果是，则流程600沿“是”分支前进到步骤608，其中处理器106/204选择最近添加的支付卡作为用于提供给乘客的默认支付方法。否则，流程600沿“否”分支前进到步骤610，其中处理器106/204选择基于在线支付平台的支付方法作为默认支付方法。
返回步骤604，如果处理器106/204确定没有预先登记的在线支付方法可用，则流程600沿“否”分支前进到步骤612，其中处理器106/204进一步确定是否存在最近使用的支付方法的记录。如果是，则流程600沿“是”分支前进到步骤614，其中选择最后使用的支付方法作为默认支付方法。最近使用的支付方法可能包括现金支付、POS支付等。否则，流程600沿“否”分支前进到步骤616，其中处理器106/204确定行程的位置(例如，请求位置、接送位置、下车位置、行程的主要部分的位置等)是否属于无现金区域(例如，墨西哥城)。如果是，则流程600沿“是”分支前进到步骤618，其中处理器106/204不提供默认支付方法选择。相反，由乘客决定应该使用哪种支付方法。如果行程的位置不在无现金区域内，则流程600沿“否”分支前进到步骤620，其中选择现金支付方法作为默认支付方法。
图7示出了根据一些实施例的用于使用账户余额作为首选支付方法的示例性工作流程700。流程700在步骤702开始，其可以由例如请求约车服务的用户触发。流程700然后进行到步骤704，其中处理器106/204确定用户是否是账户余额功能的新用户。如果是，则流程700第一时间沿着“是”分支继续以使用账户余额。如果确定用户不是新用户，则流程700沿“否”分支前进到步骤706，其中处理器106/204确定用户是否使用账户余额作为支付方法来支付最近一次行程。如果是，则流程700沿着“是”分支继续以使用账户余额，这导致步骤710。在步骤710，处理器106/204确定帐户中的可用余额是否等于或大于服务费用(例如，估计的或实际的服务费用)。如果是，则流程700沿“是”分支前进到步骤712，其中账户余额用作首选支付方法。返回步骤710，如果确定帐户中的余额小于服务费用，则流程700沿“否”分支前进到步骤714，其中处理器106/204确定是否存在任何预先登记的支付卡。如果是，则流程700沿“是”分支前进到步骤716，其中使用组合的支付方法。例如，该组合可以包括帐户中的可用余额和最后使用/最近添加的支付卡以支付服务费用的剩余部分。返回步骤714，如果没有预先登记的支付卡，则流程700沿“否”分支前进到步骤718，其中处理器106/204确定行程是否落在无现金区域内，类似于步骤616。如果不是，则流程700沿“否”分支前进到步骤720，其中使用离线支付方法，例如现金支付或POS支付。如果在步骤718确定行程落在无现金区域内，则流程700沿“是”分支前进到步骤722，其中处理器106/204要求用户登记支付卡或基于在线支付平台的支付方法。
返回步骤706，如果确定用户在最后一次行程中没有使用账户余额作为支付方法，则流程700沿“否”分支前进到步骤708，其中最近的支付方法用作首选支付方法。
图8示出了使用账户余额作为基于位置信息的支付方法的示例性工作流程800。流程800在步骤802开始。步骤802可以由例如用户打开支付界面触发。在步骤804，处理器106/204确定与用户相关联的终端设备是否正在漫游。例如，终端设备(例如，移动电话)在其本国/地区之外操作时正在漫游。因此，基于漫游状态，处理器106/204可以确定终端设备是否在其本国/地区或外国/地区中操作。如果确定终端设备正在漫游，则流程800沿着“漫游”分支前进到步骤806，其中确定终端设备当前正在漫游的国家/区域是否存在或者是否可用。如果不是，则流程800沿着“否”分支前进到步骤808，其中不向用户显示账户余额。否则，流程800沿“是”分支前进到步骤810，其中显示账户余额。例如，账户余额可以在当前漫游的外国/地区的货币对应中保持余额。在另一个示例中，可以不显示其他货币的账户余额，或者可以以不可选择的方式显示账户余额。返回步骤804，当确定终端设备没有漫游时，流程800沿着“无漫游”分支前进到步骤812，其中处理器106/204确定是否存在账户余额。如果否，则流程800沿“否”分支前进到步骤814，其中不显示账户余额。否则，流程800沿“是”分支前进到步骤816，其中处理器106/204确定可用余额是否大于零。如果不是，则流程800沿“否”分支前进到步骤818，其中显示零余额。否则，流程800沿着“是”分支前进到步骤820，其中处理器106/204确定用户是否是账户余额功能的新用户(例如，用户没有使用账户余额来支付任何行程费用)。如果是，则流程800沿着“是”分支前进到步骤822，其中使用账户余额或账户余额和一个或以上在线支付方法的组合，类似于从步骤710开始的流程700的子流程。另一方面，如果账户余额不是新的支付方法，则流程800沿“否”分支前进到步骤824，其中选择最近使用的支付方法。
在一些实施例中，处理器106/204可以从各种支付方法中确定支付方法，例如基于卡支付的方法(例如，信用卡支付、借记卡支付等)、基于在线支付平台的支付方法(例如，PaypalTM、AlipayTM等)、账户余额(例如，在O2O服务平台登记的一个或以上支付账户)、POS支付(例如，使用POS终端的离线支付)、现金支付等。
本申请的另一方面涉及一种存储指令的非暂时性计算机可读介质，所述指令在被执行时使得一个或以上处理器执行如上所述的方法。计算机可读介质可以包括易失性或非易失性、磁性、基于半导体、基于磁带、光学、可移动、不可移动或其他类型的计算机可读介质或计算机可读存储设备。例如，如本申请的计算机可读介质可以是存储设备或其上存储有计算机指令的内存模块。在一些实施例中，计算机可读介质可以是其上存储有计算机指令的盘或闪存驱动器。
显而易见，本领域普通技术人员可以对本申请的系统和相关方法进行各种修改和变化。考虑到本申请的系统和相关方法的说明书和实践，其他实施例对于本领域普通技术人员是显而易见的。
本申请中的说明书和示例的目的仅被认为是示例性的，真正的范围由以下权利要求及其等同物限定。

Claims (33)

1.一种计算机实现的方法，用于确定支付通过线上到线下(O2O)服务平台提供的服务的支付方法，包括：
从第一用户接收对所述服务的请求；
确定与所述第一用户的关联终端设备相关联的位置信息；
基于所述位置信息确定至少一种支付方法；以及
在所述终端设备的显示器上提供所述至少一种支付方法的描述。
2.根据权利要求1所述的方法，其特征在于：
所述位置信息包括所述终端设备的地理位置；以及
所述方法还包括：
确定所述地理位置是否属于预定地理区域；以及
响应于确定所述地理位置属于预定地理区域，基于对应于所述预定地理区域的第一标准确定所述至少一种支付方法。
3.根据权利要求2所述的方法，其特征在于：
所述第一标准包括所述预定地理区域中的规定；以及
所述方法还包括基于所述规定确定所述至少一种支付方法，使得在所述预定地理区域中使用所述至少一种支付方法符合所述规定。
4.根据权利要求2所述的方法，其特征在于：
所述第一标准包括所述预定地理区域中的用户习惯的一种或以上支付方法；以及
所述方法还包括基于所述预定地理区域中的用户习惯的所述一种或以上支付方法，确定所述至少一种支付方法。
5.根据权利要求2所述的方法，其特征在于：
所述第一标准包括所述预定地理区域中使用的货币；以及
所述方法还包括基于所述预定地理区域中使用的所述货币，确定所述至少一种支付方法。
6.根据权利要求1至5任一项所述的方法，其特征在于：
所述至少一种支付方法包括首选支付方法；以及
所述方法还包括：
基于所述位置信息确定所述首选支付方法；以及
在所述终端设备的所述显示器上提供所述首选支付方法的描述作为默认支付方法。
7.根据权利要求6所述的方法，还包括：
确定所述第一用户是否具有在所述O2O服务平台上登记的至少一种预先登记的支付方法；以及
响应于所述第一用户具有至少一种预先登记的支付方法的确定，基于所述至少一种预先登记的支付方法确定所述首选支付方法。
8.根据权利要求7所述的方法，还包括：
确定所述至少一种预先登记的支付方法是否包括一张或以上预先登记的支付卡的信息；以及
响应于确定所述至少一种预先登记的支付方法包括一个或以上预先登记的支付卡的信息，选择最近登记的支付卡作为所述首选支付方法。
9.根据权利要求6所述的方法，还包括：
确定所述第一用户是否有与所述O2O服务平台相关的账户余额；以及
响应于确定所述第一用户有账户余额，基于所述账户余额中的可用余额确定所述首选支付方法。
10.根据权利要求9所述的方法，还包括：
当所述可用余额等于或高于所述服务的服务费用时，选择所述账户余额为所述首选支付方法。
11.根据权利要求9所述的方法，还包括：
当所述可用余额低于所述服务的服务费时，选择所述账户余额和第二支付方法作为所述首选支付方法，其中所述第二支付方法用于支付所述服务费与所述账户余额的所述可用余额之间的差额。
12.根据权利要求6至11任一项所述的方法，还包括：
确定所述第一用户是否在一个或以上先前服务中使用了至少一种历史支付方法；以及
响应于确定所述第一用户在一个或以上先前服务中使用了至少一种历史支付方法，选择最近使用的历史支付方法作为所述首选支付方法。
13.根据权利要求1至12任一项所述的方法，还包括：
确定与第二用户相关的一个或以上可接受的支付方法，所述第二用户向所述第一用户提供所述服务；以及
基于与所述第二用户相关的所述一个或以上可接受的支付方法确定所述至少一种支付方法。
14.根据权利要求1至13任一项所述的方法，还包括：
接收来自所述第一用户的输入，表明确认对所述服务的支付；以及
使用所述至少一种支付方法进行对所述服务的所述支付。
15.一种系统，用于确定支付通过线上到线下(O2O)服务平台提供的服务的支付方法，包括：
通信接口.被配置为：
从第一用户接收对所述服务的请求；
至少一个内存；以及
与所述通信接口和所述至少一个内存连接的至少一个处理器，其中所述至少一个处理器被配置为：
确定与所述第一用户的关联终端设备相关联的位置信息；
基于所述位置信息确定至少一种支付方法；以及
在所述终端设备的显示器上提供所述至少一种支付方法的描述。
16.根据权利要求15所述的系统，其特征在于：
所述位置信息包括所述终端设备的地理位置；以及
至少一个处理器还配置为：
确定所述地理位置是否属于预定地理区域；以及
响应于确定所述地理位置属于预定地理区域，基于对应于所述预定地理区域的第一标准确定所述至少一种支付方法。
17.根据权利要求16所述的系统，其特征在于：
所述第一标准包括所述预定地理区域中的规定；以及
所述至少一个处理器还被配置为基于所述规定确定所述至少一种支付方法，使得在所述预定地理区域中使用所述至少一种支付方法符合所述规定。
18.根据权利要求16所述的系统，其特征在于：
所述第一标准包括所述预定地理区域中的用户习惯的一种或以上支付方法；以及
所述至少一个处理器还被配置为基于所述预定地理区域的所述用户习惯的所述一种或以上支付方法确定所述至少一种支付方法。
19.根据权利要求16所述的系统，其特征在于：
所述第一标准包括所述预定地理区域中使用的货币；以及
所述至少一个处理器还被配置为基于所述预定地理区域中使用的所述货币确定所述至少一种支付方法。
20.根据权利要求15至19任一项所述的系统，其特征在于：
所述至少一种支付方法包括首选支付方法；以及
所述至少一个处理器还被配置为：
基于所述位置信息确定所述首选支付方法；以及
在所述终端设备的所述显示器上提供所述首选支付方法的描述作为默认支付方法。
21.根据权利要求20所述的系统，其特征在于，所述至少一个处理器还被配置为：
确定所述第一用户是否具有在所述O2O服务平台上登记的至少一种预先登记的支付方法；以及
响应于所述第一用户具有至少一种预先登记的支付方法的确定，基于所述至少一种预先登记的支付方法确定所述首选支付方法。
22.根据权利要求21所述的系统，其特征在于，所述至少一个处理器还被配置为：
确定所述至少一种预先登记的支付方法是否包括一张或以上预先登记的支付卡的资料；以及
响应于所述至少一种预先登记的支付方法包括一个或以上预先登记的支付卡的信息的确定，选择最近登记的支付卡作为所述首选支付方法。
23.根据权利要求20所述的系统，其特征在于，所述至少一个处理器还被配置为：
确定所述第一用户是否与所述O2O服务平台相关的账户余额；以及
响应于确定所述第一用户拥有账户余额，基于所述账户余额中的可用余额确定所述首选支付方法。
24.根据权利要求23所述的系统，其特征在于，所述至少一个处理器还被配置为：
当所述可用余额等于或高于所述服务的服务费用时，选择所述账户余额作为所述首选支付方法。
25.根据权利要求23所述的系统，其特征在于，所述至少一个处理器还被配置为：
当所述可用余额低于所述服务的服务费时，选择所述账户余额和第二支付方法作为所述首选支付方法，其中所述第二支付方法用于支付所述服务费与所述账户余额的所述可用余额之间的差额。
26.根据权利要求20至25任一项所述的系统，其特征在于，所述至少一个处理器还被配置为：
确定所述第一用户是否在一个或以上先前服务中使用了至少一种历史支付方法；以及
响应于确定所述第一用户在一个或以上先前服务中使用了至少一种历史支付方法，选择最近使用的历史支付方法用作所述首选支付方法。
27.根据权利要求15至26任一项所述的系统，其特征在于，所述至少一个处理器还被配置为：
确定与第二用户相关的一个或以上可接受的支付方法，所述第二用户向所述第一用户提供所述服务；以及
基于与所述第二用户相关的所述一个或以上可接受的支付方法确定所述至少一种支付方法。
28.根据权利要求15至27任一项所述的系统，其特征在于，所述至少一个处理器还被配置为：
接收来自所述第一用户的输入，表明确认对所述服务的支付；以及
使用所述至少一种支付方法进行对所述服务提供的所述支付。
29.一种非暂时性计算机可读介质，所述介质存储一组指令，当由电子设备的至少一个处理器执行所述指令时，使所述电子设备执行一种方法，用于确定支付通过线上到线下(O2O)服务平台提供的服务的支付方法，所述方法包括：
从第一用户接收对所述服务的请求；
确定与所述第一用户的关联终端设备相关联的位置信息；
基于所述位置信息确定至少一种支付方法；以及
在所述终端设备的显示器上提供所述至少一种支付方法的描述。
30.根据权利要求29所述的非暂时性计算机可读介质，其特征在于：
所述位置信息包括所述终端设备的地理位置；以及
所述方法还包括：
确定所述地理位置是否属于预定地理区域；以及
响应于确定所述地理位置属于预定地理区域，基于对应于所述预定地理区域的第一标准确定所述至少一种支付方法。
31.根据权利要求29或30所述的非暂时性计算机可读介质，其特征在于：
所述至少一种支付方法包括首选支付方法；以及
所述方法还包括：
基于所述位置信息确定所述首选支付方法；以及
在所述终端设备的所述显示器上提供所述首选支付方法的描述作为默认支付方法。
32.根据权利要求29至31任一项所述的非暂时性计算机可读介质，其特征在于，所述方法还包括：
确定与第二用户相关的一个或以上可接受的支付方法，所述第二用户向所述第一用户提供所述服务；以及
基于与所述第二用户相关的所述一个或以上可接受的支付方法确定所述至少一种支付方法。
33.根据权利要求29至32任一项所述的非暂时性计算机可读介质，其特征在于，所述方法还包括：
接收来自所述第一用户的输入，表明确认对所述服务的支付；以及
使用所述至少一种支付方法进行对所述服务的所述支付。
CN201880043896.8A 2018-11-07 2018-11-07 用于确定支付线上到线下服务的支付方法的方法和系统 Pending CN111417973A (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2018/114394 WO2020093279A1 (en) 2018-11-07 2018-11-07 Methods and systems for determining payment method for rendering payment for online-to-offline service

Publications (1)

Publication Number Publication Date
CN111417973A true CN111417973A (zh) 2020-07-14

Family

ID=70610797

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201880043896.8A Pending CN111417973A (zh) 2018-11-07 2018-11-07 用于确定支付线上到线下服务的支付方法的方法和系统

Country Status (2)

Country Link
CN (1) CN111417973A (zh)
WO (1) WO2020093279A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11100499B1 (en) * 2014-05-07 2021-08-24 Google Llc Location modeling using transaction data for validation

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101968907A (zh) * 2010-09-17 2011-02-09 宇龙计算机通信科技(深圳)有限公司 一种基于双卡移动终端的支付方法、系统及移动终端
CN103875010A (zh) * 2011-07-27 2014-06-18 罗素·斯图尔特·古德温 智能支付系统
WO2015026184A1 (ko) * 2013-08-22 2015-02-26 에스케이씨앤씨 주식회사 결제카드 사용 위치 및 과거 결제 내역에 기반한 모바일 결제카드 추천 방법 및 이를 적용한 관리 서버
US20150254636A1 (en) * 2014-03-06 2015-09-10 Samsung Electronics Co., Ltd. Method and apparatus for providing mobile payment
CN105512884A (zh) * 2015-12-21 2016-04-20 联想(北京)有限公司 移动设备及其控制方法
CN106022773A (zh) * 2016-05-27 2016-10-12 广州羊城通有限公司 一种ic卡与银行卡的绑定方法
CN107146077A (zh) * 2017-05-02 2017-09-08 广州市智专信息科技有限公司 一种支付方法及相应的便携式终端、第三方支付平台
CN107403316A (zh) * 2017-08-03 2017-11-28 广州爱九游信息技术有限公司 筛选支付方式的方法、装置、计算设备和存储介质

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100876296B1 (ko) * 2008-06-02 2008-12-31 주식회사 포비커 이동통신망을 이용한 전자상품 공동 이용 방법 및 시스템
CN102843645B (zh) * 2012-08-01 2015-07-29 社交郡有限公司 基于移动终端地理位置信息的服务提供方法和系统
CN104966197B (zh) * 2015-06-15 2019-05-17 腾讯科技（北京）有限公司 信息处理方法、客户端及服务器

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101968907A (zh) * 2010-09-17 2011-02-09 宇龙计算机通信科技(深圳)有限公司 一种基于双卡移动终端的支付方法、系统及移动终端
CN103875010A (zh) * 2011-07-27 2014-06-18 罗素·斯图尔特·古德温 智能支付系统
WO2015026184A1 (ko) * 2013-08-22 2015-02-26 에스케이씨앤씨 주식회사 결제카드 사용 위치 및 과거 결제 내역에 기반한 모바일 결제카드 추천 방법 및 이를 적용한 관리 서버
US20150254636A1 (en) * 2014-03-06 2015-09-10 Samsung Electronics Co., Ltd. Method and apparatus for providing mobile payment
CN105512884A (zh) * 2015-12-21 2016-04-20 联想(北京)有限公司 移动设备及其控制方法
CN106022773A (zh) * 2016-05-27 2016-10-12 广州羊城通有限公司 一种ic卡与银行卡的绑定方法
CN107146077A (zh) * 2017-05-02 2017-09-08 广州市智专信息科技有限公司 一种支付方法及相应的便携式终端、第三方支付平台
CN107403316A (zh) * 2017-08-03 2017-11-28 广州爱九游信息技术有限公司 筛选支付方式的方法、装置、计算设备和存储介质

Also Published As

Publication number Publication date
WO2020093279A1 (en) 2020-05-14

Similar Documents

Publication Publication Date Title
US20220335363A1 (en) System and method for transportation
US20210319380A1 (en) System and method for facilitating a transport service for drivers and users of a geographic region
US10339749B2 (en) System and method for parking vehicles using a mobile computing device
US9928540B1 (en) System for integrating courier service with customer applications
US11593774B2 (en) Mobile banking system and method
US20130246301A1 (en) Providing user feedback for transport services through use of mobile devices
US20150248689A1 (en) Systems and methods for providing transportation discounts
US20230283988A1 (en) Network system for creating and managing a session at a remote computing system
JP2024097968A (ja) プログラムおよび情報処理方法
CN106530423A (zh) 一种实现停车费支付的方法和服务器
CN106228359A (zh) 司机客户端的账单结算方法、打车系统服务器及相关系统
US20170191848A1 (en) Location detection and user information processing for intelligent selection of parking locations
AU2020281086A1 (en) Payment Re-direction System and Topology and Programming Method
CN111417973A (zh) 用于确定支付线上到线下服务的支付方法的方法和系统
US20210375068A1 (en) Computer readable recording medium, payment system, and payment server
JP7134301B2 (ja) 精算システム、ホスト端末、精算方法、プログラム及び車両
AU2017203891B2 (en) System and method for arranging transport amongst parties through use of mobile devices
US20190057346A1 (en) Progress-based load delivery settlement system
JP2022060136A (ja) タクシー情報処理方法、タクシー情報処理システム及びタクシー端末システム
AU2016277703A1 (en) System and Method for Arranging Transport Amongst Parties Through Use of Predominantly Mobile Devices
CN112106089A (zh) 数字钱包

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20200714