WO2020207084A1 - 支付申诉方法、装置、服务器及可读存储介质 - Google Patents

支付申诉方法、装置、服务器及可读存储介质 Download PDF

Info

Publication number
WO2020207084A1
WO2020207084A1 PCT/CN2020/071234 CN2020071234W WO2020207084A1 WO 2020207084 A1 WO2020207084 A1 WO 2020207084A1 CN 2020071234 W CN2020071234 W CN 2020071234W WO 2020207084 A1 WO2020207084 A1 WO 2020207084A1
Authority
WO
WIPO (PCT)
Prior art keywords
target user
appeal
target
payment card
transaction
Prior art date
Application number
PCT/CN2020/071234
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 创新先进技术有限公司
Priority to US16/882,670 priority Critical patent/US10963888B2/en
Publication of WO2020207084A1 publication Critical patent/WO2020207084A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/903—Querying
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance

Definitions

  • the embodiments of this specification relate to the field of data processing technology, and in particular to a payment appeal method, device, server, and readable storage medium.
  • the user’s high-risk card is first analyzed through data warehouse retrieval or other analysis tools, and then communicated with the user many times to obtain at least one high-risk card.
  • the card is used as the target payment card, and the user is then prompted to submit the target payment card for appeal.
  • the process of determining the target payment card requires manual communication with the user many times, which leads to the problem of long appeal processing time and low efficiency.
  • the embodiments of this specification provide a payment appeal method, device, server, and readable storage medium, which can effectively shorten the appeal processing time and improve the appeal processing efficiency.
  • the first aspect of the embodiments of this specification provides a payment appeal method, including:
  • the second aspect of the embodiments of this specification provides a payment appeal device, including:
  • the appeal query request receiving unit is used to receive the appeal query request of the target user sent by the user terminal;
  • the appeal query request response unit is configured to respond to the appeal query request and use the target user information of the target user to query the target payment card corresponding to the target user for appealing from the transaction database;
  • An appeal voucher generating and sending unit configured to generate appeal voucher information of the target user based on the target user information and the target payment card, and return the appeal voucher information to the user terminal;
  • An appeal creation request receiving unit configured to receive an appeal creation request sent by the user terminal
  • the appeal creation request response unit is configured to respond to the appeal creation request and create an appeal task corresponding to the target user, wherein the appeal creation request is created by the user terminal based on the appeal credential information.
  • the third aspect of the embodiments of this specification also provides a payment appeal system, including:
  • the user terminal is used to obtain the appeal operation of the target user, respond to the appeal operation, generate the appeal query request of the target user, and send the appeal query request to the server;
  • the server is configured to receive the appeal query request, and respond to the appeal query request, and use the target user information of the target user to query the target user corresponding to the target payment for appealing from the transaction database Card; according to the target user information and the target payment card, generate appeal voucher information of the target user, and return the appeal voucher information to the user terminal;
  • the user terminal is configured to receive the appeal credential information, create the appeal creation request according to the appeal credential information, and send the appeal creation request to the server;
  • the server is configured to receive the appeal creation request, respond to the appeal creation request, and create an appeal task corresponding to the target user.
  • the fourth aspect of the embodiments of this specification also provides a server, including a memory, a processor, and a computer program stored in the memory and running on the processor.
  • the processor implements the above payment appeal method when the program is executed. step.
  • the fifth aspect of the embodiments of the present specification also provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the steps of the above payment appeal method are provided.
  • the target user information of the target user to automatically query the target payment card corresponding to the target user for appealing from the transaction database, and communicate with
  • the time for obtaining the target payment card can be greatly shortened, and the appeal efficiency can be effectively improved when the time for obtaining the target payment card is shortened, and the target payment card identification strategy can The accuracy of automatically screening out the target payment card that meets the appeal conditions according to the transaction data of the target user is also high.
  • Figure 1 is a system architecture diagram of the payment application system in the embodiment of this specification.
  • FIG. 2 is a schematic diagram of the structure of displaying the appeal page on the user terminal in the embodiment of the specification
  • Figure 3 is a diagram of data interaction among the user terminal, the complaint processing system, the payment card industry data security standard system, the risk control system, and the sensitive data storage system in the embodiment of this specification;
  • Figure 4 is a method flowchart of the payment appeal method in the embodiment of the specification.
  • Figure 5 is a schematic diagram of the structure of the payment application device in the embodiment of the specification.
  • Fig. 6 is a schematic diagram of the structure of the server in the embodiment of the specification.
  • an embodiment of this specification provides a payment appeal system, including:
  • the user terminal 100 is configured to obtain an appeal operation of a target user, respond to the appeal operation, generate an appeal query request of the target user, and send the appeal query request to the server 200;
  • the server 200 is configured to receive the appeal query request and respond to the appeal query request, and use the target user information of the target user to query the target payment card corresponding to the target user for appealing from the transaction database ; According to the target user information and the target payment card, generate the appeal voucher information of the target user, and return the appeal voucher information to the user terminal 100;
  • the user terminal 100 is configured to receive the appeal credential information, create the appeal creation request based on the appeal credential information, and send the appeal creation request to the server 200;
  • the server 200 is configured to receive the appeal creation request, respond to the appeal creation request, and create an appeal task corresponding to the target user.
  • the payment card includes credit payment tools such as bank cards and electronic payment cards used by users in the transaction process.
  • the user terminal 100 may display an appeal page on the display unit of the user terminal 100 or a display unit connected to the user terminal 100, receive the appeal operation of the target user on the appeal page, and respond to all
  • the appeal operation is described, the appeal query request is generated, and the appeal query request is sent to the server 200; wherein, the appeal operation can be an operation of clicking the appeal button on the appeal page, or the voice collected by a sound collection device Information, etc.
  • the sound collection device can be set in the user terminal 100, the sound collection device can also be a device connected to the user terminal 100, the sound collection device can be, for example, a microphone, a recorder, etc., and the appeal page can also be H5 page.
  • the user terminal 100 may be, for example, a smart phone, a tablet computer, a desktop computer, a notebook computer, etc.; further, the server 200 may be, for example, a desktop computer, a cloud server, a notebook computer, and other devices.
  • an appeal page 101 is displayed on the display unit of the user terminal 100, and user A clicks the appeal query button 102 on the appeal page 101 to generate an appeal query request.
  • the appeal query request carries user information of user A, and then the appeal query request is sent to the server 200.
  • the server 200 may also determine whether the target user has the appeal authority, and if it is determined that the target user has appeal authority, then respond to the appeal query request; if If it is determined that the target user does not have the appeal authority, it is forbidden to respond to the appeal query request, and information that does not have the appeal authority is returned to the user terminal 100.
  • the server 200 when the server 200 responds to the appeal query request, it may first determine whether the offline data of the transaction database contains the transaction data of the target user; if it is determined that the offline data contains some The transaction data of the target user, the transaction data of the target user in the offline data is analyzed to obtain the target payment card; if it is determined that the offline data does not contain the transaction data of the target user , Then analyze the transaction data of the target user in the online data to obtain the target payment card.
  • the transaction database stores transaction data of multiple users, the transaction data includes user information, payment information, and user device information for payment, etc., and the payment information includes payment card and payment amount information;
  • the transaction data of the target user can be queried in the offline data according to the target user information; if found, Then it is determined that the offline data contains the transaction data of the target user, and then the transaction data of the target user in the offline data is analyzed to obtain the target payment card; if it is not found, it is determined If the offline data does not contain the transaction data of the target user, the transaction data of the target user in the online data is analyzed to obtain the target payment card.
  • the appeal query request carries the target user information of the target user, so that after the user terminal 100 sends the appeal query request to the server 200, the server 200 can obtain the target user Target user information.
  • the transaction data of the target user included in the offline data may be analyzed, and the transaction data of the target user Extract at least one payment card as the target payment card; accordingly, when it is determined that the online data contains the target user’s transaction data, the target user’s transaction data included in the online data can be The transaction data is analyzed, and at least one payment card is extracted from the transaction data of the target user as the target payment card.
  • the target payment card identification strategy can be used to use the target payment card
  • the target user information is queried from the transaction database to the target payment card; and/or the target payment card is queried from the transaction database by using the target user information through a target payment card identification model.
  • the transaction data of the target user may be analyzed through the target payment card identification strategy to obtain the target payment card; And/or, analyzing the transaction data of the target user through the target payment card identification model to obtain the target payment card.
  • the target payment card identification strategy can be used to analyze the target user's transaction data to obtain the target payment card; and /Or, analyzing the transaction data of the target user through the target payment card identification model to obtain the target payment card.
  • the target payment card recognition model can be obtained by modeling based on historical user transaction data, and its modeling logic can be the same as or different from the logic of the target payment card recognition strategy. This application will not make specific details. limit.
  • the server 200 uses the target user information to query the target payment card from the transaction database through the target payment card identification strategy, it specifically includes the following steps:
  • the abnormal card includes the payment card for which the address of the payment device used by the target user in the transaction does not match the delivery address and the payment for which the payment amount and the transaction amount do not match during the transaction At least one of the cards;
  • the third number of non-abnormal cards used by the target user is queried from the transaction database, and the judgment is Whether the sum of the third quantity, the second quantity, and the first quantity is not less than the set threshold, wherein the non-abnormal card includes the address and address of the payment device used by the target user during the transaction At least one of the payment card whose delivery address matches and the payment card whose payment amount matches the transaction amount during the transaction;
  • the target user If it is determined that the sum of the third number, the second number, and the first number is less than the set threshold, obtain a new card used by the target user, and obtain a new card used by the target user At least one payment card is selected from a high-risk card, an abnormal card, a non-abnormal card, and a new card as the target payment card, wherein the new card includes the payment card used by the target user most recently from the current time.
  • step S301 when step S301 is performed, the transaction data of the target user is first queried from the transaction database through the target user information, and then the transaction data of the target user is analyzed to obtain the transaction data used by the target user.
  • the first number of high-risk cards and then determine whether the first number is not less than the set threshold, if it is not less than the set threshold, perform step S302; if it is less than the set threshold, perform step S303.
  • the transaction data of the target user may be analyzed, and the number of high-risk cards used by the target user within a set time is obtained as the first number.
  • the set threshold can be set manually or by the server 200, or it can be set according to actual needs.
  • the set threshold can be an integer not less than 1, such as 2, 3, and 4. Etc., this application does not make specific restrictions.
  • the set time can be set manually or by the server 200, or it can be set according to actual needs. The set time can be, for example, 2 days, 3 weeks, and 4 months. Specific restrictions.
  • step S302 is executed to select at least one payment card from the high-risk cards as the target payment card.
  • one or more payment cards may be selected from the high-risk cards used by the target user as the target payment card, and the number of selected payment cards may be equal to or less than or greater than the set threshold. No specific restrictions.
  • the first number is 4 and the set threshold value is 3. Since 4>3, 3 high-risk cards can be selected from 4 high-risk cards as the target payment card.
  • step S303 is executed, and the transaction data of the target user can be analyzed to obtain the second quantity, and then the second quantity and the Whether the sum of the first number is not less than the set threshold, if it is not less than the set threshold, step S304 is executed; if it is less than the set threshold, step S305 is executed.
  • the transaction data of the target user may be analyzed, and the number of abnormal cards used by the target user within a set time can be obtained as the second number.
  • the transaction data of the target user can be analyzed, and it is determined that Whether the address of the payment device used in the transaction and the delivery address match, if the address of the payment device used in a transaction matches the delivery address, the payment card used in the transaction is determined to be a non-abnormal card; If the address of the payment device used in a certain transaction does not match the delivery address, the payment card used in the transaction is determined to be an abnormal card.
  • the locating device set in the payment device is used to obtain the address of the payment device used in each transaction, and then determine Whether the address of the payment device used in each transaction and the receiving address corresponding to the transaction are located in the same area, if it is determined that the address of the payment device used in a certain transaction and the receiving address corresponding to the transaction are located in the same area Area, it is determined that the address of the payment device used in this transaction matches the delivery address corresponding to this transaction; otherwise, the address of the payment device used in this transaction and the delivery address corresponding to this transaction are determined Mismatch.
  • the same area when determining whether the address of the payment device used in each transaction and the receiving address corresponding to the transaction are located in the same area, the same area can be set according to the system or manually, or according to actual needs. It is set that the same area can correspond to a certain city, a certain district in a certain city, a certain street in a certain city, etc., and this specification does not make specific restrictions.
  • the transaction process is determined The address of the payment device used in the transaction matches the delivery address corresponding to the transaction; otherwise, it is determined that the address of the payment device used in the transaction does not match the delivery address corresponding to the transaction.
  • the abnormal card includes a payment card for which the payment amount and the transaction amount of the target user in the transaction process do not match
  • the payment amount and the transaction amount of the target user in the transaction process are acquired, and then it is judged each time. Whether the payment amount and the transaction amount in the transaction process are the same; if the payment amount in a certain transaction process is the same as the transaction amount, it is determined that the payment amount in the transaction process matches the transaction amount, and then the transaction amount used in the transaction process is determined
  • the payment card is a non-abnormal card; otherwise, it is determined that the payment amount used in the transaction does not match the transaction amount, and then the payment card used in the transaction is determined to be an abnormal card.
  • the abnormal card includes a payment card for which the address of the payment device used by the target user during the transaction does not match the delivery address and a payment card for which the payment amount and the transaction amount do not match during the transaction, If the address of the payment device used in a certain transaction matches the delivery address and the payment amount matches the transaction amount, then the payment card used in the transaction is determined to be a non-abnormal card; otherwise, it is determined to be in the transaction
  • the payment card used is an abnormal card.
  • step S304 is executed, and at least one payment card and the target can be selected from the abnormal cards used by the target user
  • the high-risk card used by the user is used as the target payment card; it is also possible to select at least one payment card from the abnormal cards used by the target user as the target payment card, or select from the abnormal cards used by the target user
  • At least one payment card is selected as the target payment card among at least one payment card and a high-risk card used by the target user.
  • step S305 is executed to analyze the transaction data of the target user to obtain the third quantity, and then determine the Whether the sum of the third quantity, the second quantity and the first quantity is not less than the set threshold, if it is not less than the set threshold, execute step S306; if it is less than the set threshold, execute Step S307.
  • step S306 is executed, and at least one of the non-abnormal cards used by the target user can be selected.
  • Payment cards and high-risk cards and abnormal cards used by the target user as the target payment cards; of course, one or more of the non-abnormal cards, high-risk cards and abnormal cards used by the target user can also be selected At least one card is selected as the target payment card.
  • step S307 is executed to obtain the new card used by the target user, and obtain the new card from the target user At least one payment card is selected as the target payment card among the used high-risk card, abnormal card, non-abnormal card and new card.
  • Time constraint conditions, and each time constraint condition set in the high-risk card, non-abnormal card and abnormal card used by the target user in the transaction process can be the same or different.
  • the high-risk card used by the target user in the transaction process in the last 6 months can be queried from the transaction database; and the transaction database of the target user in the last 60 days can be queried from the transaction database
  • the abnormal card used in the process; the non-abnormal card used by the target user in the transaction process in the last 50 days can also be queried from the transaction database.
  • the target payment card identification strategy described above can automatically screen out the target payment card that meets the appeal conditions based on the transaction data of the target user. Compared with obtaining the target payment card through manual communication, it can greatly shorten the acquisition cost.
  • the time for the target payment card can effectively improve the appeal efficiency when the time for obtaining the target payment card is shortened, and the target payment card identification strategy can automatically screen out the appeal conditions according to the transaction data of the target user The accuracy of the target payment card is also high.
  • the server 200 may also generate appeal voucher information of the target user according to the target user information and the target payment card, wherein the appeal voucher information It can be displayed in pictures or text.
  • the appeal voucher information can be compressed and returned to the user Terminal 100.
  • the user terminal 100 is configured to receive the appeal voucher information, create the appeal creation request based on the appeal voucher information, and send the appeal creation request to the server 200, where the appeal creation request is Carrying the appeal credential information; and after receiving the appeal creation request, the server 200 responds to the appeal creation request, creates an appeal task corresponding to the target user, and then processes the appeal task to obtain the appeal The processing result of the task. If the processing result of the appeal task indicates that the appeal is successful, the target user is allowed to use the target payment card to complete payment; if the processing result of the appeal task indicates that the appeal failed, the target user is prohibited Use the target payment card to complete the payment.
  • the server 200 when the server 200 performs the above steps, the above steps can be performed through the appeal processing system 300, the payment card industry data security standard system 301, the risk control system 302, and the sensitive data storage system 303.
  • the specific implementation process is as follows:
  • the user terminal 100 first performs step 1.1 and sends the obtained appeal query request to the appeal processing system 300; after the appeal processing system 300 receives the appeal query request, it performs step 1.2 and sends the appeal authority query request to the risk control system 302, where , The appeal authority request is generated based on the appeal inquiry request; after the risk control system 302 receives the appeal authority inquiry request, it executes step 1.3 to find out whether the target user has appeal authority, specifically, respond to the appeal Permission query request to find out the appeal result of whether the target user has appeal permission; then perform step 1.4, return information about whether the target user has appeal permission; the appeal processing system 300 receives whether the target user returned by the risk control system 302 has appeal After the permission information, if it is determined that the target user does not have the appeal permission, step 1.5 is executed, and the non-appealing information is returned to the user terminal 100; if it is determined that the target user has the appeal permission, step 1.6 is executed and sent to the risk control system 302 Appeal voucher information query request; after the risk control system 30
  • step 2.0 After the user terminal 100 receives the appeal voucher information, it performs step 2.0 and sends the appeal voucher information to the payment card industry data security standard system 301; after the payment card industry data security standard system 301 receives the appeal voucher information, it performs step 2.1, compression Appeal voucher information, then go to step 2.2, send the compressed appeal voucher information to the sensitive data storage system 303 for storage; after the sensitive data storage system 303 receives the compressed appeal voucher information, perform step 2.3, save the compressed appeal Voucher information, then go to step 2.4, return the information that the appeal voucher information is saved successfully; after the payment card industry data security standard system 301 receives the information that the appeal voucher information is saved successfully, go to step 2.5, send the appeal voucher information to the user terminal 100 and save successfully Information.
  • step 2.6 creates an appeal creation request based on the appeal credential information, and then executes step 2.7, sends the appeal creation request to the appeal processing system 300;
  • the appeal processing system 300 receives After the appeal creation request, perform step 2.8, forward the appeal creation request to the risk control system 302; after the risk control system 302 receives the appeal creation request, perform step 2.9, create an appeal task, and then perform step 2.10, return to the appeal task creation success
  • step 2.11 forwards the information that the appeal task is successfully created to the user terminal 100.
  • the target payment card identification strategy described above can automatically screen out the target payment card that meets the appeal conditions according to the transaction data of the target user, and Compared with obtaining the target payment card through manual communication, the time for obtaining the target payment card can be greatly shortened, and the appeal efficiency can be effectively improved when the time for obtaining the target payment card is shortened.
  • the recognition strategy can automatically screen out the target payment card that meets the appeal conditions according to the transaction data of the target user, and the accuracy is also high.
  • the embodiments of this specification provide a payment appeal method, as shown in Figure 4, including:
  • S402 Receive the appeal query request of the target user sent by the user terminal;
  • the using the target user information of the target user to query the target payment card corresponding to the target user for appealing from a transaction database includes:
  • the offline data includes the transaction data of the target user, analyzing the transaction data of the target user in the offline data to obtain the target payment card;
  • the transaction data of the target user is not included in the offline data
  • the transaction data of the target user in the online data is analyzed to obtain the target payment card.
  • the using the target user information of the target user to query the target payment card corresponding to the target user for appealing from a transaction database includes:
  • Target user information to query the target payment card from the transaction database through a target payment card identification strategy
  • the target payment card is queried from the transaction database by using the target user information through a target payment card identification model.
  • the querying the target payment card from the transaction database by using the target user information through the target payment card identification strategy includes:
  • the transaction database It is queried from the transaction database whether the first number of high-risk cards used by the target user is not less than a set threshold, wherein the high-risk card is a payment in the blacklist used by the target user during the transaction card;
  • At least one payment card from the high-risk cards is selected as the target payment card.
  • the querying the target payment card from the transaction database by using the target user information through the target payment card identification strategy includes:
  • the abnormal card includes the payment card whose payment device address used by the target user during the transaction does not match the delivery address and the payment card whose payment amount and the transaction amount do not match during the transaction At least one of
  • At least one payment card is selected as the target payment card from the abnormal cards and high-risk cards used by the target user .
  • the querying the target payment card from the transaction database by using the target user information through the target payment card identification strategy includes:
  • the third number of non-abnormal cards used by the target user is queried from the transaction database, and the first number is determined 3.
  • the quantity, whether the sum of the second quantity and the first quantity is not less than the set threshold, wherein the non-abnormal card includes the address and receipt of the payment device used by the target user in the transaction process At least one of the payment card with matching address and the payment card with matching payment amount and transaction amount during the transaction;
  • the target payment card If it is determined that the sum of the third number, the second number, and the first number is not less than the set threshold, select at least one of the high-risk cards, abnormal cards, and non-abnormal cards used by the target user A payment card is used as the target payment card.
  • the querying the target payment card from the transaction database by using the target user information through the target payment card identification strategy includes:
  • At least one payment card is selected as the target payment card from an abnormal card, a non-abnormal card, and a new card, wherein the new card includes the payment card used by the target user most recently from the current time.
  • an embodiment of this specification provides a payment appeal device, as shown in FIG. 5, including:
  • the appeal query request receiving unit 501 is configured to receive the appeal query request of the target user sent by the user terminal;
  • the appeal query request response unit 502 is configured to respond to the appeal query request and use the target user information of the target user to query the target payment card corresponding to the target user for appealing from the transaction database;
  • the appeal voucher generating and sending unit 503 is configured to generate appeal voucher information of the target user according to the target user information and the target payment card, and return the appeal voucher information to the user terminal;
  • the appeal creation request response unit 505 is configured to respond to the appeal creation request and create an appeal task corresponding to the target user, wherein the appeal creation request is created by the user terminal based on the appeal credential information.
  • the appeal query request response unit 502 is specifically configured to determine whether the offline data of the transaction database contains the transaction data of the target user; if it is determined that the offline data contains the Target user’s transaction data, analyze the target user’s transaction data in the offline data to obtain the target payment card; if it is determined that the offline data does not contain the target user’s transaction data, Then, the transaction data of the target user in the online data is analyzed to obtain the target payment card.
  • the application query request response unit 502 is further configured to use the target user information to query the target payment card from the transaction database through the target payment card identification strategy; and/or, through the target payment The card recognition model uses the target user information to query the target payment card from the transaction database.
  • the appeal query request response unit 502 is further configured to query from the transaction database whether the first number of high-risk cards used by the target user is not less than a set threshold, wherein the high-risk card The card is a payment card in the blacklist used by the target user during the transaction; if the query finds that the first number is not less than the set threshold, select at least one payment card from the high-risk cards as The target payment card.
  • the query request response unit 502 finds that the first number is less than the set threshold, it is also used to query the transaction database for the abnormal card used by the target user. Whether the sum of the second quantity and the first quantity is not less than the set threshold, wherein the abnormal card includes a payment card whose payment device address used by the target user during the transaction does not match the delivery address At least one of the payment cards that do not match the payment amount and the transaction amount during the transaction; if the sum of the first quantity and the second quantity is not less than the set threshold, then the At least one payment card is selected from the abnormal card and the high-risk card used by the target user as the target payment card.
  • the query request response unit 502 finds that the sum of the first quantity and the second quantity is less than the set threshold, it is also used to query the transaction database from the transaction database.
  • the third number of non-abnormal cards used by the target user is determined whether the sum of the third number, the second number, and the first number is not less than the set threshold, wherein the non-abnormal cards include At least one of the payment card whose payment device address matches the delivery address used by the target user during the transaction and the payment card whose payment amount and the transaction amount match during the transaction; if it is determined that the third The sum of the number, the second number and the first number is not less than the set threshold, then at least one payment card is selected as the high-risk card, abnormal card and non-abnormal card used by the target user Target payment card.
  • the appeal query request response unit 502 is further used to obtain the third quantity, the second quantity, and the first quantity if the sum of the third quantity, the second quantity, and the first quantity is less than the set threshold.
  • a new card used by the target user, and at least one payment card is selected as the target payment card from high-risk cards, abnormal cards, non-abnormal cards, and new cards used by the target user, wherein the new card includes the The payment card used by the target user most recently from the current time.
  • an embodiment of this specification also provides a server, as shown in FIG. 6, including a memory 604, a processor 602, and a memory 604 stored on the A computer program running on the processor 602, when the processor 602 executes the program, the steps of any one of the aforementioned payment appeal methods are implemented.
  • bus 600 may include any number of interconnected buses and bridges
  • bus 600 will include one or more processors represented by processor 602 and memory 604
  • the various circuits of the memory are linked together.
  • the bus 600 can also link various other circuits such as peripheral devices, voltage regulators, power management circuits, etc., which are all known in the art, and therefore, no further description will be given herein.
  • the bus interface 605 provides an interface between the bus 600 and the receiver 601 and transmitter 603.
  • the receiver 601 and the transmitter 603 may be the same element, that is, a transceiver, which provides a unit for communicating with various other devices on the transmission medium.
  • the processor 602 is responsible for managing the bus 600 and general processing, and the memory 604 may be used to store data used by the processor 602 when performing operations.
  • the embodiment of this specification also provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the foregoing payment is realized.
  • the steps of any method of the appeal method are not limited to the inventive concept of the payment appeal method.
  • These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing equipment to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including the instruction device.
  • the device implements the functions specified in one process or multiple processes in the flowchart and/or one block or multiple blocks in the block diagram.
  • These computer program instructions can also be loaded on a computer or other programmable data processing equipment, so that a series of operation steps are executed on the computer or other programmable equipment to produce computer-implemented processing, so as to execute on the computer or other programmable equipment.
  • the instructions provide steps for implementing functions specified in a flow or multiple flows in the flowchart and/or a block or multiple blocks in the block diagram.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Computational Linguistics (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种支付申诉方法，接收用户终端（100）发送的目标用户的申诉查询请求（S402），响应所述申诉查询请求，利用所述目标用户的目标用户信息，从交易数据库中查询到所述目标用户对应的用于进行申诉的目标支付卡（S404）；根据所述目标用户信息和所述目标支付卡，生成所述目标用户的申诉凭证信息，并将所述申诉凭证信息返回给所述用户终端（100）（S406）；接收所述用户终端（100）发送的申诉创建请求，响应所述申诉创建请求，创建所述目标用户对应的申诉任务，其中，所述申诉创建请求是所述用户终端（100）基于所述申诉凭证信息创建的（S408）。如此，利用所述目标用户的目标用户信息自动从交易数据库中查询到所述目标用户对应的用于进行申诉的目标支付卡，与通过人工沟通得到所述目标支付卡相比，能够极大缩短获取所述目标支付卡的时间，在获取所述目标支付卡的时间缩短的情况下能够有效提高申诉效率。

Description

支付申诉方法、装置、服务器及可读存储介质 技术领域
本说明书实施例涉及数据处理技术领域，尤其涉及一种支付申诉方法、装置、服务器及可读存储介质。
背景技术
目前在国际风控卡支付的场景下，在用户使用支付卡进行支付时会被风控拒绝，而其中有一部分被风控拒绝的支付卡属于被误拒的支付卡；此时，若用户希望能够再次支付成功，用户需要通过上传材料的方式来进行申诉；但是用户提供的卡材料未必是风控需要审核的卡，从而需要通过人工与用户进行多次沟通后才能提供需要审核的卡(即目标支付卡)，然后促使用户提交目标支付卡进行申诉。
现有技术中，在通过人工与用户进行沟通之前，会首先通过数仓取数或者通过其他分析工具分析出用户的高危卡，再与用户进行多次沟通，进而从高危卡中获取至少一张卡作为目标支付卡，然后促使用户提交目标支付卡进行申诉，此时，目标支付卡的确定过程需要人工与用户进行多次沟通，导致存在申诉处理的时间较长且效率低下的问题。
发明内容
本说明书实施例提供了一种支付申诉方法、装置、服务器及可读存储介质，能够有效缩短申诉处理的时间，且提高申诉处理效率。
本说明书实施例第一方面提供了一种支付申诉方法，包括：
接收用户终端发送的目标用户的申诉查询请求；
响应所述申诉查询请求，利用所述目标用户的目标用户信息，从交易数据库中查询到所述目标用户对应的用于进行申诉的目标支付卡；
根据所述目标用户信息和所述目标支付卡，生成所述目标用户的申诉凭证信息，并将所述申诉凭证信息返回给所述用户终端；
接收所述用户终端发送的申诉创建请求，响应所述申诉创建请求，创建所述目标用户对应的申诉任务，其中，所述申诉创建请求是所述用户终端基于所述申诉凭证信息创建的。
本说明书实施例第二方面提供了一种支付申诉装置，包括：
申述查询请求接收单元，用于接收用户终端发送的目标用户的申诉查询请求；
申述查询请求响应单元，用于响应所述申诉查询请求，利用所述目标用户的目标用户信息，从交易数据库中查询到所述目标用户对应的用于进行申诉的目标支付卡；
申述凭证生成及发送单元，用于根据所述目标用户信息和所述目标支付卡，生成所述目标用户的申诉凭证信息，并将所述申诉凭证信息返回给所述用户终端；
申述创建请求接收单元，用于接收所述用户终端发送的申诉创建请求；
申述创建请求响应单元，用于响应所述申诉创建请求，创建所述目标用户对应的申诉任务，其中，所述申诉创建请求是所述用户终端基于所述申诉凭证信息创建的。
本说明书实施例第三方面还提供了一种支付申诉系统，包括：
用户终端，用于获取目标用户的申诉操作，响应所述申诉操作，生成所述目标用户的申诉查询请求，并将所述申诉查询请求发送给服务器；
所述服务器，用于接收所述申诉查询请求，并响应所述申诉查询请求，利用所述目标用户的目标用户信息，从交易数据库中查询到所述目标用户对应的用于进行申诉的目标支付卡；根据所述目标用户信息和所述目标支付卡，生成所述目标用户的申诉凭证信息，并将所述申诉凭证信息返回给所述用户终端；
所述用户终端，用于接收所述申诉凭证信息，根据所述申诉凭证信息创建所述申诉创建请求，将所述申诉创建请求发送所述服务器；
所述服务器，用于接收所述申诉创建请求，响应所述申诉创建请求，创建与所述目标用户对应的申诉任务。
本说明书实施例第四方面还提供了一种服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述支付申诉方法的步骤。
本说明书实施例第五方面还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时上述支付申诉方法的步骤。
本说明书实施例的有益效果如下：
基于上述技术方案，对所述申述查询请求进行响应，利用所述目标用户的目标用户 信息，自动从交易数据库中查询到所述目标用户对应的用于进行申诉的目标支付卡，与通过人工沟通得到所述目标支付卡相比，能够极大缩短获取所述目标支付卡的时间，在获取所述目标支付卡的时间缩短的情况下能够有效提高申诉效率，而且通过上述目标支付卡识别策略能够根据所述目标用户的交易数据自动筛选出符合申诉条件的所述目标支付卡的准确度也较高。
附图说明
图1为本说明书实施例中支付申述系统的系统架构图；
图2为本说明书实施例中在用户终端上显示申述页面的结构示意图；
图3为本说明书实施例中用户终端、诉处理系统、支付卡行业数据安全标准系统、风控系统和敏感数据存储系统之间的数据交互图；
图4为本说明书实施例中支付申诉方法的方法流程图；
图5为本说明书实施例中支付申述装置的结构示意图；
图6为本说明书实施例中服务器的结构示意图。
具体实施方式
为了更好的理解上述技术方案，下面通过附图以及具体实施例对本说明书实施例的技术方案做详细的说明，应当理解本说明书实施例以及实施例中的具体特征是对本说明书实施例技术方案的详细的说明，而不是对本说明书技术方案的限定，在不冲突的情况下，本说明书实施例以及实施例中的技术特征可以相互组合。
第一方面，如图1所示，本说明书实施例提供一种支付申诉系统，包括：
用户终端100，用于获取目标用户的申诉操作，响应所述申诉操作，生成所述目标用户的申诉查询请求，并将所述申诉查询请求发送给服务器200；
服务器200，用于接收所述申诉查询请求，并响应所述申诉查询请求，利用所述目标用户的目标用户信息，从交易数据库中查询到所述目标用户对应的用于进行申诉的目标支付卡；根据所述目标用户信息和所述目标支付卡，生成所述目标用户的申诉凭证信息，并将所述申诉凭证信息返回给用户终端100；
用户终端100，用于接收所述申诉凭证信息，根据所述申诉凭证信息创建所述申诉 创建请求，将所述申诉创建请求发送给服务器200；
服务器200，用于接收所述申诉创建请求，响应所述申诉创建请求，创建与所述目标用户对应的申诉任务。
本说明书实施例中，所述支付卡包括用户在交易过程中使用的银行卡和电子支付卡等信用支付工具。
具体来讲，用户终端100，可以在用户终端100的显示单元或与用户终端100的相连的显示单元上显示申诉页面，接收所述目标用户在所述申诉页面上的所述申诉操作，响应所述申诉操作，生成所述申诉查询请求，并将所申诉查询请求发送给服务器200；其中，所述申诉操作可以是点击所申诉页面中的申诉按键的操作，也可以通过声音采集设备采集的语音信息等，所述声音采集设备可以设置在用户终端100中，所述声音采集设备也可以与用户终端100相连的设备，所述声音采集设备例如可以麦克风、录音机等设备，所述申诉页面也可以H5页面。
本说明书实施例中，用户终端100例如可以是智能手机、平板电脑、台式电脑和笔记本电脑等；进一步地，服务器200例如可以是台式电脑、云端服务器和笔记本电脑等设备。
例如，参见图2，以目标用户为A用户为例，用户终端100的显示单元上显示有申诉页面101，A用户点击申诉页面101上的申诉查询按钮102，生成申诉查询请求，其中，所述申诉查询请求中携带有用户A的用户信息，然后将所述申诉查询请求发送给服务器200。
本说明书实施例中，服务器200在响应所述申诉查询请求之前，还可以先判断所述目标用户是否具有申诉权限，若判断出所述目标用户具有申诉权限，则响应所述申诉查询请求；若判断出所述目标用户不具有申诉权限，则禁止响应所述申诉查询请求，并向返回不具有申诉权限的信息给用户终端100。
本说明书实施例中，服务器200在响应所述申诉查询请求时，可以首先判断所述交易数据库的离线数据中是否包含有所述目标用户的交易数据；若判断出所述离线数据中包含有所述目标用户的交易数据，则对所述离线数据中的所述目标用户的交易数据进行分析，得到所述目标支付卡；若判断出所述离线数据中未包含有所述目标用户的交易数据，则对所述在线数据中的所述目标用户的交易数据进行分析，得到所述目标支付卡。
具体来讲，所述交易数据库中存储有多个用户的交易数据，所述交易数据包括用户 信息、支付信息和进行支付的用户设备信息等，所述支付信息包括支付卡和支付金额等信息；如此，使得在判断所述交易数据库的离线数据中是否包含有所述目标用户的交易数据时，可以根据所述目标用户信息在所述离线数据查询所述目标用户的交易数据；若查找到，则判断出所述离线数据中包含有所述目标用户的交易数据，再对所述离线数据中的所述目标用户的交易数据进行分析，得到所述目标支付卡；若未查找到，则判断出所述离线数据中未包含有所述目标用户的交易数据，再对所述在线数据中的所述目标用户的交易数据进行分析，得到所述目标支付卡。
本说明书实施例中，所述申诉查询请求会携带所述目标用户的目标用户信息，如此，使得用户终端100将所述申诉查询请求发送给服务器200之后，使得服务器200能够获取到所述目标用户的目标用户信息。
具体来讲，在判断出所述离线数据中包含有所述目标用户的交易数据时，可以对所述离线数据中包含的所述目标用户的交易数据进行分析，从所述目标用户的交易数据中提取至少一张支付卡作为所述目标支付卡；相应地，在判断出所述在线数据中包含有所述目标用户的交易数据时，可以对所述在线数据中包含的所述目标用户的交易数据进行分析，从所述目标用户的交易数据中提取至少一张支付卡作为所述目标支付卡。
本申请说明书实施例中，在利用所述目标用户的目标用户信息，从交易数据库中查询到所述目标用户对应的用于进行申诉的目标支付卡时，可以通过目标支付卡识别策略利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡；和/或，通过目标支付卡识别模型利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡。
具体来讲，在判断出所述离线数据中包含有所述目标用户的交易数据时，可以通过所述目标支付卡识别策略对所述目标用户的交易数据进行分析，得到所述目标支付卡；和/或，通过所述目标支付卡识别模型对所述目标用户的交易数据进行分析，得到所述目标支付卡。
相应地，在判断出所述在线数据中包含有所述目标用户的交易数据时，可以通过所述目标支付卡识别策略对所述目标用户的交易数据进行分析，得到所述目标支付卡；和/或，通过所述目标支付卡识别模型对所述目标用户的交易数据进行分析，得到所述目标支付卡。
本说明书实施例中，所述目标支付卡识别模型可以根据历史用户的交易数据进行建模得到的，其建模的逻辑可以与所述目标支付卡识别策略的逻辑相同或不同，本申请不 作具体限制。
本说明书实施例中，服务器200在通过目标支付卡识别策略利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡时，具体包括以下步骤：
S301、从所述交易数据库中查询出所述目标用户使用的高危卡的第一数量是否不小于设定阈值，其中，所述高危卡为所述目标用户在交易过程中使用的在黑名单中的支付卡；
S302、若查询出所述第一数量不小于所述设定阈值，则从所述高危卡中选取至少一张支付卡作为所述目标支付卡。
S303、若查询出所述第一数量小于所述设定阈值，则从所述交易数据库中查询出所述目标用户使用的异常卡的第二数量和所述第一数量之和是否不小于所述设定阈值，其中，所述异常卡包括所述目标用户在交易过程中使用的支付设备所在地址与收货地址不匹配的支付卡和在交易过程中的支付金额和交易金额不匹配的支付卡中的至少一种；
S304、若查询出所述第一数量和所述第二数量之和不小于所述设定阈值，则从所述目标用户使用的异常卡和高危卡中选取至少一张支付卡作为所述目标支付卡；
S305、若查询出所述第一数量和所述第二数量之和小于所述设定阈值，则从所述交易数据库中查询出所述目标用户使用的非异常卡的第三数量，判断所述第三数量、所述第二数量和所述第一数量之和是否不小于所述设定阈值，其中，所述非异常卡包括所述目标用户在交易过程中使用的支付设备所在地址与收货地址匹配的支付卡和在交易过程中的支付金额和交易金额匹配的支付卡中的至少一种；
S306、若判断出所述第三数量、所述第二数量和所述第一数量之和不小于所述设定阈值，则从所述目标用户使用的高危卡、异常卡和非异常卡中选取至少一张支付卡作为所述目标支付卡；
S307、若断出所述第三数量、所述第二数量和所述第一数量之和小于所述设定阈值，则获取所述目标用户使用的新卡，并从所述目标用户使用的高危卡、异常卡、非异常卡和新卡中选取至少一张支付卡作为所述目标支付卡，其中，所述新卡包括所述目标用户距离当前时间最近使用的支付卡。
其中，在执行步骤S301时，首先通过所述目标用户信息从所述交易数据库中查询出所述目标用户的交易数据，然后对所述目标用户的交易数据进行分析，得到所述目标用户使用的高危卡的所述第一数量，然后判断所述第一数量是否不小于所述设定阈值， 若不小于所述设定阈值，则执行步骤S302；若小于所述设定阈值，则执行步骤S303。
具体来讲，在得到所述第一数量时，可以对所述目标用户的交易数据进行分析，得到所述目标用户在设定时间内使用的高危卡的数量作为所述第一数量。
本说明书实施例中，所述设定阈值可以由人工或服务器200自行设定，也可以根据实际需求进行设定，所述设定阈值可以为不小于1的整数，例如为2,3和4等，本申请不作具体限制。进一步地，所述设定时间可以由人工或服务器200自行设定，也可以根据实际需求进行设定，所述设定时间例如可以为2天、3周和4个月等时间，本申请不作具体限制。
若查询出所述第一数量不小于所述设定阈值，则执行步骤S302,从所述高危卡中选取至少一张支付卡作为所述目标支付卡。
具体来讲，可以从所述目标用户使用的高危卡中选取1张或多张支付卡作为所述目标支付卡，选取的支付卡的数量可以等于或小于或大于所述设定阈值，本申请不作具体限制。
例如，所述第一数量为4，而所述设定阈值为3，由于4>3，则可以从4张高危卡中选取3张高危卡作为所述目标支付卡。
若查询出所述第一数量小于所述设定阈值，则执行步骤S303，则可以对所述目标用户的交易数据进行分析，得到所述第二数量，然后判断所述第二数量和所述第一数量之和是否不小于所述设定阈值，若不小于所述设定阈值，则执行步骤S304；若小于所述设定阈值，则执行步骤S305。
具体来讲，在得到所述第二数量时，可以对所述目标用户的交易数据进行分析，得到所述目标用户在设定时间内使用的异常卡的数量作为所述第二数量。
具体地，在所述异常卡包括所述目标用户在交易过程中使用的支付设备所在地址与收货地址不匹配的支付卡时，可以对所述目标用户的交易数据进行分析，判断在每次交易过程中使用的支付设备所在地址和收货地址是否匹配，若某次交易过程中使用的支付设备所在地址和收货地址匹配，则确定该次交易过程中使用的支付卡为非异常卡；若某次交易过程中使用支付设备所在地址和收货地址不匹配，则确定该次交易过程中使用的支付卡为异常卡。
具体来讲，在每次交易过程中使用的支付设备所在地址和收货地址是否匹配时，通过设置在所述支付设备中的定位设备获取每次交易过程中使用的支付设备所在地址，然 后判断每次交易过程中使用的支付设备所在地址和该次交易对应的收货地址是否位于同一区域，若判断出某次交易过程中使用的支付设备所在地址和该次交易对应的收货地址位于同一区域，则确定该次交易过程中使用的支付设备所在地址和该次交易对应的收货地址匹配；否则，则确定该次交易过程中使用的支付设备所在地址和该次交易对应的收货地址不匹配。
具体地，在判断每次交易过程中使用的支付设备所在地址和该次交易对应的收货地址是否位于同一区域时，所述同一区域可以根据系统或人工进行设定，也可以根据实际需求进行设定，所述同一区域可以对应某个城市、某个城市中的某个区和某个城市中某个街道等，本说明书不作具体限制。
例如，以同一区域对应某个城市为例，则判断每次交易过程中使用的支付设备所在地址和该次交易对应的收货地址是否位于同一城市，若位于同一城市，则确定该次交易过程中使用的支付设备所在地址和该次交易对应的收货地址匹配；否则，则确定该次交易过程中使用的支付设备所在地址和该次交易对应的收货地址不匹配。
具体地，在所述异常卡包括所述目标用户在交易过程中的支付金额和交易金额不匹配的支付卡时，获取所述目标用户在交易过程中的支付金额和交易金额，然后判断每次交易过程中的支付金额和交易金额是否相同；若某次交易过程中的支付金额和交易金额相同，则确定该次交易过程中的支付金额和交易金额匹配，进而确定该次交易过程中使用的支付卡为非异常卡；否则，则确定该次交易过程中使用的支付金额和交易金额不匹配，进而确定该次交易过程中使用的支付卡为异常卡。
具体地，在所述异常卡包括所述目标用户在交易过程中使用的支付设备所在地址与收货地址不匹配的支付卡和在交易过程中的支付金额和交易金额不匹配的支付卡时，若某次交易过程中使用的支付设备所在地址与收货地址匹配且支付金额和交易金额匹配，则确定该次交易过程中使用的支付卡为非异常卡；否则，则确定该次交易过程中使用的支付卡为异常卡。
若查询出所述第一数量和所述第二数量之和不小于所述设定阈值，则执行步骤S304,可以从所述目标用户使用的异常卡中选取至少一张支付卡和所述目标用户使用的高危卡作为所述目标支付卡；也可以从所述目标用户使用的异常卡中选取至少一张支付卡作为所述目标支付卡，还可以从所述目标用户使用的异常卡中选取至少一张支付卡和所述目标用户使用的高危卡中选取至少一张支付卡作为所述目标支付卡。
例如，若所述第一数量为2，而所述设定阈值为3，由于2<3，则从所述交易数据库中查询出所述目标用户使用的异常卡的第二数量，且所述第二数量为2，由于2+2＝4>3,则从2张异常卡中选取一张异常卡和2张高危卡作为所述目标支付卡。
若查询出所述第一数量和所述第二数量之和小于所述设定阈值，则执行步骤S305,对所述目标用户的交易数据进行分析，得到所述第三数量，然后判断所述第三数量、所述第二数量和所述第一数量之和是否不小于所述设定阈值，若不小于所述设定阈值，则执行步骤S306；若小于所述设定阈值，则执行步骤S307。
若判断出所述第三数量、所述第二数量和所述第一数量之和不小于所述设定阈值，则执行步骤S306,可以从所述目标用户使用的非异常卡中选取至少一张支付卡和所述目标用户使用的高危卡和异常卡作为所述目标支付卡；当然，也可以从所述目标用户使用的非异常卡、高危卡和异常卡中的一种或多种卡中选取至少一个张卡作为所述目标支付卡。
例如，若所述第一数量为1，而所述设定阈值为3，由于1<3，则从所述交易数据库中查询出所述目标用户使用的异常卡的第二数量，且所述第二数量为1，由于1+1＝2<3,则继续从所述交易数据库中查询出所述目标用户使用的非异常卡的第三数量，若所述第三数量为3，由于1+1+3＝5>3，则从3张非异常卡中选取一张非异常卡，然后将选取的一张非异常卡、1张高危卡和1张异常卡作为所述目标支付卡。
若断出所述第三数量、所述第二数量和所述第一数量之和小于所述设定阈值，则执行步骤S307,获取所述目标用户使用的新卡，并从所述目标用户使用的高危卡、异常卡、非异常卡和新卡中选取至少一张支付卡作为所述目标支付卡。
例如，若所述第一数量为0，而所述设定阈值为3，由于0<3，则从所述交易数据库中查询出所述目标用户使用的异常卡的第二数量，且所述第二数量为1，由于1<3,则继续从所述交易数据库中查询出所述目标用户使用的非异常卡的第三数量，若所述第三数量为1，由于1+1＝2<3，则继续从所述交易数据库中查询出所述目标用户使用的新卡，若所述目标支付卡的数量为3，则从所述目标用户使用的新卡中选取1张支付卡，然后将从新卡中选取的1张支付卡、1张异常卡和1张非异常卡作为所述目标支付卡。
本说明书实施例中，为了提高选取的目标支付卡更符合申诉条件，可以在从所述交易数据库中查询出所述目标用户在交易过程中使用的高危卡、非异常卡和异常卡时会设置时间约束条件，而且在查询出所述目标用户在交易过程中使用的高危卡、非异常卡和 异常卡中设置的每个时间约束条件可以相同或不同。
例如，可以从所述交易数据库中查询出所述目标用户在最近6个月内的交易过程中使用的高危卡；以及可以从所述交易数据库中查询出所述目标用户在最近60天内的交易过程中使用的异常卡；还可以从所述交易数据库中查询出所述目标用户在最近50天内的交易过程中使用的非异常卡。
如此，通过上述目标支付卡识别策略能够根据所述目标用户的交易数据自动筛选出符合申诉条件的所述目标支付卡，与通过人工沟通得到所述目标支付卡相比，能够极大缩短获取所述目标支付卡的时间，在获取所述目标支付卡的时间缩短的情况下能够有效提高申诉效率，而且通过上述目标支付卡识别策略能够根据所述目标用户的交易数据自动筛选出符合申诉条件的所述目标支付卡的准确度也较高。
本说明书实施例中，服务器200在获取到所述目标支付卡之后，还可以根据所述目标用户信息和所述目标支付卡，生成所述目标用户的申诉凭证信息，其中，所述申诉凭证信息可以用图片或文字等方式进行显示，在将所述申诉凭证信息返回给用户终端100时，为了降低所述申诉凭证信息传输耗费的时间和流量，可以将所述申诉凭证信息压缩后返回给用户终端100。
本说明书实施例中，用户终端100用于接收所述申诉凭证信息，根据所述申诉凭证信息创建所述申诉创建请求，将所述申诉创建请求发送给服务器200，其中，所述申诉创建请求中携带有所述申诉凭证信息；以及服务器200在接收到所述申诉创建请求之后，响应所述申诉创建请求，创建与所述目标用户对应的申诉任务，然后处理所述申诉任务，得到所述申诉任务的处理结果，若所述申诉任务的处理结果表征申诉成功，则使得所述目标用户使用所述目标支付卡完成支付；若所述申诉任务的处理结果表征申诉失败，则禁止所述目标用户使用所述目标支付卡完成支付。
在实际应用过程中，如图3所示，在服务器200执行上述步骤时，可以通过申诉处理系统300、支付卡行业数据安全标准系统301、风控系统302和敏感数据存储系统303执行上述步骤，具体实现过程如下：
用户终端100首先执行步骤1.1、将获取的申诉查询请求发送给申诉处理系统300；申诉处理系统300接收到所述申诉查询请求之后，执行步骤1.2、向风控系统302发送申诉权限查询请求，其中，所述申诉权限请求是基于所述申诉查询请求而生成的；风控系统302接收到所述申诉权限查询请求之后，执行步骤1.3、查询出目标用户是否具有 申诉权限，具体地，响应所申诉权限查询请求，查询出所述目标用户是否具有申诉权限的申诉结果；接着执行步骤1.4、返回目标用户是否具有申诉权限的信息；申诉处理系统300接收到风控系统302返回的目标用户是否具有申诉权限的信息之后，若判断出目标用户不具有申诉权限，则执行步骤1.5、将不可申诉信息返回给用户终端100；若判断出目标用户具有申诉权限，则执行步骤1.6、向风控系统302发送申诉凭证信息查询请求；风控系统302接收到申诉凭证信息查询请求之后，执行步骤1.7、返回获取到的申诉凭证信息；申诉处理系统300接收到申诉凭证信息之后，执行步骤1.8、向用户终端100发送申诉凭证信息。
其次，用户终端100接收到申诉凭证信息之后，执行步骤2.0、向支付卡行业数据安全标准系统301发送申诉凭证信息；支付卡行业数据安全标准系统301接收到申诉凭证信息之后，执行步骤2.1、压缩申诉凭证信息，接着执行步骤2.2、将压缩后的申诉凭证信息发送给敏感数据存储系统303进行保存；敏感数据存储系统303接收到压缩后的申诉凭证信息之后，执行步骤2.3、保存压缩后的申诉凭证信息，接着执行步骤2.4、返回申诉凭证信息保存成功的信息；支付卡行业数据安全标准系统301接收到申诉凭证信息保存成功的信息之后，执行步骤2.5、向用户终端100发送申诉凭证信息保存成功的信息。
进一步地，用户终端100接收到凭证信息保存成功的信息之后，执行步骤2.6、根据申诉凭证信息创建申诉创建请求，接着执行步骤2.7、将申诉创建请求发送给申诉处理系统300；申诉处理系统300接收到申诉创建请求之后，执行步骤2.8、将申诉创建请求转发给风控系统302；风控系统302接收到申诉创建请求之后，执行步骤2.9、创建申诉任务，接着执行步骤2.10、返回申诉任务创建成功的信息；申诉处理系统300接收到申诉任务创建成功的信息之后，执行步骤2.11、将申诉任务创建成功的信息转发给用户终端100。
本说明书实施例中采用的技术方案是:对所述申述查询请求进行响应，通过上述目标支付卡识别策略能够根据所述目标用户的交易数据自动筛选出符合申诉条件的所述目标支付卡，与通过人工沟通得到所述目标支付卡相比，能够极大缩短获取所述目标支付卡的时间，在获取所述目标支付卡的时间缩短的情况下能够有效提高申诉效率，而且通过上述目标支付卡识别策略能够根据所述目标用户的交易数据自动筛选出符合申诉条件的所述目标支付卡的准确度也较高。
第三方面，基于与第一方面相同的技术构思，本说明书实施例提供了一种支付申诉 方法，如图4所示，包括：
S402、接收用户终端发送的目标用户的申诉查询请求；
S404、响应所述申诉查询请求，利用所述目标用户的目标用户信息，从交易数据库中查询到所述目标用户对应的用于进行申诉的目标支付卡；
S406、根据所述目标用户信息和所述目标支付卡，生成所述目标用户的申诉凭证信息，并将所述申诉凭证信息返回给所述用户终端；
S408、接收所述用户终端发送的申诉创建请求，响应所述申诉创建请求，创建所述目标用户对应的申诉任务，其中，所述申诉创建请求是所述用户终端基于所述申诉凭证信息创建的。
在一种可选方式中，所述利用所述目标用户的目标用户信息，从交易数据库中查询到所述目标用户对应的用于进行申诉的目标支付卡，包括：
判断所述交易数据库的离线数据中是否包含有所述目标用户的交易数据；
若判断出所述离线数据中包含有所述目标用户的交易数据，则对所述离线数据中的所述目标用户的交易数据进行分析，得到所述目标支付卡；
若判断出所述离线数据中未包含有所述目标用户的交易数据，则对所述在线数据中的所述目标用户的交易数据进行分析，得到所述目标支付卡。
在一种可选方式中，所述利用所述目标用户的目标用户信息，从交易数据库中查询到所述目标用户对应的用于进行申诉的目标支付卡，包括：
通过目标支付卡识别策略利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡；和/或，
通过目标支付卡识别模型利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡。
在一种可选方式中，所述通过目标支付卡识别策略利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡，包括：
从所述交易数据库中查询出所述目标用户使用的高危卡的第一数量是否不小于设定阈值，其中，所述高危卡为所述目标用户在交易过程中使用的在黑名单中的支付卡；
若查询出所述第一数量不小于所述设定阈值，则从所述高危卡中选取至少一张 支付卡作为所述目标支付卡。
在一种可选方式中，所述通过目标支付卡识别策略利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡，包括：
若查询出所述第一数量小于所述设定阈值，则从所述交易数据库中查询出所述目标用户使用的异常卡的第二数量和所述第一数量之和是否不小于所述设定阈值，其中，所述异常卡包括所述目标用户在交易过程中使用的支付设备所在地址与收货地址不匹配的支付卡和在交易过程中的支付金额和交易金额不匹配的支付卡中的至少一种；
若查询出所述第一数量和所述第二数量之和不小于所述设定阈值，则从所述目标用户使用的异常卡和高危卡中选取至少一张支付卡作为所述目标支付卡。
在一种可选方式中，所述通过目标支付卡识别策略利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡，包括：
若查询出所述第一数量和所述第二数量之和小于所述设定阈值，则从所述交易数据库中查询出所述目标用户使用的非异常卡的第三数量，判断所述第三数量、所述第二数量和所述第一数量之和是否不小于所述设定阈值，其中，所述非异常卡包括所述目标用户在交易过程中使用的支付设备所在地址与收货地址匹配的支付卡和在交易过程中的支付金额和交易金额匹配的支付卡中的至少一种；
若判断出所述第三数量、所述第二数量和所述第一数量之和不小于所述设定阈值，则从所述目标用户使用的高危卡、异常卡和非异常卡中选取至少一张支付卡作为所述目标支付卡。
在一种可选方式中，所述通过目标支付卡识别策略利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡，包括：
若断出所述第三数量、所述第二数量和所述第一数量之和小于所述设定阈值，则获取所述目标用户使用的新卡，并从所述目标用户使用的高危卡、异常卡、非异常卡和新卡中选取至少一张支付卡作为所述目标支付卡，其中，所述新卡包括所述目标用户距离当前时间最近使用的支付卡。
第三方面，基于与第二方面相同的技术构思，本说明书实施例提供了一种支付申诉装置，如图5所示，包括：
申述查询请求接收单元501，用于接收用户终端发送的目标用户的申诉查询请求；
申述查询请求响应单元502，用于响应所述申诉查询请求，利用所述目标用户的目标用户信息，从交易数据库中查询到所述目标用户对应的用于进行申诉的目标支付卡；
申述凭证生成及发送单元503，用于根据所述目标用户信息和所述目标支付卡，生成所述目标用户的申诉凭证信息，并将所述申诉凭证信息返回给所述用户终端；
申述创建请求接收单元504，用于接收所述用户终端发送的申诉创建请求；
申述创建请求响应单元505，用于响应所述申诉创建请求，创建所述目标用户对应的申诉任务，其中，所述申诉创建请求是所述用户终端基于所述申诉凭证信息创建的。
在一种可选方式中，申述查询请求响应单元502，具体用于判断所述交易数据库的离线数据中是否包含有所述目标用户的交易数据；若判断出所述离线数据中包含有所述目标用户的交易数据，则对所述离线数据中的所述目标用户的交易数据进行分析，得到所述目标支付卡；若判断出所述离线数据中未包含有所述目标用户的交易数据，则对所述在线数据中的所述目标用户的交易数据进行分析，得到所述目标支付卡。
在一种可选方式中申述查询请求响应单元502，还用于通过目标支付卡识别策略利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡；和/或，通过目标支付卡识别模型利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡。
在一种可选方式中，申述查询请求响应单元502，还用于从所述交易数据库中查询出所述目标用户使用的高危卡的第一数量是否不小于设定阈值，其中，所述高危卡为所述目标用户在交易过程中使用的在黑名单中的支付卡；若查询出所述第一数量不小于所述设定阈值，则从所述高危卡中选取至少一张支付卡作为所述目标支付卡。
在一种可选方式中，申述查询请求响应单元502，若查询出所述第一数量小于所述设定阈值，还用于从所述交易数据库中查询出所述目标用户使用的异常卡的第二数量和所述第一数量之和是否不小于所述设定阈值，其中，所述异常卡包括所述目标用户在交易过程中使用的支付设备所在地址与收货地址不匹配的支付卡和在交易过程中的支付金额和交易金额不匹配的支付卡中的至少一种；若查询出所述第一数量和所述第二数量之和不小于所述设定阈值，则从所述目标用户使用的异常卡和高危卡中选取至少一张支付卡作为所述目标支付卡。
在一种可选方式中，申述查询请求响应单元502，若查询出所述第一数量和所述第二数量之和小于所述设定阈值，还用于从所述交易数据库中查询出所述目标用户使用的非异常卡的第三数量，判断所述第三数量、所述第二数量和所述第一数量之和是否不 小于所述设定阈值，其中，所述非异常卡包括所述目标用户在交易过程中使用的支付设备所在地址与收货地址匹配的支付卡和在交易过程中的支付金额和交易金额匹配的支付卡中的至少一种；若判断出所述第三数量、所述第二数量和所述第一数量之和不小于所述设定阈值，则从所述目标用户使用的高危卡、异常卡和非异常卡中选取至少一张支付卡作为所述目标支付卡。
在一种可选方式中，申述查询请求响应单元502，若断出所述第三数量、所述第二数量和所述第一数量之和小于所述设定阈值，还用于获取所述目标用户使用的新卡，并从所述目标用户使用的高危卡、异常卡、非异常卡和新卡中选取至少一张支付卡作为所述目标支付卡，其中，所述新卡包括所述目标用户距离当前时间最近使用的支付卡。
第四方面，基于与前述实施例中支付申诉方法同样的发明构思，本说明书实施例还提供一种服务器，如图6所示，包括存储器604、处理器602及存储在存储器604上并可在处理器602上运行的计算机程序，所述处理器602执行所述程序时实现前文所述支付申诉方法的任一方法的步骤。
其中，在图6中，总线架构(用总线600来代表)，总线600可以包括任意数量的互联的总线和桥，总线600将包括由处理器602代表的一个或多个处理器和存储器604代表的存储器的各种电路链接在一起。总线600还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口605在总线600和接收器601和发送器603之间提供接口。接收器601和发送器603可以是同一个元件，即收发机，提供用于在传输介质上与各种其他装置通信的单元。处理器602负责管理总线600和通常的处理，而存储器604可以被用于存储处理器602在执行操作时所使用的数据。
第五方面，基于与前述实施例中支付申诉方法的发明构思，本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前文所述支付申诉方法的任一方法的步骤。
本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多 个方框中指定的功能的设备。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令设备的制造品，该指令设备实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本说明书的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本说明书范围的所有变更和修改。
显然，本领域的技术人员可以对本说明书进行各种改动和变型而不脱离本说明书的精神和范围。这样，倘若本说明书的这些修改和变型属于本说明书权利要求及其等同技术的范围之内，则本说明书也意图包含这些改动和变型在内。

Claims (17)

  1. 一种支付申诉方法，包括：
    接收用户终端发送的目标用户的申诉查询请求；
    响应所述申诉查询请求，利用所述目标用户的目标用户信息，从交易数据库中查询到所述目标用户对应的用于进行申诉的目标支付卡；
    根据所述目标用户信息和所述目标支付卡，生成所述目标用户的申诉凭证信息，并将所述申诉凭证信息返回给所述用户终端；
    接收所述用户终端发送的申诉创建请求，响应所述申诉创建请求，创建所述目标用户对应的申诉任务，其中，所述申诉创建请求是所述用户终端基于所述申诉凭证信息创建的。
  2. 如权利要求1所述的方法，所述利用所述目标用户的目标用户信息，从交易数据库中查询到所述目标用户对应的用于进行申诉的目标支付卡，包括：
    判断所述交易数据库的离线数据中是否包含有所述目标用户的交易数据；
    若判断出所述离线数据中包含有所述目标用户的交易数据，则对所述离线数据中的所述目标用户的交易数据进行分析，得到所述目标支付卡；
    若判断出所述离线数据中未包含有所述目标用户的交易数据，则对所述在线数据中的所述目标用户的交易数据进行分析，得到所述目标支付卡。
  3. 如权利要求1所述的方法，所述利用所述目标用户的目标用户信息，从交易数据库中查询到所述目标用户对应的用于进行申诉的目标支付卡，包括：
    通过目标支付卡识别策略，利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡；和/或，
    通过目标支付卡识别模型，利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡。
  4. 如权利要求3所述的方法，所述通过目标支付卡识别策略利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡，包括：
    从所述交易数据库中查询出所述目标用户使用的高危卡的第一数量是否不小于设定阈值，其中，所述高危卡为所述目标用户在交易过程中使用的在黑名单中的支付卡；
    若查询出所述第一数量不小于所述设定阈值，则从所述高危卡中选取至少一张支付卡作为所述目标支付卡。
  5. 如权利要求4所述的方法，所述通过目标支付卡识别策略利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡，包括：
    若查询出所述第一数量小于所述设定阈值，则从所述交易数据库中查询出所述目标用户使用的异常卡的第二数量和所述第一数量之和是否不小于所述设定阈值，其中，所述异常卡包括所述目标用户在交易过程中使用的支付设备所在地址与收货地址不匹配的支付卡，和在交易过程中的支付金额和交易金额不匹配的支付卡中的至少一种；
    若查询出所述第一数量和所述第二数量之和不小于所述设定阈值，则从所述目标用户使用的异常卡和高危卡中选取至少一张支付卡作为所述目标支付卡。
  6. 如权利要求5所述的方法，所述通过目标支付卡识别策略利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡，包括：
    若查询出所述第一数量和所述第二数量之和小于所述设定阈值，则从所述交易数据库中查询出所述目标用户使用的非异常卡的第三数量，判断所述第三数量、所述第二数量和所述第一数量之和是否不小于所述设定阈值，其中，所述非异常卡包括所述目标用户在交易过程中使用的支付设备所在地址与收货地址匹配的支付卡和在交易过程中的支付金额和交易金额匹配的支付卡中的至少一种；
    若判断出所述第三数量、所述第二数量和所述第一数量之和不小于所述设定阈值，则从所述目标用户使用的高危卡、异常卡和非异常卡中选取至少一张支付卡作为所述目标支付卡。
  7. 如权利要求6所述的方法，所述通过目标支付卡识别策略利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡，包括：
    若断出所述第三数量、所述第二数量和所述第一数量之和小于所述设定阈值，则获取所述目标用户使用的新卡，并从所述目标用户使用的高危卡、异常卡、非异常卡和新卡中选取至少一张支付卡作为所述目标支付卡，其中，所述新卡包括所述目标用户距离当前时间最近使用的支付卡。
  8. 一种支付申诉装置，包括：
    申述查询请求接收单元，用于接收用户终端发送的目标用户的申诉查询请求；
    申述查询请求响应单元，用于响应所述申诉查询请求，利用所述目标用户的目标用户信息，从交易数据库中查询到所述目标用户对应的用于进行申诉的目标支付卡；
    申述凭证生成及发送单元，用于根据所述目标用户信息和所述目标支付卡，生成所述目标用户的申诉凭证信息，并将所述申诉凭证信息返回给所述用户终端；
    申述创建请求接收单元，用于接收所述用户终端发送的申诉创建请求；
    申述创建请求响应单元，用于响应所述申诉创建请求，创建所述目标用户对应的申诉任务，其中，所述申诉创建请求是所述用户终端基于所述申诉凭证信息创建的。
  9. 如权利要求8所述的装置，所述申述查询请求响应单元，具体用于判断所述交易数据库的离线数据中是否包含有所述目标用户的交易数据；若判断出所述离线数据中包含有所述目标用户的交易数据，则对所述离线数据中的所述目标用户的交易数据进行分析，得到所述目标支付卡；若判断出所述离线数据中未包含有所述目标用户的交易数据，则对所述在线数据中的所述目标用户的交易数据进行分析，得到所述目标支付卡。
  10. 如权利要求8所述的装置，所述申述查询请求响应单元，还用于通过目标支付卡识别策略利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡；和/或，通过目标支付卡识别模型利用所述目标用户信息从所述交易数据库中查询到所述目标支付卡。
  11. 如权利要求10所述的装置，所述申述查询请求响应单元，还用于从所述交易数据库中查询出所述目标用户使用的高危卡的第一数量是否不小于设定阈值，其中，所述高危卡为所述目标用户在交易过程中使用的在黑名单中的支付卡；若查询出所述第一数量不小于所述设定阈值，则从所述高危卡中选取至少一张支付卡作为所述目标支付卡。
  12. 如权利要求11所述的装置，所述申述查询请求响应单元，若查询出所述第一数量小于所述设定阈值，还用于从所述交易数据库中查询出所述目标用户使用的异常卡的第二数量和所述第一数量之和是否不小于所述设定阈值，其中，所述异常卡包括所述目标用户在交易过程中使用的支付设备所在地址与收货地址不匹配的支付卡和在交易过程中的支付金额和交易金额不匹配的支付卡中的至少一种；若查询出所述第一数量和所述第二数量之和不小于所述设定阈值，则从所述目标用户使用的异常卡和高危卡中选取至少一张支付卡作为所述目标支付卡。
  13. 如权利要求12所述的装置，所述申述查询请求响应单元，若查询出所述第一数量和所述第二数量之和小于所述设定阈值，还用于从所述交易数据库中查询出所述目标用户使用的非异常卡的第三数量，判断所述第三数量、所述第二数量和所述第一数量之和是否不小于所述设定阈值，其中，所述非异常卡包括所述目标用户在交易过程中使用的支付设备所在地址与收货地址匹配的支付卡和在交易过程中的支付金额和交易金额匹配的支付卡中的至少一种；若判断出所述第三数量、所述第二数量和所述第一数量之和不小于所述设定阈值，则从所述目标用户使用的高危卡、异常卡和非异常卡中选取至少一张支付卡作为所述目标支付卡。
  14. 如权利要求13所述的装置，所述申述查询请求响应单元，若断出所述第三数量、所述第二数量和所述第一数量之和小于所述设定阈值，还用于获取所述目标用户使用的新卡，并从所述目标用户使用的高危卡、异常卡、非异常卡和新卡中选取至少一张 支付卡作为所述目标支付卡，其中，所述新卡包括所述目标用户距离当前时间最近使用的支付卡。
  15. 一种支付申诉系统，包括：
    用户终端，用于获取目标用户的申诉操作，响应所述申诉操作，生成所述目标用户的申诉查询请求，并将所述申诉查询请求发送给服务器；
    所述服务器，用于接收所述申诉查询请求，并响应所述申诉查询请求，利用所述目标用户的目标用户信息，从交易数据库中查询到所述目标用户对应的用于进行申诉的目标支付卡；根据所述目标用户信息和所述目标支付卡，生成所述目标用户的申诉凭证信息，并将所述申诉凭证信息返回给所述用户终端；
    所述用户终端，用于接收所述申诉凭证信息，根据所述申诉凭证信息创建所述申诉创建请求，将所述申诉创建请求发送所述服务器；
    所述服务器，用于接收所述申诉创建请求，响应所述申诉创建请求，创建与所述目标用户对应的申诉任务。
  16. 一种服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现权利要求1-7任一项所述方法的步骤。
  17. 一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现权利要求1-7任一项所述方法的步骤。
PCT/CN2020/071234 2019-04-10 2020-01-09 支付申诉方法、装置、服务器及可读存储介质 WO2020207084A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/882,670 US10963888B2 (en) 2019-04-10 2020-05-25 Payment complaint method, device, server and readable storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910285016.4 2019-04-10
CN201910285016.4A CN110163739B (zh) 2019-04-10 2019-04-10 支付申诉方法、装置、服务器及可读存储介质

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/882,670 Continuation US10963888B2 (en) 2019-04-10 2020-05-25 Payment complaint method, device, server and readable storage medium

Publications (1)

Publication Number Publication Date
WO2020207084A1 true WO2020207084A1 (zh) 2020-10-15

Family

ID=67638539

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/071234 WO2020207084A1 (zh) 2019-04-10 2020-01-09 支付申诉方法、装置、服务器及可读存储介质

Country Status (2)

Country Link
CN (1) CN110163739B (zh)
WO (1) WO2020207084A1 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110163739B (zh) * 2019-04-10 2020-08-18 阿里巴巴集团控股有限公司 支付申诉方法、装置、服务器及可读存储介质
US10963888B2 (en) 2019-04-10 2021-03-30 Advanced New Technologies Co., Ltd. Payment complaint method, device, server and readable storage medium
CN110738401A (zh) * 2019-09-25 2020-01-31 支付宝(杭州)信息技术有限公司 申诉处理方法、装置、电子设备
CN111429278B (zh) * 2020-03-19 2021-08-06 宁波智正伟盈信息科技有限公司 一种基于5g和区块链的金融大数据处理系统及方法
CN113986429B (zh) * 2021-10-27 2023-12-22 上海倍通医药科技咨询有限公司 一种基于客户咨询的渠道数据快速反馈系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108446905A (zh) * 2018-03-19 2018-08-24 阿里巴巴集团控股有限公司 一种支付方法、装置及电子设备
CN108650240A (zh) * 2018-04-17 2018-10-12 广州四三九九信息科技有限公司 账号申诉审核方法、装置及电子设备
US20180315029A1 (en) * 2015-11-04 2018-11-01 Zae Young KIM Method of remitting/receiving payment using messenger server
CN109118374A (zh) * 2018-08-09 2019-01-01 辽宁万象联合医疗科技有限公司 在线申请理赔的方法、装置及服务器
CN110163739A (zh) * 2019-04-10 2019-08-23 阿里巴巴集团控股有限公司 支付申诉方法、装置、服务器及可读存储介质

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101599151A (zh) * 2009-07-03 2009-12-09 阿里巴巴集团控股有限公司 一种自适应选择银行卡进行支付的系统及方法
US10115268B2 (en) * 2013-03-15 2018-10-30 Linq3 Technologies Llc Systems and methods for integrated game play at payment-enabled terminals
CN103955643B (zh) * 2014-05-20 2017-02-15 北京握奇智能科技有限公司 一种网银交易安全判断与提示方法及系统
CN107705003A (zh) * 2017-09-25 2018-02-16 平安科技（深圳）有限公司 保险产品配送管理方法、装置、计算机设备及存储介质
CN108022080A (zh) * 2017-11-24 2018-05-11 深圳市买买提乐购金融服务有限公司 一种申诉处理方法及相关设备

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180315029A1 (en) * 2015-11-04 2018-11-01 Zae Young KIM Method of remitting/receiving payment using messenger server
CN108446905A (zh) * 2018-03-19 2018-08-24 阿里巴巴集团控股有限公司 一种支付方法、装置及电子设备
CN108650240A (zh) * 2018-04-17 2018-10-12 广州四三九九信息科技有限公司 账号申诉审核方法、装置及电子设备
CN109118374A (zh) * 2018-08-09 2019-01-01 辽宁万象联合医疗科技有限公司 在线申请理赔的方法、装置及服务器
CN110163739A (zh) * 2019-04-10 2019-08-23 阿里巴巴集团控股有限公司 支付申诉方法、装置、服务器及可读存储介质

Also Published As

Publication number Publication date
CN110163739A (zh) 2019-08-23
CN110163739B (zh) 2020-08-18

Similar Documents

Publication Publication Date Title
WO2020207084A1 (zh) 支付申诉方法、装置、服务器及可读存储介质
US10963888B2 (en) Payment complaint method, device, server and readable storage medium
CN107798038B (zh) 数据响应方法及数据响应设备
EP3258397A1 (en) Text address processing method and apparatus
CN111221726A (zh) 一种测试数据生成方法、装置、存储介质和智能设备
US20140359362A1 (en) Information interaction test device and method based on automatic generation of associated test cases
US10540724B2 (en) Electronic receipt-linking database system
CN109214676B (zh) 一种业务订单处理方法、装置、服务器及存储介质
CN104579909B (zh) 一种用户信息的分类、用户分组信息的获取方法和设备
CN106326243B (zh) 一种数据处理方法及装置
WO2016062173A1 (zh) 用户属性数值转移方法及终端
CN111857674B (zh) 业务产品生成方法及装置、电子设备和可读存储介质
CN112395390B (zh) 意图识别模型的训练语料生成方法及其相关设备
WO2019033741A1 (zh) 投资产品的资源处理方法、装置、存储介质和计算机设备
CN110515929B (zh) 书籍展示方法、计算设备及存储介质
CN114996675A (zh) 数据查询方法、装置、计算机设备及存储介质
CN117094729A (zh) 请求处理方法、装置、计算机设备及存储介质
CN116401410B (zh) 多场景图数据库接入图谱数据的方法、装置、存储介质和设备
CN110619275B (zh) 信息推送方法、装置、计算机设备和存储介质
CN112651716A (zh) 数据处理方法、设备及存储介质
CN116681045A (zh) 报表生成方法、装置、计算机设备及存储介质
CN111311357B (zh) 一种房屋交易信息管理方法及系统
CN112632391A (zh) 数据处理方法、设备及存储介质
CN111914065B (zh) 短信内容验证方法、装置、计算机系统和计算机可读介质
CN111882294B (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: 20787981

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

Country of ref document: EP

Kind code of ref document: A1