CN111932237B - Cloud-based one-card transaction method and system - Google Patents
Cloud-based one-card transaction method and system Download PDFInfo
- Publication number
- CN111932237B CN111932237B CN202010763094.3A CN202010763094A CN111932237B CN 111932237 B CN111932237 B CN 111932237B CN 202010763094 A CN202010763094 A CN 202010763094A CN 111932237 B CN111932237 B CN 111932237B
- Authority
- CN
- China
- Prior art keywords
- card
- cloud
- card type
- service interface
- terminal
- 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.)
- Active
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/08—Payment architectures
- G06Q20/14—Payment architectures specially adapted for billing systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F18/00—Pattern recognition
- G06F18/20—Analysing
- G06F18/25—Fusion techniques
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K17/00—Methods or arrangements for effecting co-operative working between equipments covered by two or more of main groups G06K1/00 - G06K15/00, e.g. automatic card files incorporating conveying and reading operations
-
- 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/346—Cards serving only as information carrier of service
-
- 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/349—Rechargeable cards
Abstract
The invention discloses a cloud-based one-card transaction method and system, and relates to the field of water, electricity, gas and heat prepayment card meters. And traversing the card types in the card type list to test the card type of the current card to be read until the test is successful, and loading the common service interface. According to the service selected by the user, jumping to a common service interface or a unique service interface corresponding to the card type, and scheduling an independent transaction thread event group corresponding to the card type to complete the card writing operation. The invention can integrate the disperse systems of different card types, reduces the problems of complex database installation and the like in the prior art, and has very convenient use and higher practicability.
Description
Technical Field
The invention relates to the field of water, electricity, gas and heat prepayment card meters, in particular to a cloud-based one-card transaction method and system.
Background
With the continuous progress of computer technology and the rapid development of mobile payment services, the payment services of water, electricity and heat can be directly carried out by using respective cards. However, the cards are different from each other, so that the user needs to store the cards of a plurality of card types and remember the corresponding relationship of the cards to ensure that the cards can complete the transaction service corresponding to the card types. The mode is very inconvenient, the user transaction experience is influenced, and the user transaction willingness is reduced.
Therefore, technical personnel propose a way of carrying out integrated payment by the one-card, but the payment way is not practical, and long configuration and processing time is needed for installing responsibility, selecting and connecting different payment services. Namely, the existing one-card system cannot meet the requirements of customers in the aspects of installation, payment convenience and maintenance response time.
Disclosure of Invention
Aiming at the defects in the prior art, the invention aims to provide a cloud-based one-card transaction method and system and an operation method thereof, which integrate disperse systems of different card types, reduce the problems of complex database installation and the like in the prior art, are very convenient to use and have higher practicability.
In order to achieve the above object, in a first aspect, an embodiment of the present invention provides a cloud-based one-card transaction method, including:
uploading login information of a user, acquiring a card type list corresponding to the login information after the login information is matched at the cloud, and loading independent transaction thread event groups of all card types according to the card type list;
traversing the card types in the card type list to test the card type of the current card to be read until the test is successful, and loading a common service interface;
according to the service selected by the user, jumping to a common service interface or a unique service interface corresponding to the card type, scheduling an independent transaction thread event group corresponding to the card type, and completing card writing operation.
As an optional implementation, the common service interface is an interface corresponding to a common service supported by all card types in the card type list;
the unique service interface is an interface of a unique service supported by only a single card type.
As an optional embodiment, the traversing the card types in the card type list to test the card type of the card to be read currently until the test is successful includes:
obtaining a card type used by a user last time;
and testing the card type of the current card to be read, and if the card type fails, testing other card types in the card type list until the test is successful.
As an optional implementation, the skipping to the common service interface or the unique service interface according to the service selected by the user, and scheduling the independent transaction thread event group corresponding to the card type to complete the card writing operation includes:
the cloud calculates in advance to obtain card writing data according to the business handled by the user and sends the card writing data to the terminal;
the terminal writes the card according to the card writing data, and if the card is successfully written, the card writing success information is reported to the cloud end;
and after confirming the successful card writing information, the cloud end submits the successful card writing information to the database.
As an optional implementation, the terminal writes the card according to the card writing data, and if the card is successfully written, reports the card writing success information to the cloud, including:
if the terminal writes the card according to the card writing data and the card writing fails, continuously inquiring whether to retry or not;
and if the card is not rewritten, the cloud end stores the transaction information contained in the transaction content.
As an optional embodiment, the cloud stores transaction information included in the transaction content, including:
and if the transaction content is a recharging service, the cloud end dumps the payment amount into a balance.
As an alternative embodiment, the method includes, until the card writing is successful:
and storing the step flow of the independent transaction thread event group, namely data according to the operation of the user and the time point.
As an optional implementation, the common service interface or the unique service interface corresponding to the card type is instantly connected to the cloud through HTTP + JSON.
In a second aspect, an embodiment of the present invention further provides a cloud-based one-card transaction method, which includes:
the terminal acquires and uploads login information of a user to a cloud;
after the cloud end matches the login information, obtaining a card type list corresponding to the login information, and issuing the card type list to the terminal;
the terminal loads independent transaction thread event groups of all the card types according to the card type list, traverses the card types in the card type list and tests the card type of the current card to be read until the test is successful;
and the terminal loads the common service interface according to the successfully tested card type, skips the common service interface or the unique service interface corresponding to the card type according to the service selected by the user, and schedules the independent transaction thread event group corresponding to the card type.
In a third aspect, an embodiment of the present invention further provides a cloud-based all-purpose card transaction system, which includes a terminal and a cloud:
the terminal is used for acquiring and uploading login information to a cloud;
the cloud is used for sending a card type list corresponding to the login information to the terminal after matching the login information;
the terminal is further configured to:
-loading a group of independent transaction thread events for all card types according to said list of card types;
traversing the card types in the card type list to test the card type of the current card to be read until the test is successful, and loading a common service interface;
-according to the service selected by the user, skipping to the common service interface or the unique service interface corresponding to the card type, and scheduling the independent transaction thread event group corresponding to the card type until the card writing is successful.
Compared with the prior art, the invention has the advantages that:
the cloud-based all-purpose card transaction method and system uniformly identify and read and write various card types, so that a user can use the card more conveniently, and the cloud-based all-purpose card transaction method and system have higher practicability and market popularization value. Furthermore, the invention fuses the common service interfaces of different card types, and distinguishes the common service interfaces from unique tasks, thereby reducing the complexity of the system interface and simplifying the structure of the system. Finally, the card types are all completed by respective independent transaction thread event groups, so that mutual interference is avoided when relevant data is actually processed, and meanwhile, when the card types are fused, the transaction threads are basically unchanged before fusion, and therefore complex overall modification and maintenance are not needed.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings corresponding to the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without creative efforts.
FIG. 1 is a flowchart illustrating steps of an embodiment of a cloud-based one-card transaction method according to the present invention;
FIG. 2 is a schematic diagram of testing a test card type according to an embodiment of the cloud-based one-card transaction method of the present invention;
FIG. 3 is a schematic diagram of interface loading in an embodiment of a cloud-based one-card transaction method of the present invention
FIG. 4 is a flowchart illustrating steps of a recharging service according to an embodiment of a cloud-based one-card transaction method;
fig. 5 is a flowchart illustrating steps of revoking a recharge service in an embodiment of a cloud-based one-card transaction method according to the present invention.
Detailed Description
Embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.
The embodiment of the invention provides a cloud-based one-card transaction method and system, which are used for carrying out card type identification, skipping to a common service interface or a unique service interface corresponding to a card type according to a service selected by a user, scheduling an independent transaction thread event group corresponding to the card type, integrating disperse systems of different card types, reducing the problems of complex database installation and the like in the prior art, and being very convenient to use and high in practicability.
In order to achieve the technical effect, the general idea of the application is as follows:
uploading login information of a user, acquiring a card type list corresponding to the login information after the login information is matched at the cloud, and loading independent transaction thread event groups of all card types according to the card type list;
traversing the card types in the card type list to test the card type of the current card to be read until the test is successful, and loading a common service interface;
according to the service selected by the user, jumping to a common service interface or a unique service interface corresponding to the card type, and scheduling an independent transaction thread event group corresponding to the card type to complete the card writing operation.
In summary, in the present invention, the cloud stores the card types used by the user for the user login information, so that when the user logs in, the user can issue the card types possibly used by the user for further identification. After the identification, interface skipping is carried out according to the service selected by the user, the common service corresponds to the common service interface, and the unique service interface corresponds to the card type.
In order to better understand the technical solution, the following detailed description is made with reference to specific embodiments.
Referring to fig. 1, an embodiment of the present invention provides a cloud-based all-purpose card transaction method, including:
s1: uploading login information of a user, obtaining a card type list corresponding to the login information after the login information is matched at the cloud, and loading independent transaction thread event groups of all card types according to the card type list.
According to the invention, the card types possibly used by the user are stored in the cloud, the user inputs login information when needing to transact business, and the cloud can issue to the client by matching the login information with the card types possibly used by the user, so that the client prepares an independent transaction thread event group possibly related to each card type in advance. Preferably, the client is SaaS, and the cloud is PaaS.
The login information may be manually input by the user or may be in other manners, such as facial recognition, etc., as long as the login information corresponds to the user identity information.
For example, as shown in fig. 2, a set of card type lists is configured in the cloud storage for each terminal client. When a terminal client logs in the SaaS system, the card type list CardList is read to the local through the PaaS end API interface, and an independent transaction thread event group is correspondingly loaded for each card type, wherein the independent transaction thread event group preferably comprises a dynamic library and a card operation event group.
Although the system may support multiple card types, such as SLE4442 card, ST5557 card, M1 card, CPU card, not all customers use these four cards, if all end customers round-robin the test cards and operate the cards according to all card types, significant jamming may occur, resulting in a poor operating experience for the customer. In order to improve the response speed, the invention adopts a mode of cloud matching and issuing a card type list, thereby reducing the time consumed by polling and accelerating the response speed.
S2: and traversing the card types in the card type list to test the card type of the current card to be read until the test is successful, and loading the common service interface.
When a user places a card for transaction in an identification area, the card needs to be identified by a client, and in the embodiment of the invention, the card type list issued by a polling cloud is used for testing one by one.
As a preferred embodiment, traversing the card types in the card type list to test the card type of the card to be read until the test is successful, including:
obtaining a card type used by a user last time;
and testing the card type of the current card to be read, and if the card type fails, testing other card types in the card type list until the test is successful.
In order to further increase the testing speed, the invention preferably stores the card type used by the user for the last time, and the user is generally used to always use the same card type.
For example, as shown in fig. 2, the last card type is stored in the buffer area of the local SaaS system, before each card reading operation, the card type of the card used by the user last time is taken as the starting point, the card type list CardList is traversed to search, and the corresponding card type loading card operation event group is located:
after the card operation event group is loaded, carrying out card testing operation, and if the test is successful, carrying out subsequent card reading operation; if the test fails, the CardList sequence number is incremented by 1 to point to the next card type for operation. After the card testing is successful, the last operated card type is stored in the buffer area for later use, so that the hit rate is improved, and the operation experience is increased.
S3: according to the service selected by the user, jumping to a common service interface or a unique service interface corresponding to the card type, and scheduling an independent transaction thread event group corresponding to the card type to complete the card writing operation.
Through the common service interface and the unique interface, the interfaces which need to be read and processed by a user are reduced, the data content and the architecture of the interfaces are simplified, and the maintenance is simpler. Different card type characteristic functions are extracted and manufactured into independent interfaces, and common parts are manufactured into common interfaces, so that the expansibility of a program is solved, and the development work is simplified
As a preferred embodiment, the common service interface is an interface corresponding to the common service supported by all the card types in the card type list;
the unique service interface is an interface of a unique service supported by only a single card type.
For example, as shown in fig. 3, the current user uses 4 card types, and the contents of each card type are partially overlapped and completely different. In the functional modules of account opening, IC card data inquiry and recharging card writing, different interfaces are respectively compiled for the public part and each card type difference part, and when the dynamic interface technology is used, the interfaces of the card type difference parts are fused on the public interface and are displayed to a user as a same whole, so that the maintainability and the expansibility of a program are greatly improved, and the development work of the program interface is successfully simplified. The charging of different card types is inconsistent, the charging is in a certain amount, the corresponding processing events are inconsistent, the program performs fusion after judging the card types, and dynamic event binding is performed on input frames input and calculated on an interface, so that the purposes of obtaining different processing results according to different card types on the same display interface are achieved.
As a preferred embodiment, according to the service selected by the user, skipping the common service interface or the unique service interface, and scheduling the independent transaction thread event group corresponding to the card type, to complete the card writing operation, comprising:
the cloud calculates in advance to obtain card writing data according to the business handled by the user and sends the card writing data to the terminal;
the terminal writes the card according to the card writing data, and if the card is successfully written, the card writing success information is reported to the cloud end;
and after confirming the successful card writing information, the cloud end submits the successful card writing information to the database.
In order to improve the efficiency and the safety of transaction, the invention selects a scheme that the cloud prepares data in advance and the client directly archives the data after the client confirms the success. After the user submits a business application, card writing data is calculated in advance according to the business of the user and is sent to the terminal, the terminal finishes card writing and reports success, and the cloud submits the calculated data to the database for archiving. The problem that the database, the cloud and the client are inconsistent is effectively solved, and meanwhile, the speed and the efficiency of business handling are improved.
Preferably, the service handled by the user includes a recharge service and a revocation of the current recharge operation service.
For example, as shown in fig. 4, when a customer transacts a recharge service and needs to write a card with a recharge, the data is pre-stored at the PaaS terminal, and then the card is written at the SaaS terminal. And after the card writing of the SaaS terminal is successful, the recharging data is submitted to the DB at the PaaS terminal.
Further, the terminal writes the card according to the card writing data, and if the card is successfully written, the card writing success information is reported to the cloud, including:
if the terminal writes the card according to the card writing data and the card writing fails, continuously inquiring whether to retry or not;
and if the card is not rewritten, the cloud end stores the transaction information contained in the transaction content.
As a preferred embodiment, the cloud stores the transaction information included in the transaction content, including:
if the transaction content is a recharging service, the cloud end dumps the payment amount to a balance
For example, as shown in fig. 4, for the top-up card-writing service:
the recharging card writing is initiated by the SaaS terminal, after the recharging amount/recharging amount is input by the SaaS terminal, the background thread calculates the amount due, the front-end client selects the payment mode, and then the recharging information is submitted to the cloud for taking in the HTTP + JSON mode by calling the PaaS recharging interface. After receiving the service, the cloud service judges the charging mode: if the payment mode is a cash payment mode, directly defaulting to receiving cash, pre-storing recharging information, and then returning the result to the SaaS system; if the payment is in other three-party payment modes, after the recharge information is pre-stored, a payment two-unique code is applied from a three-party payer, the payment two-unique code is returned to the SaaS system after the recharge information is successful, then a payment daemon thread (a payment result query thread and a payment overtime detection thread) is started while the SaaS terminal displays the payment two-unique code, and after the payment success is detected, the card writing process of the SaaS terminal is started as the cash payment mode. After calling interface libraries of different card types to complete card writing operation, the SaaS terminal submits card writing confirmation information to the cloud service through the PaaS interface in an HTTP + JSON mode, the cloud service changes pre-stored recharging information into formal recharging information after receiving the card writing confirmation information, and returns the formal recharging information to the SaaS system after the formal recharging information is successfully received, and the SaaS prompts a user to write the card and complete a recharging process successfully. Through the mode, the data storage is guaranteed to be correct basically, the card writing is correct, the problem that the data storage fails or the card writing fails is avoided, and the payment amount accuracy is also protected.
In the above block diagram, the formula for calculating the amount due is as follows (including 1 electric meter, 6 additional tables, and N additional fees):
W amount of writing card ＝[B Amount of purchase ÷R Transformation ratio ]+W Retreat and mend +W Preview borrowing
C Amount of purchase ＝B Amount of purchase ×P Unit price of
C Amount of money due ＝C Sum of electricity meter purchases +C Attached Table 1 purchase amount +C Attached Table 2 purchase amount +C Attached table 3 purchase amount +C Attached table 4 purchase amount +C Attached table 5 purchase amount +C Attached table 6 purchase amount +C Total sum of additional fees
Wherein
To round up the symbol, e.g.
Meaning rounding up to a specified digit refers to the smallest integer greater than x, and for the purposes of this invention the amount is generally rounded up to two decimal places, and thus, preferably, rounding up to two decimal places, e.g., C Amount of money due ＝10.123,C Last balance ＝9：
Then
Wherein W Amount of writing card For the number of cards to be written, B Amount of purchase For the number of purchases, R Transformation ratio As a conversion rate of money, W Retreat and mend For refunding, compensating quantities, W Preview borrowing To a pre-loan amount, C Amount of purchase For the amount of purchase, P Unit price of For purchase of goods, C Amount of money due Amount of money to be charged to the user, C Amount due Amount C that the user should pay Amount of electricity meter purchase Amount of money purchased on the meter, C N purchase amount in attached table Is the amount of money purchased on the nth additional table of contents.
Wherein C is Amount due The following formula also needs to be adopted. (wherein C Amount due By x substitution)
C The balance of the time ＝C Actual amount of money -C Amount due
Wherein, C This balance The amount of money remaining on the card after the transaction, C Actual amount of money The amount actually received on the card.
Similarly, as shown in fig. 5, when the card writing data needs to be revoked, the user performs a revocation operation, prestores the revocation data at the PaaS terminal, and then writes the card at the SaaS terminal. After the card writing of the SaaS terminal is successful, the recharging data is submitted to DB at the PaaS terminal
The charge cancellation is initiated by a SaaS terminal, after the SaaS automatically follows the card and reads charge information on the card, the charge information on the card (including the card writing amount of an electric meter 1+ an attached table 1-an attached table 6 on the card) is submitted to cloud service in an HTTP + JSON mode by calling a PaaS interface, and the cloud service judges whether cancellation operation is allowed or not according to business logic. If the revocation operation can be carried out, the cloud service carries out pre-revocation operation on the background database and returns complete revocable data to the SaaS terminal. And after the secondary confirmation, the SaaS terminal performs card writing cancellation operation on the card. If the card writing is successfully cancelled, information of the successful card writing cancellation is transmitted to the cloud service in an HTTP + JSON mode by calling the PaaS interface, and the cloud service stores the pre-cancellation information as cancellation data to finish the recharging cancellation operation. If the card writing revocation is failed, transferring card writing revocation failure information to cloud service in an HTTP + JSON mode by calling a PaaS interface, and clearing the previous pre-revocation information by the cloud service to finish the recharging revocation operation. Through the mode, the corresponding data in the cloud database is also cancelled while the data on the card is basically cancelled, and the phenomenon that a single side is cancelled on the card or in the cloud database cannot occur.
In the above block diagram, the determining, by the cloud service, whether revocable may include: and analyzing the card writing quantity of the electric meter and the attached table from the interface, inquiring the slave DB, calling the revocable record to be compared with the interface data if the card has the revocable record, and indicating the revocable state if the electric meter data and the attached table data are completely equal.
In the above block diagram, the pre-storing, by the cloud service, the revocation information includes: calculating the last balance, marking the purchasing information of the electric meter, marking the purchasing information of the attached tables 1 to 6 and marking the charging information of the additional fee 1 to the additional fee n. The algorithm for calculating the last balance is as follows:
C amount of purchase ＝C Amount of electricity meter purchase +C Attached Table 1 purchase amount +C Attached Table 2 purchase amount +C Attached Table 3 purchase amount +C Attached table 4 purchase amount +C Attached table 5 purchase amount +C Attached table 6 purchase amount +C Total sum of additional fees
C Last balance ＝C Current balance +C Amount of purchase -C Actual amount of money
Wherein, C Last balance The amount remaining on the card after the last transaction.
Based on the same inventive concept, the present application further provides an embodiment, which is implemented as follows.
A cloud-based one-card transaction method, comprising:
the terminal acquires and uploads login information of a user to a cloud;
after the cloud end matches the login information, obtaining a card type list corresponding to the login information, and issuing the card type list to the terminal;
the terminal loads independent transaction thread event groups of all the card types according to the card type list, traverses the card types in the card type list and tests the card type of the current card to be read until the test is successful;
and the terminal loads the common service interface according to the successfully tested card type, skips the common service interface or the unique service interface corresponding to the card type according to the service selected by the user, and schedules the independent transaction thread event group corresponding to the card type.
Various modifications and specific examples of the foregoing embodiments of the method are also suitable for this embodiment, and the detailed description of the method will be clear to those skilled in the art, so that the detailed description is omitted here for the sake of brevity.
Based on the same inventive concept, the present application further provides an embodiment, which is implemented as follows.
A cloud-based all-purpose card transaction system comprises a terminal and a cloud end:
the terminal is used for acquiring and uploading login information to a cloud;
the cloud is used for sending a card type list corresponding to the login information to the terminal after matching the login information;
the terminal is further configured to:
-loading a group of independent transaction thread events for all card types according to said list of card types;
traversing the card types in the card type list to test the card type of the current card to be read until the test is successful, and loading a common service interface;
skipping to the common service interface or the unique service interface corresponding to the card type according to the service selected by the user, and scheduling the independent transaction thread event group corresponding to the card type until the card writing is successful.
Various modifications and specific examples of the foregoing embodiments of the method are also suitable for this embodiment, and the detailed description of the method will be clear to those skilled in the art, so that the detailed description is omitted here for the sake of brevity.
Generally, the cloud-based one-card transaction method and system provided by the embodiment of the invention integrate different card-type decentralized systems to reduce the problems of complex database installation and the like in the prior art, and are very convenient to use and high in practicability.
It should be apparent to those skilled in the art that embodiments of the present invention may be provided as methods and systems, or computer program products. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, optical storage, and the like) having computer-usable program code embodied therein.
The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.
Claims (8)
1. A cloud-based one-card transaction method is characterized by comprising the following steps:
uploading login information of a user, acquiring a card type list corresponding to the login information after the login information is matched at the cloud, and loading independent transaction thread event groups of all card types according to the card type list;
traversing the card types in the card type list to test the card type of the current card to be read until the test is successful, and loading a common service interface;
according to the service selected by the user, jumping to a common service interface or a unique service interface corresponding to the card type, scheduling an independent transaction thread event group corresponding to the card type, and completing card writing operation;
the method comprises the following steps of skipping a common service interface or a unique service interface according to a service selected by a user, scheduling an independent transaction thread event group corresponding to a card type, and completing card writing operation, wherein the method comprises the following steps:
the cloud calculates in advance to obtain card writing data according to the business handled by the user and sends the card writing data to the terminal;
the terminal writes the card according to the card writing data, and if the card is written successfully, card writing success information is reported to the cloud;
after confirming the successful card writing information, the cloud end submits the successful card writing information to a database;
the common service interface is an interface corresponding to a common service supported by all the card types in the card type list;
the unique service interface is an interface of a unique service supported by only a single card type.
2. The cloud-based one-card-through transaction method according to claim 1, wherein traversing the card types in the card type list to test the card type of the card to be read until the test is successful comprises:
acquiring a card type used by a user last time;
and testing the card type of the current card to be read, and if the card type fails, testing other card types in the card type list until the test is successful.
3. The cloud-based one-card-through transaction method according to claim 1, wherein the terminal writes a card according to the card writing data, and if the card is successfully written, the card writing success information is reported to the cloud, and the method comprises the following steps:
if the terminal writes the card according to the card writing data and the card writing fails, continuously inquiring whether to retry or not;
and if the card is not rewritten, the cloud end stores the transaction information contained in the transaction content.
4. The cloud-based one-card-through transaction method of claim 3, wherein the cloud end stores transaction information contained in the transaction content, and the transaction information comprises:
and if the transaction content is a recharging service, the cloud terminal dumps the payment amount into a balance.
5. The cloud-based one-card-through transaction method according to claim 1, wherein the step until the card writing is successful comprises the following steps:
and storing the step flow of the independent transaction thread event group, namely data according to the operation of the user and the time point.
6. The cloud-based one-card-through transaction method according to claim 1, wherein the common service interface or the unique service interface corresponding to the card type is instantly connected to the cloud through HTTP + JSON.
7. A cloud-based one-card transaction method is characterized by comprising the following steps:
the terminal acquires and uploads login information of a user to a cloud;
after the cloud end matches the login information, obtaining a card type list corresponding to the login information, and issuing the card type list to the terminal;
the terminal loads independent transaction thread event groups of all the card types according to the card type list, traverses the card types in the card type list and tests the card type of the current card to be read until the test is successful;
the terminal loads a common service interface according to the successfully tested card type, skips the common service interface or a unique service interface corresponding to the card type according to the service selected by the user, and schedules an independent transaction thread event group corresponding to the card type;
the skipping to the common service interface or the unique service interface according to the service selected by the user and scheduling the independent transaction thread event group corresponding to the card type comprises the following steps:
the cloud calculates in advance to obtain card writing data according to the business handled by the user and sends the card writing data to the terminal;
the terminal writes the card according to the card writing data, and if the card is successfully written, the card writing success information is reported to the cloud end;
after confirming the successful card writing information, the cloud end submits the successful card writing information to a database;
the common service interface is an interface corresponding to a common service supported by all the card types in the card type list;
the unique service interface is an interface of a unique service supported by only a single card type.
8. The utility model provides a card leads to transaction system based on cloud which characterized in that, it includes terminal and high in the clouds:
the terminal is used for acquiring and uploading login information to a cloud;
the cloud is used for sending a card type list corresponding to the login information to the terminal after matching the login information;
the terminal is further configured to:
-loading a group of independent transaction thread events for all card types according to said list of card types;
traversing the card types in the card type list to test the card type of the current card to be read until the test is successful, and loading a common service interface;
-according to the service selected by the user, skipping to a common service interface or a unique service interface corresponding to the card type, and scheduling an independent transaction thread event group corresponding to the card type until the card writing is successful;
the skipping to the common service interface or the unique service interface according to the service selected by the user and scheduling the independent transaction thread event group corresponding to the card type until the card writing is successful comprises the following steps:
the cloud calculates in advance to obtain card writing data according to the business handled by the user and sends the card writing data to the terminal;
the terminal writes the card according to the card writing data, and if the card is successfully written, the card writing success information is reported to the cloud end;
after confirming the successful card writing information, the cloud end submits the successful card writing information to a database;
the common service interface is an interface corresponding to a common service supported by all the card types in the card type list;
the unique service interface is an interface of a unique service supported by only a single card type.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010763094.3A CN111932237B (en) | 2020-07-31 | 2020-07-31 | Cloud-based one-card transaction method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010763094.3A CN111932237B (en) | 2020-07-31 | 2020-07-31 | Cloud-based one-card transaction method and system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111932237A CN111932237A (en) | 2020-11-13 |
| CN111932237B true CN111932237B (en) | 2022-11-29 |
Family
ID=73315955
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010763094.3A Active CN111932237B (en) | 2020-07-31 | 2020-07-31 | Cloud-based one-card transaction method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111932237B (en) |
Family Cites Families (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001243434A (en) * | 2000-02-29 | 2001-09-07 | Fyuutorekku:Kk | Card type recording medium, its manufacturing method, rom inspecting method, and reader for card type recording medium |
| US20110011931A1 (en) * | 2009-07-14 | 2011-01-20 | Fidelisoft Inc. | One-Card Transaction Management System |
| CN102324076A (en) * | 2011-08-24 | 2012-01-18 | 南京中兴群力信息科技有限公司 | Unification all-purpose card payment system based on cloud calculation and method thereof |
| CN102800038B (en) * | 2012-08-13 | 2016-05-18 | 南京鑫三强科技实业有限公司 | Wisdom education E cartoon system platform based on Internet of Things and cloud computing |
| CN103021081B (en) * | 2012-11-21 | 2015-04-29 | 江苏鸿信系统集成有限公司 | Method for realizing communication and interaction between non-contact integrated circuit (IC) cards and card reading terminal on basis of multi-card fusion application |
| TWI599969B (en) * | 2013-06-25 | 2017-09-21 | yi-hong Xu | Integrated payment services for cloud trading system |
| CN104700337A (en) * | 2013-12-04 | 2015-06-10 | 大连鸿祺科技发展有限公司 | Campus card system |
| CN104063756A (en) * | 2014-05-23 | 2014-09-24 | 国网辽宁省电力有限公司本溪供电公司 | Electric power utilization information remote control system |
| CN105260885A (en) * | 2015-10-09 | 2016-01-20 | 上海中核维思仪器仪表有限公司 | Internet of things mobile phone APP self-service prepayment and cloud management system |
| CN106022176A (en) * | 2016-05-11 | 2016-10-12 | 新智数字科技有限公司 | Card recharging method, terminal, intelligent card, and card recharging system |
| CN108960810B (en) * | 2017-05-18 | 2022-04-15 | 腾讯科技（深圳）有限公司 | Card writing method and device, computer equipment and storage medium |
| CN108304245B (en) * | 2018-03-01 | 2021-05-25 | 腾讯科技（深圳）有限公司 | Interface processing method and device, computer readable medium and electronic equipment |
| CN110363511B (en) * | 2019-06-10 | 2023-08-11 | 创新先进技术有限公司 | Service realization method based on IC card, virtual IC card and mobile terminal |
| CN110442410A (en) * | 2019-07-15 | 2019-11-12 | 深圳市元征科技股份有限公司 | Embedded type interface design method, device, electronic equipment and storage medium |
-
2020
- 2020-07-31 CN CN202010763094.3A patent/CN111932237B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN111932237A (en) | 2020-11-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11410247B2 (en) | Automatic triggering of receipt delivery | |
| US7806321B1 (en) | Systems and methods for automated reward redemption | |
| CN110111107B (en) | Payment method, device, equipment and storage medium | |
| US20130030984A1 (en) | Credit card usage management system, credit card usage management method, program, and information storage medium | |
| JP2018073249A (en) | Data checking program and data checking method | |
| US20160283922A1 (en) | Information processing device, information processing method, information processing program, and storage medium storing information processing program | |
| CN110264214A (en) | It is a kind of trade bill generation and check and write off method, device and equipment | |
| CN110750692A (en) | Invoice automatic verification and sale computer processing method and device | |
| CN113706140A (en) | Cloud POS-based intelligent payment and refund method and electronic equipment | |
| US20160300203A1 (en) | Settlement system, server device, terminal device, recording medium, method and program | |
| CN112435019A (en) | General settlement method, settlement server, system and storage medium for multi-service platform | |
| US20190066075A1 (en) | System and method for providing point of sale cloud services | |
| CN111932237B (en) | Cloud-based one-card transaction method and system | |
| US7708193B1 (en) | Systems and methods for automated reward redemption | |
| CN109325766A (en) | Pricing method and device under cross-border payment scene based on Multiple Currencies | |
| CN113554509B (en) | Processing method, device, medium and electronic equipment for online payment service | |
| CN101742022B (en) | Prepayment system and method | |
| WO2017197468A1 (en) | A method and system for facilitating the delivery of goods | |
| CN111563735A (en) | Payment method and system based on block chain | |
| JPH09106422A (en) | Household economy management supporting system | |
| CN112686719B (en) | Billing method and device, storage medium and electronic equipment | |
| CN113222568B (en) | Shipping service settlement method, platform, equipment, medium and product | |
| AU2007240205A1 (en) | Automated Reconciliation of Transaction Records | |
| KR102149865B1 (en) | Method and system for generating receipt | |
| CN113409037A (en) | Hotel settlement method and settlement 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 |