CN111507724A - Payment verification method and system - Google Patents
Payment verification method and system Download PDFInfo
- Publication number
- CN111507724A CN111507724A CN201910097732.XA CN201910097732A CN111507724A CN 111507724 A CN111507724 A CN 111507724A CN 201910097732 A CN201910097732 A CN 201910097732A CN 111507724 A CN111507724 A CN 111507724A
- Authority
- CN
- China
- Prior art keywords
- payment
- bill
- server
- verification
- order
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000012795 verification Methods 0.000 title claims abstract description 200
- 238000000034 method Methods 0.000 title claims abstract description 35
- 230000000977 initiatory effect Effects 0.000 claims abstract description 10
- 238000010200 validation analysis Methods 0.000 claims description 14
- 238000012163 sequencing technique Methods 0.000 claims 1
- 238000012545 processing Methods 0.000 description 8
- 230000002159 abnormal effect Effects 0.000 description 3
- 230000003111 delayed effect Effects 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 108091007065 BIRCs Proteins 0.000 description 1
- 241000713321 Intracisternal A-particles Species 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
-
- 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/42—Confirmation, e.g. check or permission by the legal debtor of payment
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
The invention relates to a payment verification method and a system.A payment server creates a merchant order mark according to a request of a payment client, so that the payment client can associate the merchant order mark when initiating a payment request, and obtains a bill returned by a third party verification server as a payment result certificate after a user completes payment; the order information associated with the merchant order mark comprises a user mark and a commodity mark corresponding to the payment; when the payment verification request initiated by the payment client in real time does not obtain the payment success information or the bill invalid information returned by the payment server, caching the payment information and accessing the payment server at regular time to reinitiate the verification request; when the bill verification request initiated by the payment server in real time does not obtain a result returned by the third party verification server, the bill is cached and the third party verification server is accessed regularly to reinitiate the verification request. The invention reduces the bill loss possibly caused by the payment link, and has high safety and good user experience.
Description
Technical Field
The invention relates to a payment verification method and a payment verification system, in particular to a merchant payment verification method and a merchant payment verification system for apple IAP payment.
Background
Apple is the largest consumer technology company at present, all virtual goods purchased in apple iOS (operating system) need to use IAP (in-App Purchase) payment solution provided by apple, but after a user pays, the merchant often cannot know the real payment condition of the user due to some technical problems of the IAP payment solution, and the professional term is called as a drop order. The merchant pays the IAP for the total order drop amount/total payment amount, namely the order drop rate. The reason that the IAP payment bill loss rate is high is that the payment architecture scheme commonly adopted by the overseas such as the apple is a bill verification scheme of the client. That is, after a user initiates payment on the iOS device, the apple server issues a ticket to the client, the client issues the ticket to the server of the merchant, and the server requests the apple server to verify the validity of the ticket by using the ticket. The bill transfer process from the client to the server often fails due to poor network, interruption of execution of the client and the like, so that the merchant does not receive the result of completing payment of the user, and further the bill is dropped. On the other hand, IAP payment does not support merchants to use merchant tags or user information to obtain payment results in order to guarantee user privacy.
One of the solutions now proposed is therefore a solution for validating tickets directly by clients using apple IAP payment. However, in this mode, the client itself has the characteristic of being hacked, which often results in the merchant being swiped by lawless persons, resulting in huge economic loss for the merchant.
Yet another is to validate the ticket scheme by the apple server. However, the client will retry after getting the ticket, and the ticket will not be delivered successfully due to the network characteristics of the client itself. Even if the merchant server takes the bill, the bill is lost or the payment is delayed to be checked out due to the instability of the apple server overseas.
In addition, the bill cannot be traced back to implementation in the case that the user uninstalls the payment APP (application) or the merchant order fails to associate the apple bill callback result.
Disclosure of Invention
The invention provides a payment verification method and a payment verification system, which are used for solving the problems encountered when a merchant is in connection with an IAP payment system, and performing detailed exception handling on most of the links which are easy to drop the order and the links which are safe risks, so that the requirements on extremely low order dropping rate, high safety and high performance are ensured.
In the payment verification method provided by the invention, a payment client requests and obtains a merchant order identifier created by a payment server when a user initiates payment, and order information associated with the merchant order identifier comprises a user identifier and a commodity identifier corresponding to the payment;
the payment client associates the merchant order identification when initiating payment, and obtains a bill returned by the third party verification server as a payment result certificate after the user completes payment;
the payment client side initiates at least one payment verification request to the payment server side in real time after receiving the bill, if the agreement signal returned by the payment server is not obtained, the payment client side caches the information of the payment, and the payment server side is accessed regularly to initiate the payment verification request again for the payment.
Optionally, the payment verification request includes a merchant order identifier and a ticket sequence; or, the payment verification request includes merchant account information and a ticket sequence.
Optionally, the payment client initiates a payment verification request at any time in real time, and if an agreement signal returned by the payment server is received, the payment client ends the payment;
if the payment client side receives an appointed signal returned by the payment server side, the payment client side finishes the payment, and a mark corresponding to the payment is removed from a cache;
the appointment signal is a payment success signal or a bill invalidation signal;
and when the payment client is awakened by the user, the operation of reinitiating the payment verification request is executed regularly.
Optionally, the payment client caches the information of the payment through a bill cache queue;
the bill cache queue uses a sorting dictionary structure, keys are stored in the merchant order identification, values are stored in the bill and the payment time, and sorting is carried out in sequence according to the payment time; the bill buffer queue is set with the maximum entry buffer time.
Optionally, the payment client background enables a fixed thread, and periodically initiates a payment verification request to the payment server based on the cached payment information of this time in the order from far to near in the payment time according to the increasing frequency of the time interval from the current time to the payment time.
Optionally, the payment client establishes and stores a merchant order identifier list, which includes merchant order identifiers paid for the last several times;
after the user finishes payment, if the obtained information returned by the third-party verification server does not contain the merchant order identification, the payment client searches the binding information of the merchant order identification one by one, executes the operation of initiating at least one payment verification request to the payment server in real time, and deletes the currently bound merchant order identification from the merchant order identification list.
Optionally, the payment client establishes and stores a merchant order identifier list, which includes merchant order identifiers paid for the last several times; the third party authentication server is an apple server;
the payment client stores the bill caching queue and the merchant order identification list into the iOS keyhain system; when the user reinstalls the payment client, the bill cache queue and the merchant order identification list are read from the keyhide, and the order which is not finished with payment verification before the payment client is deleted is continuously processed.
In another payment verification method provided by the invention, a payment server creates an order according to a request initiated by a payment client when a user pays, and sends the created merchant order identifier to the payment client; the order information associated with the merchant order mark comprises a user mark and a commodity mark corresponding to the payment;
the payment server receives a first payment verification request initiated by the payment client, and initiates a first bill verification request to a third party verification server in real time when finding a user and an order corresponding to the merchant order identification; or when the payment server receives a second payment verification request initiated by the payment client, the payment server initiates a second bill verification request to a third party verification server in real time;
wherein the first bill validation request or the second bill validation request comprises a bill obtained by the payment client from a third party validation server as a payment result voucher; the first payment verification request comprises merchant identification information and a bill sequence; the second payment verification request comprises merchant account information and a bill sequence;
and if the bill return result of the third party verification server is not obtained, the payment server caches the bill, and periodically accesses the third party verification server to reinitiate the first bill verification request or the second bill verification request for the cached bill.
Optionally, the payment server initiates a first bill validation request to a third party validation server according to a first payment validation request initiated or reinitiated by the payment client in real time, and when the payment server obtains a bill return result of the third party validation server, if the bill return result indicates that the bill is invalid, the payment server returns bill invalid information to the payment client;
if the bill returned result shows that the bill is valid, the payment server records the transaction identifier of the current time, and inquires whether the verified transaction identifier library has the current transaction identifier:
if the verified transaction identification library does not have the current transaction identification, the payment server side adds the current transaction identification into the verified transaction identification library, sets the order delivery state of the current order and returns payment success information to the payment client side; and if the current transaction identification exists in the verified transaction identification library, the payment server side returns the invalid bill information to the payment client side.
Optionally, the payment server initiates a second bill validation request to the third party validation server according to a second payment validation request initiated or reinitiated by the payment client in real time, and when the payment server obtains a bill return result of the third party validation server, if the bill return result indicates that the bill is invalid, the payment server returns bill invalid information to the payment client;
if the bill return result shows that the bill is valid, the payment server side obtains the commodity identification of the current time from the bill return result, and inquires all orders which are placed and not delivered by the current user and correspond to the commodity identification according to the merchant account information; the payment server side obtains the transaction identification of the time from the bill return result and inquires whether the verified transaction identification library has the current transaction identification;
if the current user does not have an order which is placed but not delivered, the payment server side returns bill invalid information to the payment client side, and logs record the user and the bill corresponding to the order; if the current user has orders which are placed and not delivered and correspond to the commodity identification, searching the latest order;
if the verified transaction identification library does not have the current transaction identification, the payment server side adds the current transaction identification into the verified transaction identification library, sets the latest order as an order delivery state, and returns payment success information to the payment client side; and if the current transaction identification exists in the verified transaction identification library, the payment server side returns the invalid bill information to the payment client side.
Optionally, the payment server adds the ticket retry request to a delay queue system, sets a retry interval from secret to sparse for delayed verification, and returns the ticket invalid information to the payment client; and the delay queue system sends a message when a set time interval arrives to prompt the payment server to reinitiate the first bill verification request or the second bill verification request.
In another payment verification method provided by the invention, a third party verification server receives and processes a payment request initiated by a user through a payment client, wherein the payment request is associated with a merchant order identifier created by a payment server requested by the payment client; the order information associated with the merchant order mark comprises a user mark and a commodity mark corresponding to the payment; the third party verification server provides a bill serving as a payment result certificate to a payment client of the user after confirming that the user completes payment;
when the third party verification server receives a bill verification request containing a bill sent by the payment server, if the bill is confirmed to be invalid, the third party verification server returns bill invalid information to the payment server; if the bill is confirmed to be valid, the third party verification server returns bill valid information, payment time, a commodity identifier and a transaction identifier to the payment server, so that the payment server can inquire a verified transaction identifier library through the returned transaction identifier to verify whether the order corresponding to the transaction identifier is repeatedly delivered, and inquire all orders which are placed and not delivered by the current user and correspond to the commodity identifier through the returned commodity identifier and merchant account information provided by the payment client.
The invention also provides a payment verification system, which comprises a payment client, a payment server and a third party verification server;
the payment server is provided with an interface for creating an order, receives an order creation request of the payment client to create the order, and sends a created merchant order identifier to the payment client, so that the payment client can associate the merchant order identifier when initiating a payment request to the third-party verification server, and obtains a bill returned by the third-party verification server as a payment result certificate after the user completes payment; the order information associated with the merchant order mark comprises a user mark and a commodity mark corresponding to the payment;
the payment client side is provided with a first real-time verification unit and initiates a payment verification request to the payment server side in real time after acquiring the bill provided by the third-party verification server; the payment server is provided with a payment server side, and the payment server side is provided with a first cache unit and a first delay retry unit, wherein when the payment verification request initiated by the payment client side in real time does not obtain payment success information or bill invalid information returned by the payment server side, the first cache unit caches the payment information, and the first delay retry unit accesses the payment server side regularly to reinitiate the payment verification request;
the payment server side is provided with a second real-time verification unit and initiates a bill verification request to a third party verification server in real time after acquiring a bill provided by the payment client side; the payment server is provided with a third party authentication server, and the payment server is provided with a first cache unit and a first delay retry unit, wherein the first cache unit caches the bill when the bill authentication request initiated by the payment server in real time does not obtain the result of bill validity or bill invalidity returned by the third party authentication server, and the first delay retry unit accesses the third party authentication server at regular time to reinitiate the bill authentication request on the cached bill.
Optionally, the first caching unit of the payment client includes a bill caching queue, and the bill caching queue uses a sorting dictionary-like structure, keys are stored in the merchant order identifier, values are stored in the bill and the payment time, and the bills are sequentially sorted according to the payment time; the bill cache queue is set with the maximum entry cache time;
the payment server is also connected with a delay queue system, the ticket retry request is added into the delay queue system, and the delay queue system sends a message when a delay set time interval arrives, so that a second delay retry unit of the payment server is prompted to reinitiate the ticket verification request for the buffered ticket.
Optionally, the payment server is provided with a database, in which order items associated with the created order are recorded, and a user and an order associated with the corresponding order item are searched for according to a merchant order identifier; the payment server side stores a bill provided by the payment client side when the payment client side sends a payment verification request to the payment server side;
the payment server side supports that all orders which are placed but not delivered by a current user and correspond to the commodity identification are inquired according to the commodity identification provided when the third party verification server returns the effective result of the bill and the merchant account information provided by the payment client side;
the payment server is also provided with a verified transaction identification library which records transaction identifications corresponding to the delivered orders and supports the inquiry of whether the transaction identifications corresponding to the current payment exist when a third party verification server returns a bill effective result;
the payment client establishes and stores a merchant order identification list which comprises merchant order identifications paid for the last times.
The payment verification method and the payment verification system have the following technical effects:
the payment client initiates IAP payment by associating the merchant order number to obtain the bill returned by the apple server, thereby ensuring the authenticity of transaction and solving the problem that the order is not associated with the bill callback. If the real-time verification initiated by the payment client fails, the payment information is cached, and the background periodically initiates the verification again so as to ensure that the bill can be successfully received by the payment server, thereby solving the problem that the bill is not delivered successfully due to the network characteristics of the client in the prior art.
The payment server side initiates bill verification to the apple server in real time according to the bill, caches the bill and the retry request if the real-time verification fails, and periodically initiates the verification request again in the background, so that the success rate of bill verification is greatly improved.
Furthermore, the payment server side of the invention enables the payment result of the user to have traceability by maintaining the database for recording the order entry; the method comprises the steps that all orders which are placed and not delivered and correspond to commodity identifications of a user are recorded, so that the abnormal situation that a merchant order identification is lost by a payment client and no associated identification exists in a list of the merchant order identification is solved; by maintaining the verified transaction identifier library, whether the order corresponding to the transaction identifier is delivered to the user is determined, and the illegal user is prevented from repeatedly using the bill to verify fraud.
Further, the payment client of the invention solves the problem of abnormal situation that the merchant order mark is lost by the callback result by establishing and persistently storing the list of the merchant order mark which is paid recently. The payment client stores the bill cache information and the list of the merchant order identifications in the iOS keychain system, and when the payment client is reloaded by the user, the payment client reads the bill cache information and the list of the merchant order identifications, so that verification can be continuously initiated on the order which is previously completed and is not successfully verified, and the abnormity caused by reloading the payment client by the user is solved.
In conclusion, the invention solves the problems encountered when the merchant interfaces the IAP payment system, reduces the bill loss possibly caused in each link in the IAP payment to the maximum extent, and has good user payment experience.
Drawings
FIG. 1 is a schematic diagram of a payment verification system of the present invention;
FIG. 2 is a schematic flow chart illustrating the processing of a payment client in the payment verification method of the present invention;
FIG. 3 is a schematic flow chart of the payment server processing the verification request with the merchant order number;
fig. 4 is a flowchart illustrating a process of the payment server processing a verification request for the presence or absence of a merchant order number.
Detailed Description
In order to make the technical means, the original characteristics, the achieved purposes and the effects of the invention easy to understand, the invention is further explained in detail with the accompanying drawings and the specific embodiments, but the scope of the invention is not limited in any way.
As shown in fig. 1, the payment verification system of the present invention relates to a payment client, a payment server, and a delay queue system, wherein the payment client is in communication connection with the payment server and an apple server, and the payment server is in communication connection with the delay queue system and the apple server.
The apple server is a server that apple company processes IAP payment initiated by the user through the iOS client and payment verification request initiated by the payment server, the delay queue system, such as mq (message queue) system that can receive service retry-later request and ensure service execution through asynchronous delay using DE L AYMQ (delay message queue) or dmq (distributed message queue) and the like.
In order to ensure the safety, the invention adopts a mode that the server side verifies the payment result. The non-anonymous account number purchase verification mode is adopted to adapt to the current common internet service model. The non-anonymous purchase is: the merchant system adopts an independent account system, maps the user to the account system owned by the merchant, and delivers the goods to the merchant account for appointed purchase when apple IAP payment is adopted.
The payment client sends an order establishing request to the payment server and records the obtained order number txId of the merchant; by initiating IAP payment in association with the merchant order number, the authenticity of the transaction may be ensured. The payment client side obtains the bill returned by the apple server after completing payment, sends a payment verification request to the payment client side in real time, inserts payment information into a bill cache queue arranged on the payment client side if multiple real-time verifications fail due to network and the like, and retries verification in a background regularly to ensure that the bill can be successfully received by the payment server side. After a payment success signal or a bill invalid signal returned by the payment server is obtained, the payment client can end the payment; and if the payment is finished based on the verification request during a certain retry, further removing the mark corresponding to the payment from the bill cache queue.
The payment server provides an API for creating the order, can receive an order creation request of the payment client to create the order, and provides the created merchant order number txId for the payment client. The payment server maintains a database, records order items of the created orders, and supports searching users and orders corresponding to certain order items according to information related to payment such as merchant order numbers txId and the like so as to confirm whether to initiate bill verification requests to the apple server.
The payment server side receives the bill provided by the payment client side when initiating the verification request to the payment client side and stores the bill; the payment server side can send a bill verification request to the apple server in real time through the agency private line, and returns an agreement signal of successful payment or invalid bill to the payment client side through a result which is returned by the apple server and indicates that the bill is valid or invalid. If the verification can not be successfully performed in real time due to network and other reasons, the payment server caches the bill to wait for relay retry, the bill retry request is added into the delay queue system, and the delay queue system sends a message when the delay set time interval is up, so that the payment server is prompted to initiate verification on the cached bill again, and the success rate of bill verification is greatly improved.
The payment server also maintains a verified transaction id library for recording the transaction id of the apple which is delivered to the user; if the result indicating that the bill is valid is returned by the apple server, the payment server side can inquire whether the apple transaction id corresponding to the payment exists in the verified transaction id library, so that whether the apple transaction id is delivered to the user is determined, and the illegal user is prevented from repeatedly using the bill to verify fraud.
The payment server side can also inquire all orders which are placed and not delivered by the current user and correspond to the commodity id through the commodity id provided by the apple server when the bill valid result is returned and according to the merchant account information provided by the payment client side, so that a verification request which is initiated by the payment client side and has no merchant order number txId is processed, the problem that the merchant order number txId information is lost by the payment client side is solved, and the abnormal condition that the merchant order number txId can be associated does not exist in a list of the merchant order numbers txId.
The invention provides a payment verification method applicable to a third-party verification server, which is used for processing verification requests initiated by a payment client and a payment server, wherein the third-party verification server can basically replace the apple server. When a payment client of a user initiates a payment request to a third-party verification server, the payment client carries a unique commodity id registered in the third-party verification server in advance. After the third party verification server confirms that the user completes payment, a payment result certificate is provided for the payment client of the user, and the exemplary payment result certificate is represented as an encrypted character string. The payment server of the merchant or the payment client of the user can use the payment result certificate to initiate a verification request to the third party verification server.
When a verification request containing a payment result certificate sent by a payment server is received, if a third party verification server confirms that the payment result certificate is valid, a mark with a valid bill is returned, and returned information contains payment time, commodity id and unique transaction id corresponding to the current purchase; otherwise, returning the invalid information of the bill. The payment server can obtain the transaction id through the payment result certificate returned by the third party verification server, and inquire the verified transaction id library to verify whether the user has repeatedly delivered the transaction id or not, or obtain the commodity id through the returned payment result certificate, so as to process the verification request without the merchant order number txId initiated by the payment client.
The following is a detailed description of one embodiment of the payment verification method of the present invention.
As shown in fig. 2, the processing flow of the payment client includes the following steps:
A1. when a user initiates payment through a payment client, an order creation request is sent out to request a payment server to create a unique merchant order number txId, and the merchant order number txId contains or is associated with order information including a user id (identification information) and an apple commodity id corresponding to the payment.
The apple commodity id refers to: when the IAP payment is used, a unique commodity id must be registered in the apple background; when payment is initiated to the apple server, the parameter is the mandatory field, and the commodity id is returned when the apple server verifies the returned result of apple payment, so that the merchant is assisted to confirm the type of the commodity purchased by the user.
A2. After the payment client records the merchant order number txId created by the payment server, an Application Programming Interface (API) of apple IAP payment is called, the current commodity id is appointed to initiate payment, and an apple server call-back result is waited.
A3. And D, the user finishes payment, the apple server recalls the result, and the payment client performs the operation of the step A4 after obtaining the bill. The bill or the script refers to an apple payment result voucher and is represented as an encrypted character string. The server or the client of the merchant can use the encrypted character string to send a verification request to the apple server, and if the verification request is valid, the apple server can provide information including the purchase time, the commodity id corresponding to the purchase and the unique apple transaction id when a result is returned. The apple transaction id is the only id of the apple server marking the transaction, and is not repeated with any other transaction.
A4. The payment client side instantly initiates a first payment verification request (three times in the example) containing the merchant order number txId to the payment server side for multiple times, and the structure of the first payment verification request comprises the merchant order number txId and a bill sequence; and if the payment server side returns an agreed payment success signal or an agreed ticket invalid signal, ending the payment.
A5. And if the initiated first payment verification requests for multiple times do not obtain the appointment signal returned by the payment server, the payment client inserts the information of the payment into the bill cache queue. The bill cache queue uses a sorting dictionary structure, keys are stored in a merchant order number txId, values are stored in bills and payment time, and sorting is carried out in sequence according to the payment time.
A6. And enabling the payment client background to start a fixed thread, and accessing the payment server to reinitiate payment verification by periodically accessing the information in the queue according to the sequence of the payment time from far to near according to the time interval from the current time to the payment time and the frequency of 10 seconds, 20 seconds, 30 seconds, 60 seconds, 5 minutes, 10 minutes, 30 minutes and 1 hour.
A7. And for a first payment verification request sent out when a certain retry is carried out, if the payment server side returns a payment success signal or a bill invalid signal, the payment is finished, and the payment client side removes a mark corresponding to the payment from the bill cache queue. To avoid backlog, the maximum entry buffering time in the ticket buffer queue is 7 days, considering that 99% of users do not have more than 100 IAPs occurring within 7 days.
A8. When the payment client is awakened by the user, it is executed as step a6.
As shown in fig. 3, in the payment verification method of the present invention, the processing flow of the payment server includes the following steps:
B1. the payment server provides an API for creating orders, receives an order creation request of the payment client to create the orders, provides the created merchant order number txId for the payment client, and writes order entries into the database.
B2. And when a first payment verification request containing a merchant order number txId and initiated by a payment client is received, searching a user and an order corresponding to an order entry.
B3. And if the corresponding user and the order exist, the payment server initiates a first bill verification request to the apple server, wherein the first bill verification request comprises a bill obtained from the apple server after the payment client completes payment.
B4. The payment server side obtains a bill return result of the apple server, and if the result shows that the bill is invalid, bill invalid information of the payment client side is returned; if the result shows that the bill is valid, the apple transaction id of the payment is recorded, and meanwhile, a verified transaction id library is inquired.
B5. If the verified transaction id library does not have the current apple transaction id, marking that the order delivery is successful, returning successful payment information of the client, adding the apple transaction id into the verified transaction id library, and if not, returning that the bill is invalid, thereby avoiding that an illegal user repeatedly uses the bill to verify fraud.
B6. And if the payment server does not obtain the bill return result of the apple server due to network reasons and the like after the step B3, when the bill return result cannot be successfully verified, adding a bill retry request into a delay queue system for delayed verification, wherein the delay is set to be 5 seconds later, 10 seconds later, 20 seconds later, 60 seconds later, 5 minutes later, 1 hour later, 1 day later and 1 day later in a cycle. The retry interval set by the delay is from dense to sparse, so that the balance of user experience and system performance can be ensured. After a certain retry is successful, the payment server marks that the order is successful and delivers the goods to the user; and after the payment client side is put into the delay queue system, the bill invalid information is returned to the payment client side.
Exception handling in which single ring segments are easily removed:
the payment client builds a list containing the merchant order numbers txId for the last several payments and persists in the payment client. Generally speaking, the normal callback result of the apple server carries the merchant order number txId, so that the client binds the routine executed on behalf of the apple server in the callback. In this embodiment, if the result of the apple server calling back the payment client loses the information of the merchant order number txId, the payment client searches the list, takes one merchant order number txId from the list, writes the merchant order number txId into the call-back result for binding, and then starts to execute from step a4 of the processing flow, and deletes the currently bound merchant order number txId from the list. The rule for taking a merchant order number txId from the list may be: and taking the order according to the time of storing the order number txId of the merchant, and adopting a principle of first storing and first taking.
Assuming that the user payment is completed without successful verification, the payment client APP is deleted and subsequently the APP is reinstalled. The payment client stores the list of the bill caching queue and the merchant order number txId into an iOS keyhain system; when the user reinstalls the APP, the information can be continuously read from the keyhain for verification processing.
Assuming that the payment client loses the information of the merchant order number txId and no merchant order number txId in the list of the merchant order number txId can be associated, the payment client initiates a second payment verification request without the merchant order number txId to the payment server, wherein the second payment verification request comprises merchant account information and a bill sequence.
As shown in fig. 4, when the payment server processes the second payment verification request without the merchant order number txId, the method includes the following steps:
C1. and when the payment server receives a second payment verification request without the merchant order number txId, initiating a second bill verification request to the apple server, wherein the second bill verification request comprises a bill obtained from the apple server after the payment client finishes payment.
C2. The payment server side obtains a bill return result of the apple server, and if the result shows that the bill is invalid, bill invalid information of the payment client side is returned; if the result shows that the bill is valid, the apple transaction id of the payment is recorded, and step C3 is executed.
C3. And after obtaining the commodity id from the bill return result, the payment server side inquires all orders which are placed and not delivered by the current user and correspond to the commodity id according to the merchant account information. If there are no orders placed that have not been shipped, the return ticket is invalid and the customer and ticket are logged for future use by the customer in response to the customer complaints.
C4. If the current user has orders corresponding to the item id that have been placed but not shipped, the latest order is searched.
C5. And inquiring the verified transaction id library according to the recorded apple transaction id.
C6. If the current apple transaction id does not exist in the database, setting the latest order as a delivery state, completing delivery, returning successful payment information of the client, and adding the apple transaction id into the verified transaction id database; otherwise, returning the invalid information of the bill.
C7. And if the payment server does not acquire the bill return result of the apple server due to network reasons and the like after the step C1, retrying the bill to enter a delay queue system for delay verification, wherein the delay is set to be 5 seconds later, 10 seconds later, 20 seconds later, 60 seconds later, 5 minutes later, 1 hour later, 1 day later and 1 day later in circulation. After a certain retry is successful, the payment server marks that the order is successful and delivers the goods to the user; and after the payment client enters the delay queue system, returning the invalid bill information to the payment client.
While the present invention has been described in detail with reference to the preferred embodiments, it should be understood that the above description should not be taken as limiting the invention. Various modifications and alterations to this invention will become apparent to those skilled in the art upon reading the foregoing description. Accordingly, the scope of the invention should be determined from the following claims.
Claims (15)
1. A payment verification method, characterized in that,
when a user initiates payment, a payment client requests and obtains a merchant order identification established by a payment server, wherein order information associated with the merchant order identification comprises a user identification and a commodity identification corresponding to the payment;
the payment client associates the merchant order identification when initiating payment, and obtains a bill returned by the third party verification server as a payment result certificate after the user completes payment;
the payment client side initiates at least one payment verification request to the payment server side in real time after receiving the bill, if the agreement signal returned by the payment server is not obtained, the payment client side caches the information of the payment, and the payment server side is accessed regularly to initiate the payment verification request again for the payment.
2. The payment verification method of claim 1,
the payment verification request comprises a merchant order identification and a bill sequence; or, the payment verification request includes merchant account information and a ticket sequence.
3. The payment verification method of claim 1,
the payment client side initiates any payment verification request in real time, and if an appointment signal returned by the payment server side is received, the payment client side ends the payment;
if the payment client side receives an appointed signal returned by the payment server side, the payment client side finishes the payment, and a mark corresponding to the payment is removed from a cache;
the appointment signal is a payment success signal or a bill invalidation signal;
and when the payment client is awakened by the user, the operation of reinitiating the payment verification request is executed regularly.
4. The payment verification method of claim 1,
the payment client caches the information of the payment through a bill cache queue;
the bill cache queue uses a sorting dictionary structure, keys are stored in the merchant order identification, values are stored in the bill and the payment time, and sorting is carried out in sequence according to the payment time; the bill buffer queue is set with the maximum entry buffer time.
5. The payment verification method of claim 1 or 4,
and the payment client background starts a fixed thread, and periodically initiates a payment verification request to the payment server based on the cached payment information of this time in the sequence of the payment time from far to near according to the increasing frequency of the time interval from the current time to the payment time.
6. The payment verification method of claim 1,
the payment client establishes and stores a merchant order identification list which comprises merchant order identifications paid for the last times;
after the user finishes payment, if the obtained information returned by the third-party verification server does not contain the merchant order identification, the payment client searches the binding information of the merchant order identification one by one, executes the operation of initiating at least one payment verification request to the payment server in real time, and deletes the currently bound merchant order identification from the merchant order identification list.
7. The payment verification method of claim 4,
the payment client establishes and stores a merchant order identification list which comprises merchant order identifications paid for the last times; the third party authentication server is an apple server;
the payment client stores the bill caching queue and the merchant order identification list into the iOS keyhain system; when the user reinstalls the payment client, the bill cache queue and the merchant order identification list are read from the keyhide, and the order which is not finished with payment verification before the payment client is deleted is continuously processed.
8. A payment verification method, characterized in that,
the payment server side creates an order according to a request initiated by a payment client side when a user pays, and sends the created merchant order identification to the payment client side; the order information associated with the merchant order mark comprises a user mark and a commodity mark corresponding to the payment;
the payment server receives a first payment verification request initiated by the payment client, and initiates a first bill verification request to a third party verification server in real time when finding a user and an order corresponding to the merchant order identification; or when the payment server receives a second payment verification request initiated by the payment client, the payment server initiates a second bill verification request to a third party verification server in real time;
wherein the first bill validation request or the second bill validation request comprises a bill obtained by the payment client from a third party validation server as a payment result voucher; the first payment verification request comprises merchant identification information and a bill sequence; the second payment verification request comprises merchant account information and a bill sequence;
and if the bill return result of the third party verification server is not obtained, the payment server caches the bill, and periodically accesses the third party verification server to reinitiate the first bill verification request or the second bill verification request for the cached bill.
9. The payment verification method of claim 8,
the payment server side initiates a first bill verification request to a third party verification server according to a first payment verification request initiated or reinitiated by the payment client side in real time, and when the payment server side acquires a bill return result of the third party verification server, if the bill return result shows that the bill is invalid, the payment server side returns bill invalid information to the payment client side;
if the bill returned result shows that the bill is valid, the payment server records the transaction identifier of the current time, and inquires whether the verified transaction identifier library has the current transaction identifier:
if the verified transaction identification library does not have the current transaction identification, the payment server side adds the current transaction identification into the verified transaction identification library, sets the order delivery state of the current order and returns payment success information to the payment client side; and if the current transaction identification exists in the verified transaction identification library, the payment server side returns the invalid bill information to the payment client side.
10. The payment verification method of claim 8,
the payment server side initiates a second bill verification request to a third party verification server according to a second payment verification request initiated or reinitiated by the payment client side in real time, and when the payment server side acquires a bill return result of the third party verification server, if the bill return result shows that the bill is invalid, the payment server side returns bill invalid information to the payment client side;
if the bill return result shows that the bill is valid, the payment server side obtains the commodity identification of the current time from the bill return result, and inquires all orders which are placed and not delivered by the current user and correspond to the commodity identification according to the merchant account information; the payment server side obtains the transaction identification of the time from the bill return result and inquires whether the verified transaction identification library has the current transaction identification;
if the current user does not have an order which is placed but not delivered, the payment server side returns bill invalid information to the payment client side, and logs record the user and the bill corresponding to the order; if the current user has orders which are placed and not delivered and correspond to the commodity identification, searching the latest order;
if the verified transaction identification library does not have the current transaction identification, the payment server side adds the current transaction identification into the verified transaction identification library, sets the latest order as an order delivery state, and returns payment success information to the payment client side; and if the current transaction identification exists in the verified transaction identification library, the payment server side returns the invalid bill information to the payment client side.
11. Payment verification method according to any one of claims 8 to 10,
the payment server side adds the ticket retry request into a delay queue system, sets a retry interval from secret to sparse to perform delay verification, and returns the ticket invalid information to the payment client side; and the delay queue system sends a message when a set time interval arrives to prompt the payment server to reinitiate the first bill verification request or the second bill verification request.
12. A payment verification method, characterized in that,
the third party verification server receives and processes a payment request initiated by a user through a payment client, wherein the payment request is associated with a merchant order identifier created by a payment server requested by the payment client; the order information associated with the merchant order mark comprises a user mark and a commodity mark corresponding to the payment; the third party verification server provides a bill serving as a payment result certificate to a payment client of the user after confirming that the user completes payment;
when the third party verification server receives a bill verification request containing a bill sent by the payment server, if the bill is confirmed to be invalid, the third party verification server returns bill invalid information to the payment server; if the bill is confirmed to be valid, the third party verification server returns bill valid information, payment time, a commodity identifier and a transaction identifier to the payment server, so that the payment server can inquire a verified transaction identifier library through the returned transaction identifier to verify whether the order corresponding to the transaction identifier is repeatedly delivered, and inquire all orders which are placed and not delivered by the current user and correspond to the commodity identifier through the returned commodity identifier and merchant account information provided by the payment client.
13. A payment verification system is characterized by comprising a payment client, a payment server and a third party verification server;
the payment server is provided with an interface for creating an order, receives an order creation request of the payment client to create the order, and sends a created merchant order identifier to the payment client, so that the payment client can associate the merchant order identifier when initiating a payment request to the third-party verification server, and obtains a bill returned by the third-party verification server as a payment result certificate after the user completes payment; the order information associated with the merchant order mark comprises a user mark and a commodity mark corresponding to the payment;
the payment client side is provided with a first real-time verification unit and initiates a payment verification request to the payment server side in real time after acquiring the bill provided by the third-party verification server; the payment server is provided with a payment server side, and the payment server side is provided with a first cache unit and a first delay retry unit, wherein when the payment verification request initiated by the payment client side in real time does not obtain payment success information or bill invalid information returned by the payment server side, the first cache unit caches the payment information, and the first delay retry unit accesses the payment server side regularly to reinitiate the payment verification request;
the payment server side is provided with a second real-time verification unit and initiates a bill verification request to a third party verification server in real time after acquiring a bill provided by the payment client side; the payment server is provided with a third party authentication server, and the payment server is provided with a first cache unit and a first delay retry unit, wherein the first cache unit caches the bill when the bill authentication request initiated by the payment server in real time does not obtain the result of bill validity or bill invalidity returned by the third party authentication server, and the first delay retry unit accesses the third party authentication server at regular time to reinitiate the bill authentication request on the cached bill.
14. The payment verification system of claim 13,
the first cache unit of the payment client comprises a bill cache queue, the bill cache queue uses a sorting dictionary structure, keys are stored in merchant order identifications, values are stored in bills and payment time, and sequencing is carried out in sequence according to the payment time; the bill cache queue is set with the maximum entry cache time;
the payment server is also connected with a delay queue system, the ticket retry request is added into the delay queue system, and the delay queue system sends a message when a delay set time interval arrives, so that a second delay retry unit of the payment server is prompted to reinitiate the ticket verification request for the buffered ticket.
15. The payment verification system of claim 13,
the payment server is provided with a database, wherein order items associated with the created order are recorded, and a user and an order associated with the corresponding order items are searched according to a merchant order identifier; the payment server side stores a bill provided by the payment client side when the payment client side sends a payment verification request to the payment server side;
the payment server side supports that all orders which are placed but not delivered by a current user and correspond to the commodity identification are inquired according to the commodity identification provided when the third party verification server returns the effective result of the bill and the merchant account information provided by the payment client side;
the payment server is also provided with a verified transaction identification library which records transaction identifications corresponding to the delivered orders and supports the inquiry of whether the transaction identifications corresponding to the current payment exist when a third party verification server returns a bill effective result;
the payment client establishes and stores a merchant order identification list which comprises merchant order identifications paid for the last times.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910097732.XA CN111507724B (en) | 2019-01-31 | 2019-01-31 | Payment verification method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910097732.XA CN111507724B (en) | 2019-01-31 | 2019-01-31 | Payment verification method and system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111507724A true CN111507724A (en) | 2020-08-07 |
| CN111507724B CN111507724B (en) | 2023-12-26 |
Family
ID=71870828
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910097732.XA Active CN111507724B (en) | 2019-01-31 | 2019-01-31 | Payment verification method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111507724B (en) |
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112967051A (en) * | 2021-03-16 | 2021-06-15 | 宝宝巴士股份有限公司 | Apple purchase payment method and device |
| CN113256276A (en) * | 2021-06-07 | 2021-08-13 | 深圳华南城网科技有限公司 | Payment state maintenance method and system based on order call-back |
| CN113344680A (en) * | 2021-07-02 | 2021-09-03 | 云镝智慧科技有限公司 | Order processing method, related device, equipment and storage medium |
| CN113379406A (en) * | 2021-05-20 | 2021-09-10 | 大河(深圳)信息有限公司 | Transaction method between merchant terminal and third-party payment platform |
| CN113643036A (en) * | 2021-07-01 | 2021-11-12 | 深圳市晨北科技有限公司 | Payment verification method, computer device and readable storage medium |
| CN114511365A (en) * | 2022-02-16 | 2022-05-17 | 中国银联股份有限公司 | Bill collection method and equipment |
| CN114519572A (en) * | 2022-01-30 | 2022-05-20 | 上海幻电信息科技有限公司 | Automatic detection method, device and system for payment link |
| CN114549000A (en) * | 2022-01-29 | 2022-05-27 | 中银金融科技有限公司 | Method and device for acquiring and sending payment verification parameters based on unified platform |
| CN115049385A (en) * | 2022-05-24 | 2022-09-13 | 福建天晴在线互动科技有限公司 | Method and system for ensuring purchase, recharge and account arrival of apples through online server |
| CN116308324A (en) * | 2023-05-23 | 2023-06-23 | 云账户技术(天津)有限公司 | Multi-merchant payment method, system, electronic device and readable storage medium |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103581106A (en) * | 2012-07-19 | 2014-02-12 | 深圳市财付通科技有限公司 | Interactive processing method and interactive processing system |
| US20140188726A1 (en) * | 2012-12-28 | 2014-07-03 | Wal-Mart Stores, Inc. | Payment validation systems and methods |
| CN105095977A (en) * | 2015-09-09 | 2015-11-25 | 拉扎斯网络科技（上海）有限公司 | Order allocation method and device |
| CN105989486A (en) * | 2015-02-15 | 2016-10-05 | 广州市动景计算机科技有限公司 | Payment security processing method, device and system |
| CN106228367A (en) * | 2016-07-27 | 2016-12-14 | 北京奇虎科技有限公司 | The method and apparatus of payment verification |
| CN106570688A (en) * | 2016-10-31 | 2017-04-19 | 无锡坦程物联网股份有限公司 | Transaction payment implementation method based on mobile environment |
-
2019
- 2019-01-31 CN CN201910097732.XA patent/CN111507724B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103581106A (en) * | 2012-07-19 | 2014-02-12 | 深圳市财付通科技有限公司 | Interactive processing method and interactive processing system |
| US20140188726A1 (en) * | 2012-12-28 | 2014-07-03 | Wal-Mart Stores, Inc. | Payment validation systems and methods |
| CN105989486A (en) * | 2015-02-15 | 2016-10-05 | 广州市动景计算机科技有限公司 | Payment security processing method, device and system |
| CN105095977A (en) * | 2015-09-09 | 2015-11-25 | 拉扎斯网络科技（上海）有限公司 | Order allocation method and device |
| CN106228367A (en) * | 2016-07-27 | 2016-12-14 | 北京奇虎科技有限公司 | The method and apparatus of payment verification |
| CN106570688A (en) * | 2016-10-31 | 2017-04-19 | 无锡坦程物联网股份有限公司 | Transaction payment implementation method based on mobile environment |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112967051A (en) * | 2021-03-16 | 2021-06-15 | 宝宝巴士股份有限公司 | Apple purchase payment method and device |
| CN113379406A (en) * | 2021-05-20 | 2021-09-10 | 大河(深圳)信息有限公司 | Transaction method between merchant terminal and third-party payment platform |
| CN113256276A (en) * | 2021-06-07 | 2021-08-13 | 深圳华南城网科技有限公司 | Payment state maintenance method and system based on order call-back |
| CN113643036A (en) * | 2021-07-01 | 2021-11-12 | 深圳市晨北科技有限公司 | Payment verification method, computer device and readable storage medium |
| CN113344680A (en) * | 2021-07-02 | 2021-09-03 | 云镝智慧科技有限公司 | Order processing method, related device, equipment and storage medium |
| CN114549000A (en) * | 2022-01-29 | 2022-05-27 | 中银金融科技有限公司 | Method and device for acquiring and sending payment verification parameters based on unified platform |
| CN114519572A (en) * | 2022-01-30 | 2022-05-20 | 上海幻电信息科技有限公司 | Automatic detection method, device and system for payment link |
| CN114511365A (en) * | 2022-02-16 | 2022-05-17 | 中国银联股份有限公司 | Bill collection method and equipment |
| CN115049385A (en) * | 2022-05-24 | 2022-09-13 | 福建天晴在线互动科技有限公司 | Method and system for ensuring purchase, recharge and account arrival of apples through online server |
| CN115049385B (en) * | 2022-05-24 | 2024-05-28 | 福建天晴在线互动科技有限公司 | Method and system for guaranteeing in-apple purchase recharging and account checking through online server |
| CN116308324A (en) * | 2023-05-23 | 2023-06-23 | 云账户技术(天津)有限公司 | Multi-merchant payment method, system, electronic device and readable storage medium |
| CN116308324B (en) * | 2023-05-23 | 2023-07-21 | 云账户技术(天津)有限公司 | Multi-merchant payment method, system, electronic device and readable storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111507724B (en) | 2023-12-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111507724B (en) | Payment verification method and system | |
| US11010751B2 (en) | Performing transactions using virtual card values | |
| US9123044B2 (en) | Generation systems and methods for transaction identifiers having biometric keys associated therewith | |
| US7933835B2 (en) | Secure money transfer systems and methods using biometric keys associated therewith | |
| CN110070348B (en) | Transaction processing system and transaction processing method | |
| KR101658684B1 (en) | Payment system | |
| US20130232079A1 (en) | Token based transaction authentication | |
| US20100100482A1 (en) | Intermediate Data Generation For Transaction Processing | |
| US20150348038A1 (en) | Method and Apparatus for Money Transfer to an Account | |
| KR20150058474A (en) | System and method for providing dispute resolution for electronic payment transactions | |
| JP2010528391A5 (en) | ||
| WO2001088789A1 (en) | Order processing system and method | |
| JP2012128885A (en) | System and method for confirming financial instrument | |
| US11928687B1 (en) | Systems and methods for expediting math-based currency transactions | |
| JP5503819B2 (en) | Web terminal and bridge to support transfer of authentication data to merchant contract company for payment processing | |
| CN111523902B (en) | Electronic invoice issuing method, system, control equipment and storage medium | |
| WO2001088788A1 (en) | Electronic commerce information processing system and method | |
| US20070265861A1 (en) | High latency communication transactions in a low latency communication system | |
| CN108564354B (en) | Settlement method, service platform and server | |
| JP5812645B2 (en) | Electronic commerce system | |
| US20220417223A1 (en) | Managing Communication Of Sensitive Information | |
| WO2020046899A1 (en) | Secure payments by third parties using a processing platform in live entertainment industries | |
| JP4168656B2 (en) | Rights transfer method and system, purchase control terminal and authentication charging server in digital content charging system | |
| JP5465310B1 (en) | System and method for automatically changing settlement account for electronic record receivable | |
| AU2012200584B2 (en) | Web terminal and bridge that support passing of authentication data to acquirer for payment processing |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |