WO2016177249A1 - 退款信息处理方法及装置 - Google Patents

退款信息处理方法及装置 Download PDF

Info

Publication number
WO2016177249A1
WO2016177249A1 PCT/CN2016/078604 CN2016078604W WO2016177249A1 WO 2016177249 A1 WO2016177249 A1 WO 2016177249A1 CN 2016078604 W CN2016078604 W CN 2016078604W WO 2016177249 A1 WO2016177249 A1 WO 2016177249A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
target
refund
preset
transaction order
Prior art date
Application number
PCT/CN2016/078604
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 WO2016177249A1 publication Critical patent/WO2016177249A1/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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Definitions

  • the present application relates to the field of information processing technologies, and in particular, to a refund information processing method and apparatus.
  • the normal normal process is: the buyer user purchases the goods he needs through the website of the trading platform or the application of the mobile terminal (App), generates a transaction order, and pays, and the order enters the “buyer has Payment status, at this time, the relevant funds will generally temporarily exist in the public account of the trading platform; after that, the seller user can deliver the goods in the payment status for a certain period of time, at this time, the order enters the "issued" The status of the goods, and can provide the buyer user with the option of “confirm receipt”. After the buyer receives the goods, the buyer can confirm with this option, and the trading platform will transfer the relevant funds from the public account to the seller user. The account, at this point, the transaction is over.
  • the trading platform also provides users with a corresponding "refund" process. Under normal circumstances, as long as a transaction is officially closed, the buyer user can apply for a refund.
  • the application provides a method and a device for processing refund information, which can make the refund process more convenient and efficient.
  • a method for processing refund information including:
  • the key information to be verified is extracted from the event
  • a refund information processing device comprising:
  • a monitoring unit for monitoring the status of at least one transaction order
  • a key information extracting unit configured to extract key information to be verified from the event when a quick refund request event for the target transaction order is monitored
  • a judging unit configured to determine whether the key information meets a preset verification rule, and if yes, determine a refund amount associated with the target transaction order, and invoke a preset consent refund interface, so as to corresponding amount Return to the appropriate payment account.
  • the present application discloses the following technical effects:
  • the user can provide a fast refund channel. After the key information is verified, the first user can be automatically invoked to agree to the refund interface, and the corresponding amount is refunded to the corresponding amount.
  • the payment account therefore, makes the refund process more convenient and efficient, and saves network resources and improves the user experience.
  • FIG. 2 is a flowchart of a second method embodiment provided by an embodiment of the present application.
  • FIG. 3 is a flowchart of a third method embodiment provided by an embodiment of the present application.
  • FIG. 4 is a flowchart of a fourth method embodiment provided by an embodiment of the present application.
  • FIG. 5 is a schematic diagram of an apparatus provided by an embodiment of the present application.
  • the second user in order to quickly respond to the refund request of the buyer user (that is, the consumer user of the business object in the system, or the second user), the second user may be provided with a quick refund.
  • a quick refund for example, you can provide the corresponding button on the order management page, etc.
  • the buttons for the regular refund process can also exist at the same time, the user can choose according to the actual situation).
  • the system can automatically invoke the consent refund interface.
  • an embodiment of the present application provides a method for processing refund information, which may include the following steps:
  • S101 monitor status of at least one transaction order
  • a transaction order can be generated, and the step is to monitor the status of the transaction order already generated in the system.
  • the system may provide corresponding operation options for the corresponding first user or the second user in the corresponding page, for example, after the order is generated, the second user may be provided with a payment. "Option, the second user can enter the corresponding payment page by operating the option; after the second user payment is completed, the first user can be provided with a "shipping" option, and the first user can pass the option after completing the delivery. To change the order to the "shipped" status, and so on.
  • the second user may be provided with a "Request for Refund” option as soon as the second user completes the payment.
  • the second user may send a corresponding request to the first user, and provide the first user with an operation option for agreeing or rejecting the refund.
  • the first user operates the corresponding "consent to refund” option.
  • the server can call the relevant consent refund interface to complete the refund process.
  • the second user in addition to providing the second user with the above-mentioned "request for refund” option, the second user may also be provided with a "quick refund” option, and if the second user needs to complete the refund quickly, Operate on this option.
  • This step S101 is to monitor the operation of the "quick refund” option by the second user.
  • the quick refund process of the embodiment of the present application is entered.
  • the first user does not need to perform the refund operation, and the system automatically assists the Two users complete the refund.
  • the key information in the event can be judged to determine whether it meets the preset fast.
  • the refund rule will automatically complete the quick refund only if it meets the fast refund rule, otherwise the refund process can still be performed according to the traditional process.
  • the so-called key information extracted from the event refers to the information that needs to be verified, and the key information is verified to determine whether the condition of the quick refund is satisfied.
  • which key information needs to be extracted may be determined according to the information category that needs to be verified in the verification condition. For example, in the verification condition, the time between the order status and the time between payment and application for a quick refund is required. Verification, at this point, you can extract the status of the current target trading order (including the buyer has paid, shipped, etc.), the first time point for the second user to pay for the current target trading order, and received The second time point of the current fast payment request, so that the length of time from the first time point to the second time point can be calculated.
  • the second user identification information may be extracted from the current event, so as to query the relevant database for the integrity level of the second user. and many more.
  • S103 Determine whether the key information meets a preset verification rule, and if yes, determine a refund amount associated with the target transaction order, and invoke a preset consent refund interface to refund the corresponding amount to the corresponding amount. Payment account.
  • the key information After extracting the key information, it can be judged whether the key information meets the preset verification rules. If it is, you can determine the refund amount associated with the target transaction order and call the preset consent refund interface to return the corresponding amount to the corresponding payment account.
  • the first user manually triggers the call to the interface, and in the embodiment of the present application, The automatic triggering of the system replaces the manual triggering of the first user, and the called object can be the same as the conventional method.
  • key information there are many ways to verify key information. For example, when it is determined that the current transaction order is in an unshipped state, it is determined whether the length of time from the first time point to the second time point is greater than the length of the delivery contract time, or the second user's integrity level information may also be determined. Whether the preset conditions are met, and so on.
  • a variety of key information can be verified, and only after each key information meets the preset conditions, the subsequent quick refund process can be performed. For example, first check from the perspective of the length of time, then check from the perspective of the integrity level of the second user, and so on.
  • the reason for checking from the length of time is because:
  • the second user may have looked at other similar products, or may have found quality problems after receiving the goods, etc. Wait.
  • the second user pays the first user does not ship for a long time, and the second user does not want to wait any longer, so that a refund is required.
  • traditional The refund method is more reasonable, that is, the second user first negotiates with the first user, and the first user agrees and then refunds.
  • the refund application caused by the case that the first user has not been shipped for a long time may allow a refund by means of a quick refund.
  • how to determine whether the first user has not been shipped for a long time is a problem that needs to be solved.
  • the concept of “consignment contract time” is proposed.
  • the time may be determined by the system by default, for example, may be 72 hours, and the like.
  • some first users want to provide a better service for the second user they can also set their own delivery contract time, such as promise to ship within 24 hours, and so on.
  • the key information to be verified is specifically extracted, the current state of the target transaction order can be extracted, and the first time point for payment of the target transaction order and the second time point when the refund request is received are determined; In this way, the order status and time length information can be verified when the verification is performed.
  • the refund information processing method in the embodiment of the present application may include the following steps:
  • S201 monitoring the status of at least one transaction order
  • S202 When monitoring a quick refund request event for a target transaction order, extracting key information to be verified from the event; the key information includes: a current status of the target transaction order, and the target transaction The first point in time for the payment of the order and the second point in time when the refund request is received;
  • step S203 determining whether the target transaction order is in an undelivered state; if yes, proceeding to step S204, otherwise prompting the second user to process according to the traditional refund process;
  • step S204 determining whether the length of time from the first time point to the second time point is greater than the length of the delivery contract; if yes, determining that the time information meets the verification rule, proceeding to step S205, otherwise prompting the first
  • the target first user identification information may be first extracted from the target transaction order, and then the length of the delivery contract set by the target first user is determined according to the target first user identification information. If the target first user does not set the delivery contract time, the default time length of the system is determined as the length of the delivery contract.
  • S205 Determine a refund amount associated with the target transaction order, and call a preset consent refund interface to return the corresponding amount to the corresponding payment account.
  • the subject of the refund information processing in the embodiment of the present application is a transaction platform server, it is a third-party system relative to the first user and the second user, and the first user generally has other The logistics service provider cooperates to complete the process of goods delivery and distribution. Therefore, the trading platform server generally cannot directly know the goods in the logistics state, but the first user or the related logistics service provider, after delivery. By manually modifying the status of the corresponding transaction order, the system can know whether the first user has shipped according to the status information. Therefore, in the above judgment process, there may be a situation in which the system determines that the target transaction order is in the unshipped state, and the time for requesting the refund is indeed beyond the delivery contract time, so The refund is processed directly for the second user.
  • the first user may have shipped the relevant goods, but the status of the trading order has not been updated in the system in time. Such a situation may cause economic losses to the first user.
  • the first user may be provided with a complaint channel, so that the first user can avoid the loss through the appeal, and if the appeal is successful, the relevant Payment can be made by the system.
  • the specific implementation of the specific appeal process is not related to the technical solution of the embodiment of the present application.
  • the above verification method verifies the order status and the time of payment from the payment.
  • the integrity level of the second user can also be verified. This is because there may be some second users with lower level of integrity in the system.
  • the quick refund channel in the embodiment of the present application may be used to achieve other purposes, which may damage the order of the system and affect the order.
  • the credit level of the user can also be verified, and if the second user with a low credit level is satisfied, even if the foregoing rules are met in the refund time, the fast refund service is refused.
  • the quick refund channel provided by the embodiment of the present application may be specifically provided for a second user with a relatively high level of integrity, such a second user belongs to a high-quality user in the system, and the system has a high degree of trust, and Willing to bear the corresponding risks. This will help maintain the order of the system. In addition, it can also encourage the second user to improve their level of integrity and obtain the corresponding high-end services.
  • the credit level may still be high or low.
  • different credit lines may be set in advance for different credit levels. In this way, when performing the quick refund verification, it is also possible to determine whether the amount of the refund is greater than the credit amount corresponding to the current second user's credit level, and only to make a quick refund for the result if the result is affirmative. . In this way, the risk of the system can be further reduced.
  • the key information extracted from the event may further include the target second user identifier in the transaction, so that, in particular, when determining whether the key information meets the preset verification rule, Extracting the integrity level information of the target second user from the preset database, and determining whether the integrity level information satisfies the preset condition.
  • the method may further include:
  • step S207 determining whether the integrity level is higher than a preset threshold, and if so, proceeding to step S208;
  • S208 Determine, according to a correspondence between the preset credit level and the credit line, a target credit line corresponding to the integrity level information of the target second user;
  • step S209 Determine whether the refund amount in the target transaction order is less than the target credit limit, and if yes, determine whether the integrity level information satisfies the preset condition, and proceed to step S205.
  • steps S201, S203, S204, and S205 in FIG. 3 are both in FIG. The corresponding steps are the same and will not be described here.
  • System risk can be reduced by the above verification of the second user integrity level.
  • the following steps may also be included:
  • S210 Extract, from the transaction order, a target first user and a target second user identifier in the transaction;
  • Step S211 Determine whether the number of times the second user initiates the quick refund request for the transaction order with the target first user is less than a preset threshold during the most recent preset time period, and if yes, enter Step S205.
  • steps S201 to S209 in FIG. 3 are the same as the corresponding steps in FIG. 3, and details are not described herein again.
  • the user can provide a fast refund channel. After the key information is verified and passed, the first user is not required to operate, and the consent refund interface is automatically invoked, and the corresponding amount is Returning to the appropriate payment account, making the refund process easier and more efficient.
  • the embodiment of the present application further provides a refund information processing device.
  • the device may specifically include:
  • the monitoring unit 501 is configured to monitor a status of the at least one transaction order
  • the key information extracting unit 502 is configured to extract key information to be verified from the event when the quick refund request event for the target transaction order is monitored;
  • the determining unit 503 is configured to determine whether the key information meets a preset verification rule, and if yes, determine a refund amount associated with the target transaction order, and invoke a preset consent refund interface, so as to The amount is refunded to the corresponding payment account.
  • the key information to be verified extracted from the event includes: a current status of the target transaction order, a first time point for payment of the target transaction order, and a second time for receiving a refund request Time point
  • the determining unit 503 may specifically include:
  • a first determining subunit configured to determine whether the target transaction order is in an unshipped state
  • a second determining subunit configured to determine, if the determination result of the first determining subunit is YES, whether the length of time from the first time point to the second time point is greater than a length of the delivery contract
  • a first determining subunit configured to determine that the time information meets the verification rule if the determination result of the second determining subunit is YES.
  • the length of the delivery contract is preset for the first user in the transaction, and the first user is the user of the business object; the device further includes:
  • a user identification information extracting unit configured to extract target first user identification information from the target transaction order
  • the first time length information determining unit is configured to determine, according to the target first user identification information, a length of the delivery contract set by the target first user.
  • the device may further include:
  • the second time length information determining unit is configured to determine a default time length of the system as the length of the delivery contract time if the target first user does not set the delivery contract time.
  • the key information to be verified extracted from the event may further include: a target second user identifier in the transaction, where the second user is a consumer user of the business object;
  • the determining unit 503 may further include:
  • a credit level information extraction subunit configured to extract the integrity level information of the target second user from a preset database
  • the third determining subunit is configured to determine whether the integrity level information satisfies a preset condition.
  • the third determining subunit is specifically configured to:
  • the target is determined according to the correspondence between the preset credit level and the credit line.
  • the target credit line corresponding to the credit level information of the second user;
  • the device may further comprise:
  • a user information extracting unit configured to extract, from the transaction order, a target first user and a target second user identifier in the transaction before calling the preset consent refund interface
  • a refund number determining unit configured to determine a number of times the second user initiates the quick refund request for the transaction order with the target first user within a most recent preset time period
  • a triggering unit configured to trigger, when the number of times is less than a preset threshold, to perform the step of invoking the preset agreed consent refund interface.
  • the user can provide a fast refund channel. After the key information is verified, the first user can be automatically invoked to agree to the refund interface, and the corresponding amount is refunded to the user.
  • the corresponding payment account therefore, makes the refund process more convenient and efficient.
  • 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.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

退款信息处理方法及装置，其中，所述方法包括：对至少一个交易订单的状态进行监控（S101）；当监控到针对目标交易订单的快速退款请求事件时，从所述事件中提取待校验的关键信息（S102）；判断所述关键信息是否符合预置的校验规则，如果是，则确定所述目标交易订单关联的退款金额，并调用预置的同意退款接口（S103），以便将相应的金额退还到相应的付款账户。通过本方法和装置，可以使得退款流程更加便捷高效，并节约网络资源，提高用户体验。

Description

退款信息处理方法及装置 技术领域
本申请涉及信息处理技术领域，特别是涉及退款信息处理方法及装置。
背景技术
随着电子商务交易平台的不断完善，以及传统通信、移动通信等技术的快速发展，越来越多的人们通过网上购物的方式来获取自己所需的商品，商品的种类可以涉及到人们日常生活的方方面面。
在电子商务交易的过程中，一般正常的流程是：买家用户通过交易平台的网站或者移动端的应用(App)选购自己所需的商品，生成交易订单，并付款，订单进入“买家已付款”状态，此时，相关的款项一般会暂时存在交易平台的公共账户中；之后，卖家用户可以在一定时间内，针对处于已付款状态的订单进行发货，此时，订单进入“已发货”状态，并且可以为买家用户提供“确认收货”的选项，待买家用户收到货品后，可以通过该选项进行确认，交易平台再将相关的款项，从公共账户转入卖家用户的账户，至此，交易结束。
在实际应用中，可能存在以下情况：买家用户已经生成交易订单并且付款成功，但是出于种种原因，可能又不想购买该商品了。此时，交易平台也为用户提供了相应的“退款”流程，一般情况下，只要在一次交易正式结束之前，买家用户都是可以申请退款的。
但在现有技术中，在买家申请退款时，一般需要先与卖家用户进行协商，在卖家用户同意，并在交易平台中执行了相关的操作之后，例如通过电话或即时通讯等工具进行沟通，才能将相关的款项返回给买家用户，速度往往会比较慢，效率很低，并且占用网络资源。
发明内容
本申请提供了退款信息处理方法及装置，可以使得退款流程更加便捷高效。
本申请提供了如下方案：
一种退款信息处理方法，包括：
对至少一个交易订单的状态进行监控；
当监控到针对目标交易订单的快速退款请求事件时，从所述事件中提取待校验的关键信息；
判断所述关键信息是否符合预置的校验规则，如果是，则确定所述目标交易订单关联的退款金额，并调用预置的同意退款接口，以便将相应的金额退还到相应的付款账户。
一种退款信息处理装置，包括：
监控单元，用于至少一个交易订单的状态进行监控；
关键信息提取单元，用于当监控到针对目标交易订单的快速退款请求事件时，从所述事件中提取待校验的关键信息；
判断单元，用于判断所述关键信息是否符合预置的校验规则，如果是，则确定所述目标交易订单关联的退款金额，并调用预置的同意退款接口，以便将相应的金额退还到相应的付款账户。
根据本申请提供的具体实施例，本申请公开了以下技术效果：
通过本申请实施例，可以为用户提供快速退款的通道，在对关键信息进行校验通过后，不需要第一用户进行操作，即可自动调用同意退款接口，将相应的金额退还到相应的付款账户，因此，使得退款流程更加便捷高效，并节约网络资源，提高用户体验。
当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施 例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的第一方法实施例的流程图；
图2是本申请实施例提供的第二方法实施例的流程图；
图3是本申请实施例提供的第三方法实施例的流程图；
图4是本申请实施例提供的第四方法实施例的流程图；
图5是本申请实施例提供的装置的示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。
在本申请实施例中，为了能够快速的响应买家用户(也即系统中业务对象的消费方用户，或称第二用户)的退款请求，可以为第二用户提供一种快速退款的通道(例如，可以在订单管理页面等处，提供相应的按钮，当然，用于进行常规退款流程的按钮也可以同时存在，用户可以根据实际的情况进行选择)。这样，当检测到用户的快速退款请求事件发生时，可以对事件中的一些关键信息进行检验，判断其是否满足快速退款的条件，如果满足，则可以由系统自动调用同意退款接口，快速为第二用户进行退款操作，这样，第二用户不需要与第一用户进行协商，也不需要等待第一用户进行操作，就可以快速收到相应的款项，使得第二用户获得更便捷的服务。下面对具体的实现方式进行详细介绍。
参见图1，本申请实施例提供了一种退款信息处理方法，该方法可以包括以下步骤：
S101：对至少一个交易订单的状态进行监控；
其中，在第二用户选购了某业务对象之后，即可生成交易订单，该步骤就是对系统中已经生成的交易订单的状态进行监控。具体实现时，在交易订单的各个阶段，系统都可以在相应的页面中为相应的第一用户或者第二用户提供相应的操作选项，例如，在订单生成后，可以为第二用户提供“付款”选项，第二用户可以通过操作该选项进入相应的付款页面；在第二用户付款完成之后，可以为第一用户提供“发货”选项，第一用户在完成发货之后，可以通过该选项来将订单修改为“已发货”状态，等等。另外，只要在第二用户完成付款后，就可以为第二用户提供“申请退款”选项。在现有技术中，第二用户在选择该选项之后，可以将相应的请求发送给第一用户，并为第一用户提供用于同意或者拒绝退款的操作选项，如果同意退款，则需要由第一用户对相应的“同意退款”选项进行操作，此时，服务器在收到该指令之后，就可以调用相关的同意退款接口，完成退款流程。
而在本申请实施例中，除了为第二用户提供上述“申请退款”的选项，还可以为第二用户提供“快速退款”的选项，如果第二用户需要快速完成退款，则可以对该选项进行操作。该步骤S101就是要对第二用户针对这种“快速退款”选项的操作情况进行监控。
S102：当监控到针对目标交易订单的快速退款请求事件时，从所述事件中提取待校验的关键信息；
如果某第二用户针对其交易订单选择了“快速退款”选项，则进入本申请实施例的快速退款流程，在该流程中，不需要由第一用户进行退款操作，系统自动帮助第二用户完成退款。但是，为了避免第二用户滥用该功能，也降低第一用户受到损失的可能性，在自动退款前，还可以对该事件中的各项关键信息进行判断，确定其是否符合预置的快速退款规则，只有符合快速退款规则的情况下，才自动完成快速退款，否则可以仍然按照传统的流程进行退款操作。
其中，所谓的从事件中提取的关键信息，是指需要校验的信息，通过对这些关键信息进行校验，来判断是否满足快速退款的条件。具体的，需要提取哪些关键信息，可以是根据校验条件中需要校验的信息类别来确定的。例如，在校验条件中，需要对订单状态以及从付款到申请快速退款之间的时间长度进行 校验，则此时，就可以提取出当前目标交易订单的状态(包括买家已付款、已发货等等)、第二用户为当前目标交易订单进行付款的第一时间点，以及接收到当前快速付款请求的第二时间点，这样就可以计算出从第一时间点到第二时间点之间的时间长度。或者，假设在校验条件中需要对第二用户的诚信等级进行校验，则可以从当前的事件中提取出第二用户标识信息，以便到相关的数据库中查询该第二用户的诚信等级，等等。
S103：判断所述关键信息是否符合预置的校验规则，如果是，则确定所述目标交易订单关联的退款金额，并调用预置的同意退款接口，以便将相应的金额退还到相应的付款账户。
在提取出关键信息之后，就可以判断这些关键信息是否符合预置的校验规则。如果符合，就可以确定出目标交易订单关联的退款金额，并调用预置的同意退款接口，以便将相应的金额退还到相应的付款账户。其中，关于同意退款接口，在传统的方式下，是在第一用户执行了相关的同意退款操作之后，由第一用户手动触发对该接口的调用，而在本申请实施例中，可以由系统的自动触发代替第一用户的手动触发，调用的对象与传统方法可以是相同的。
其中，在对关键信息进行校验时，可以有多种方式。例如，在判断出当前交易订单处于未发货的状态时，判断从第一时间点到第二时间点的时间长度是否大于发货合约时间长度，或者，还可以判断第二用户的诚信等级信息是否满足预置条件，等等。另外，在实际应用中，还可以对多种关键信息都进行校验，只有每项关键信息均符合预置条件时，才可以进行后续的快速退款流程。例如，首先从时间长度角度进行校验，之后再从第二用户的诚信等级角度进行校验，等等。
其中，之所以从时间长度角度进行校验，是因为：
在实际应用中，造成第二用户退款的原因一般有多种，例如，可能是第二用户又看中了其他的类似产品，或者，还可能是在收到货品之后发现有质量问题，等等。另外，还有一种原因是：第二用户在付款之后，第一用户长时间未发货，第二用户不想再等待，以至于需要进行退款。针对前几种情况，传统的 退款方式是更合理的，也就是说，先由第二用户与第一用户进行协商，并且由第一用户同意后再进行退款。而针对最后一种情况，基本上是由第一用户单方面的原因导致的，因此，可以使用本申请实施例中的快速退款方式，这也可以看作是一种系统强制性的退款，也是对于第一用户不守信行为的一种惩罚。
基于以上所述，在本申请实施例中，针对第一用户长时间未发货的情况导致的退款申请，可以允许使用快速退款的方式进行退款。其中，具体实现时，在收到一个第二用户的快速退款申请后，如何判断是否由于第一用户长时间未发货导致的，是需要解决的问题。
为此，在本申请实施例中，提出了“发货合约时间”的概念，一般情况下，该时间可以是由系统默认确定的，例如可以是72小时，等等。或者，如果有些第一用户想要为第二用户提供更为优质的服务，可以另外自行设定发货合约时间，例如承诺在24小时之内进行发货，等等。
这样，在具体提取待校验的关键信息时，就可以提取出目标交易订单的当前状态，并确定出为目标交易订单付款的第一时间点，以及接收到退款请求的第二时间点；这样，具体在进行校验时，就可以对订单状态以及时间长度信息进行校验。
参见图2，在这种方式下，本申请实施例的退款信息处理方法可以包括以下步骤：
S201：对至少一个交易订单的状态进行监控；
S202：当监控到针对目标交易订单的快速退款请求事件时，从所述事件中提取待校验的关键信息；所述关键信息包括：所述目标交易订单的当前状态，为所述目标交易订单付款的第一时间点，以及接收到退款请求的第二时间点；
S203：判断目标交易订单是否处于未发货状态；如果是，则进入步骤S204，否则提示第二用户按照传统的退款流程进行处理；
S204：判断从第一时间点到第二时间点的时间长度是否大于发货合约时间长度；如果是，则确定时间信息符合校验规则，进入步骤S205，否则提示第 二用户按照传统的退款流程进行处理；
其中，如果第一用户设定了自己的发货合约时间，则会在服务器中保存相关的信息，并且可以优先使用第一用户设定的发货合约时间进行判断。此时，还可以首先从目标交易订单中提取目标第一用户标识信息，然后根据目标第一用户标识信息，确定该目标第一用户设定的发货合约时间长度。如果目标第一用户未设定发货合约时间，则将系统默认的时间长度确定为所述发货合约时间长度。
S205：确定所述目标交易订单关联的退款金额，并调用预置的同意退款接口，以便将相应的金额退还到相应的付款账户。
当然，由于本申请实施例中进行退款信息处理的主体是交易平台服务器，相对于第一用户以及第二用户而言，都是一种第三方的系统，而第一用户一般又会与其他的物流服务提供方合作，完成货品的发货以及配送等流程，因此，交易平台服务器一般无法直接获知货品在物流状态，而是要由第一用户或者相关的物流服务提供方，在发货后手动修改对应交易订单的状态，系统才能够根据这种状态信息，知晓第一用户是否已经发货。因此，在上述判断的过程中，有可能出现的一种情况是：系统判断出目标交易订单处于未发货状态，并且申请退款的时间距离付款的时间确实已经超出了发货合约时间，于是就直接为第二用户进行了退款处理。但是实际上第一用户可能已经针对相关的货品发货了，只是尚未及时在系统中更新交易订单的状态。这样情况可能会给第一用户造成经济损失，针对这种情况，在实际应用中，可以为第一用户提供申诉途径，使得第一用户能够通过申诉来避免自己受到损失，如果申诉成功，相关的款项可以由系统承担。关于具体申诉过程的具体实现，由于与本申请实施例的技术方案无关，因此，不再详述。
上述校验方式，对订单状态以及距离付款的时间进行了校验，除此之外，在实际应用中，还可以对第二用户的诚信等级进行校验。这是因为：系统中可能存在一些诚信等级比较低第二用户，对于这种第二用户而言，可能会利用本申请实施例中的快速退款通道达到其他目的，破坏系统的秩序，影响到正常用户对系统的使用。例如，如前文所述，在实现快速退款的过程中，实际上系统 是承担了一些风险的，比如前述第一用户已经发货，但只是未更新交易订单状态的情况下，系统需要对第一用户进行赔付。部分第二用户可能会将其看作是系统的漏洞，恶意使用该功能，从而达到既收到了退款，又收到了货品的目的。
为此，在本申请实施例中，还可以对用户的诚信等级进行校验，如果诚信等级很低的第二用户，即使在退款时间上满足前述规则，也拒绝为其提供快速退款服务。换言之，本申请实施例提供的快速退款通道可以是专门为诚信等级比较高的第二用户提供的，这样的第二用户属于系统中的优质用户，系统对其有较高的信任度，也愿意承担相应的风险。这样有利于维护系统的秩序，另外，也可以激励第二用户提高自己的诚信等级，以获得相应的高端服务。
另外，对于诚信等级满足条件的不同的第二用户而言，其诚信等级可能仍然有高低之分，为此，在具体实现时，还可以预先为各种不同的诚信等级设定不同的授信额度，这样，在进行执行快速退款校验时，还可以判断需要退款的金额是否大于当前第二用户诚信等级对应的授信额度，只有在结果为肯定的状态下，才为其进行快速退款。这样，可以进一步降低系统的风险。
也就是说，在前述步骤S202中，从事件中提取的关键信息还可以包括交易中的目标第二用户标识，这样，具体在判断所述关键信息是否符合预置的校验规则时，还可以从预置的数据库中提取目标第二用户的诚信等级信息，判断该诚信等级信息是否满足预置条件。例如，参见图3，在步骤S205之前，还可以包括：
S206：从预置的数据库中提取目标第二用户的诚信等级信息；
S207：判断所述诚信等级是否高于预置的阈值，如果是，进入步骤S208；
S208：根据预置的诚信等级与授信额度之间的对应关系，确定所述目标第二用户的诚信等级信息对应的目标授信额度；
S209：判断所述目标交易订单中的退款金额是否小于所述目标授信额度，如果是，则确定所述诚信等级信息是否满足预置条件，进入步骤S205。
需要说明的是，图3中的步骤S201、S203、S204以及S205均与图2中 对应的步骤相同，这里不再赘述。
通过上述关于第二用户诚信等级的校验，可以降低系统风险。而在具体实现时，为了进一步降低系统风险，还可以对同一第二用户在最近一段时间内请求进行快速退款的次数进行限制，避免同一第二用户在短时间内频繁地进行快速退款。具体的，参见图4，在步骤S205之前，还可以包括以下步骤：
S210：从所述交易订单中提取交易中的目标第一用户以及目标第二用户标识；
S211：判断在最近预置时间段内，所述第二用户针对所述与所述目标第一用户的交易订单发起所述快速退款请求的次数是否小于预置的阈值，如果是，则进入步骤S205。
需要说明的是，图3中的步骤S201至S209均与图3中对应的步骤相同，这里不再赘述。
总之，在本申请实施例中，可以为用户提供快速退款的通道，在对关键信息进行校验通过后，不需要第一用户进行操作，即可自动调用同意退款接口，将相应的金额退还到相应的付款账户，因此，使得退款流程更加便捷高效。
与本申请实施例提供的退款信息处理方法相对应，本申请实施例还提供了一种退款信息处理装置，参见图5，该装置具体可以包括：
监控单元501，用于对至少一个交易订单的状态进行监控；
关键信息提取单元502，用于当监控到针对目标交易订单的快速退款请求事件时，从所述事件中提取待校验的关键信息；
判断单元503，用于判断所述关键信息是否符合预置的校验规则，如果是，则确定所述目标交易订单关联的退款金额，并调用预置的同意退款接口，以便将相应的金额退还到相应的付款账户。
其中，所述从所述事件中提取的待校验的关键信息包括：所述目标交易订单的当前状态，为所述目标交易订单付款的第一时间点，以及接收到退款请求的第二时间点；
所述判断单元503具体可以包括：
第一判断子单元，用于判断所述目标交易订单是否处于未发货状态；
第二判断子单元，用于如果所述第一判断子单元的判断结果为是，则判断从第一时间点到第二时间点的时间长度是否大于发货合约时间长度；
第一确定子单元，用于如果所述第二判断子单元的判断结果为是，则确定时间信息符合校验规则。
其中，所述发货合约时间长度为交易中的第一用户预先设定，所述第一用户为业务对象所有方用户；所述装置还包括：
用户标识信息提取单元，用于从所述目标交易订单中提取目标第一用户标识信息；
第一时间长度信息确定单元，用于根据所述目标第一用户标识信息，确定该目标第一用户设定的发货合约时间长度。
或者，所述装置还可以包括：
第二时间长度信息确定单元，用于如果所述目标第一用户未设定发货合约时间，则将系统默认的时间长度确定为所述发货合约时间长度。
另外，所述从所述事件中提取的待校验的关键信息还可以包括：交易中的目标第二用户标识，所述第二用户为业务对象的消费方用户；
所述判断单元503还可以包括：
诚信等级信息提取子单元，用于从预置的数据库中提取所述目标第二用户的诚信等级信息；
第三判断子单元，用于判断所述诚信等级信息是否满足预置条件。
其中，所述第三判断子单元具体用于：
判断所述诚信等级是否高于预置的阈值；
如果是，则根据预置的诚信等级与授信额度之间的对应关系，确定所述目 标第二用户的诚信等级信息对应的目标授信额度；
判断所述目标交易订单中的退款金额是否小于所述目标授信额度；
如果是，则确定所述诚信等级信息是否满足预置条件。
此外，该装置还可以包括：
用户信息提取单元，用于在所述调用预置的同意退款接口之前，从所述交易订单中提取交易中的目标第一用户以及目标第二用户标识；
退款次数判断单元，用于判断在最近预置时间段内，所述第二用户针对所述与所述目标第一用户的交易订单发起所述快速退款请求的次数；
触发单元，用于如果所述次数小于预置的阈值，则触发执行所述调用预置的同意退款接口的步骤。
在本申请实施例中，可以为用户提供快速退款的通道，在对关键信息进行校验通过后，不需要第一用户进行操作，即可自动调用同意退款接口，将相应的金额退还到相应的付款账户，因此，使得退款流程更加便捷高效。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需 要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上对本申请所提供的退款信息处理方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (14)

  1. 一种退款信息处理方法，其特征在于，包括：
    对至少一个交易订单的状态进行监控；
    当监控到针对目标交易订单的快速退款请求事件时，从所述事件中提取待校验的关键信息；
    判断所述关键信息是否符合预置的校验规则，如果是，则确定所述目标交易订单关联的退款金额，并调用预置的同意退款接口，以便将相应的金额退还到相应的付款账户。
  2. 根据权利要求1所述的方法，其特征在于，所述从所述事件中提取的待校验的关键信息包括：所述目标交易订单的当前状态，为所述目标交易订单付款的第一时间点，以及接收到退款请求的第二时间点；
    所述判断所述关键信息是否符合预置的校验规则，包括：
    判断所述目标交易订单是否处于未发货状态；
    如果是，则判断从第一时间点到第二时间点的时间长度是否大于发货合约时间长度；
    如果是，则确定时间信息符合校验规则。
  3. 根据权利要求2所述的方法，其特征在于，所述发货合约时间长度为交易中的第一用户预先设定，所述第一用户为业务对象所有方用户；所述方法还包括：
    从所述目标交易订单中提取目标第一用户标识信息；
    根据所述目标第一用户标识信息，确定该目标第一用户设定的发货合约时间长度。
  4. 根据权利要求3所述的方法，其特征在于，还包括：
    如果所述目标第一用户未设定发货合约时间，则将系统默认的时间长度确定为所述发货合约时间长度。
  5. 根据权利要求2所述的方法，其特征在于，所述从所述事件中提取的待校验的关键信息还包括：交易中的目标第二用户标识，所述第二用户为业务对象的消费方用户；
    所述判断所述关键信息是否符合预置的校验规则，还包括：
    从预置的数据库中提取所述目标第二用户的诚信等级信息；
    判断所述诚信等级信息是否满足预置条件。
  6. 根据权利要求5所述的方法，其特征在于，所述判断所述诚信等级信息是否满足预置条件，包括：
    判断所述诚信等级是否高于预置的阈值；
    如果是，则根据预置的诚信等级与授信额度之间的对应关系，确定所述目标第二用户的诚信等级信息对应的目标授信额度；
    判断所述目标交易订单中的退款金额是否小于所述目标授信额度；
    如果是，则确定所述诚信等级信息是否满足预置条件。
  7. 根据权利要求2或5所述的方法，其特征在于，在所述调用预置的同意退款接口之前，还包括：
    从所述交易订单中提取交易中的目标第一用户以及目标第二用户标识；
    判断在最近预置时间段内，所述第二用户针对所述与所述目标第一用户的交易订单发起所述快速退款请求的次数；
    如果所述次数小于预置的阈值，则触发执行所述调用预置的同意退款接口的步骤。
  8. 一种退款信息处理装置，其特征在于，包括：
    监控单元，用于至少一个交易订单的状态进行监控；
    关键信息提取单元，用于当监控到针对目标交易订单的快速退款请求事件时，从所述事件中提取待校验的关键信息；
    判断单元，用于判断所述关键信息是否符合预置的校验规则，如果是，则确定所述目标交易订单关联的退款金额，并调用预置的同意退款接口，以便将相应的金额退还到相应的付款账户。
  9. 根据权利要求8所述的装置，其特征在于，所述从所述事件中提取的待校验的关键信息包括：所述目标交易订单的当前状态，为所述目标交易订单付款的第一时间点，以及接收到退款请求的第二时间点；
    所述判断单元，包括：
    第一判断子单元，用于判断所述目标交易订单是否处于未发货状态；
    第二判断子单元，用于如果所述第一判断子单元的判断结果为是，则判断从第一时间点到第二时间点的时间长度是否大于发货合约时间长度；
    第一确定子单元，用于如果所述第二判断子单元的判断结果为是，则确定时间信息符合校验规则。
  10. 根据权利要求9所述的装置，其特征在于，所述发货合约时间长度为交易中的第一用户预先设定，所述第一用户为业务对象所有方用户；所述装置还包括：
    用户标识信息提取单元，用于从所述目标交易订单中提取目标第一用户标识信息；
    第一时间长度信息确定单元，用于根据所述目标第一用户标识信息，确定该目标第一用户设定的发货合约时间长度。
  11. 根据权利要求10所述的装置，其特征在于，还包括：
    第二时间长度信息确定单元，用于如果所述目标第一用户未设定发货合约时间，则将系统默认的时间长度确定为所述发货合约时间长度。
  12. 根据权利要求9所述的装置，其特征在于，所述从所述事件中提取的待校验的关键信息还包括：交易中的目标第二用户标识，所述第二用户为业务对象的消费方用户；
    所述判断单元还包括：
    诚信等级信息提取子单元，用于从预置的数据库中提取所述目标第二用户的诚信等级信息；
    第三判断子单元，用于判断所述诚信等级信息是否满足预置条件。
  13. 根据权利要求12所述的装置，其特征在于，所述第三判断子单元具体用于：
    判断所述诚信等级是否高于预置的阈值；
    如果是，则根据预置的诚信等级与授信额度之间的对应关系，确定所述目标第二用户的诚信等级信息对应的目标授信额度；
    判断所述目标交易订单中的退款金额是否小于所述目标授信额度；
    如果是，则确定所述诚信等级信息是否满足预置条件。
  14. 根据权利要求9或12所述的装置，其特征在于，还包括：
    用户信息提取单元，用于在所述调用预置的同意退款接口之前，从所述交易订单中提取交易中的目标第一用户以及目标第二用户标识；
    退款次数判断单元，用于判断在最近预置时间段内，所述第二用户针对所述与所述目标第一用户的交易订单发起所述快速退款请求的次数；
    触发单元，用于如果所述次数小于预置的阈值，则触发执行所述调用预置的同意退款接口的步骤。
PCT/CN2016/078604 2015-05-05 2016-04-06 退款信息处理方法及装置 WO2016177249A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201510224826.0A CN106204052A (zh) 2015-05-05 2015-05-05 退款信息处理方法及装置
CN201510224826.0 2015-05-05

Publications (1)

Publication Number Publication Date
WO2016177249A1 true WO2016177249A1 (zh) 2016-11-10

Family

ID=57217478

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2016/078604 WO2016177249A1 (zh) 2015-05-05 2016-04-06 退款信息处理方法及装置

Country Status (3)

Country Link
CN (1) CN106204052A (zh)
HK (1) HK1231606A1 (zh)
WO (1) WO2016177249A1 (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110826921A (zh) * 2019-11-08 2020-02-21 腾讯科技（深圳）有限公司 数据处理方法、装置、计算机可读存储介质和计算机设备
CN111652723A (zh) * 2020-06-01 2020-09-11 泰康保险集团股份有限公司 数据处理方法、装置、设备及计算机可读存储介质
CN112348475A (zh) * 2020-11-11 2021-02-09 国网浙江省电力有限公司检修分公司 电力系统的操作任务生成方法及装置
CN113298607A (zh) * 2020-12-29 2021-08-24 阿里巴巴集团控股有限公司 订单信息处理方法、装置及电子设备
CN113643111A (zh) * 2021-07-16 2021-11-12 国网山东省电力公司营销服务中心(计量中心) 电力营销退费管理系统及方法
CN114092171A (zh) * 2021-08-30 2022-02-25 北京达佳互联信息技术有限公司 数据处理方法、装置、服务器及介质
CN117391876A (zh) * 2023-12-05 2024-01-12 杭州瀚斯科技有限公司 对账信息的智能化处理方法及相关装置

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106960336A (zh) * 2017-03-14 2017-07-18 世纪禾光科技发展（北京）有限公司 跨境电商平台美国运通信用卡退款自动化的方法及系统
CN109409856A (zh) * 2017-08-18 2019-03-01 阿里巴巴集团控股有限公司 退款信息处理方法及装置
CN107909362A (zh) * 2017-11-30 2018-04-13 广州唯品会网络技术有限公司 退款数据的处理方法及装置
CN109978529B (zh) * 2017-12-27 2024-01-23 海尔衣联生态科技(上海)有限公司 离线支付方法
CN108921387A (zh) * 2018-06-07 2018-11-30 安徽鼎龙网络传媒有限公司 一种微场景管理后台手机商城的风险评估系统
CN113850603B (zh) * 2018-08-02 2024-10-22 创新先进技术有限公司 一种支付失败原因的确定方法及装置
CN109255616B (zh) * 2018-08-06 2022-06-07 创新先进技术有限公司 一种拒付任务处理方法及装置
CN110895756A (zh) * 2018-09-13 2020-03-20 湖南共睹互联网科技有限责任公司 基于效果确认的退款保障交易方法、装置、介质及设备
CN109614262B (zh) * 2018-09-25 2023-03-07 创新先进技术有限公司 业务校验方法、装置及计算机可读存储介质
CN109325786B (zh) * 2018-09-29 2022-03-08 湖南共睹互联网科技有限责任公司 交易保障平台的双级双轨授权方法、终端及可读存储介质
CN109272327B (zh) * 2018-09-29 2021-04-23 湖南共睹互联网科技有限责任公司 退款追踪方法、交易保障平台、终端及可读存储介质
CN109272328B (zh) * 2018-09-29 2021-04-13 湖南共睹互联网科技有限责任公司 退款追踪方法、交易保障平台、终端及可读存储介质
CN110969504A (zh) * 2018-09-30 2020-04-07 北京京东尚科信息技术有限公司 一种订单取消的方法和装置
CN110046995B (zh) * 2018-12-28 2023-09-26 创新先进技术有限公司 退费请求处理方法、装置及设备
CN110033274A (zh) * 2019-01-09 2019-07-19 阿里巴巴集团控股有限公司 退款方法、退款系统和收单受理系统
CN110046912A (zh) * 2019-02-26 2019-07-23 阿里巴巴集团控股有限公司 一种申诉系统、申诉处理方法和装置
CN110163606B (zh) * 2019-04-29 2023-06-30 创新先进技术有限公司 基于区块链的退款方法和装置、电子设备
CN110163634B (zh) * 2019-04-29 2023-10-10 创新先进技术有限公司 基于区块链的退款方法和装置、电子设备
CN110363612A (zh) * 2019-05-28 2019-10-22 成都美美臣科技有限公司 一种通过投诉ipn改变订单状态的方法
CN110610399A (zh) * 2019-08-12 2019-12-24 阿里巴巴集团控股有限公司 实体票状态变更方法、装置及电子设备
CN111861502B (zh) * 2020-04-03 2024-04-19 上海寻梦信息技术有限公司 信息处理方法、系统、电子设备及存储介质
CN113298591B (zh) * 2020-07-13 2025-02-11 阿里巴巴集团控股有限公司 交易处理方法以及装置
CN112200629A (zh) * 2020-10-12 2021-01-08 绿瘦健康产业集团有限公司 一种退款支付处理方法、装置、介质及终端设备
CN112561633B (zh) * 2020-12-09 2023-01-06 完美世界控股集团有限公司 虚拟对象订单数据的校验方法、装置及设备
CN112950191A (zh) * 2021-02-25 2021-06-11 平安养老保险股份有限公司 基于退费业务的业务数据处理方法、装置及计算机设备
CN115049447B (zh) * 2021-03-09 2025-01-17 北京同邦卓益科技有限公司 一种订单处理方法、装置、电子设备及存储介质
CN113409102B (zh) * 2021-05-24 2023-02-21 支付宝(杭州)信息技术有限公司 一种交易对象转移方法、装置及设备
CN113869918A (zh) * 2021-10-13 2021-12-31 芸豆数字科技有限公司 一种商品退货处理方法、装置、电子设备及存储介质
CN115147182B (zh) * 2022-07-05 2025-02-28 北京达佳互联信息技术有限公司 订单信息处理方法、装置、电子设备及存储介质
CN115392921A (zh) * 2022-09-06 2022-11-25 平安消费金融有限公司 退款业务的处理方法、装置、计算机设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020120510A1 (en) * 2001-02-27 2002-08-29 Hidehiko Kawakami Information consuming system and program with a refund capability, and information package for use therein
CN102496221A (zh) * 2011-11-16 2012-06-13 上海翰鑫信息科技有限公司 Pos机、订单确认系统及方法、交易系统及方法
CN102521747A (zh) * 2011-12-05 2012-06-27 中国联合网络通信集团有限公司 电子钱包账户绑定方法、业务处理方法、装置及系统
CN102982479A (zh) * 2012-12-21 2013-03-20 江苏乐买到网络科技有限公司 一种网络购物中退款的方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020120510A1 (en) * 2001-02-27 2002-08-29 Hidehiko Kawakami Information consuming system and program with a refund capability, and information package for use therein
CN102496221A (zh) * 2011-11-16 2012-06-13 上海翰鑫信息科技有限公司 Pos机、订单确认系统及方法、交易系统及方法
CN102521747A (zh) * 2011-12-05 2012-06-27 中国联合网络通信集团有限公司 电子钱包账户绑定方法、业务处理方法、装置及系统
CN102982479A (zh) * 2012-12-21 2013-03-20 江苏乐买到网络科技有限公司 一种网络购物中退款的方法

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110826921A (zh) * 2019-11-08 2020-02-21 腾讯科技（深圳）有限公司 数据处理方法、装置、计算机可读存储介质和计算机设备
CN110826921B (zh) * 2019-11-08 2023-04-18 腾讯科技（深圳）有限公司 数据处理方法、装置、计算机可读存储介质和计算机设备
CN111652723A (zh) * 2020-06-01 2020-09-11 泰康保险集团股份有限公司 数据处理方法、装置、设备及计算机可读存储介质
CN112348475A (zh) * 2020-11-11 2021-02-09 国网浙江省电力有限公司检修分公司 电力系统的操作任务生成方法及装置
CN113298607A (zh) * 2020-12-29 2021-08-24 阿里巴巴集团控股有限公司 订单信息处理方法、装置及电子设备
CN113643111A (zh) * 2021-07-16 2021-11-12 国网山东省电力公司营销服务中心(计量中心) 电力营销退费管理系统及方法
CN114092171A (zh) * 2021-08-30 2022-02-25 北京达佳互联信息技术有限公司 数据处理方法、装置、服务器及介质
CN117391876A (zh) * 2023-12-05 2024-01-12 杭州瀚斯科技有限公司 对账信息的智能化处理方法及相关装置
CN117391876B (zh) * 2023-12-05 2024-03-26 杭州瀚斯科技有限公司 对账信息的智能化处理方法及相关装置

Also Published As

Publication number Publication date
HK1231606A1 (zh) 2017-12-22
CN106204052A (zh) 2016-12-07

Similar Documents

Publication Publication Date Title
WO2016177249A1 (zh) 退款信息处理方法及装置
US20210233132A1 (en) Order processing method and terminal
US11882240B2 (en) Predictive cross-platform system
TWI640937B (zh) Online payment method and equipment
WO2017032226A1 (zh) 退货信息处理方法及装置
WO2016155197A1 (zh) 一种安全网络交易的激励方法、网络交易平台以及激励资金平台
CN107909362A (zh) 退款数据的处理方法及装置
CN109190026B (zh) 客户的推荐方法及计算机可读存储介质
US10264124B2 (en) Customizable user experience system
WO2017059789A1 (zh) 物流履行方式信息处理方法及装置
CN109034603A (zh) 业务流程执行方法、设备及计算机可读存储介质
WO2020156008A1 (zh) 基于区块链的信息分发方法和系统
CN113313279A (zh) 一种单据审核方法和装置
US8862093B2 (en) Terminal-initiated override of charging system rules
CN107886428B (zh) 一种确定支付清算汇率的方法及支付清算系统
US20150248673A1 (en) Methods and apparatus for a token management system for transactions
CN107153953B (zh) 一种进行支付的方法和设备
CN111507594A (zh) 一种数据处理方法以及设备
CN116703395A (zh) 一种数字人民币的支付方法、装置、设备、系统及介质
CN114358543A (zh) 一种信息处理方法和装置
CN113962775A (zh) 用于虚拟对象和实体对象的投递方法、装置
WO2016018623A1 (en) Techniques for selling and purchasing products via synchronous two-way electronic communication sessions
KR102675207B1 (ko) 이동통신망 기반의 문자발송을 이용한 간편 기부 결제 방법 및 시스템
JP7443318B2 (ja) オンラインショッピング代金精算サービス提供方法、装置及びコンピュータプログラム
CN119379377A (zh) 一种订单数据处理方法和装置

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: 16789243

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: 16789243

Country of ref document: EP

Kind code of ref document: A1