CN112150161A - Electronic ticket transaction risk management and control system and method - Google Patents
Electronic ticket transaction risk management and control system and method Download PDFInfo
- Publication number
- CN112150161A CN112150161A CN202011062737.8A CN202011062737A CN112150161A CN 112150161 A CN112150161 A CN 112150161A CN 202011062737 A CN202011062737 A CN 202011062737A CN 112150161 A CN112150161 A CN 112150161A
- Authority
- CN
- China
- Prior art keywords
- transaction
- central server
- information
- terminal
- request
- 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
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
- G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2453—Query optimisation
- G06F16/24534—Query rewriting; Transformation
- G06F16/24549—Run-time optimisation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- 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/04—Payment circuits
- G06Q20/045—Payment circuits using payment protocols involving tickets
- G06Q20/0457—Payment circuits using payment protocols involving tickets the tickets being sent electronically
-
- 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/382—Payment protocols; Details thereof insuring higher security of transaction
- G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Accounting & Taxation (AREA)
- General Engineering & Computer Science (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Software Systems (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Health & Medical Sciences (AREA)
- Finance (AREA)
- Computational Linguistics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The invention relates to the technical field of block chains, in particular to an electronic ticket transaction risk management and control system, which comprises a buyer terminal, a seller terminal, a first central server, a second central server and a third-party central server, wherein the buyer terminal is connected with the seller terminal; the first central server and the second central server are respectively in signal connection with the buyer terminal and the seller terminal, and the first central server and the second central server respectively form a corresponding regional transaction subsystem with the buyer terminal and the seller terminal which are connected with the first central server and the second central server; the first central server is used for acquiring a transaction request initiated by a buyer terminal of the regional transaction subsystem and extracting transaction object information from the transaction request, wherein the transaction object information comprises seller terminal information; the first central server is also used for judging whether the seller terminal belongs to the local area transaction subsystem according to the seller terminal information, and if so, the transaction is completed; the problem that the electronic ticket transaction security is low can be solved to this scheme of adoption.
Description
Technical Field
The invention relates to the technical field of block chains, in particular to an electronic ticket transaction risk management and control system and method.
Background
The ticket is a written certificate which is issued by a unit or a person, contains a certain value and is used for shopping or consumption; with the continuous improvement of the mobile communication network environment and the further popularization of smart phones, the application of electronic payment is becoming more important, and especially, in order to achieve better advertising and publicity effects, a shop owner issues paperless electronic tickets by using a network transaction platform has become a common financial transaction mode.
However, the conventional electronic ticket transaction system still has a certain risk that the conventional electronic ticket is recorded and calculated by a single server, and if the calculation method is cracked by a hacker, the original electronic data is possibly tampered, even reproduced and reused, so that the user rights and interests are damaged.
Therefore, there is an urgent need for a system for managing and controlling the risk of electronic ticket transaction with higher security, which can prevent data from being tampered.
Disclosure of Invention
The invention aims to provide an electronic ticket transaction risk management and control system and method, which can solve the problem of low security.
The basic scheme provided by the invention is as follows: an electronic ticket transaction risk management and control system comprises a buyer terminal, a seller terminal, a first central server, a second central server and a third-party central server;
the first central server and the second central server are respectively in signal connection with the buyer terminal and the seller terminal, and the first central server and the second central server respectively form a corresponding regional transaction subsystem with the buyer terminal and the seller terminal which are connected with the first central server and the second central server;
the first central server is used for acquiring a transaction request initiated by a buyer terminal of the regional transaction subsystem and extracting transaction object information from the transaction request, wherein the transaction object information comprises seller terminal information;
the first central server is also used for judging whether the seller terminal belongs to the local area transaction subsystem according to the seller terminal information, and if so, the transaction is completed; otherwise, judging whether the regional transaction subsystem can achieve a transaction similar to the transaction request, if so, initiating a supplementary notification to the buyer terminal, acquiring reason information fed back by the buyer terminal according to the supplementary notification, and forwarding the reason information to another terminal of the regional transaction subsystem; if not, a transaction is concluded;
the first central server is also used for receiving confirmation information sent by the other terminal according to the reason information, judging whether the reason information is true or not according to the confirmation information, and if not, the transaction is failed; if yes, the transaction request is sent to a second central server for consensus judgment; if the transaction request passes the consensus judgment, broadcasting the transaction request to a third-party central server;
the first central server is also used for obtaining a risk evaluation result sent by the third-party central service, and if any third-party central server does not broadcast risk information within preset time, the uplink of the transaction is sealed and stored according to a block chain algorithm; if any third-party central server broadcasts that the transaction has risks, risk information is broadcasted, and the transaction is cancelled.
The working principle and the advantages of the invention are as follows:
in the process of electronic ticket transaction, a transaction request initiated by a local user side is obtained firstly, and as the transaction mainly relates to a buyer and a seller, the transaction request comprises an initiator and a corresponding transaction object, so that the transaction can be completed according to the initiator; the transaction object information can be extracted from the transaction request, whether the transaction object belongs to the local area or not is judged, if not, the transaction request initiated by the user end of the local area is a cross-area transaction, risk control is required, namely whether the local area can achieve similar transactions or not is judged, and if not, the initiation of the transaction belongs to conventional selection; on the contrary, if the local area can achieve similar transaction, the initiation of the transaction is an abnormal event, and more strict risk control needs to be executed, namely the user end of the local area is required to supplement reasons, a confirmation request is sent to another terminal in the local area, after the condition is confirmed, the transaction request is verified through the central server of the buyer and the seller, the transaction is broadcasted to the third-party server after the verification is passed, and the third-party server starts to judge the transaction risk after receiving the broadcast; finally, acquiring a risk evaluation result sent by the third-party center service, judging whether any third-party center server broadcasts the transaction in a preset time and has a risk, if so, broadcasting risk information and canceling the transaction, if not, indicating that the wind control judgment is qualified, executing the transaction, and sealing the chain according to a block chain algorithm;
the beneficial effect of this scheme does: 1. the cross-region transaction of the electronic ticket can be completed through the plurality of central servers arranged in each region, the selection range of users can be widened, the transaction delay of the electronic ticket due to large data volume in a transaction peak period is avoided, and the transaction efficiency of the electronic ticket is accelerated;
2. aiming at the cross-district transaction which can be achieved in the local district, the system can carry out strict risk control, namely, the validity of the transaction can be admitted by the whole network through checking and supplementing reasons, server consensus judgment of buyers and sellers and risk broadcasting participated by a third-party center server, the characteristic that a block chain cannot be tampered with and the safety coefficient is high is realized, the trust problem is solved, and the trust cost is reduced;
3. the transaction request for achieving the cross-region transaction is subjected to uplink sealing, so that the transaction information cannot be tampered, and the safety of data storage can be improved.
Further, the first central server is further configured to encrypt the transaction request according to hash operation, calculate a corresponding hash value, store the hash value in a database, and generate a relational mapping table between the transaction request and the hash value.
Has the advantages that: the Hash operation is mainly to calculate a string of information through a Hash function in cryptography, and the obtained result is a character string with fixed number of bits, so that the information can be simplified, and a Hash value can be obtained in limited time and limited resources; and the method also has certain secrecy, so that the transaction information cannot be tampered.
Further, the first central server is further configured to obtain a protocol address of the transaction object, and determine whether the transaction object belongs to the local area according to the protocol address.
Has the advantages that: the method aims to provide a specific mode for judging whether the electronic ticket transaction occurs in the same area, namely, the area to which the server belongs can be easily and directly found by extracting the protocol addresses of the two servers.
Further, the first central server also comprises a storage module used for storing historical transaction information in advance; the first central server is also used for extracting the transaction name of the transaction request, inquiring whether historical transaction information identical to the transaction name exists in the storage module according to a keyword matching algorithm, and if so, judging that the local area can achieve a transaction similar to the transaction request.
Has the advantages that: by adopting the scheme, the data volume of the storage module can be expanded by continuously storing the transaction requests of the completed transactions as historical transaction information; the historical transaction information similar to the transaction request at this time can be conveniently found out from the storage module subsequently.
Further, the regional transaction subsystem also comprises a transaction pool which is used for receiving and storing the transaction request which passes the validity verification; the regional transaction subsystem is also used for inquiring the transaction requests in the transaction pool according to a preset time period until two same transaction requests are found in the transaction pool, and then stopping continuous inquiry.
Has the advantages that: in the scheme, the transaction request is stored in the transaction pool after being verified by the buyer and the seller, and then the transaction information which passes the validity verification is inquired in the transaction pool according to the preset time period, so that the real-time inquiry is not needed, and the system load is reduced.
Further, the regional transaction subsystem is further configured to record query times, and if the query times are greater than a preset time threshold, extend a time period.
Has the advantages that: the time period of each central server traversing the transaction pool can be adjusted according to the ground, so that the query times are reduced, invalid query operation is avoided, and the system computation amount is reduced.
The invention also provides an electronic ticket transaction risk control method, which comprises the following steps:
s1, acquiring a transaction request initiated by a buyer terminal of the regional transaction subsystem, and extracting transaction object information from the transaction request, wherein the transaction object information comprises seller terminal information;
s2, judging whether the seller terminal belongs to the local area transaction subsystem according to the seller terminal information, and if so, completing the transaction; otherwise, judging whether the regional transaction subsystem can achieve a transaction similar to the transaction request, if so, initiating a supplementary notification to the buyer terminal, acquiring reason information fed back by the buyer terminal according to the supplementary notification, and forwarding the reason information to another terminal of the regional transaction subsystem; if not, a transaction is concluded;
s3, receiving confirmation information sent by another terminal according to the reason information, and judging whether the reason information is true according to the confirmation information, if not, the transaction is failed; if yes, the transaction request is sent to a second central server for consensus judgment; if the transaction request passes the consensus judgment, broadcasting the transaction request to a third-party central server;
s4, obtaining a risk evaluation result sent by the third-party center service, and if no third-party center server broadcasts risk information within a preset time, sealing the uplink of the transaction according to a block chain algorithm; if any third-party central server broadcasts that the transaction has risks, risk information is broadcasted, and the transaction is cancelled.
Has the advantages that: by adopting the scheme, the cross-area transaction of the electronic ticket can be completed through the plurality of central servers arranged in each area, the selection range of users can be widened, the transaction delay of the electronic ticket caused by large data volume in a transaction peak period is avoided, and the transaction efficiency of the electronic ticket is accelerated; secondly, aiming at the cross-regional transaction which can be achieved in the local region, the system can carry out strict risk control, namely the effectiveness of the transaction can be admitted in the whole network through verification and supplement reasons, server consensus judgment of buyers and sellers and risk broadcasting participated by a third-party center server, the characteristic that a block chain cannot be tampered with and the safety factor is high is realized, the trust problem is solved, and the trust cost is reduced; and finally, the transaction request for achieving the trans-regional transaction is subjected to uplink sealing, so that the transaction information cannot be tampered, and the safety of data storage can be improved.
Further, the step S4 specifically includes step S41, the transaction request is encrypted according to the hash operation, a corresponding hash value is obtained through calculation, and the hash value is stored in the database, so as to generate a relation mapping table between the transaction request and the hash value.
Has the advantages that: by adopting the Hash operation to process the transaction information, the information can be simplified, and a Hash value can be obtained in limited time and limited resources; and the method also has certain secrecy, so that the transaction information cannot be tampered.
Further, the step S2 specifically includes the step S21 of obtaining a protocol address of the transaction object, and determining whether the transaction object belongs to the local area according to the protocol address.
Has the advantages that: a specific way of determining whether an electronic ticket transaction occurs in the same area can be provided.
Further, the step S3 specifically includes step S31, accepting the transaction request passing the validity verification, and storing the transaction request in a transaction pool; s32, inquiring the transaction requests in the transaction pool according to a preset time period until two identical transaction requests are found in the transaction pool, and stopping continuous inquiry; and S33, recording the query times, and if the query times are larger than a preset time threshold, prolonging the time period.
Has the advantages that: the transaction information in the transaction pool is inquired according to the number of times by setting a time period, and real-time inquiry is not needed, so that the operation load of the system can be reduced; in addition, the time period is adjusted through the actual condition, the query times are reduced, invalid query operation can be avoided, and the system operation amount is reduced.
Drawings
Fig. 1 is a flowchart illustrating a system and a method for risk management of electronic ticket transactions according to a first embodiment of the present invention.
Detailed Description
The following is further detailed by the specific embodiments:
example one
An electronic ticket transaction risk management and control system comprises a buyer terminal, a seller terminal, a first central server, a second central server and a third-party central server;
the first central server and the second central server are respectively in signal connection with the buyer terminal and the seller terminal, and the first central server and the second central server respectively form a corresponding regional transaction subsystem with the buyer terminal and the seller terminal which are connected with the first central server and the second central server;
the first central server is used for acquiring a transaction request initiated by a buyer terminal of the regional transaction subsystem and extracting transaction object information from the transaction request, wherein the transaction object information comprises seller terminal information;
the first central server is also used for judging whether the seller terminal belongs to the local area transaction subsystem according to the seller terminal information, and if so, the transaction is completed; otherwise, judging whether the regional transaction subsystem can achieve a transaction similar to the transaction request, if so, initiating a supplementary notification to the buyer terminal, acquiring reason information fed back by the buyer terminal according to the supplementary notification, and forwarding the reason information to another terminal of the regional transaction subsystem; if not, a transaction is concluded;
specifically, the transaction mainly involves both buyer and seller, so the transaction request includes the initiator and the corresponding transaction object, and the information comes from the transaction request and can be known through the transaction request; in this embodiment, the first central server is further configured to obtain a protocol address of the transaction object, and determine whether the transaction object belongs to the local area according to the protocol address; the protocol address is similar to the IP address of a server in the prior art, the protocol address of a central server can be synchronously obtained in the ticket transaction process, whether a transaction object belongs to a local area or not is judged according to the specific protocol address of the server, and the specific server to which the transaction object belongs can be positioned, and the technology is the prior art and is not described herein again; particularly, if the transaction object is judged not to belong to the local area, the transaction request initiated by the buyer user side is indicated to be a cross-area transaction, and the risk management and control are required to be carried out on the transaction request; whether the regional transaction subsystem can achieve similar transactions needs to be judged, so that the first central server further comprises a storage module for storing historical transaction information in advance in the embodiment; the first central server is also used for extracting the transaction name of the transaction request, inquiring whether historical transaction information which is the same as the transaction name exists in the storage module according to a keyword matching algorithm, and if so, judging that the local area can achieve a transaction similar to the transaction request; the storage module is screened according to the name of the transaction by the existing keyword matching technology, similar to a database searching function, whether similar transaction information exists in the local area can be judged by adopting the method, and whether the transaction similar to the transaction request can be achieved in the local area is further judged; the purpose of this is to: if the transaction cannot be achieved in the local area, the initiation of the transaction is indicated to belong to a conventional choice; on the contrary, if the local area can achieve similar transaction, it means that the initiation of the transaction is an abnormal event, and a more strict risk management and control need to be performed, that is, a supplement reason is required for the buyer terminal, and the supplement reason is specifically to obtain the text information entered by the user terminal in the text box.
The other terminal of the regional transaction subsystem is mainly responsible for checking and confirming reason information, and after the buyer terminal sends the text information, the text information is synchronously forwarded to the terminal;
the first central server is also used for receiving confirmation information sent by the other terminal according to the reason information, judging whether the reason information is true or not according to the confirmation information, and if not, the transaction is failed; if yes, the transaction request is sent to a second central server for consensus judgment; if the transaction request passes the consensus judgment, broadcasting the transaction request to a third-party central server; specifically, in the embodiment, an operator mainly uses another terminal to check reason information, and selects an actual button or a non-actual button to perform information confirmation feedback according to actual conditions; in addition, the consensus judgment can be understood as judging whether the two parties agree literally, and since the first central server is only the central server associated with the buyer terminal, in order to ensure that the two parties agree, the transaction request needs to be forwarded to the second central server associated with the seller terminal; the consensus judgment in the scheme mainly refers to that the first central server and the second central server verify the validity of the transaction request, and the validity verification mode mainly comprises the steps of collecting fingerprint information or signatures of central servers (the first central server and the second central server) of both the buyer and the seller to confirm; if both sides 'central server pass the legality verification, the transaction request information is recorded and propagated in the third party's central server.
The first central server is also used for obtaining a risk evaluation result sent by the third-party central service, and if any third-party central server does not broadcast risk information within preset time, the uplink of the transaction is sealed and stored according to a block chain algorithm; if any third-party central server broadcasts that the transaction has risks, risk information is broadcasted, and the transaction is cancelled. Similar to the existing block chain whole-network broadcast, each message is broadcast in the whole network and is broadcast to each node, so that the whole network can acknowledge validity, and the trust problem can be solved. In this embodiment, since most of the third-party central servers record the information of the transaction request, if there is a risk in the transaction broadcast by one third-party central server, specifically, the decision logic for performing risk decision through the third-party central server is mainly: if the information or the transaction state of both transaction sides reported by the single or multiple third-party central servers is not consistent with the whole, the information of a certain node is falsified, the transaction has a safety problem, and the transaction is cancelled; in the embodiment, in order to acquire more risk broadcasts of the third-party central server as much as possible, the preset time is adjusted to 3 minutes, and although the broadcast mechanism occupies a long time and has certain efficiency problems, the method is fair and has higher safety; on the contrary, if the risk evaluation results sent by all the third-party servers in the time period have no abnormal report, the first central server encrypts the transaction request according to the hash operation, calculates the corresponding hash value, stores the hash value into the database, and generates a relational mapping table of the transaction request and the hash value. The hash algorithm is the most used algorithm in the blockchain, and is widely used for constructing blocks and confirming the integrity of transactions.
A basic execution flow of the above system is shown in fig. 1, and the basic method specifically includes the following steps:
s1, acquiring a transaction request initiated by a buyer terminal of the regional transaction subsystem, and extracting transaction object information from the transaction request, wherein the transaction object information comprises seller terminal information;
s2, judging whether the seller terminal belongs to the local area transaction subsystem according to the seller terminal information, and if so, completing the transaction; otherwise, judging whether the regional transaction subsystem can achieve a transaction similar to the transaction request, if so, initiating a supplementary notification to the buyer terminal, acquiring reason information fed back by the buyer terminal according to the supplementary notification, and forwarding the reason information to another terminal of the regional transaction subsystem; if not, a transaction is concluded; in this embodiment, the step S2 further includes step S21, obtaining a protocol address of the transaction object, and determining whether the transaction object belongs to the local area according to the protocol address;
s3, receiving confirmation information sent by another terminal according to the reason information, and judging whether the reason information is true according to the confirmation information, if not, the transaction is failed; if yes, the transaction request is sent to a second central server for consensus judgment; if the transaction request passes the consensus judgment, broadcasting the transaction request to a third-party central server;
s4, obtaining a risk evaluation result sent by the third-party center service, and if no third-party center server broadcasts risk information within a preset time, sealing the uplink of the transaction according to a block chain algorithm; if any third-party central server broadcasts that the transaction has risks, risk information is broadcasted, and the transaction is cancelled. Specifically, the step S4 further includes step S41, the transaction request is encrypted according to the hash operation, a corresponding hash value is obtained through calculation, and the hash value is stored in the database, so as to generate a relation mapping table between the transaction request and the hash value.
Example two
Compared with the first embodiment, the difference is that the regional transaction subsystem further comprises a transaction pool for receiving and storing the transaction request which passes the validity verification; the regional transaction subsystem is also used for inquiring the transaction requests in the transaction pool according to a preset time period until two same transaction requests are found in the transaction pool, and then stopping continuous inquiry; the preset time period is 60s, which indicates that the regional transaction subsystem can automatically execute the query operation of the transaction pool once in 60s, judge whether two identical transaction information exist in the transaction pool, and stop querying at the moment; in another embodiment, the regional transaction subsystem is further configured to record query times, and if the query times are greater than a preset time threshold, extend a time period; and the set time threshold is specifically 5 times, for example, when a certain transaction information query is executed, the regional transaction subsystem a performs 6 queries, and the time period is adjusted to 70s to execute one query.
On the basis of the first embodiment, the electronic ticket transaction wind control management method specifically includes step S31 of receiving a transaction request passing validity verification and storing the transaction request in a transaction pool in step S3; s32, inquiring the transaction requests in the transaction pool according to a preset time period until two identical transaction requests are found in the transaction pool, and stopping continuous inquiry; and S33, recording the query times, and if the query times are larger than a preset time threshold, prolonging the time period.
EXAMPLE III
Compared with the first embodiment, the difference is that the system further comprises a sealing module, wherein the sealing module is used for encrypting the transaction request according to hash operation, calculating to obtain a first hash value, generating a relational mapping table of the transaction request and the first hash value, and respectively storing the relational mapping table into the first central server and the second central server; the transaction request comprises information of both transaction parties and transaction detail records. A sealing module, configured to record storage time of the mapping relation table in the first central server and the second central server, and if the storage time is greater than a preset time threshold (set to 3 days in this embodiment), only keep information of both parties of the transaction from a transaction detail record in the transaction request, and generate a new transaction request; and encrypting the new transaction request according to the hash operation, calculating to obtain a second hash value, generating a relational mapping table of the new transaction request and the second hash value, and storing the relational mapping table in the third central server.
According to the scheme, the transaction detail records are still kept and the corresponding hash values are calculated in the first central server and the second central server which are subjected to transaction operation, so that the integrity of data can be ensured, and the subsequent description and calling of the database are facilitated; and only the information of both transaction parties is stored in the third-party central server as a simplified transaction request, and the hash value is calculated instead of storing the transaction details which occupy larger space, so that the storage space of the central server can be saved.
In the prior art, after the transaction information is linked up synchronously, the ticket transaction information is backed up in all third-party central servers; and along with the continuous progress of the transaction, a large amount of transaction information can be accumulated in the third-party server, and a large amount of storage space is occupied. By adopting the scheme, the third-party central server which does not participate in the transaction does not store specific transaction details, only stores simple transaction object information, and can be convenient for subsequent extraction and identification of transaction information through the reference information, so that the storage space of the system can be saved.
The foregoing is merely an example of the present invention, and common general knowledge in the field of known specific structures and characteristics is not described herein in any greater extent than that known in the art at the filing date or prior to the priority date of the application, so that those skilled in the art can now appreciate that all of the above-described techniques in this field and have the ability to apply routine experimentation before this date can be combined with one or more of the present teachings to complete and implement the present invention, and that certain typical known structures or known methods do not pose any impediments to the implementation of the present invention by those skilled in the art. It should be noted that, for those skilled in the art, without departing from the structure of the present invention, several changes and modifications can be made, which should also be regarded as the protection scope of the present invention, and these will not affect the effect of the implementation of the present invention and the practicability of the patent. The scope of the claims of the present application shall be determined by the contents of the claims, and the description of the embodiments and the like in the specification shall be used to explain the contents of the claims.
Claims (10)
1. An electronic ticket transaction risk management and control system is characterized by comprising a buyer terminal, a seller terminal, a first central server, a second central server and a third-party central server;
the first central server and the second central server are respectively in signal connection with the buyer terminal and the seller terminal, and the first central server and the second central server respectively form a corresponding regional transaction subsystem with the buyer terminal and the seller terminal which are connected with the first central server and the second central server;
the first central server is used for acquiring a transaction request initiated by a buyer terminal of the regional transaction subsystem and extracting transaction object information from the transaction request, wherein the transaction object information comprises seller terminal information;
the first central server is also used for judging whether the seller terminal belongs to the local area transaction subsystem according to the seller terminal information, and if so, the transaction is completed; otherwise, judging whether the regional transaction subsystem can achieve a transaction similar to the transaction request, if so, initiating a supplementary notification to the buyer terminal, acquiring reason information fed back by the buyer terminal according to the supplementary notification, and forwarding the reason information to another terminal of the regional transaction subsystem; if not, a transaction is concluded;
the first central server is also used for receiving confirmation information sent by the other terminal according to the reason information, judging whether the reason information is true or not according to the confirmation information, and if not, the transaction is failed; if yes, the transaction request is sent to a second central server for consensus judgment; if the transaction request passes the consensus judgment, broadcasting the transaction request to a third-party central server;
the first central server is also used for obtaining a risk evaluation result sent by the third-party central service, and if any third-party central server does not broadcast risk information within preset time, the uplink of the transaction is sealed and stored according to a block chain algorithm; if any third-party central server broadcasts that the transaction has risks, risk information is broadcasted, and the transaction is cancelled.
2. The electronic ticket transaction risk management and control system of claim 1, wherein: the first central server is further used for encrypting the transaction request according to the Hash operation, calculating to obtain a corresponding Hash value, storing the Hash value into a database, and generating a relational mapping table of the transaction request and the Hash value.
3. The electronic ticket transaction risk management and control system of claim 1, wherein: the first central server is further used for acquiring a protocol address of the transaction object and judging whether the transaction object belongs to the local area according to the protocol address.
4. The electronic ticket transaction risk management and control system of claim 1, wherein: the first central server also comprises a storage module which is used for storing historical transaction information in advance; the first central server is also used for extracting the transaction name of the transaction request, inquiring whether historical transaction information identical to the transaction name exists in the storage module according to a keyword matching algorithm, and if so, judging that the local area can achieve a transaction similar to the transaction request.
5. The electronic ticket transaction risk management and control system of claim 1, wherein: the regional transaction subsystem also comprises a transaction pool which is used for receiving and storing the transaction request which passes the validity verification; the regional transaction subsystem is also used for inquiring the transaction requests in the transaction pool according to a preset time period until two same transaction requests are found in the transaction pool, and then stopping continuous inquiry.
6. The electronic ticket transaction risk management and control system of claim 5, wherein: the regional transaction subsystem is also used for recording the query times, and if the query times are larger than a preset time threshold value, the time period is prolonged.
7. An electronic ticket transaction risk management and control method is characterized by comprising the following steps:
s1, acquiring a transaction request initiated by a buyer terminal of the regional transaction subsystem, and extracting transaction object information from the transaction request, wherein the transaction object information comprises seller terminal information;
s2, judging whether the seller terminal belongs to the local area transaction subsystem according to the seller terminal information, and if so, completing the transaction; otherwise, judging whether the regional transaction subsystem can achieve a transaction similar to the transaction request, if so, initiating a supplementary notification to the buyer terminal, acquiring reason information fed back by the buyer terminal according to the supplementary notification, and forwarding the reason information to another terminal of the regional transaction subsystem; if not, a transaction is concluded;
s3, receiving confirmation information sent by another terminal according to the reason information, and judging whether the reason information is true according to the confirmation information, if not, the transaction is failed; if yes, the transaction request is sent to a second central server for consensus judgment; if the transaction request passes the consensus judgment, broadcasting the transaction request to a third-party central server;
s4, obtaining a risk evaluation result sent by the third-party center service, and if no third-party center server broadcasts risk information within a preset time, sealing the uplink of the transaction according to a block chain algorithm; if any third-party central server broadcasts that the transaction has risks, risk information is broadcasted, and the transaction is cancelled.
8. The electronic ticket transaction risk management and control method as claimed in claim 7, wherein: the step S4 further includes step S41, encrypting the transaction request according to the hash operation, calculating a corresponding hash value, storing the hash value in the database, and generating a relation mapping table between the transaction request and the hash value.
9. The electronic ticket transaction risk management and control method as claimed in claim 7, wherein: the step S2 further includes the step S21 of obtaining a protocol address of the transaction object, and determining whether the transaction object belongs to the local area according to the protocol address.
10. The electronic ticket transaction risk management and control method as claimed in claim 7, wherein: the step S3 further includes step S31, accepting the transaction request passing the validity verification, and storing the transaction request in a transaction pool; s32, inquiring the transaction requests in the transaction pool according to a preset time period until two identical transaction requests are found in the transaction pool, and stopping continuous inquiry; and S33, recording the query times, and if the query times are larger than a preset time threshold, prolonging the time period.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011062737.8A CN112150161B (en) | 2020-09-30 | 2020-09-30 | Electronic ticket transaction risk management and control system and method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011062737.8A CN112150161B (en) | 2020-09-30 | 2020-09-30 | Electronic ticket transaction risk management and control system and method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112150161A true CN112150161A (en) | 2020-12-29 |
| CN112150161B CN112150161B (en) | 2023-08-08 |
Family
ID=73951640
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011062737.8A Active CN112150161B (en) | 2020-09-30 | 2020-09-30 | Electronic ticket transaction risk management and control system and method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112150161B (en) |
Citations (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001273416A (en) * | 2000-03-23 | 2001-10-05 | Goodsdaq Co Ltd | System and method for communication commodity exchange by means of many-to-many bidirectional auction system |
| US20100268649A1 (en) * | 2009-04-17 | 2010-10-21 | Johan Roos | Method and Apparatus for Electronic Ticket Processing |
| KR101164219B1 (en) * | 2011-08-02 | 2012-08-07 | (주)그린엠앤씨 | Electronic coupon dealing system and electronic coupon dealing method |
| US20130205000A1 (en) * | 2010-08-31 | 2013-08-08 | Onsite Concierge | Private network with enhanced user experience |
| CN103324891A (en) * | 2013-05-10 | 2013-09-25 | 四川省林业调查规划院 | Stand growth and yield model dynamic management method based on encryption technique |
| JP2016053765A (en) * | 2014-09-02 | 2016-04-14 | 株式会社バンダイナムコエンターテインメント | Server system for virtual currency management, program, and virtual currency management system |
| CN105701651A (en) * | 2016-01-11 | 2016-06-22 | 何伯祥 | Cross-regional settlement transaction system and method |
| US20160342989A1 (en) * | 2015-05-21 | 2016-11-24 | Mastercard International Incorporated | Method and system for processing blockchain-based transactions on existing payment networks |
| CN107025602A (en) * | 2017-02-24 | 2017-08-08 | 杭州象链网络技术有限公司 | A kind of financial asset transaction system construction method based on alliance's chain |
| CN107705113A (en) * | 2017-09-06 | 2018-02-16 | 浙江大学 | A kind of cross-border inter-bank method of payment of block chain based on Baas frameworks and system |
| CN108711089A (en) * | 2018-05-15 | 2018-10-26 | 成都市微泊科技有限公司 | A kind of shared method of commerce in the cross-platform parking stall based on block chain |
| CN109246137A (en) * | 2018-10-23 | 2019-01-18 | 北京航空航天大学 | The safety protecting method and device of naval warfare data based on block chain |
| CN110569675A (en) * | 2019-09-18 | 2019-12-13 | 上海海事大学 | Multi-Agent transaction information protection method based on block chain technology |
| WO2019245577A1 (en) * | 2018-06-22 | 2019-12-26 | Jeff Stollman | Systems and methods to validate transactions for inclusion in electronic blockchains |
| CN110738474A (en) * | 2019-10-14 | 2020-01-31 | 普联软件股份有限公司 | method and system for encrypting digital currency tokens based on SM2 cryptographic algorithm |
| US20200043007A1 (en) * | 2018-07-31 | 2020-02-06 | Americorp Investments Llc | Techniques For Expediting Processing Of Blockchain Transactions |
| US20200065794A1 (en) * | 2017-08-03 | 2020-02-27 | Liquineq AG | System and method for conducting and securing transactions when blockchain connection is unreliable |
| US20200193432A1 (en) * | 2017-04-24 | 2020-06-18 | Blocksettle Ab | Method and system for settling a blockchain transaction |
| CN111598389A (en) * | 2020-04-09 | 2020-08-28 | 广东工业大学 | Block chain-based trading system for preventing bill market risk |
| CN111652707A (en) * | 2020-04-12 | 2020-09-11 | 链农(深圳)信息科技有限公司 | Block chain based electronic credit card transaction method |
| CN111667270A (en) * | 2020-06-10 | 2020-09-15 | 中信银行股份有限公司 | Region-based digital currency using method and device and electronic equipment |
-
2020
- 2020-09-30 CN CN202011062737.8A patent/CN112150161B/en active Active
Patent Citations (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001273416A (en) * | 2000-03-23 | 2001-10-05 | Goodsdaq Co Ltd | System and method for communication commodity exchange by means of many-to-many bidirectional auction system |
| US20100268649A1 (en) * | 2009-04-17 | 2010-10-21 | Johan Roos | Method and Apparatus for Electronic Ticket Processing |
| US20130205000A1 (en) * | 2010-08-31 | 2013-08-08 | Onsite Concierge | Private network with enhanced user experience |
| KR101164219B1 (en) * | 2011-08-02 | 2012-08-07 | (주)그린엠앤씨 | Electronic coupon dealing system and electronic coupon dealing method |
| CN103324891A (en) * | 2013-05-10 | 2013-09-25 | 四川省林业调查规划院 | Stand growth and yield model dynamic management method based on encryption technique |
| JP2016053765A (en) * | 2014-09-02 | 2016-04-14 | 株式会社バンダイナムコエンターテインメント | Server system for virtual currency management, program, and virtual currency management system |
| US20160342989A1 (en) * | 2015-05-21 | 2016-11-24 | Mastercard International Incorporated | Method and system for processing blockchain-based transactions on existing payment networks |
| CN105701651A (en) * | 2016-01-11 | 2016-06-22 | 何伯祥 | Cross-regional settlement transaction system and method |
| CN107025602A (en) * | 2017-02-24 | 2017-08-08 | 杭州象链网络技术有限公司 | A kind of financial asset transaction system construction method based on alliance's chain |
| US20200193432A1 (en) * | 2017-04-24 | 2020-06-18 | Blocksettle Ab | Method and system for settling a blockchain transaction |
| US20200065794A1 (en) * | 2017-08-03 | 2020-02-27 | Liquineq AG | System and method for conducting and securing transactions when blockchain connection is unreliable |
| CN107705113A (en) * | 2017-09-06 | 2018-02-16 | 浙江大学 | A kind of cross-border inter-bank method of payment of block chain based on Baas frameworks and system |
| CN108711089A (en) * | 2018-05-15 | 2018-10-26 | 成都市微泊科技有限公司 | A kind of shared method of commerce in the cross-platform parking stall based on block chain |
| WO2019245577A1 (en) * | 2018-06-22 | 2019-12-26 | Jeff Stollman | Systems and methods to validate transactions for inclusion in electronic blockchains |
| US20200043007A1 (en) * | 2018-07-31 | 2020-02-06 | Americorp Investments Llc | Techniques For Expediting Processing Of Blockchain Transactions |
| CN109246137A (en) * | 2018-10-23 | 2019-01-18 | 北京航空航天大学 | The safety protecting method and device of naval warfare data based on block chain |
| CN110569675A (en) * | 2019-09-18 | 2019-12-13 | 上海海事大学 | Multi-Agent transaction information protection method based on block chain technology |
| CN110738474A (en) * | 2019-10-14 | 2020-01-31 | 普联软件股份有限公司 | method and system for encrypting digital currency tokens based on SM2 cryptographic algorithm |
| CN111598389A (en) * | 2020-04-09 | 2020-08-28 | 广东工业大学 | Block chain-based trading system for preventing bill market risk |
| CN111652707A (en) * | 2020-04-12 | 2020-09-11 | 链农(深圳)信息科技有限公司 | Block chain based electronic credit card transaction method |
| CN111667270A (en) * | 2020-06-10 | 2020-09-15 | 中信银行股份有限公司 | Region-based digital currency using method and device and electronic equipment |
Non-Patent Citations (4)
| Title |
|---|
| 姜灵敏,徐朗明: "网上证券交易安全解决方案", 计算机工程与应用, no. 06 * |
| 杨帆;王燕霞;李国勇;周扬眉;王佩;: "成渝地区双城经济圈综合科技服务模式研究及应用示范", 中国基础科学, no. 02 * |
| 赵超;: "区块链技术与创新券资源共享模式优化", 开发研究, no. 03 * |
| 韩爽;蒲宝明;李顺喜;李相泽;张笑东;王帅;: "区块链技术在数字资产安全交易中的应用", 计算机系统应用, no. 03 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112150161B (en) | 2023-08-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109413087B (en) | Data sharing method and device, digital gateway and computer readable storage medium | |
| CN110633963B (en) | Electronic bill processing method, electronic bill processing device, computer readable storage medium and computer readable storage device | |
| CN108650270B (en) | Data sharing method and system based on alliance chain and incentive mechanism | |
| CN107342867B (en) | Signature verification method and device | |
| CN109711836A (en) | A kind of storage method of transaction, storage network and electronic equipment | |
| CN108830733A (en) | A kind of information processing method, block scm cluster and system | |
| CN111723385B (en) | Data information processing method, device, electronic equipment and storage medium | |
| CN110602116B (en) | Block chain based data verification method, device and computer readable storage medium | |
| CN111798209A (en) | Engineering project management method based on block chain, electronic equipment and storage medium | |
| US20230208642A1 (en) | Secure data transfer system and method | |
| CN112801778B (en) | Alliance type bad asset block chain system | |
| CN113407954A (en) | Data management method and device based on block chain | |
| CN110689348B (en) | Revenue verification method, device, terminal and medium based on alliance chain | |
| CN111583041B (en) | Block chain-based bond issuing data storage and verification processing method and device | |
| CN118229293A (en) | Block chain-based certification storage system, method and readable medium | |
| KR102159431B1 (en) | Method and apparatus for providing contract service based on blockchain | |
| CN111861688B (en) | Electronic tax registration method and system based on blockchain | |
| CN112150160B (en) | Electronic ticket transaction suggestion generation method and system | |
| CN111507818A (en) | Information sharing method and device based on block chain and storage medium | |
| CN112150161A (en) | Electronic ticket transaction risk management and control system and method | |
| CN114244520B (en) | Block chain-based method, system and equipment for admitting Internet of things equipment | |
| CN110598479A (en) | Data processing method and device and computer readable storage medium | |
| US20210350368A1 (en) | Method and system for blockchain intrusion prevention | |
| CN111866009B (en) | Vehicle information updating method and device | |
| CN111866010B (en) | Vehicle information updating method and device |
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 |