WO2018006717A1 - 订单信息处理以及订单类型转换处理方法及装置 - Google Patents

订单信息处理以及订单类型转换处理方法及装置 Download PDF

Info

Publication number
WO2018006717A1
WO2018006717A1 PCT/CN2017/089979 CN2017089979W WO2018006717A1 WO 2018006717 A1 WO2018006717 A1 WO 2018006717A1 CN 2017089979 W CN2017089979 W CN 2017089979W WO 2018006717 A1 WO2018006717 A1 WO 2018006717A1
Authority
WO
WIPO (PCT)
Prior art keywords
order
user
credit
information
server
Prior art date
Application number
PCT/CN2017/089979
Other languages
English (en)
French (fr)
Inventor
黄宇舟
胡光华
袁超
刘伟
Original Assignee
阿里巴巴集团控股有限公司
黄宇舟
胡光华
袁超
刘伟
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 阿里巴巴集团控股有限公司, 黄宇舟, 胡光华, 袁超, 刘伟 filed Critical 阿里巴巴集团控股有限公司
Publication of WO2018006717A1 publication Critical patent/WO2018006717A1/zh

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
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events

Definitions

  • the present application relates to the field of order information processing technologies, and in particular, to an order information processing and an order type conversion processing method and apparatus.
  • some e-commerce platforms can provide "on-line reservation offline check-in" service.
  • a hotel is booked online, if a check-in date is specified and the hotel is required to reserve a room for it, the user usually needs to pay a certain margin if If the user does not check in on time, the deposit will not be refunded, so as to avoid the economic loss of the hotel. If the user stays on time, the deposit will be refunded to the user when the user leaves the store.
  • the above traditional guarantee method has some drawbacks.
  • the user needs to pay the deposit in advance, which will occupy the user's funds.
  • the user's payment account information is usually provided to the hotel, and for some domestic hotels, it can support There are many payment methods, including bank cards, Alipay, etc., and other third-party payment tools.
  • Some international hotels usually only support bank card payment, but regardless of the payment method, there are user account information.
  • Provided to the hotel therefore, there are security risks in the process of payment; in addition, the operation process is relatively complicated and the efficiency is relatively low. In the case of the user staying on time, the reverse process is also required to return the deposit to the user's account.
  • the application provides an order information processing and an order type conversion processing method and device, which can improve user information security, improve efficiency, and save network resources.
  • a method for processing order information comprising:
  • the server receives a request from the client to create a secured order for the target data object of the specified first user
  • a method for processing order information comprising:
  • the first user data processing system receives a credit guarantee order provided by the server, the credit guarantee order being generated by: the server determining the client association when receiving a request for the client to create a guarantee order for the target data object Whether the credit information of the second user satisfies the preset business condition, and if so, creates an order and adds a credit identifier;
  • the status information is that the second user fails to perform on time, so that the server transfers the preset amount from the payment account associated with the second user to the The first user's collection account.
  • An order type conversion processing method including:
  • the server records related information of the business order, where the related information includes a first user associated with the service order and second user information, where the business order is a non-guaranteed order;
  • An order type conversion processing method including:
  • the first user data processing system submits to the server a request to convert the specified non-guaranteed order into a secured order, such that the server determines whether the credit information of the second user associated with the specified non-guaranteed order satisfies a preset business condition, if satisfied Translating the specified non-guaranteed order into a credit guarantee order;
  • An order type conversion processing method including:
  • the second user client submits a request to the server to convert the specified non-guaranteed order into a secured order, so that the server determines whether the credit information of the second user associated with the specified non-guaranteed order satisfies a preset business condition, and if so, Translating the specified non-guaranteed order into a credit guarantee order;
  • An order information processing device is applied to a server, including:
  • a request receiving unit configured to receive a request for the client to create a secured order for the target data object of the specified first user
  • a determining unit configured to determine whether the credit information of the second user associated with the client meets a preset service condition
  • An order creation unit configured to create an order if the judgment result of the judgment unit is satisfied, add a credit identifier, and provide the credit guarantee order to the first user data processing system, so that the first The user provides offline service reservation for the second user in the manner of credit guarantee. Business.
  • An order information processing apparatus is applied to a first user data processing system, including:
  • An order receiving unit configured to receive a credit guarantee order provided by the server, where the credit guarantee order is generated by: the server determining, when the client requests to create a guarantee order for the target data object, Whether the credit information of the second user satisfies the preset business condition, and if so, creates an order, and marks and adds a credit guarantee order identifier;
  • a status submitting unit configured to submit order status information to the server if the second user fails to perform on time, the status information is that the second user fails to perform on time, so that the server transfers from the payment account associated with the second user Presetting the amount to the first user's collection account.
  • An order type conversion processing device applied to a server comprising:
  • An order information recording unit configured to record related information of a business order, where the related information includes a first user associated with the service order and second user information, where the business order is a non-guaranteed order;
  • a conversion request receiving unit configured to receive a request to convert the specified non-guaranteed order into a secured order
  • a credit judging unit configured to determine whether the credit information of the second user associated with the specified non-guaranteed order satisfies a preset service condition
  • a conversion unit configured to convert the specified non-guaranteed order into a credit guarantee order if the judgment result of the credit judgment unit is satisfied, and provide the conversion result to the data processing system of the first user, so that the first The user provides the offline resource reservation service for the second user in the manner of credit guarantee.
  • An order type conversion processing device is applied to a first user data processing system, including:
  • a first conversion request submitting unit configured to submit, to the server, a request to convert the specified non-guaranteed order into a secured order, so that the server determines whether the credit information of the second user associated with the specified non-guaranteed order satisfies a preset business condition And if so, converting the specified non-guaranteed order into a credit guarantee order;
  • a first conversion result receiving unit configured to receive a conversion result returned by the server, so as to follow the credit
  • the manner of guarantee provides the offline resource reservation service for the second user.
  • An order type conversion processing device is applied to a second user client, including:
  • a second conversion request submitting unit configured to submit, to the server, a request to convert the specified non-guaranteed order into a secured order, so that the server determines whether the credit information of the second user associated with the specified non-guaranteed order satisfies a preset business condition And if so, converting the specified non-guaranteed order into a credit guarantee order;
  • the second conversion result receiving unit is configured to receive a conversion result returned by the server.
  • the present application discloses the following technical effects:
  • a trust attitude is adopted, and when the first user needs to provide a service for reserving offline resources, the user may not have to pay a deposit, that is, You can enjoy the corresponding service.
  • the user does not default, no additional occupation of the user funds is caused, and since the information such as the payment account of the second user does not have to be provided to the first user, the second user privacy is also ensured.
  • Information security since it is not necessary to perform a series of processes such as the second user pre-payment of the deposit and the first user re-delivery of the deposit, the resources of the system in terms of network, storage, and the like are also greatly saved. For the second user, they will feel that they are trusted and respected during the consumption process, so they can also enhance the experience of the second user.
  • the corresponding payment can be transferred from the second user's payment account to the first user's payment account by the server, and therefore, The first user suffered a loss.
  • FIG. 1 is a schematic diagram of a system provided by an embodiment of the present application.
  • FIG. 3 is a flowchart of a second method provided by an embodiment of the present application.
  • FIG. 5 is a flowchart of a fourth method provided by an embodiment of the present application.
  • FIG. 6 is a flowchart of a fifth method provided by an embodiment of the present application.
  • FIG. 7 is a schematic diagram of a first device provided by an embodiment of the present application.
  • FIG. 8 is a schematic diagram of a second device provided by an embodiment of the present application.
  • FIG. 9 is a schematic diagram of a third device provided by an embodiment of the present application.
  • FIG. 10 is a schematic diagram of a fourth device provided by an embodiment of the present application.
  • FIG. 11 is a schematic diagram of a fifth device provided by an embodiment of the present application.
  • the first user may be a merchant user or a seller user, and the first user usually provides a service for the second user in a manner of providing offline resources, and correspondingly, the second user passes the Use the offline resources provided by the first user to obtain the buyer user, consumer user, etc. of the corresponding service.
  • the specific types of offline resources are also different.
  • the specific offline resources may include rooms, facilities in the room, etc., for car rental.
  • the first user of the class the specific offline resources mainly refer to the car and so on.
  • the interaction entities involved generally include: a platform server, a second user client provided by the platform, and a first user data processing system (for example, a hotel's PMS (Property Management System)) or a first user client provided by the platform (for convenience of description, Here, the PMS is taken as an example.
  • the platform and the first user PMS may be in a cooperative relationship, and some interfaces may be opened in advance to each other.
  • the second user client of the platform may be used to first book the hotel with the “credit residence” attribute, and the platform server verifies the user credit according to the Alipay credit system.
  • the user who meets the credit rating can enjoy the credit-storage mode reservation and deliver the user reservation information to the first user PMS system in real time, and the first user front-end can also directly see the order information.
  • the deposit-free check-in can be directly performed.
  • the platform server can directly directly transfer the funds from the second user's associated account (for example, an Alipay account, etc.) is transferred to the first user's account.
  • the second user may not need to book online in advance, but directly go to the hotel to check in.
  • the first user PMS system may also collect the identity information of the second user and the Alipay account. Information, etc., is passed to the platform server, and the platform server performs credit authority verification on the second user. If the condition is met, the hotel may be notified to handle the credit for the second user. Similarly, the second user may also deposit without deposit. When you leave the store, you will be free to check the room and skip the queue. The platform server will handle the checkout.
  • the e-commerce transaction platform such as Ali Travel can cooperate with the PMS system of the first user to provide convenience for both the first user and the second user.
  • the embodiment of the present application can further provide the processing method of the order guarantee by using the feature that the server can cooperate with the first user PMS system on the basis of the above technical solutions, so that the order guarantee can also be
  • the first user and the second user provide convenience, improve efficiency, and save user time.
  • an application platform capable of providing a "credit consumption service" function is not limited to Ali travel.
  • a dedicated server may be provided for the function, and a dedicated first user client and a second user client may be developed. ,and many more.
  • the function of processing the guarantee order in the embodiment of the present application is implemented, it is not necessary to implement the function of “credit consumption service”, that is, the function of processing the guarantee order may be separately provided.
  • an order information processing method is first provided from the perspective of a server.
  • the method may include the following steps:
  • S201 The server receives a request for the client to create a guarantee order for the target data object of the specified first user;
  • the first user such as a hotel can publish its hotel product to the server, and the server can provide the data to the client in the form of a data object, wherein if the first user wants to provide a service in the form of a guarantee, the data object is published.
  • the corresponding attribute information can be provided, including the required margin amount and so on.
  • the server can provide corresponding information according to the attribute information provided when the first user issues the data object. In this way, if a user finds an option to generate a guaranteed order when subscribing to a first user's data object, this option can be used to initiate a request to create a secured order to the server.
  • S202 Determine whether the credit information of the second user associated with the client meets a preset service condition.
  • the server may first determine the credit information of the second user.
  • the specific judgment manner may be multiple.
  • the specific verification manner may be multiple, and the specific service condition may be based on actual conditions.
  • the business needs are determined. For example, it may be a restriction on the user's credit rating, the size of the credit limit, the number of outstanding transaction orders, and the like.
  • the server performs the judgment, the parameter values corresponding to the current user may be determined for each parameter involved in the service condition, and compared with the threshold set in the condition, thereby determining whether the user meets the service condition. .
  • the “sesame credit” information associated with the user's Alipay account can be obtained, and the amount information provided by the “ant flower garden” for the second user can be obtained, and the Alipay account can also be determined.
  • the number of associated outstanding orders, and so on, all of the above factors can be used to determine whether the current user meets the business conditions.
  • the user may determine that the credit information of the second user is determined by the user. And a credit amount of the second user, if the credit amount is greater than the preset amount, determining that the credit information of the second user satisfies the preset service condition.
  • an order can be generated and the type of the order marked as a credit guarantee order. For example, in one mode, a field of "whether it is a guaranteed order" can be provided in the data table in which the order information is saved, and in the case of generating a secured order, the value of the field can be set to "yes", and so on.
  • S204 The credit guarantee order is provided to the data processing system of the first user, so that the first user provides offline resource reservation service for the second user in a credit guarantee manner.
  • the order information can be provided to the first user's data processing system (for example, PMS, etc.), so that after the first user receives the order, the order date, room type, etc. recorded in the order can be followed. Reserve corresponding offline resources for the second user.
  • the data processing system of the first user can provide the order status to the server, and the order status can be: the second user fails to perform on time, at this time, The server then transfers the corresponding amount used as the deposit to the first user's collection account from the payment account associated with the second user.
  • the server and the first user's data processing system can communicate with each other through direct connection, that is, the server can establish a cooperative relationship with the first user's data processing system, and mutual Open your own standardized interface to the other party, so that each other can be directly connected to each other through the interface call, without the need for the staff of both parties to transfer information through the form of manual work orders.
  • the attitude of trust is adopted.
  • the first user needs to provide the service for the reserved offline resources, the corresponding service can be enjoyed without paying the deposit.
  • the second user privacy is also ensured.
  • Information security since it is not necessary to perform a series of processes such as the second user pre-payment of the deposit and the first user re-delivery of the deposit, the resources of the system in terms of network, storage, and the like are also greatly saved.
  • the second user will feel that they are respected in the consumption process, so they can also enhance the experience of the second user.
  • the corresponding payment can be transferred from the second user's payment account to the first user's payment account by the server, and therefore, Will not cause the first user to suffer losses.
  • the second embodiment is corresponding to the first embodiment. From the perspective of the first user data processing system, an order information processing method is provided. Referring to FIG. 3, the method may include the following steps:
  • the first user's data processing system receives a credit guarantee order provided by the server, and the credit guarantee order is generated by: the server determining the client when receiving a request for the client to create a guarantee order for the target data object Whether the credit information of the second user associated with the end meets the preset business condition, and if so, creates an order and adds a credit identifier;
  • S302 If the second user fails to perform on time, submit the order status information to the server, where the status information is that the second user fails to perform on time, so that the server allocates the preset amount from the payment account associated with the second user to The first user's collection account.
  • the following application scenarios may also exist: when the second user subscribes online, The way of non-guaranteed order, however, it is later hoped that the first user will reserve the offline resources for it.
  • the second user can usually only cancel the original non-guaranteed order. , then re-book and generate a warranty order, or ask the user to provide information such as a credit card to guarantee. This obviously makes the operation process more cumbersome and inefficient, and it will also waste resources for the platform server. Therefore, in the embodiment of the present application, on the basis of the guarantee method mentioned in the foregoing embodiment, the function of performing order type conversion can also be provided.
  • the initiator of the order type conversion may be the second user client, or may be the data processing system of the first user, which is described in detail below.
  • an order type conversion processing method is first provided from the perspective of the server.
  • the method may include the following steps:
  • the server records related information of the service order, where the related information includes a first user associated with the service order and second user information, where the business order is a non-guaranteed order;
  • the corresponding business order is usually generated by the server, and the identification information of the first user and the second user may be recorded in the service order.
  • the online subscription since the online subscription is adopted, it means that the first user and the second user are registered users of the current platform (for example, Ali travel), and therefore, the identification information of the first user and the second user is saved. It can be saved by user id, user name, account information, and so on.
  • the first user client initiates a credit check to the second user to the server, and the verification is passed. If the server determines that the second user is a trusted user, the first user client generates a service order for the first user client, and the first user client can save the business order information to the server after generating the business order (for example, Ali travels The server, etc., including the status of the order, the associated first user second user identification information, etc., the server can save the relevant information of the business order.
  • the business order information for example, Ali travels The server, etc., including the status of the order, the associated first user second user identification information, etc.
  • the user is usually a user registered on a platform such as Ali Travel, and therefore, the user id, user name or account name registered by the user in the platform can be utilized. Information such as the identity of the second user.
  • the first user if the first The user is using the client provided by the Ali travel platform, and can also be identified by the user id, user name or account name registered by the first user in the Ali travel platform. If the third-party PMS system is used, the first user may be identified by other information, for example, the device id used by the first user, or the user id, account name, and the like registered in the PMS system.
  • S402 Receive a request to convert the specified non-guaranteed order into a secured order
  • the request for converting the order type may be initiated by the second user.
  • the second user client may submit the conversion request to the server.
  • the foregoing conversion request may be initiated by the second user, or may be sent by the data processing system of the first user according to the planned check-in time recorded in the non-guaranteed order.
  • the data processing system of the first user may first submit the reminder information to the server, and then the server sends the reminder message to the second user client, or may also be based on the second record recorded in the server.
  • the user's contact information, the short message, etc., the reminder message is sent to the second user, and so on.
  • the request to convert the order type may also be initiated by the data processing system of the first user, in which case the two users may negotiate when the second user contacts the first user through some means. Thereafter, a request for an order type conversion is initiated by the first user data processing system.
  • the server may first send a notification message to the second user client after receiving the request sent by the data processing system of the first user. The order is applied by the first user's data processing system for order type conversion, and in the case where the second user client returns confirmation that it can be converted, the subsequent conversion operation is performed.
  • S403 Determine whether the credit information of the second user associated with the specified non-guaranteed order satisfies a preset service condition
  • the verification process of the second user credit information in this step may be similar to that in the first embodiment.
  • the description in the first embodiment refer to the description in the first embodiment.
  • the previous non-guaranteed order is already a “credit consumption order”
  • the second user cannot perform on time after being converted into a guarantee order, there is a standard according to the preset.
  • the non-guaranteed order can be converted into a credit guarantee order.
  • the process of the conversion only needs to mark the order, Other operations need to be performed, including the second user paying the deposit in advance.
  • the conversion result can be provided to the data processing system of the first user, so that the first user can provide the second user according to the credit guarantee manner, that is, without the second user pre-payment In the case of margin, you can keep the corresponding offline resources, including rooms, etc., according to the reservation information in the order.
  • the conversion result can also be provided to the second user client.
  • the subsequent processing can be the same as in the first embodiment, that is, if the second user performs on time, the second user does not need to pay the additional fee associated with the deposit, and when the second When the user has not fulfilled the contract on time, the data processing system of the first user may provide the order status information to the server to notify the server that the second user fails to perform on time, and at this time, the server may be used by the server from the second user.
  • the associated payment account transfers the preset amount to the first user's collection account.
  • the order type can be flexibly converted, the non-guaranteed order is converted into a guarantee order, and in the conversion process, the second user can also enjoy the first user without paying the deposit in advance.
  • the fourth embodiment corresponds to the three phases of the embodiment, and is performed from the perspective of the data processing system of the first user.
  • the fourth embodiment provides an order type conversion processing method, and the method may include the following steps:
  • the first user data processing system submits a request for converting the specified non-guaranteed order into a guarantee order to the server, so that the server determines whether the credit information of the second user associated with the specified non-guaranteed order satisfies a preset business condition. If satisfied, converting the specified non-guaranteed order into a credit guarantee order;
  • S502 Receive a conversion result returned by the server, so as to provide the second user with an offline resource reservation service in a credit guarantee manner.
  • the order status information may also be submitted to the server, the status information being that the second user fails to perform on time, so that the server allocates the preset amount from the payment account associated with the second user to The first user's collection account.
  • the order type conversion request is submitted by the first user data processing system to the server, and in another implementation, the order type conversion request may also be submitted by the second user client to the server.
  • the fifth embodiment provides an order type conversion processing method, and the method may include the following steps:
  • S601 The client submits a request for converting the specified non-guaranteed order into a guarantee order to the server, so that the server determines whether the credit information of the second user associated with the specified non-guaranteed order satisfies a preset business condition, and if yes, Converting the specified non-guaranteed order into a credit guarantee order;
  • the fourth embodiment and the fifth embodiment are corresponding to the three-phase of the embodiment. Therefore, the related specific implementation can be referred to in the third embodiment, and details are not described herein again.
  • the embodiment of the present application further provides an order information processing device, and the device The device is applied to the server.
  • the device may specifically include:
  • the request receiving unit 701 is configured to receive a request for the client to create a guarantee order for the target data object of the specified first user;
  • the determining unit 702 is configured to determine whether the credit information of the second user associated with the client meets a preset service condition
  • An order creating unit 703 configured to: if the judgment result of the determining unit is satisfied, create an order, add a credit identifier, and provide the credit guarantee order to the first user data processing system, so that the A user provides offline resource reservation service for the second user in a credit guarantee manner.
  • the order creation unit 703 may specifically provide the credit guarantee order to the first user data processing system through an interface of the first user data processing system that is known in advance.
  • the device may further include:
  • An order status receiving unit configured to receive status information of the order provided by the data processing system of the first user
  • the resource allocation unit is configured to: if the order status is that the second user fails to perform on time, transfer the preset resource information from the payment account associated with the second user to the first user's collection account.
  • the preset resource information may be provided by the first user when the target data object is published.
  • the determining unit 702 may be specifically configured to: determine, according to the credit information of the second user, a credit quota of the second user; if the credit quota is greater than the preset amount, determine the second user The credit information satisfies the preset business conditions.
  • the embodiment of the present application further provides an order information processing device, which is applied to the first user data processing system.
  • the device may specifically include:
  • An order receiving unit 801 configured to receive a credit guarantee order provided by a server, where the credit guarantee The order is generated by the server determining, when the client requests to create a guarantee order for the target data object, whether the credit information of the second user associated with the client satisfies a preset business condition, and if yes, Create an order, mark it and add a credit guarantee order identifier;
  • the status submitting unit 802 is configured to submit, to the server, order status information if the second user fails to perform on time, the status information is that the second user fails to perform on time, so that the server associates the payment account with the second user. Transfer the preset amount to the first user's collection account.
  • the embodiment of the present application further provides an order information processing device, which is applied to a server.
  • the device may specifically include:
  • the order information recording unit 901 is configured to record related information of the business order, where the related information includes the first user and the second user information associated with the service order, and the business order is a non-guaranteed order;
  • a conversion request receiving unit 902 configured to receive a request to convert the specified non-guaranteed order into a secured order
  • the credit determining unit 903 is configured to determine whether the credit information of the second user associated with the specified non-guaranteed order satisfies a preset service condition
  • the converting unit 904 is configured to convert the specified non-guaranteed order into a credit guarantee order if the judgment result of the credit judging unit is satisfied, and provide the conversion result to the data processing system of the first user, so that the A user provides offline resource reservation service for the second user in a credit guarantee manner.
  • the conversion request receiving unit 902 may be specifically configured to receive a request submitted by the data processing system of the first user to convert the specified non-guaranteed order into a secured order;
  • the device may further include:
  • a notification unit configured to send a notification message to the second user client associated with the specified non-guarantee order before determining whether the credit information of the second user associated with the specified non-guarantee order meets the preset service condition
  • the triggering unit is configured to trigger the performing the determining operation after receiving the response of the confirmation conversion returned by the second user client.
  • the conversion request receiving unit 902 may be specifically configured to: receive a request submitted by the second user client to convert the specified non-guaranteed order into a secured order.
  • the device may further include:
  • the conversion result providing unit is configured to provide the order conversion result to the second user client.
  • the device may further include:
  • An order status information receiving unit configured to receive order status information provided by the data processing system of the first user
  • the resource allocation unit is configured to: if the order status is that the second user fails to perform on time, transfer the preset resource information from the payment account associated with the second user to the first user's collection account.
  • the embodiment of the present application further provides an order information processing device, which is applied to the first user data processing system.
  • the device may specifically include:
  • a first conversion request submitting unit 1001 configured to submit, to the server, a request to convert the specified non-guaranteed order into a secured order, so that the server determines whether the credit information of the second user associated with the specified non-guaranteed order satisfies a preset service a condition, if satisfied, converting the specified non-guaranteed order into a credit guarantee order;
  • the first conversion result receiving unit 1002 is configured to receive a conversion result returned by the server, so as to provide the second user with an offline resource reservation service according to a credit guarantee manner.
  • the embodiment of the present application further provides an order information processing device, which is applied to the second user client.
  • the device may specifically include:
  • a second conversion request submitting unit 1101 configured to submit to the server to convert the specified non-guaranteed order a request for guaranteeing an order, so that the server determines whether the credit information of the second user associated with the specified non-guaranteed order satisfies a preset business condition, and if so, converts the specified non-guaranteed order into a credit guarantee order;
  • the second conversion result receiving unit 1102 is configured to receive a conversion result returned by the server.
  • a trust attitude is adopted, and when the first user needs to provide a service for reserving offline resources, the user may not have to pay a deposit, that is, You can enjoy the corresponding service.
  • the user does not default, no additional occupation of the user funds is caused, and since the information such as the payment account of the second user does not have to be provided to the first user, the second user privacy is also ensured.
  • Information security since it is not necessary to perform a series of processes such as the second user pre-payment of the deposit and the first user re-delivery of the deposit, the resources of the system in terms of network, storage, and the like are also greatly saved. For the second user, they will feel that they are trusted and respected during the consumption process, so they can also enhance the experience of the second user.
  • the present application can be implemented by means of software plus a necessary general hardware platform. Based on such understanding, the technical solution of the present application may be embodied in the form of a software product in essence or in the form of a software product, which may be stored in a storage medium such as a ROM/RAM or a disk. , an optical disk, etc., includes instructions for causing a computer device (which may be a personal computer, server, or network device, etc.) to perform the methods described in various embodiments of the present application or portions of the embodiments.
  • a computer device which may be a personal computer, server, or network device, etc.

Abstract

本申请实施例公开了订单信息处理以及订单类型转换处理方法及装置，所述方法包括：服务器接收客户端针对指定第一用户的目标数据对象创建担保订单的请求；判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件；如果满足，则创建订单，并添加信用标识符，并将所述信用担保订单提供给所述第一用户的数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。通过本申请实施例，能够提高用户信息安全性，提高效率，节省网络资源。

Description

订单信息处理以及订单类型转换处理方法及装置 技术领域
本申请涉及订单信息处理技术领域，特别是涉及订单信息处理以及订单类型转换处理方法及装置。
背景技术
随着电子商务交易平台以及在线支付业务不断扩大，线下到线下(O2O)市场的重要性逐渐凸显出来，而“衣食住行”中“住”作为其中非常重要的组成部分，人们对于旅游服务品质的追求也上升到了全新的高度。在此背景下，未来的酒店业将需要在技术设备、营销模式、经营效率及服务理念等方面升级到新的高度，才能满足消费者预期，提升行业竞争力。
现有技术中，一些电商平台能够提供“在线订房线下入住”的服务，在线预订酒店时，如果指定了入住日期，并且要求酒店为其保留房间，则用户通常需要支付一定的保证金，如果用户不按时入住，则保证金不予退还，以免造成酒店的经济损失。而如果用户按时入住，则在用户离店时，将保证金退还给用户。
以上这种传统的担保方式具有一些弊端，首先，需要用户提前支付保证金，会对用户的资金造成占用；其次，通常需要将用户的支付账户信息提供给酒店，其中，对于一些国内酒店，能够支持的支付途径比较多，可以包括银行卡、支付宝等、其他第三方支付工具等，而一些国际的酒店，通常只能支持银行卡支付，但无论采用何种支付方式，都存在将用户的账户信息提供给酒店的情况，因此，在支付的过程中存在安全隐患；再者，操作流程相对复杂，效率比较低，在用户按时入住的情况下，还需要执行逆向流程，将保证金退还到用户的账户，对于网络资源等也会造成一定程度的浪费，并且逆向流程一般无法实时到账，用户资金占用时间更长，另外，通常还需要通过支付工具交易明细查询资金到账情况，体验非常差。
发明内容
本申请提供了订单信息处理以及订单类型转换处理方法及装置，能够提高用户信息安全性，提高效率，节省网络资源。
本申请提供了如下方案：
一种订单信息处理方法，包括：
服务器接收客户端针对指定第一用户的目标数据对象创建担保订单的请求；
判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件；
如果满足，则创建订单，并添加信用标识符，并将所述信用担保订单提供给所述第一用户数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。
一种订单信息处理方法，包括：
第一用户数据处理系统接收服务器提供的信用担保订单，所述信用担保订单通过以下方式生成：所述服务器在接收到客户端针对目标数据对象创建担保订单的请求时，判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则创建订单，并添加信用标识符；
如果第二用户未能按时履约，则向所述服务器提交订单状态信息，所述状态信息为第二用户未按时履约，以便服务器从所述第二用户关联的支付账户划拨预置金额到所述第一用户的收款账户。
一种订单类型转换处理方法，包括：
服务器记录业务订单的相关信息，所述相关信息包括所述业务订单关联的第一用户以及第二用户信息，所述业务订单为非担保订单；
接收将指定非担保订单转换为担保订单的请求；
判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件；
如果满足，则将所述指定非担保订单转换为信用担保订单，并将转换结果提供给第一用户数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。
一种订单类型转换处理方法，包括：
第一用户数据处理系统向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；
接收服务器返回的转换结果，以便按照信用担保的方式为所述第二用户提供线下资源预留服务。
一种订单类型转换处理方法，包括：
第二用户客户端向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；
接收服务器返回的转换结果。
一种订单信息处理装置，应用于服务器，包括：
请求接收单元，用于接收客户端针对指定第一用户的目标数据对象创建担保订单的请求；
判断单元，用于判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件；
订单创建单元，用于如果所述判断单元的判断结果为满足，则创建订单，并添加信用标识符，并将所述信用担保订单提供给所述第一用户数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服 务。
一种订单信息处理装置，应用于第一用户数据处理系统，包括：
订单接收单元，用于接收服务器提供的信用担保订单，所述信用担保订单通过以下方式生成：所述服务器在接收到客户端针对目标数据对象创建担保订单的请求时，判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则创建订单，标记为并添加信用担保订单标识符；
状态提交单元，用于如果第二用户未能按时履约，则向所述服务器提交订单状态信息，所述状态信息为第二用户未按时履约，以便服务器从所述第二用户关联的支付账户划拨预置金额到所述第一用户的收款账户。
一种订单类型转换处理装置，应用于服务器，包括：
订单信息记录单元，用于记录业务订单的相关信息，所述相关信息包括所述业务订单关联的第一用户以及第二用户信息，所述业务订单为非担保订单；
转换请求接收单元，用于接收将指定非担保订单转换为担保订单的请求；
信用判断单元，用于判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件；
转换单元，用于如果所述信用判断单元的判断结果为满足，则将所述指定非担保订单转换为信用担保订单，并将转换结果提供给第一用户的数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。
一种订单类型转换处理装置，应用于第一用户数据处理系统，包括：
第一转换请求提交单元，用于向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；
第一转换结果接收单元，用于接收服务器返回的转换结果，以便按照信用 担保的方式为所述第二用户提供线下资源预留服务。
一种订单类型转换处理装置，应用于第二用户客户端，包括：
第二转换请求提交单元，用于向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；
第二转换结果接收单元，用于接收服务器返回的转换结果。
根据本申请提供的具体实施例，本申请公开了以下技术效果：
通过本申请实施例，对于信用度比较高的第二用户，采用的是信任的态度，在其需要第一用户为其提供预留线下资源的服务时，可以在不必支付保证金的情况下，即可享受相应的服务。这样，在用户未发生违约的情况下，就不会造成对用户资金的额外占用，并且，由于不必将第二用户的支付账户等信息提供给第一用户，因此，也保证了第二用户隐私信息的安全性。另外，由于不必执行第二用户预先支付保证金、第一用户再退还保证金等一系列的流程，因此，也大大节省了系统在网络、存储等方面的资源。对于第二用户而言，会感觉到自己在消费过程中被信任而获得尊重，因此，也可以提升第二用户的体验。
对于第一用户而言，在第二用户未按时履约的情况下，还可以由服务器将相应的款项，从第二用户的支付账户划拨到第一用户的收款账户，因此，也不会使得第一用户受到损失。
当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的系统的示意图；
图2是本申请实施例提供的第一方法的流程图；
图3是本申请实施例提供的第二方法的流程图；
图4是本申请实施例提供的第三方法的流程图；
图5是本申请实施例提供的第四方法的流程图；
图6是本申请实施例提供的第五方法的流程图；
图7是本申请实施例提供的第一装置的示意图；
图8是本申请实施例提供的第二装置的示意图；
图9是本申请实施例提供的第三装置的示意图；
图10是本申请实施例提供的第四装置的示意图；
图11是本申请实施例提供的第五装置的示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。
在本申请实施例中，第一用户可以是商家用户或者卖家用户等，并且这种第一用户通常是以提供线下资源的方式，为第二用户提供服务，相应的，第二用户就是通过使用第一用户提供的线下资源获得相应服务的买家用户、消费者用户等。具体的，对于不同类别的第一用户，线下资源的具体种类也有所不同，例如，对于酒店类的第一用户，具体的线下资源可以包括客房、房内的设施等等，对于汽车租赁类的第一用户，具体的线下资源主要是指汽车等。
针对上述应用场景，在本申请人提交的其他专利申请中，提供了以下技术方案：基于现有的电子商务交易平台(例如，阿里旅行、支付宝等，为便于描述，这里以阿里旅行为例进行介绍)，可以为用户提供“信用消费服务”，例如，可以称为“信用住”等。具体实现时，参见图1，涉及到的交互实体通常包括： 平台服务器，平台提供的第二用户客户端，以及第一用户数据处理系统(例如，酒店的PMS(Property Management System，经营管理系统))或者平台提供的第一用户客户端等(为便于描述，这里以PMS为例进行介绍，此时，平台与第一用户PMS之间可以是合作关系，可以预先开放自己的一些接口给对方)。当第二用户具体需要使用信用消费服务(例如，信用住)时，可以首先利用平台的第二用户客户端，在线预订具有“信用住”属性的酒店，平台服务器依据支付宝信用体系校验用户信用等级，符合信用等级的用户可以享受信用住模式预定，并将用户预定信息实时传递到第一用户PMS系统，第一用户前台也可以直接看到订单信息。第二用户到第一用户办理入住时，可以直接进行免押金入住，在第二用户离店时，免查房、免排队，平台服务器可以直接将实际消费的资金从第二用户的关联账户(例如，支付宝账户等)划拨到第一用户的账户。或者，在其中的“信用住”模式下，第二用户也可以不必预先在线预订，而是直接到酒店办理入住，此时，第一用户PMS系统也可以采集第二用户的身份信息、支付宝账户信息等，将其传递给平台服务器，平台服务器对第二用户进行信用权限验证，如果满足条件，则可以通知酒店为该第二用户办理信用住，同样，该第二用户也可以免押金入住，离店时免查房、免排队，由平台服务器办理结账事宜。
总之，在提供信用消费服务的过程中，阿里旅行等电子商务交易平台可以与第一用户的PMS系统相互配合，为第一用户以及第二用户都提供了便利。相应的，本申请实施例就可以在以上技术方案的基础上，利用服务器能够与第一用户PMS系统相互配合这一特点，进一步提供订单担保的处理方法，以便在开具订单担保环节上也能够为第一用户以及第二用户提供便利，提高效率，节省用户时间。当然，在实际应用中，能够提供“信用消费服务”功能的应用平台也不限于阿里旅行，例如，还可以为该功能提供专用的服务器，开发专用的第一用户客户端、第二用户客户端，等等。另外，在实现本申请实施例中的处理担保订单的功能时，也可以不必以实现“信用消费服务”功能为前提，也就是说，可以单独提供处理担保订单的功能。
需要说明的是，前文所述中提及的“酒店”、“阿里旅行”、“信用住”等是为了对本申请实施例的具体实现方式进行举例说明，不应看作是对本申请实施 例保护范围的限定。
下面对具体的实现方式进行详细介绍。
实施例一
该实施例一首先从服务器的角度提供了一种订单信息处理方法，参见图2，该方法可以包括以下步骤：
S201：服务器接收客户端针对指定第一用户的目标数据对象创建担保订单的请求；
具体实现时，酒店等第一用户可以将其酒店产品发布到服务器，服务器就可以以数据对象的形式提供给客户端，其中，如果第一用户想要提供担保形式的服务，则在发布数据对象时可以提供相应的属性信息，包括所需的保证金金额等等。服务器在向客户端提供数据对象信息时，就可以根据第一用户发布数据对象时提供的属性信息，提供相应的信息。这样，如果某用户在预订某第一用户的数据对象时，发现存在可生成担保订单的选项，则可以通过该选项，向服务器发起创建担保订单的请求。
S202：判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件；
服务器在收到客户端的请求后，可以首先对第二用户的信用信息进行判断，具体的判断方式可以有多种，例如，具体的验证方式可以有多种，并且，具体的业务条件可以根据实际的业务需求来确定。例如，可以是对用户的信用等级、信用额度的大小、未结账交易订单的数量等进行限制。这样，服务器具体在进行判断时，针对业务条件中涉及到的各项参数，可以确定出当前用户对应的参数值，并与条件中设定的阈值等进行比对，进而确定用户是否符合业务条件。例如，在阿里旅行平台下，可以获取到用户的支付宝账户关联的“芝麻信用”信息，还可以获取“蚂蚁花呗”为该第二用户提供的额度信息，另外，还可以确定出该支付宝账户关联的未结账订单数量，等等，以上因素都可以用于确定当前用户是否满足业务条件。
其中，如果数据对象信息中记录有如果发生未按时履约的情况下，需要支付的金额信息，则在进行业务条件判断时，还可以判断用户的根据所述第二用户的信用信息，确定所述第二用户的授信额度，如果所述授信额度大于所述预置金额，则确定所述第二用户的信用信息满足所述预置的业务条件。
S203：如果满足，则创建订单，并添加信用标识符；
如果满足条件，即可生成订单，并将订单的类型标记为信用担保订单。例如，在一种方式下，可以在保存订单信息的数据表中提供“是否为担保订单”的字段，在生成担保订单的情况下，可以将该字段的值置为“是”，等等。
需要说明的是，在本申请实施例中，在生成担保订单后，只需要添加相应的标识符即可，第二用户不需要执行支付保证金操作，也就不存在将其支付账户信息提供给第一用户的情况，因此，可以降低安全隐患。当然，关于在用户未按时入住等情况下需要支付的金额，可以记录在相应的订单中，以便后续当发生这种违约情况时，按照订单中记录的金额，向第一用户进行款项的划拨。
S204：将所述信用担保订单提供给所述第一用户的数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。
在生成订单后，就可以将订单信息提供给第一用户的数据处理系统(例如，PMS等)，这样，在第一用户收到订单后，就可以按照订单中记录的入住日期、房型等，为第二用户预留相应的线下资源。之后，如果第二用户未能按照订单中约定的时间进店入住，则第一用户的数据处理系统可以将订单状态提供给服务器，该订单状态可以为：第二用户未按时履约，此时，服务器再从第二用户关联的支付账户中，将相应的用作保证金的金额划拨到第一用户的收款账户中。
需要说明的是，在实际应用中，服务器与第一用户的数据处理系统之间可以通过直连的方式进行互通，也即，服务器可以与第一用户的数据处理系统之间建立合作关系，相互开放自己的标准化接口给对方，这样，相互之间就可以通过接口调用的方式，实现信息的直连式互通，而不需要由双方的工作人员通过手动工单的形式来进行信息传递。
总之，通过本申请实施例提供的实现方案，对于信用度比较高的第二用户， 采用的是信任的态度，在其需要第一用户为其提供预留线下资源的服务时，可以在不必支付保证金的情况下，即可享受相应的服务。这样，在用户未发生违约的情况下，就不会造成对用户资金的额外占用，并且，由于不必将第二用户的支付账户等信息提供给第一用户，因此，也保证了第二用户隐私信息的安全性。另外，由于不必执行第二用户预先支付保证金、第一用户再退还保证金等一系列的流程，因此，也大大节省了系统在网络、存储等方面的资源。对于第二用户而言，会感觉到自己在消费过程中获得尊重，因此，也可以提升第二用户的体验。当然，对于第一用户而言，由于在第二用户未按时履约的情况下，还可以由服务器将相应的款项，从第二用户的支付账户划拨到第一用户的收款账户，因此，也不会使得第一用户受到损失。
实施例二
该实施例二是与实施例一相对应的，从第一用户数据处理系统的角度，提供了一种订单信息处理方法，参见图3，该方法可以包括以下步骤：
S301：第一用户的数据处理系统接收服务器提供的信用担保订单，所述信用担保订单通过以下方式生成：所述服务器在接收到客户端针对目标数据对象创建担保订单的请求时，判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则创建订单，并添加信用标识符；
S302：如果第二用户未能按时履约，则向所述服务器提交订单状态信息，所述状态信息为第二用户未按时履约，以便服务器从所述第二用户关联的支付账户划拨预置金额到所述第一用户的收款账户。
以上实施例二是与实施例一相对应的，因此，相关的具体实现参见实施例一中的介绍即可，这里不再赘述。
实施例三
在实际应用中，还可能存在以下应用场景：第二用户在线预订时，采用了 非担保订单的方式，但是，在后来又希望第一用户为其进行线下资源的预留，此时，如果是在现有技术中，则第二用户通常只能将原来的非担保订单取消，然后再重新进行预订，并生成担保订单，或者要求用户提供信用卡等信息用来担保。这样显然会使得操作流程比较繁琐，效率不高，对于平台服务器而言，也会造成资源的浪费。为此，在本申请实施例中，在采用前述实施例中提到的担保方式的基础下，还可以提供进行订单类型转换的功能。其中，订单类型转换的发起方可以是第二用户客户端，还可以是第一用户的数据处理系统，下面分别进行详细介绍。
在该实施例三中，首先从服务器的角度提供了一种订单类型转换处理方法，参见图4，该方法可以包括以下步骤：
S401：服务器记录业务订单的相关信息，所述相关信息包括所述业务订单关联的第一用户以及第二用户信息，所述业务订单为非担保订单；
具体实现时，如果是第二用户预先通过客户端预订了“信用消费服务”，则相应的业务订单通常是由服务器生成的，该业务订单中可以记录第一用户以及第二用户的标识信息。其中，由于是采用在线预订的方式，因此，也即意味着第一用户以及第二用户都是当前平台(例如阿里旅行)的注册用户，因此，在保存第一用户以及第二用户的标识信息时，可以通过用户id、用户名、账户信息等进行保存。
如果第二用户并没有提前在线预订“信用消费服务”，而是在第二用户进店消费时，由第一用户客户端向服务器发起对第二用户的信用校验，并在校验通过，服务器确定该第二用户为可信用户的情况下，第一用户客户端为其生成业务订单，则第一用户客户端在生成业务订单后，可以将业务订单信息保存到服务器(例如，阿里旅行的服务器等)，包括订单的状态、关联的第一用户第二用户标识信息等，服务器可以对业务订单的这些相关信息进行保存。
需要说明的是，在上述第二种情况下，关于第二用户，该用户通常是在阿里旅行等平台注册的用户，因此，可以利用该用户在平台中注册的用户id、用户名或者账户名等信息，作为第二用户的标识。而关于第一用户，如果第一 用户使用的是阿里旅行平台提供的客户端，则也可以通过第一用户在阿里旅行平台中注册的用户id、用户名或者账户名等信息进行标识。而如果是使用的第三方PMS系统，则可以通过其他信息对第一用户进行标识，例如，可以是第一用户使用的设备id，或者，在PMS系统中注册的用户id、账户名等等。
S402：接收将指定非担保订单转换为担保订单的请求；
具体实现时，转换订单类型的请求可以是由第二用户发起的，例如，此时，可以由第二用户客户端向服务器提交转换请求。当然，在实际应用中，上述转换请求可以是由第二用户主动发起，或者，也可以由第一用户的数据处理系统根据非担保订单中记录的计划入住时间等信息，提前发出提醒消息，以提醒第二用户进行订单类型的转换。其中，对于后者，第一用户的数据处理系统，可以首先将提醒信息提交到服务器，然后，再由服务器将提醒消息发送到第二用户客户端，或者，还可以根据服务器中记录的第二用户的联系方式，通过短消息等方式，将提醒消息发送给第二用户，等等。
或者，转换订单类型的请求也可以是由第一用户的数据处理系统发起的，在这种情况下，可以是在第二用户通过某种途径联系到第一用户的情况下，两者进行协商之后，由第一用户数据处理系统发起订单类型转换的请求。当然，对于这种情况，为了确保第二用户对该转换操作的知情权，服务器在接收到第一用户的数据处理系统发送的请求后，还可以首先向第二用户客户端发送通知消息，通知其订单被第一用户的数据处理系统申请进行订单类型转换，在第二用户客户端返回确认可以转换的情况下，再执行后续的转换操作。
S403：判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件；
该步骤中具体对第二用户信用信息的验证过程可以与实施例一中类似，参见实施例一中的记载即可。需要说明的是，如果之前的非担保订单已经是“信用消费订单”，则意味着在生成非担保订单时，已经对第二用户进行了信用验证，因此，也可以直接根据非担保订单是否为信用消费订单进行验证。当然，由于在转换成担保订单后，如果第二用户不能按时履约，则存在按照预置的标 准对第一用户进行赔付的情况，因此，即使在之前的非担保订单生成过程中已经对第二用户进行了信用校验，该步骤中，也可以进行进一步的校验，例如，判断第二用户的授信额度，是否高于失约时的赔付标准，等等。
S404：如果满足，则将所述指定非担保订单转换为信用担保订单，并将转换结果提供给第一用户的数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。
在确定第二用户的信用符合预置业务条件的情况下，即可将非担保订单转换为信用担保订单，在本申请实施例中，该转换的过程，只需要对订单进行标记即可，不需要执行其他操作，包括第二用户预先支付保证金等。在类型转换完成后，即可将转换结果提供给第一用户的数据处理系统，这样，第一用户就可以按照信用担保的方式为第二用户提供服务，也即，在无需第二用户预先支付保证金的情况下，即可按照订单中的预约信息，保留相应的线下资源，包括房间，等等。另外，在订单类型转换完成后，还可以将转换结果提供给第二用户客户端。
在将订单转换为信用担保订单之后，后续的处理便可以与前述实施例一中相同，也即，如果第二用户按时履约，则第二用户无需支付与保证金相关的额外费用，而当第二用户存在未按时履约的情况时，第一用户的数据处理系统可以将订单状态信息提供给服务器，以通知服务器，第二用户未能按时履约，此时，就可以由服务器从所述第二用户关联的支付账户划拨预置金额到所述第一用户的收款账户。
可见，在该实施例三中，可以灵活的进行订单类型的转换，将非担保订单转换为担保订单，并且，在转换过程中，同样无需第二用户提前支付保证金，即可享受到第一用户为其预留相应线下资源的服务，提高效率，节省系统资源，同时，也可以提升用户体验。
实施例四
该实施例四是与实施例三相对应的，从第一用户的数据处理系统角度进行 介绍，具体的，参见图5，该实施例四提供了一种订单类型转换处理方法，该方法可以包括以下步骤：
S501：第一用户数据处理系统向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；
S502：接收服务器返回的转换结果，以便按照信用担保的方式为所述第二用户提供线下资源预留服务。
如果第二用户未能按时履约，则还可以向所述服务器提交订单状态信息，所述状态信息为第二用户未按时履约，以便服务器从所述第二用户关联的支付账户划拨预置金额到所述第一用户的收款账户。
实施例五
在上述实施例四中，订单类型转换请求是由第一用户数据处理系统提交到服务器的，而在另一种实现方式下，该订单类型转换请求也可以是由第二用户客户端提交到服务器，具体的，参见图6，该实施例五提供了一种订单类型转换处理方法，该方法可以包括以下步骤：
S601：客户端向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；
S602：接收服务器返回的转换结果。
以上实施例四、五均是与实施例三相对应的，因此，相关的具体实现参见实施例三中的介绍即可，这里不再赘述。
与实施例一相对应，本申请实施例还提供了一种订单信息处理装置，该装 置应用于服务器，参见图7，该装置具体可以包括：
请求接收单元701，用于接收客户端针对指定第一用户的目标数据对象创建担保订单的请求；
判断单元702，用于判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件；
订单创建单元703，用于如果所述判断单元的判断结果为满足，则创建订单，并添加信用标识符，并将所述信用担保订单提供给所述第一用户数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。
具体实现时，所述订单创建单元703具体可以通过预先获知的所述第一用户数据处理系统的接口，将所述信用担保订单提供给所述第一用户数据处理系统。
在一种具体的实现方式下，该装置还可以包括：
订单状态接收单元，用于接收所述第一用户的数据处理系统提供的所述订单的状态信息；
资源划拨单元，用于如果所述订单状态为第二用户未按时履约，则从所述第二用户关联的支付账户划拨预置资源信息到所述第一用户的收款账户。
其中，所述预置资源信息可以由所述第一用户在发布所述目标数据对象时提供。
此时，判断单元702具体可以用于：根据所述第二用户的信用信息，确定所述第二用户的授信额度；如果所述授信额度大于所述预置金额，则确定所述第二用户的信用信息满足所述预置的业务条件。
与实施例二相对应，本申请实施例还提供了一种订单信息处理装置，该装置应用于第一用户数据处理系统，参见图8，该装置具体可以包括：
订单接收单元801，用于接收服务器提供的信用担保订单，所述信用担保 订单通过以下方式生成：所述服务器在接收到客户端针对目标数据对象创建担保订单的请求时，判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则创建订单，标记为并添加信用担保订单标识符；
状态提交单元802，用于如果第二用户未能按时履约，则向所述服务器提交订单状态信息，所述状态信息为第二用户未按时履约，以便服务器从所述第二用户关联的支付账户划拨预置金额到所述第一用户的收款账户。
与实施例三相对应，本申请实施例还提供了一种订单信息处理装置，该装置应用于服务器，参见图9，该装置具体可以包括：
订单信息记录单元901，用于记录业务订单的相关信息，所述相关信息包括所述业务订单关联的第一用户以及第二用户信息，所述业务订单为非担保订单；
转换请求接收单元902，用于接收将指定非担保订单转换为担保订单的请求；
信用判断单元903，用于判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件；
转换单元904，用于如果所述信用判断单元的判断结果为满足，则将所述指定非担保订单转换为信用担保订单，并将转换结果提供给第一用户的数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。
具体实现时，转换请求接收单元902具体可以用于接收第一用户的数据处理系统提交的将指定非担保订单转换为担保订单的请求；
此时，该装置还可以包括：
通知单元，用于在判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件之前，向所述指定非担保订单关联的第二用户客户端发送通知消息；
触发单元，用于在接收到第二用户客户端返回的确认转换的响应后，触发执行所述判断操作。
在另一种实现方式下，所述转换请求接收单元902具体可以用于：接收第二用户客户端提交的将指定非担保订单转换为担保订单的请求。
此时，该装置还可以包括：
转换结果提供单元，用于将订单转换结果提供给第二用户客户端。
另外，该装置还可以包括：
订单状态信息接收单元，用于接收所述第一用户的数据处理系统提供的订单状态信息；
资源划拨单元，用于如果所述订单状态为第二用户未按时履约，则从所述第二用户关联的支付账户划拨预置资源信息到所述第一用户的收款账户。
与实施例四相对应，本申请实施例还提供了一种订单信息处理装置，该装置应用于第一用户数据处理系统，参见图10，该装置具体可以包括：
第一转换请求提交单元1001，用于向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；
第一转换结果接收单元1002，用于接收服务器返回的转换结果，以便按照信用担保的方式为所述第二用户提供线下资源预留服务。
与实施例五相对应，本申请实施例还提供了一种订单信息处理装置，该装置应用于第二用户客户端，参见图11，该装置具体可以包括：
第二转换请求提交单元1101，用于向服务器提交将指定非担保订单转换 为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；
第二转换结果接收单元1102，用于接收服务器返回的转换结果。
通过本申请实施例，对于信用度比较高的第二用户，采用的是信任的态度，在其需要第一用户为其提供预留线下资源的服务时，可以在不必支付保证金的情况下，即可享受相应的服务。这样，在用户未发生违约的情况下，就不会造成对用户资金的额外占用，并且，由于不必将第二用户的支付账户等信息提供给第一用户，因此，也保证了第二用户隐私信息的安全性。另外，由于不必执行第二用户预先支付保证金、第一用户再退还保证金等一系列的流程，因此，也大大节省了系统在网络、存储等方面的资源。对于第二用户而言，会感觉到自己在消费过程中被信任而获得尊重，因此，也可以提升第二用户的体验。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上对本申请所提供的订单信息处理以及订单类型转换处理方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (19)

  1. 一种订单信息处理方法，其特征在于，包括：
    服务器接收客户端针对指定第一用户的目标数据对象创建担保订单的请求；
    判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件；
    如果满足，则创建订单，并添加信用标识符，并将所述信用担保订单提供给所述第一用户数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。
  2. 根据权利要求1所述的方法，其特征在于，所述将所述信用担保订单提供给所述第一用户数据处理系统，包括：
    通过预先获知的所述第一用户数据处理系统的接口，将所述信用担保订单提供给所述第一用户数据处理系统。
  3. 根据权利要求1所述的方法，其特征在于，还包括：
    接收所述第一用户数据处理系统提供的所述订单的状态信息；
    如果所述订单状态为第二用户未按时履约，则从所述第二用户关联的支付账户划拨预置资源信息到所述第一用户的收款账户。
  4. 根据权利要求3所述的方法，其特征在于，所述预置资源信息由所述第一用户在发布所述目标数据对象时提供。
  5. 根据权利要求4所述的方法，其特征在于，所述判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件，包括：
    根据所述第二用户的信用信息，确定所述第二用户的授信额度；
    如果所述授信额度大于所述预置金额，则确定所述第二用户的信用信息满足所述预置的业务条件。
  6. 一种订单信息处理方法，其特征在于，包括：
    第一用户数据处理系统接收服务器提供的信用担保订单，所述信用担保订单通过以下方式生成：所述服务器在接收到客户端针对目标数据对象创建担保订单的请求时，判断所述客户端关联的第二用户的信用信息是否满足预置的业 务条件，如果满足，则创建订单，并添加信用标识符；
    如果第二用户未能按时履约，则向所述服务器提交订单状态信息，所述状态信息为第二用户未按时履约，以便服务器从所述第二用户关联的支付账户划拨预置金额到所述第一用户的收款账户。
  7. 一种订单类型转换处理方法，其特征在于，包括：
    服务器记录业务订单的相关信息，所述相关信息包括所述业务订单关联的第一用户以及第二用户信息，所述业务订单为非担保订单；
    接收将指定非担保订单转换为担保订单的请求；
    判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件；
    如果满足，则将所述指定非担保订单转换为信用担保订单，并将转换结果提供给第一用户数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。
  8. 根据权利要求7所述的方法，其特征在于，所述接收将指定非担保订单转换为担保订单的请求，包括：
    接收第一用户数据处理系统提交的将指定非担保订单转换为担保订单的请求；
    所述判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件之前，还包括：
    向所述指定非担保订单关联的第二用户客户端发送通知消息；
    在接收到第二用户客户端返回的确认转换的响应后，触发执行所述判断操作。
  9. 根据权利要求7所述的方法，其特征在于，所述接收将指定非担保订单转换为担保订单的请求，包括：
    接收第二用户客户端提交的将指定非担保订单转换为担保订单的请求。
  10. 根据权利要求7所述的方法，其特征在于，还包括：
    将订单转换结果提供给第二用户客户端。
  11. 根据权利要求7所述的方法，其特征在于，还包括：
    接收所述第一用户数据处理系统提供的订单状态信息；
    如果所述订单状态为第二用户未按时履约，则从所述第二用户关联的支付账户划拨预置资源信息到所述第一用户的收款账户。
  12. 一种订单类型转换处理方法，其特征在于，包括：
    第一用户数据处理系统向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；
    接收服务器返回的转换结果，以便按照信用担保的方式为所述第二用户提供线下资源预留服务。
  13. 根据权利要求12所述的方法，其特征在于，还包括：
    如果第二用户未能按时履约，则向所述服务器提交订单状态信息，所述状态信息为第二用户未按时履约，以便服务器从所述第二用户关联的支付账户划拨预置金额到所述第一用户的收款账户。
  14. 一种订单类型转换处理方法，其特征在于，包括：
    第二用户客户端向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；
    接收服务器返回的转换结果。
  15. 一种订单信息处理装置，其特征在于，应用于服务器，包括：
    请求接收单元，用于接收客户端针对指定第一用户的目标数据对象创建担保订单的请求；
    判断单元，用于判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件；
    订单创建单元，用于如果所述判断单元的判断结果为满足，则创建订单，并添加信用标识符，并将所述信用担保订单提供给所述第一用户数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。
  16. 一种订单信息处理装置，其特征在于，应用于第一用户数据处理系统，包括：
    订单接收单元，用于接收服务器提供的信用担保订单，所述信用担保订单通过以下方式生成：所述服务器在接收到客户端针对目标数据对象创建担保订单的请求时，判断所述客户端关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则创建订单，标记为并添加信用担保订单标识符；
    状态提交单元，用于如果第二用户未能按时履约，则向所述服务器提交订单状态信息，所述状态信息为第二用户未按时履约，以便服务器从所述第二用户关联的支付账户划拨预置金额到所述第一用户的收款账户。
  17. 一种订单类型转换处理装置，其特征在于，应用于服务器，包括：
    订单信息记录单元，用于记录业务订单的相关信息，所述相关信息包括所述业务订单关联的第一用户以及第二用户信息，所述业务订单为非担保订单；
    转换请求接收单元，用于接收将指定非担保订单转换为担保订单的请求；
    信用判断单元，用于判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件；
    转换单元，用于如果所述信用判断单元的判断结果为满足，则将所述指定非担保订单转换为信用担保订单，并将转换结果提供给第一用户的数据处理系统，以便所述第一用户按照信用担保的方式为所述第二用户提供线下资源预留服务。
  18. 一种订单类型转换处理装置，其特征在于，应用于第一用户数据处理系统，包括：
    第一转换请求提交单元，用于向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；
    第一转换结果接收单元，用于接收服务器返回的转换结果，以便按照信用担保的方式为所述第二用户提供线下资源预留服务。
  19. 一种订单类型转换处理装置，其特征在于，应用于第二用户客户端， 包括：
    第二转换请求提交单元，用于向服务器提交将指定非担保订单转换为担保订单的请求，以便所述服务器判断所述指定非担保订单关联的第二用户的信用信息是否满足预置的业务条件，如果满足，则将所述指定非担保订单转换为信用担保订单；
    第二转换结果接收单元，用于接收服务器返回的转换结果。
PCT/CN2017/089979 2016-07-06 2017-06-26 订单信息处理以及订单类型转换处理方法及装置 WO2018006717A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610529886.8 2016-07-06
CN201610529886.8A CN107590706A (zh) 2016-07-06 2016-07-06 订单信息处理以及订单类型转换处理方法及装置

Publications (1)

Publication Number Publication Date
WO2018006717A1 true WO2018006717A1 (zh) 2018-01-11

Family

ID=60921576

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/089979 WO2018006717A1 (zh) 2016-07-06 2017-06-26 订单信息处理以及订单类型转换处理方法及装置

Country Status (3)

Country Link
CN (1) CN107590706A (zh)
TW (1) TW201802741A (zh)
WO (1) WO2018006717A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111612577A (zh) * 2020-05-14 2020-09-01 北京字节跳动网络技术有限公司 一种订单处理方法、装置、电子设备及存储介质
CN112036593A (zh) * 2020-08-25 2020-12-04 中国大地财产保险股份有限公司上海分公司 用于保险增值服务的数据处理方法以及系统、服务器
US11410146B2 (en) 2018-03-30 2022-08-09 Beijing Sankuai Online Technology Co., Ltd Order processing

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110298678B (zh) * 2018-03-23 2023-12-05 阿里巴巴集团控股有限公司 用户权益信息处理方法、装置及系统
CN108564358B (zh) * 2018-04-13 2021-08-13 携程计算机技术（上海）有限公司 信用卡的担保支付方法及系统
CN110009358A (zh) * 2018-12-25 2019-07-12 阿里巴巴集团控股有限公司 资源调拨风险防控方法、装置及服务器
CN111861599A (zh) * 2019-04-24 2020-10-30 北京嘀嘀无限科技发展有限公司 一种资源处理方法及装置
CN110473053A (zh) * 2019-07-17 2019-11-19 阿里巴巴集团控股有限公司 基于担保的风险控制方法和装置
CN113505906B (zh) * 2021-07-01 2024-02-20 上海哔哩哔哩科技有限公司 对象预定方法及装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104537421A (zh) * 2014-12-17 2015-04-22 珠海高点科技有限公司 一种使用pos机进行酒店预订的方法及装置
WO2016100722A1 (en) * 2014-12-18 2016-06-23 Expedia, Inc. Automatic conversion of formatted travel information

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101419692A (zh) * 2007-10-25 2009-04-29 阿里巴巴集团控股有限公司 一种网络联保的处理方法和系统
CN102789596A (zh) * 2011-05-17 2012-11-21 徐建军 一种订餐处理流程
CN105701740A (zh) * 2016-03-25 2016-06-22 吴江 一种预定服务方法及其平台

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104537421A (zh) * 2014-12-17 2015-04-22 珠海高点科技有限公司 一种使用pos机进行酒店预订的方法及装置
WO2016100722A1 (en) * 2014-12-18 2016-06-23 Expedia, Inc. Automatic conversion of formatted travel information

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
LIU, JUAN ET AL.: "Launching of Ali Credit Living Hotel Management System", COMPUTER & NETWORK, vol. 42, no. 1, 9 May 2016 (2016-05-09), pages 45, ISSN: 1008-1739 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11410146B2 (en) 2018-03-30 2022-08-09 Beijing Sankuai Online Technology Co., Ltd Order processing
CN111612577A (zh) * 2020-05-14 2020-09-01 北京字节跳动网络技术有限公司 一种订单处理方法、装置、电子设备及存储介质
CN111612577B (zh) * 2020-05-14 2023-06-13 北京字节跳动网络技术有限公司 一种订单处理方法、装置、电子设备及存储介质
CN112036593A (zh) * 2020-08-25 2020-12-04 中国大地财产保险股份有限公司上海分公司 用于保险增值服务的数据处理方法以及系统、服务器

Also Published As

Publication number Publication date
TW201802741A (zh) 2018-01-16
CN107590706A (zh) 2018-01-16

Similar Documents

Publication Publication Date Title
WO2018006717A1 (zh) 订单信息处理以及订单类型转换处理方法及装置
TW201802758A (zh) 資料對象資訊處理方法、裝置及系統
JP7162587B2 (ja) 注文情報処理方法、装置およびシステム
TWI640937B (zh) Online payment method and equipment
KR100917036B1 (ko) 부동산 전자거래 시스템 및 그 시스템을 이용한 부동산전자거래 방법
TWI599969B (zh) Integrated payment services for cloud trading system
US20090182645A1 (en) Provisioning Web Services
RU2610414C2 (ru) Способ и система для распределения потока данных
RU2718175C1 (ru) Устройство и способ сетевой транзакции, основанные на управлении разделения привилегий
AU2017274264A1 (en) Method and system for efficient shared transaction processing
CN103942616A (zh) 基于移动互联网的车险测算报价服务系统
WO2022262527A1 (zh) 一种基于数字货币的支付方法、平台、终端及支付系统
JP4461220B2 (ja) 賃貸契約保険システム
TW201828210A (zh) 使用智能合約完成投保之系統及其方法
US20110125653A1 (en) System for managing online transactions involving voice talent
KR101676065B1 (ko) 부동산 거래정보에 관한 정보이용가치를 이용하는 부동산 중개 시스템 및 방법
TW201426615A (zh) 資產管理網路系統平台及方法
KR101598799B1 (ko) 결제 요청 분배 방법 및 시스템
CN108446901A (zh) 基于多人付费的咨询通讯系统和方法
JP5805920B2 (ja) 情報表示装置、およびこれを用いた情報表示システム
KR100950267B1 (ko) 부동산 중개 방법
WO2017012005A1 (zh) 资金管理服务器、跨行开电子凭证的数据处理方法及系统
CN110113419A (zh) 一种基于Android的CORS账号管理系统及其设计方法
US20230103796A1 (en) Event-based triggers of cryptocurrency transactions
WO2021096457A1 (en) A guaranteed vehicle sales system

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17823529

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17823529

Country of ref document: EP

Kind code of ref document: A1