Detailed Description
The technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the drawings in the embodiments of the present disclosure, and it is obvious that the described embodiments are only a part of the embodiments of the present disclosure, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.
Please refer to fig. 1, fig. 2, fig. 3 and fig. 4. The embodiment of the specification provides a transaction processing system.
In this embodiment, the transaction processing system may include a payer client. The payer may be a consumer. The payer client may be a smart phone, a tablet electronic device, a portable computer, a Personal Digital Assistant (PDA), or a smart wearable device, etc. In one implementation of this embodiment, the payer client may have a location function. The Positioning function may be implemented by a GPS (Global Positioning System), a BDS (BeiDou Navigation Satellite System), a GLONASS (GLONASS Satellite Navigation System), a Galileo Satellite Navigation System (Galileo Satellite Navigation System), a base station Wireless signal, a WIFI (Wireless-Fidelity) signal, a Bluetooth (Bluetooth) signal, or any combination of the above.
In this embodiment, the transaction processing system may include a login server. The login server may be one server or a server cluster including a plurality of servers.
The login server may be provided with a collection of payer location information. The set of payer location information may include at least one payer location information. The payer location information may correspond to a payer identification and a generation time. The payer identification may be used to identify a payer, such as the name, account, or number of the payer. The payer location information may be used to indicate a geographic area. The size of the geographical area represented by the payer location information can be flexibly set according to business needs, and can be, for example, a country, a region, a city, or the like.
The payer location information may specifically include any one of a geographical area identifier, longitude and latitude, a geographical location code, and an Internet Protocol Address (IP). The geographic area identifier may be used to identify a geographic area, and may be, for example, a country name, a country number, a city name, a city number, or the like. The geographical area represented by the longitude and latitude may be a geographical area in which a geographical position corresponding to the longitude and latitude is located. For example, the longitude and latitude (116.389550, 39.928167) may correspond to a geographic location in beijing, china, and then the geographic area represented by the longitude and latitude (116.389550, 39.928167) may be beijing, china. The geographical position code can be a character string generated by calculating the longitude and latitude according to a preset algorithm. The preset algorithm may be, for example, a tail-removing algorithm, a GeoHash algorithm, or the like. For example, the longitude and latitude (116.389550, 39.928167) may be calculated according to the GeoHash algorithm to generate a geographical position code wx4 g. The geographical area represented by the geographical position code may be a geographical area in which the geographical position corresponding to the geographical position code is located. The geographic area represented by the network address may be the geographic area to which the network address is mapped. For example, the geographic region to which the network address (222.92.255.XXX) is mapped may be suzhou, china.
For example, the payer location information set may be as shown in table 1 below.
TABLE 1
Payer location information
|
Payer identification
|
Generating time of day
|
Hong Kong, China
|
CA
|
12 and 30 in 2017 and 11 and 00 points in day 11
|
Seattle city of America
|
CB
|
18 o 30 o' clock on 01 month and 01 day in 2018
|
Ottawa, Canada
|
CC
|
15 o 'clock of 03 h in 2018 and 24 o' clock of 03 h in 01 month
|
Manchester, UK
|
CC
|
14 o 00 o' clock on year 2018, month 01, 08 and day |
In this embodiment, the payer client may upload the payer identification and longitude and latitude to the login server. The login server can receive the identifier and longitude and latitude of the payer; payor location information may be determined based on the received latitude and longitude; the received payer identification can be used as the payer identification corresponding to the payer position information; the current time can be used as the generation time corresponding to the payment position information; the payer location information may be used as payer location information in the set of payer location information.
The user may enter the payer identification at the payer client for login. The payment side client can acquire the longitude and latitude of the payment side client through a positioning function after detecting a login instruction; the payer identification and latitude and longitude may be uploaded to the login server. The login instruction may be generated upon detecting that a login key is activated. The login key can be a physical key or a virtual key, etc. Where the login key is triggered including, but not limited to, the login key being pressed, clicked, double-clicked, swiped, pressed for more than a predetermined time, etc. Or the payer client can acquire the longitude and latitude of the payer client through a positioning function after detecting the uploading instruction; the identity and longitude and latitude of the registered payer may be uploaded to the login server. The upload instruction may be automatically generated by the payer client. For example, the payer client may generate the upload instruction at intervals of a preset time period. The size of the preset time period can be flexibly set according to needs, and for example, the preset time period can be 1 hour, 1.5 hours and the like. The upload instruction may also be generated by a user active trigger. For example, the payer client may have an upload key, which in turn may generate the upload instruction upon detecting that the upload key is triggered. The uploading key can be a physical key or a virtual key and the like. Where the upload button is triggered including, but not limited to, the upload button being pressed, clicked, double-clicked, stroked, pressed for more than a predetermined time, etc.
The login server can directly use the longitude and latitude as the position information of the payer. Alternatively, the login server may also encode the geographic position corresponding to the latitude and longitude as the position information of the payer. For example, the login server may calculate the longitude and latitude by using a preset algorithm to obtain the geographic position code corresponding to the longitude and latitude; the geo-location code may be encoded as payer location information. The preset algorithm may be a tail-removing algorithm, a GeoHash algorithm, or the like. Or, the login server may identify a geographic area corresponding to the latitude and longitude as the location information of the payer. For example, the login server may use an identifier of a geographic area in which a geographic location corresponding to the latitude and longitude is located as the payer location information.
Alternatively, in this embodiment, the payer client may upload payer identification and other information to the login server. The login server may receive payer identification and other information; payor location information may be determined based on the received other information; the received payer identification can be used as the payer identification corresponding to the payer position information; the current time can be used as the generation time corresponding to the payment position information; the payer location information may be used as payer location information in the set of payer location information. For example, the other information may include a network address used by the payer client. Then, in particular, the login server may directly use the network address as payer location information. Or, the login server may further obtain an identifier of a geographic area mapped by the network address; the geographic region may be identified as payer location information. The login server may have a mapping relationship between a network address and a geographical area identifier; and further, based on the mapping relation, acquiring the geographic area identifier mapped by the received network address. Of course, servers other than the login server may have a mapping of network addresses and geographic area identifications. The login server may send the received network address to the other server. The other server may receive a network address; acquiring a geographical area identifier mapped by the network address based on the mapping relation; a geographical area identification may be sent to the login server. The login server may receive the returned geographical area identification.
In one implementation of this embodiment, the set of payer location information may include a first set of sub-information. The first set of sub-information may include at least one payer first location information. The payer first location information may correspond to a payer identification and a generation time. The payer first location information may be associated with latitude and longitude. Specifically, the payer first location information may be latitude and longitude. Alternatively, the payer first location information may be a geographic location code determined based on latitude and longitude, or a geographic area identifier.
The payment location information set may also include a second sub-information set. The second set of sub-information may include at least one payer second location information. The payer second location information may correspond to a payer identification and a generation time. The payer second location information may be associated with a network address. In particular, the payer second location information may be a network address, or a geographic area identification determined based on the network address.
For example, the payer client may upload the payer identification, latitude and longitude, and network address to the login server. The login server can receive the identifier, longitude and latitude and network address of the payer; determining payer first location information based on the received latitude and longitude; determining payer second location information based on the received network address; the received payer identification can be respectively used as the payer identification corresponding to the first position information of the payer and the payer identification corresponding to the second position information of the payer; the current time can be respectively used as the generation time corresponding to the first position information of the payer and the generation time corresponding to the second position information of the payer; the payer first location information may be made the payer first location information in the first set of sub-location information; the payer second location information may be made the payer second location information in the second set of sub-information. The process of uploading the payer identification, the longitude and latitude and the network address to the login server by the payer client, the process of determining the first position information of the payer based on the longitude and latitude and the process of determining the second position information of the payer based on the network address can refer to the description in the front, and are not repeated herein.
In this embodiment, the transaction processing system may further include a payee client. The payee may be a merchant who provides offline business services to consumers in a mall, hotel, restaurant, etc. The payee client may be a mobile device, such as a smart phone, a tablet electronic device, a portable computer, a Personal Digital Assistant (PDA), a POS (e.g., a merchant POS, a public transit POS, etc.), or a smart wearable device, etc. The payee client may also be a desktop device, such as a server, an industrial personal computer (industrial control computer), a Personal Computer (PC), a kiosk, or a smart self-service terminal (kiosk) (e.g., subway self-service ticket machine, train ticket self-service ticket machine), etc. The payee client may be one client or a payee system including a plurality of clients. In an implementation manner of this embodiment, the payee client may have a positioning function. The Positioning function may be implemented by a GPS (Global Positioning System), a BDS (BeiDou Navigation Satellite System), a GLONASS (GLONASS Satellite Navigation System), a Galileo Satellite Navigation System (Galileo Satellite Navigation System), a base station Wireless signal, a WIFI (Wireless-Fidelity) signal, a Bluetooth (Bluetooth) signal, or any combination of the above.
In this embodiment, the transaction processing system may further include a registration server. The registration server may be one server or a server cluster including a plurality of servers. The registration server may be a separate server or may be integrated with the login server.
The registration server may be provided with a set of payee location information. The set of payee location information may include at least one payee location information. The payee location information may correspond to a payee identification. The payee identification may be used to identify a payee, such as the name, account, or number of the payee. The payee location information may be used to represent a geographic area. The size of the geographical area represented by the payee location information may be flexibly set according to business needs, and may be, for example, a country, a region, a city, or the like. The payee location information may specifically include any one of a geographical area identifier, a longitude and latitude, a geographical location code, and an Internet Protocol Address (IP). It should be noted that the location information of the payee is relatively fixed and rarely changes with time. The payee location information may not need to correspond to the generation time. Of course, this embodiment does not exclude the technical solution that the position information of the receiving location corresponds to the generation time.
For example, the payee location information set is shown in table 2 below.
TABLE 2
Payee location information
|
Payee identification
|
Hong Kong, China
|
MA
|
Macao, China
|
MB
|
London, UK
|
MC |
In this embodiment, the payee typically needs to register in order to gain access to the transaction processing system. Specifically, the payee client may send a registration request to the registration server, where the registration request may carry a payee identifier and location information, and a geographic area indicated by the location information may be a geographic area of offline service provided by the payee. The location information may include any one of a geographical area identification, a latitude and longitude, a geographical location code, and a network address. The registration server may receive the registration request; the received location information may be used as payee location information; the received payee identification can be used as the payee identification corresponding to the payee position information; the payee location information may be used as payee location information in a payee location information set. Of course, the registration request may also carry other information, such as the type of offline service provided by the payee, a license of the payee, and the like. The location information carried in the registration request may be input by the user, or may be obtained by the payee client through a positioning function.
Alternatively, in this embodiment, the payee client may also upload the payee identifier and the location information to the registration server in other manners. For example, after detecting the upload instruction, the payee client may obtain the location information of the payee client through a positioning function; payee identification and location information may be uploaded to the registration server. For the introduction of the upload instruction, reference may be made to the foregoing description, and details are not described herein.
In this embodiment, the transaction processing system may further include a payment server. The payment server may be one server, or may also be a server cluster including a plurality of servers. The payment server may be a separate server or may be integrated with the login server or the registration server.
In this embodiment, the payment server may receive a payment request sent by a payer client or a payee client, where the payment request may carry a payer identifier, a payee identifier, and a payment amount. The payment server may send a payer identification to the login server. The login server may receive a payer identification; the corresponding payer position information can be acquired from the payer position information set based on the payer identification; the acquired payer location information may be transmitted to the payment server. The payment server may receive payer location information. In addition, the payment server may also send a payee identification to the registration server. The registration server may receive a payee identification; corresponding payee location information may be obtained from the payee location information set based on the payee identification; payee location information may be sent to the payment server. The payment server may receive payee location information. Thus, the payment server can compare the geographical area represented by the position information of the payer with the geographical area represented by the position information of the payee; if the transaction is the same as the payment request, the transaction corresponding to the payment request can be identified as a normal transaction; if the transaction is not the same, the transaction corresponding to the payment request can be identified as an abnormal transaction.
Please refer to fig. 1, fig. 2, fig. 3 and fig. 4. The embodiment of the specification provides a transaction processing method. The transaction processing method takes the payment server as an execution subject and can comprise the following steps.
Step S10: a payment request is received.
In this embodiment, the payment request may carry an identifier of a payer and an identifier of a payee. The payer identification may be used to identify a payer, and the payee identification may be used to identify a payee. Of course, the payment request may also carry other information, such as the payment amount.
In one implementation of this embodiment, the payment request may come from a payer client.
For example, the payee may have a payment code. The payment code can be a graphical code or a sound wave code, and the graphical code can comprise a bar code, a two-dimensional code and the like. The payment code may include a payee identifier and a payment page identifier. The payment page identifier may be used to identify a payment page, and may be, for example, a link address of the payment page, or a code of the link address, etc. The link address may be, for example, a URL (Uniform Resource Locator) address. The payer client can scan the payment code of the payee to obtain a payee identifier and a payment page identifier; the payment page may be presented based on the payment page identification; the payment amount input by the user on the payment page can be acquired; the identifier of the registered payer can be acquired; a payment request may be sent to the payment server.
As another example, the payer client may provide a payment page; the payment amount and the payee identification input by the user on the payment page can be obtained; the identifier of the registered payer can be acquired; a payment request may be sent to the payment server.
Of course, those skilled in the art should understand that the payer client may also send the payment request to the payment server in other manners, and this embodiment is not limited in this respect.
In another implementation of this embodiment, the payment request may also come from the payee client.
For example, the payer client may provide a payment code, which may include the payer identification. The payee client can scan the payment code provided by the payer client to obtain a payer identifier; a payment amount may be determined; a payee identification may be obtained; a payment request may be sent to the payment server. The payee client can specifically acquire a preset default amount as the payment amount; alternatively, the amount input by the user may be acquired as the payment amount.
Of course, those skilled in the art should understand that the payee client may also send the payment request to the payment server in other manners, and this embodiment is not limited in this respect.
Step S12: and acquiring the position information of the payer based on the payer identification.
In this embodiment, the number of the payer location information acquired by the payment server may be at least one. The payment position information acquired by the payment server may include any one of a geographical area identifier, latitude and longitude, a geographical position code, and a network address.
In this embodiment, the payment server may send the payer identification to the login server. The login server may receive a payer identification; corresponding at least one payer position information can be obtained from the payer position information set based on the received payer identification; the acquired payer location information may be transmitted to the payment server. The payment server may receive the transmitted payer location information.
The login server may be provided with payer location information. In this way, the login server may specifically obtain, from the set of payer location information, payer location information that corresponds to the received payer identification and that has the smallest difference between the generation time and the current time. Or the login server can also acquire at least one piece of payer position information which corresponds to the received payer identification and has a difference value between the generation time and the current time smaller than or equal to a preset threshold value from the payer position information set. The preset threshold can be flexibly set according to needs, and may be, for example, 30 minutes, 1 hour, or 2 hours, etc.
Step S14: and acquiring payee position information based on the payee identification.
In this embodiment, the number of payee location information acquired by the payment server is generally one in view of the payee location information being relatively fixed. The position information of the payment receiver acquired by the payment server may include any one of a geographical area identifier, a longitude and latitude, a geographical position code, and a network address.
In this embodiment, the login server may be provided with payer location information. As such, the payment server may send the payee identification to the registration server. The registration server may receive a payee identification; corresponding payee location information may be obtained from the payee location information set based on the received payee identification; the acquired payee location information may be transmitted to the payment server. The payment server may receive the payee location information.
Step S16: and under the condition that the geographical area represented by the payer position information is different from the geographical area represented by the payee position information, identifying the transaction corresponding to the payment request as an abnormal transaction.
In this embodiment, the number of the payer location information acquired by the payment server may be at least one. Thus, the payment server can compare the geographical area represented by the position information of each payer with the geographical area represented by the position information of the payee; under the condition that the geographical area represented by the position information of each payer is the same as the geographical area represented by the position information of the payee, identifying the transaction corresponding to the payment request as a normal transaction; and under the condition that the geographical area represented by the position information of one or more payers is different from the geographical area represented by the position information of the payee, identifying the transaction corresponding to the payment request as an abnormal transaction.
It should be noted that, under the condition that the transaction corresponding to the payment request is identified as a normal transaction or an abnormal transaction, the payment server may execute a preset action. The preset action can be flexibly set according to the service requirement. For example, the payment server may perform a payment operation based on the payer identification, the payee identification, and the payment amount on the condition that the transaction corresponding to the payment request is identified as a normal transaction. Further, the payment server may transfer a certain amount of bonus money to the payer account corresponding to the payer identifier and the payee account corresponding to the payee identifier, respectively. The payment server may not perform the payment operation on the condition that the transaction corresponding to the payment request is identified as an abnormal transaction; but may send a prompt to the payer client and/or the payee client.
In one implementation of this embodiment, the set of payer location information may include a first set of sub-information and a second set of sub-information. In this way, after receiving the payer identification sent by the payment server, the login server may obtain, based on the received payer identification, the corresponding first location information of at least one payer from the first sub-information set, and obtain the corresponding second location information of at least one payer from the second sub-information set; the acquired payer first location information and the payer second location information may be transmitted to the payment server. The payment server may receive the sent first payer location information and the second payer location information.
In this embodiment, the login server may obtain, from the first sub-information set, first position information of the payer, which corresponds to the received payer identifier and has a smallest difference between the generation time and the current time. Or, the login server may further obtain, from the first sub-information set, at least one first location information of the payer, which corresponds to the received payer identifier and for which a difference between the generation time and the current time is less than or equal to a preset threshold.
The login server may obtain, from the second set of sub-information, second location information of the payer, corresponding to the received payer identification, and having a smallest difference between the generation time and the current time. Or, the login server may further obtain, from the second sub-information set, at least one second location information of the payer, which corresponds to the received payer identifier and for which a difference between the generation time and the current time is less than or equal to a preset threshold.
In this embodiment, the payment server may compare the geographic area represented by the first location information of each payer and the geographic area represented by the second location information of each payer with the geographic area represented by the location information of the payee, respectively; under the condition that the geographic area represented by the first position information of each payer and the geographic area represented by the second position information of each payer are the same as the geographic area represented by the position information of the payee, identifying the transaction corresponding to the payment request as a normal transaction; the transaction corresponding to the payment request may be identified as an anomalous transaction if the geographic area represented by the first location information of the one or more payers is not the same as the geographic area represented by the location information of the payee, or if the geographic area represented by the second location information of the one or more payers is not the same as the geographic area represented by the location information of the payee.
In this embodiment, the payment server may receive a payment request carrying a payer identifier and a payee identifier; payer location information may be obtained based on the payer identification; payee location information may be obtained based on the payee identification; the transaction corresponding to the payment request can be identified as an abnormal transaction under the condition that the geographical area represented by the payer position information is different from the geographical area represented by the payee position information. In this way, the payment server can identify the transaction corresponding to the payment request as an abnormal transaction based on the geographical position of the payer and the geographical position of the payee, so that the false offline payment transaction can be accurately identified.
Please refer to fig. 5. The embodiment of the specification provides a server. The server may include:
a receiving unit 20 for receiving a payment request; the payment request carries a payer identification and a payee identification;
an obtaining unit 22, configured to obtain payer location information based on the payer identification; obtaining payee location information based on the payee identification;
the identifying unit 24 is configured to identify, under the condition that the geographic area indicated by the payer location information is different from the geographic area indicated by the payee location information, that the transaction corresponding to the payment request is an abnormal transaction.
Please refer to fig. 6. The embodiment of the specification provides a server. The server may include a communication component and a processor.
In this embodiment, the communication component includes, but is not limited to, a wired network card, a wireless network card, a bluetooth module, an infrared transceiver module, an ultra-wideband communication module, a zigbee protocol communication module, and the like. The communication component may be used to establish a communication connection and perform data transmission.
In this embodiment, the processor may be implemented in any suitable manner. For example, the processor may take the form of, for example, a microprocessor or processor and a computer-readable medium that stores computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, an embedded microcontroller, and so forth.
In this embodiment, the processor may be configured to control the communication component to receive a payment request; the payment request carries a payer identification and a payee identification; acquiring payer position information based on the payer identification; obtaining payee location information based on the payee identification; and under the condition that the geographical area represented by the payer position information is different from the geographical area represented by the payee position information, identifying the transaction corresponding to the payment request as an abnormal transaction.
It should be noted that, in the present specification, each embodiment is described in a progressive manner, and the same or similar parts in each embodiment may be referred to each other, and each embodiment focuses on differences from other embodiments. In particular, for the server embodiment, since it is basically similar to the transaction processing method embodiment, the description is relatively simple, and for relevant points, reference may be made to part of the description of the transaction processing method embodiment.
In addition, it is understood that one skilled in the art, after reading this specification document, may conceive of any combination of some or all of the embodiments listed in this specification without the need for inventive faculty, which combinations are also within the scope of the disclosure and protection of this specification.
In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate a dedicated integrated circuit chip 2. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Language Description Language), traffic, pl (core unified Programming Language), HDCal, JHDL (Java Hardware Description Language), langue, Lola, HDL, laspam, hardbyscript Description Language (vhr Description Language), and the like, which are currently used by Hardware compiler-software (Hardware Description Language-software). It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
From the above description of the embodiments, it is clear to those skilled in the art that the present specification can be implemented by software plus a necessary general hardware platform. Based on such understanding, the technical solutions of the present specification may be essentially or partially implemented in the form of software products, which may be stored in a storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and include instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments of the present specification.
The description is operational with numerous general purpose or special purpose computing system environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet-type devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
This description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
While the specification has been described with examples, those skilled in the art will appreciate that there are numerous variations and permutations of the specification that do not depart from the spirit of the specification, and it is intended that the appended claims include such variations and modifications that do not depart from the spirit of the specification.