Detailed Description
Hereinafter, embodiments of the present application will be described with reference to the accompanying drawings. It should be understood that the description is only illustrative and is not intended to limit the scope of the application. In the following detailed description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the application. It may be evident, however, that one or more embodiments may be practiced without these specific details. In addition, in the following description, descriptions of well-known structures and techniques are omitted so as not to unnecessarily obscure the present application.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The terms "comprises," "comprising," and/or the like, as used herein, specify the presence of stated features, steps, operations, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, or components.
All terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art unless otherwise defined. It should be noted that the terms used herein should be construed to have meanings consistent with the context of the present specification and should not be construed in an idealized or overly formal manner.
Where a convention analogous to "at least one of A, B and C, etc." is used, in general such a convention should be interpreted in accordance with the meaning of one of skill in the art having generally understood the convention (e.g., "a system having at least one of A, B and C" would include, but not be limited to, systems having a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B, C together, etc.).
Traditional POS order receiving system long-term relies on three-level architecture of terminal-acquirer-card organization, and the core logic is to realize strong coupling of terminal and specific order receiving bank through hardware binding. Under the architecture, each POS terminal device needs to be directly connected with a clearing system of a single acquiring bank through a physical private line (such as PSTN dialing and private line network) to form a one-to-one closed channel. The design results in high solidification of the functions of the terminal equipment, so that each POS terminal can only be in butt joint with a clearing channel of a single bank and cannot dynamically switch or be compatible with payment services of other banks. For example, if a customer needs to access the order receiving services of the bank a and the bank B at the same time, two independent terminals must be deployed to bind private networks of different banks respectively.
The defects of the architecture are particularly remarkable in a multi-bank order-receiving scene, and merchants need to configure independent terminals for different order-receiving banks, so that equipment redundancy, large occupied space and high maintenance cost are caused. Account switching relies on manual operations (e.g., terminal exchange, manual parameter entry), is not only time-consuming (3-5 minutes per switch on average), but also prone to transaction failure or funds mismatch due to operational errors. The order receiving system and the merchant sales terminal (such as a cash receiving system) are not deeply integrated, order information (such as commodity names and amounts) is needed to be input and output through manual input or USB flash disk input, the risk of data secondary input errors exists, and real-time synchronization of transaction flow and order data is difficult to realize. In addition, the traditional terminal mostly adopts a plaintext or simple encryption mode when transmitting sensitive information (such as bank account numbers and transaction amounts), has hidden danger of data leakage, and once a private network is attacked, the safety of the merchant and the consumer funds is threatened. The problems limit the efficiency and the safety of the traditional POS receipt system together, and are difficult to adapt to the high requirements of modern businesses on multi-account management, data interconnection and intercommunication and payment safety.
In order to solve the problems, the embodiment of the application provides a multiplexing order receiving method, wherein an order receiving service intelligent identification and dynamic interaction mechanism is introduced in a traditional POS order receiving process, and seamless switching and accurate order receiving of a POS terminal under a multi-bank and multi-account scene are realized through the interaction logic of a reconstruction terminal and a background system. Specifically, a multi-level deposit account relationship is preconfigured at a sales terminal (such as a merchant deposit system), so that the same merchant is supported to be associated with different bank accounts (such as an A-bank main account and a B-bank standby account) or different sub-merchant accounts (such as a chain store branch account). The terminal automatically matches the target account according to the transaction characteristics (such as order amount and payment channel), or the merchant actively selects to realize millisecond account switching, so that the operation of manually replacing the terminal or manually inputting the account is thoroughly replaced. The terminal integrates three payment modes of card swiping, main scanning and scanned, a consumer can freely select card insertion/card volatilization, show a payment code or scan a dynamic two-dimensional code of a merchant to finish payment, and the merchant can cover the requirements of the whole guest group without deploying a plurality of devices. And generating a unique Transaction Identifier (TID) based on the service serial number, and ensuring traceability and reconciliation of the order through the whole flow of order generation, payment processing and result feedback. Pushing the single receipt fruits to a receipt system, synchronously updating transaction states (such as 'successful payment' and 'transaction withdrawal') and triggering subsequent accounting processing to form a 'payment-clearing-settlement' full-link closed loop, so that the fund risk is reduced. Through the optimization, the method remarkably improves the automation degree and user experience of the order receiving operation, and simultaneously provides an account management scheme with low cost and high flexibility for merchants.
The embodiment of the application provides a multiplexing order receiving method, which comprises the steps of responding to an order receiving request of an order receiving system, generating an order two-dimensional code containing a unique transaction identifier based on a service serial number, utilizing a sales terminal to scan the order two-dimensional code, acquiring service information and order receiving information, wherein the order receiving information comprises a receiving amount, a receiving bank, a receiving user name, a receiving account number and a payment code, confirming the service information and the order receiving information through the sales terminal, and executing an order receiving operation, wherein the sales terminal is pre-associated with a plurality of receiving banks, a plurality of receiving user names and a plurality of receiving account numbers, and supporting dynamic switching of the associated accounts in the order receiving operation.
As shown in fig. 1, an application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 is a medium used to provide a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.
The user may interact with the server 105 via the network 104 using the first terminal device 101, the second terminal device 102, the third terminal device 103, to receive or send messages etc. Various communication client applications, such as a shopping class application, a web browser application, a search class application, an instant messaging tool, a mailbox client, social platform software, etc. (by way of example only) may be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103.
The first terminal device 101, the second terminal device 102, the third terminal device 103 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smartphones, tablets, laptop and desktop computers, and the like.
The server 105 may be a server providing various services, such as a background management server (by way of example only) providing support for websites browsed by the user using the first terminal device 101, the second terminal device 102, and the third terminal device 103. The background management server may analyze and process the received data such as the user request, and feed back the processing result (e.g., the web page, information, or data obtained or generated according to the user request) to the terminal device.
It should be noted that, the multiplexing acquirer method provided by the embodiment of the present application may be generally performed by the server 105. Accordingly, the multiplexing order receiving device provided by the embodiment of the present application may be generally disposed in the server 105. The multiplex acquiring method provided by the embodiment of the present application may also be performed by a server or a server cluster which is different from the server 105 and is capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103 and/or the server 105. Accordingly, the multiplex acquiring apparatus provided by the embodiment of the present application may be also provided in a server or a server cluster which is different from the server 105 and is capable of communicating with the first terminal device 101, the second terminal device 102, the third terminal device 103 and/or the server 105.
It should be understood that the number of terminal devices, networks and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.
The multiplexing acquirer method according to the embodiment of the present application will be described in detail below with reference to the scenario described in fig. 1 through fig. 2 to 3.
Fig. 2 schematically shows a flow chart of a first multiplex order reception method according to an embodiment of the application.
As shown in fig. 2, the multiplexing acquirer method of this embodiment includes operations S210 to S230.
In operation S210, an order two-dimensional code including a unique transaction identifier is generated based on the service serial number in response to an order receipt request of the order receiving system.
In some exemplary embodiments, operation S210 includes operations S211-S212.
In operation S211, the service serial number is combined with the terminal number and the time stamp to generate a unique transaction identifier.
In practical implementation, the service serial number may be in the form of "ORD" +yearday+4-bit serial number, such as ORD202310010001, the terminal number may be a fixed number allocated when the device leaves the factory, such as DEV001, and the timestamp is accurate to seconds, and is in the format of YYYYMMDDHHMMSS, such as 20231001120000. This information is underlined to form the final unique transaction identifier ORD202310010001 DEV001_20231001120000. The method ensures that the identifier of each transaction is unique through multi-field combination, avoids order collision, and meanwhile, the identifier comprises the service serial number and the timestamp, thereby facilitating subsequent audit and tracing, and further, the identifier is changed along with time due to the introduction of the timestamp, so that the repetition risk is further reduced.
In operation S212, a two-dimensional code is generated based on the unique transaction identifier, and the encrypted order information is embedded, so as to obtain an order two-dimensional code.
In an embodiment of the application, the order receiving information includes, but is not limited to, a receipt amount including a transaction amount, such as 100.00 yuan, a receipt bank including a target bank name, such as "China Industrial and commercial Bank", a receipt user name including an account holder name, such as "Zhang Sano", a receipt account number including a bank account number, and a payment code, which is an optional field for a specific business scenario. The encryption process may employ symmetric encryption (e.g., advanced encryption standard-256 bits, AES-256) or asymmetric encryption (e.g., RSA). Taking an AES-256 encryption algorithm as an example, the specific steps are that order receiving information is converted into a JSON (fully called JavaScriptObjectNotation, which is a lightweight data exchange format) format, a pre-allocated Advanced Encryption Standard (AES) key (32 bytes) and a randomly generated initialization vector (IV, 16 bytes) are used for encrypting the JSON character string, encrypted binary data is converted into a Base64 (coding mode based on 64 printable characters) coding character string, and the Base64 character string is combined with a transaction identifier to generate final two-dimensional code content. The encryption mode ensures the security of the receipt information, and even if the two-dimensional code is illegally acquired, the sensitive information in the two-dimensional code cannot be directly read.
Further, in order to ensure the security and traceability of the transaction and the validity of the access of the order receiving system, the device registration and security authentication of the sales terminal need to be completed. Prior to step S210, the method further comprises operations S310-S320, see fig. 3.
In operation S310, device information of the sales terminal including a device number, a device model number, a communication address, and a communication key is collected and stored in a server database.
In the embodiment of the application, the equipment information is stored in the server database after being encrypted, and the secret key is protected by symmetric encryption or asymmetric encryption. The device number is a serial number (such as DEV 001) that uniquely identifies the point-of-sale terminal, and is used to ensure the uniqueness of the point-of-sale terminal and avoid repeated registration. The equipment model is a sales terminal hardware model (such as POS-X100), and hardware maintenance, compatibility test and batch upgrade are facilitated by recording the equipment model. The communication address is the network address of the sales terminal (e.g. 192.168.1.100 or MAC address 00:1A:2B:3C:4D:5E), and by recording the communication address, the network location of the device can be located, and abnormal access behavior is monitored. The communication key is used for the subsequent two-way authentication key (such as an AES-256 key 32-bit random character string), and the communication key is stored for the device and the server for encrypted communication, so that data leakage or tampering is prevented.
The scheme of the embodiment of the application realizes unified standardized management of equipment information through structured storage, supports flexible extension fields to adapt to service dynamic changes, stores a communication key by adopting an AES-256 encryption technology, ensures data transmission safety by combining with an HTTPS/TLS protocol, can effectively resist safety risk TLS, and ensures compliance audit requirements of industries such as finance, medical treatment and the like by ensuring that HTTPS (hyper text transmission safety protocol) and TLS (transport layer safety protocol) are core technologies for ensuring network communication safety and are in close cooperation to realize data encryption, identity verification and integrity protection.
In operation S320, the sales terminal logs in to the order receiving system to complete the two-way authentication and system check-in based on the encrypted communication key.
In the embodiment of the application, the sales terminal verifies the legitimacy of the digital certificate of the order receiving system through the preset root certificate or public key library, ensures that the communication object is a real system and prevents the falsification of a middleman. The acquiring system confirms that the identity of the terminal is legal and is not tampered through the unique identification (such as a serial number and a certificate fingerprint) of the device and dynamic signature verification (such as a device private key signature) so as to prevent the counterfeit terminal from accessing. When the terminal is accessed for the first time, equipment information (such as IP and position) is registered to the order receiving system after two-way authentication, the system distributes a unique terminal number and records the state, and in the signing process, the order receiving system issues parameters such as a merchant number, a key index, a transaction allowance and the like, and the terminal locally stores and activates a service function. Through the three steps of authentication, registration and authorization, only legal equipment is ensured to be accessed, only authorized equipment is ensured to develop business, and meanwhile, through a dynamic key and state synchronization mechanism, the safe and reliable communication between the sales terminal and the order receiving system is realized, and the high safety and high availability requirements of a financial payment scene are met.
In some exemplary embodiments, operation S320 includes operations S321-S323.
In operation S321, a dynamic session key pair is generated by a hardware security module of the sales terminal, and a public key of the dynamic session key pair is signed.
In the embodiment of the application, the HSM chip is arranged in the sales terminal, the temporary key pair is generated based on the elliptic curve algorithm by calling the key generation interface of the HSM chip, the generated temporary key pair comprises a private key and a public key, the temporary key pair has the characteristics of temporary property and safety, the new key pair is generated in each session, the risk of long-term key leakage is avoided, and the HSM can provide physical attack resistance protection, so that the private key cannot be extracted.
In operation S322, the signature of the public key in the dynamic session key pair is verified based on the server-side pre-stored public key, and the shared key pair is generated. The method comprises the steps of signing an ECC public key (namely a public key (PubKey_ECC) generated based on an elliptic curve encryption algorithm (EllipticCurveCryptography, ECC) and commonly used for key negotiation or data encryption) by using a preset RSA private key (namely a private key (PrivKey _RSA) generated based on an RSA algorithm and used for signing data, enabling the identity authenticity of a signer to be guaranteed), sending the signed ECC public key to a server, generating an ECC key pair after the server verifies the signature, and negotiating a shared key as a session key by two parties through an elliptic curve diffie-Hellman key exchange algorithm (ECDH, ellipticCurveDiffie-Hellman) algorithm, wherein ECDH is a key negotiation protocol based on elliptic curve cryptography, enabling the two parties to generate the shared key through exchanging the public key without directly transmitting the key, and ensuring that the identity of the two parties is true and the key negotiation process is not tampered through signature verification and ECDH key negotiation.
In operation S323, the sales terminal and the server end encrypt the transmission data end-to-end using the shared key, and perform data integrity and certificate verification to ensure identity authenticity.
In the embodiment of the application, the two parties carry out advanced encryption standard on the transmission data based on the negotiated shared secret key, carry out end-to-end encryption, verify the integrity of the data through or digital signature, ensure the authenticity of the identity through certificate verification and prevent replay attack through a time stamp and random number mechanism, thereby establishing a complete secure communication channel. By establishing a secure channel, confidentiality, integrity and playback resistance of data transmission are ensured, illegal device access is prevented by strong association of a receipt device number (such as a POS terminal ID and an IoT device serial number) and an encryption key, and key management efficiency is optimized and frequent re-authentication is avoided on the premise of ensuring security by multiplexing and updating the key.
The security communication channel ensures the security of data transmission through a multi-level mechanism, wherein confidentiality guarantee relies on a high-intensity encryption algorithm (such as AES) to encrypt the data end to end, and the encryption process covers the whole process from data generation to data reception, so that only authorized parties with legal keys can decrypt the data, and network interception and flow analysis attacks are effectively resisted. Even if an attacker intercepts ciphertext, the ciphertext cannot be cracked in a reasonable time, the integrity check generates a data check value through a message authentication code (HMAC-SHA 256) or a digital signature (RSA/ECDSA), and a receiver verifies whether the data is tampered by recalculating the check value and comparing the check value with a transmission value. The mechanism can detect modification of any bit level, ensure the credibility of data sources, prevent middle people from falsifying sensitive information such as transaction amount, instruction parameters and the like, verify the authenticity of identities of two communication parties by means of a digital certificate or asymmetric signature technology, prevent counterfeiting or middle people from attacking, ensure the communication with a real service end by verifying the validity period, the revocation state and a signature chain of the certificate, prevent phishing attack or hijacking session of the counterfeiting service end, resist replay attack by embedding a timestamp, a random number or an incremental serial number in a message, and reject repeated or expired messages by checking a time window (such as +/-5 minutes) or the uniqueness of the serial number by a receiver. For example, if the timestamp in a payment request exceeds the expiration date, the system will discard the request directly, preventing an attacker from intercepting the old message and resubmitting. Forward secrecy uses a temporary key exchange (e.g., ECDHE) to generate a short-term session key, each session generates an independent short-term session key, and the long-term key is used only for identity authentication and not data encryption. Even if the server private key is revealed, the attacker still cannot decrypt the history communication record because the session key is destroyed as the session ends. Dynamic defenses actively defend against threats by periodic rotation of keys (e.g., updated every 15 minutes) and abnormal behavior monitoring (e.g., pattern analysis of traffic bursts, off-time accesses, etc.). The system can block suspicious requests in real time, and dynamically adjust the protection strategy in combination with threat information to form a deep protection system covering the whole transmission process. The mechanism combines four dimensions of encryption, authentication, verification and dynamic defense, and constructs a full-closed-loop security guarantee from data generation to receiving, so that a mainstream attack means in the current network environment can be effectively achieved.
Returning to fig. 2, in operation S220, the sales terminal is utilized to scan the order two-dimensional code, obtain the service information and the order receiving information, and the order receiving information includes the deposit amount, the deposit bank, the deposit user name, the deposit account number and the payment code.
In the embodiment of the application, the sales terminal associates a plurality of receiving banks, a plurality of receiving user names and a plurality of receiving account numbers in advance, and supports dynamic switching of the associated accounts in the order receiving operation. Preferably, the sales terminal stores a plurality of the storage account information through a local database or a profile. The sales terminal scans the order two-dimension code to obtain service information and order information, and the specific process is that the terminal camera scans the two-dimension code to read the original data, analyzes the transaction identifier and the encrypted order information, decrypts the order information by using the stored decryption key, verifies the validity of the transaction identifier (such as checking whether the time stamp is in the validity period or not), and finally displays the decrypted order information on the terminal interface. In this process, the system supports the merchant to dynamically switch between a plurality of pre-stored bank accounts. The sales terminal interface presents the currently selected bank account information, the list of other accounts that can be switched, and the account switch button. The account information is stored in an encryption database of the terminal, each account record covers the contents of bank names, account types, the encrypted stored account numbers, account holders, account opening information, last use time and the like, merchants can switch among different accounts through simple interface operation, and the system can update target account information of transactions in real time.
The sales terminal is flexible and diverse in account association through pre-associating a plurality of deposit banks, user names and account numbers, can meet the demand of different scene receipts, enhances the flexibility of business processing, supports account dynamic switching in the receipts operation, is convenient and efficient to operate, does not need complicated setting, improves user experience, ensures the accuracy and safety of information through multiple links, prevents information leakage through encryption storage, is intuitive and easy to use in interface design, facilitates merchants to know account states and switch, is perfect in account information management, stores detailed and updates transaction target account information in real time, and ensures accurate and traceable transactions.
In operation S230, service information and order receiving information are confirmed through the sales terminal, and an order receiving operation is performed.
In some exemplary embodiments, the payment mode of the order receiving operation comprises card swiping payment, reading bank card information and completing payment deduction through magnetic card swiping and integrated circuit card identification, being applicable to a bank card with a magnetic stripe or a chip, main scanning payment, scanning code payment by a client mobile device through generating a payment two-dimensional code, and scanned payment, scanning the payment code of the client mobile device to complete payment, wherein the payment result can be displayed on a sales terminal in real time, and recording an encrypted transaction log.
For example, a certain chain restaurant supports three modes of card swiping payment, main scanning payment (generating a merchant two-dimensional code) and scanned payment (scanning a customer payment code), the payment mode can be dynamically switched according to the customer demand, real-time feedback of the payment result is ensured, and the transaction log is safely stored.
The merchant selects a payment mode on a sales terminal interface, wherein the payment mode comprises card swiping payment, a customer inserts or lightly touches a bank card (magnetic stripe/chip card), a terminal reads card information and verifies card validity, main scanning payment, the terminal dynamically generates a payment two-dimensional code (comprising merchant ID, order number and amount), the customer finishes payment by using WeChat/payment precious scanning codes, scanned payment is performed, the terminal scans a payment code displayed by a customer mobile device, and an encrypted payment instruction in the code is analyzed. Meanwhile, the sales terminal display can show business information (order amount, commodity detail) and receipt information (payment mode and target account), and the merchant triggers a payment request after confirmation. And the payment result is returned to the terminal in real time through the bank/third party payment platform, and the 'successful payment' or failure reasons (such as insufficient balance and abnormal card state) are displayed. The terminal encrypts and stores the transaction data into a local database (AES-256 encryption) to form an encrypted transaction log, wherein the log field comprises order number, payment mode, transaction time, payment result, target account, equipment ID and sensitive information of a merchant operator (such as four bits after a bank card number and payment code fragments) for desensitization treatment (such as x and x 1234).
According to the scheme provided by the embodiment of the invention, multi-mode payment can be supported, different customer preferences are met, the processing efficiency of the order in the peak period is improved by 40%, meanwhile, the encrypted log is supported to be inquired according to the order number and the time range, and the supervision audit requirement is met.
Based on the multiplexing receipt method shown in fig. 2 and fig. 3, in order to acquire information of the receipt account in real time, the method may further include pushing the receipt to the receipt system to update the flow status flag and the corresponding receipt account details.
For example, conventional reconciliation requires manual derivation of terminal transaction data for comparison with the order receiving system, which is time consuming and error prone. And pushing the result to the order receiving system immediately after the sale terminal successfully pays. The order receiving system automatically matches orders and updates states, and account checking efficiency can be effectively improved. The account-arriving time of the cross-border transaction is uncertain, the merchant is difficult to grasp the fund state in real time, and after the receipt system receives pushing, the merchant is informed of account-arriving information through a short message/mail, so that the merchant can check account balance and transaction detail in real time.
In the first embodiment, a teaching institution provides three classes of courses of sports, literature and art, and customers can pay the academic fee of different courses through a unified order two-dimension code. The institution needs to dynamically match corresponding receipts accounts (such as a sports course receives an A bank account, a literature course receives a B bank account, and an art course receives a C bank account) according to courses selected by clients, and records payment codes for subsequent reconciliation.
The local encryption database of the sales terminal pre-stores the mapping relation between courses and accounts:
Sports course→A bank account (account number: ENC_XXXXXX1)
Literature course → bank account B (account number: ENC_XXXXX2)
Art course→C bank account (account number: ENC_XXXX3)
Account information is stored encrypted (e.g., AES-256) and only authorized administrators may modify it.
The customer presents an ORDER two-dimensional code, the sales terminal camera analyzes the two-dimensional code after scanning, the service information comprises a course name (already-matched), an ORDER number (ORDER 20231001-001), and the ORDER receiving information comprises a receiving amount (besides 5000), a receiving bank (encryption), a receiving account number (encryption) and a payment code (PAY 20231001-ABC). And the sales terminal automatically selects an A bank account according to the course name 'sports' query mapping table. And decrypting the bank name, the account number and the family name in the order receiving information by using a prestored A bank account decryption key. The sales terminal displays the decrypted order information (bank A, account number: 6228 x 1234, family name: XX institution), and the institution confirms the payment. The terminal encryption database records transaction details including order numbers, course names, target accounts, payment codes, transaction time and finally account time.
The multiplexing order receiving method described based on fig. 2-3 provides a multiplexing order receiving POS terminal based on modular design, which can realize the multiplexing order receiving method, and describes the multiplexing order receiving POS terminal in detail.
The embodiment of the application provides a modularized and highly-multiplexing intelligent POS terminal, which realizes seamless switching and efficient order collection of multiple banks and multiple accounts through the collaborative design of hardware and software. The POS terminal comprises an image acquisition and identification module, a card swiping and IC card identification module, an information display module, an information processing and storage module and a communication module.
The image acquisition and identification module can support optical signal identification and a main scanning mode and a scanned mode, wherein the optical signal identification is based on a high-resolution camera and an image processing algorithm, quick analysis of bar codes/two-dimensional codes is supported, a merchant scans a payment code presented by a consumer through a terminal in the main scanning mode, and the terminal dynamically generates a merchant collection code (including a gold amount and an order number) for the consumer to pay by scanning the code in the scanned mode.
The card swiping and IC card identification module supports magnetic stripe card, IC card and NFC non-connected payment, and simultaneously, sensitive information such as card number, validity period and the like is encrypted in real time through a hardware encryption module (such as HSM).
The information display module can perform multi-interface interaction, and comprises the steps of displaying operation menus such as collection, refund, account checking and the like, dynamically displaying key information such as transaction amount, payment mode, merchant name and the like, and generating an encrypted collection code based on order information in real time to support a self-defined validity period (such as 1 minute).
The information processing and storage module can process tasks such as image recognition, card transaction, network communication and the like in parallel, can store real-time transaction data and temporary files, and can store transaction logs, merchant configuration and encryption keys.
The communication module is used for the communication between the terminal equipment and the remote background system.
According to the POS terminal provided by the embodiment of the application, the functions of basic data processing, data storage and data communication can be provided, the whole operation flow of the receipt terminal is completed, the seamless switching between different banks and different accounts is realized, the accurate and convenient receipt operation is ensured, the POS terminal is multiplexed in multiple accounts, the purchasing and maintenance cost of the POS terminal is effectively reduced, the quick payment information acquisition and accurate processing are realized, the transaction time is shortened, the payment experience of consumers is improved, and the fund safety of the customers is ensured.
For example, a supermarket has 2000 stores in the country, POS terminals of different banks are required to be configured for each store, and management is complicated and cost-intensive. After the POS terminal is deployed, the store accounts are uniformly configured through the management background. The terminal automatically switches to the corresponding bank account according to the store ID, so that 'one machine with multiple functions' is realized. The hardware purchasing cost is reduced by 62%, the operation and maintenance efficiency is improved by 75%, and the customer complaint rate is reduced by 40%. Through the modularized design, multi-account multiplexing and safe encryption technology, the POS terminal has high efficiency, low cost and safe.
Based on the multiplexing order receiving method, the embodiment of the application also provides a multiplexing order receiving device. The device will be described in detail below in connection with fig. 4.
Fig. 4 schematically shows a block diagram of a multiplexing order-receiving apparatus according to an embodiment of the present application.
As shown in fig. 4, the multiplex acquiring apparatus 800 of this embodiment includes a generating module 810, an acquiring module 820, and an acquiring module 830.
The generating module 810 is configured to generate an order two-dimensional code including a unique transaction identifier based on the service serial number in response to an order receiving request of the order receiving system. In an embodiment, the generating module 810 may be configured to perform the operation S210 described above, which is not described herein.
The obtaining module 820 is configured to scan the two-dimensional code of the order with the sales terminal, obtain the service information and the order receiving information, and the order receiving information includes a receiving amount, a receiving bank, a receiving user name, a receiving account number, and a payment code, where the sales terminal associates in advance a plurality of receiving banks, a plurality of receiving user names, and a plurality of receiving account numbers, and supports dynamic switching of the associated accounts in the order receiving operation. In an embodiment, the obtaining module 820 may be configured to perform the operation S220 described above, which is not described herein.
And the order receiving module 830 is configured to confirm the service information and the order receiving information through the sales terminal, and perform an order receiving operation. In an embodiment, the order receiving module 830 may be configured to perform the operation S230 described above, which is not described herein.
According to an embodiment of the present application, the multiplex acquiring device 800 may further include an acquisition module 840 and an authentication module 850.
The collection module 840 is configured to collect device information of the sales terminal, and store the device information in the server database, where the device information includes a device number, a device model number, a communication address, and a communication key. In an embodiment, the acquisition module 840 may be configured to perform the operation S310 described above, which is not described herein.
The authentication module 850 is used for logging in the order receiving system through the sales terminal to complete the bidirectional authentication and system sign-in based on the encryption communication key. In an embodiment, the authentication module 850 may be used to perform the operation S320 described above, which is not described herein.
Any of the generation module 810, the acquisition module 820, and the order receiving module 830 may be combined in one module to be implemented, or any of the modules may be split into a plurality of modules, according to an embodiment of the present application. Or at least some of the functionality of one or more of the modules may be combined with, and implemented in, at least some of the functionality of other modules. At least one of the generating module 810, the acquiring module 820 and the acquiring module 830 may be implemented at least in part as hardware circuitry, such as a Field Programmable Gate Array (FPGA), a Programmable Logic Array (PLA), a system on a chip, a system on a substrate, a system on a package, an Application Specific Integrated Circuit (ASIC), or in hardware or firmware in any other reasonable way of integrating or packaging the circuitry, or in any one of or a suitable combination of three of software, hardware and firmware, according to embodiments of the present application. Or at least one of the generation module 810, the acquisition module 820 and the order taking module 830 may be at least partially implemented as computer program modules that, when executed, perform the corresponding functions.
Fig. 5 schematically shows a block diagram of an electronic device adapted to implement a multiplex order reception method according to an embodiment of the application.
As shown in fig. 5, the electronic device 900 according to the embodiment of the present application includes a processor 901 that can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 902 or a program loaded from a storage section 908 into a Random Access Memory (RAM) 903. The processor 901 may include, for example, a general purpose microprocessor (e.g., a CPU), an instruction set processor and/or an associated chipset and/or a special purpose microprocessor (e.g., an Application Specific Integrated Circuit (ASIC)), or the like. Processor 901 may also include on-board memory for caching purposes. Processor 901 may include a single processing unit or multiple processing units for performing the different actions of the method flows according to embodiments of the application.
In the RAM903, various programs and data necessary for the operation of the electronic device 900 are stored. The processor 901, the ROM902, and the RAM903 are connected to each other by a bus 904. The processor 901 performs various operations of the method flow according to an embodiment of the present application by executing programs in the ROM902 and/or the RAM 903. Note that the program may be stored in one or more memories other than the ROM902 and the RAM 903. The processor 901 may also perform various operations of the method flow according to embodiments of the present application by executing programs stored in one or more memories.
According to an embodiment of the application, the electronic device 900 may also include an input/output (I/O) interface 905, the input/output (I/O) interface 905 also being connected to the bus 904. The electronic device 900 may also include one or more of an input portion 906 including a keyboard, a mouse, etc., an output portion 907 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), etc., and a speaker, etc., a storage portion 908 including a hard disk, etc., and a communication portion 909 including a network interface card such as a LAN card, a modem, etc., connected to an input/output (I/O) interface 905. The communication section 909 performs communication processing via a network such as the internet. The drive 910 is also connected to an input/output (I/O) interface 905 as needed. A removable medium 911 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is installed as needed on the drive 910 so that a computer program read out therefrom is installed into the storage section 908 as needed.
The present application also provides a computer-readable storage medium that may be included in the apparatus/device/system described in the above embodiments, or may exist alone without being assembled into the apparatus/device/system. The computer-readable storage medium carries one or more programs which, when executed, implement methods in accordance with embodiments of the present application.
According to embodiments of the application, the computer-readable storage medium may be a non-volatile computer-readable storage medium, which may include, for example, but is not limited to, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. For example, according to embodiments of the application, the computer-readable storage medium may include ROM902 and/or RAM903 and/or one or more memories other than ROM902 and RAM903 described above.
Embodiments of the present application also include a computer program product comprising a computer program containing program code for performing the method shown in the flowcharts. The program code means for causing a computer system to carry out the multiplex acquiring method provided by the embodiment of the application when the computer program product is run in the computer system.
The above-described functions defined in the system/apparatus of the embodiment of the present application are performed when the computer program is executed by the processor 901. The systems, apparatus, modules, units, etc. described above may be implemented by computer program modules according to embodiments of the application.
In one embodiment, the computer program may be based on a tangible storage medium such as an optical storage device, a magnetic storage device, or the like. In another embodiment, the computer program may also be transmitted, distributed, and downloaded and installed in the form of a signal on a network medium, via communication portion 909, and/or installed from removable medium 911. The computer program may comprise program code that is transmitted using any appropriate network medium, including but not limited to wireless, wireline, etc., or any suitable combination of the preceding.
In such an embodiment, the computer program may be downloaded and installed from the network via the communication portion 909 and/or installed from the removable medium 911. The above-described functions defined in the system of the embodiment of the present application are performed when the computer program is executed by the processor 901. The systems, devices, apparatus, modules, units, etc. described above may be implemented by computer program modules according to embodiments of the application.
According to embodiments of the present application, program code for carrying out computer programs provided by embodiments of the present application may be written in any combination of one or more programming languages, and in particular, such computer programs may be implemented in high-level procedural and/or object-oriented programming languages, and/or in assembly/machine languages. Programming languages include, but are not limited to, such as Java, c++, python, "C" or similar programming languages. The program code may execute entirely on the user's computing device, partly on the user's device, partly on a remote computing device, or entirely on the remote computing device or server. In the case of remote computing devices, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., connected via the Internet using an Internet service provider).
The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
Those skilled in the art will appreciate that the features recited in the various embodiments of the application can be combined and/or combined in a variety of ways, even if such combinations or combinations are not explicitly recited in the present application. In particular, the features recited in the various embodiments of the application can be combined and/or combined in various ways without departing from the spirit and teachings of the application. All such combinations and/or combinations fall within the scope of the application.
The embodiments of the present application are described above. These examples are for illustrative purposes only and are not intended to limit the scope of the present application. Although the embodiments are described above separately, this does not mean that the measures in the embodiments cannot be used advantageously in combination. Various alternatives and modifications can be made by those skilled in the art without departing from the scope of the application, and such alternatives and modifications are intended to fall within the scope of the application.