Traffic payment service processing method, device and equipment

Abstract

The embodiment of the invention discloses a traffic payment service processing method, device and equipment which are applied to card swiping of a user. The method comprises the following steps: receiving a consumption fee deduction instruction correspondingly sent by an acceptance terminal corresponding to a vehicle after the acceptance terminal swipes a card; responding to the consumption fee deduction instruction, running customization logic pre-deployed in the card-swiping card, not executing fee deduction of the corresponding consumption amount on the balance in the card-swiping card actually, and returning an instruction completion result, so that the consumption fee deduction of the corresponding consumption amount is completed through the instruction completion result. And triggering the acceptance terminal or the server of the acceptance terminal to interact with a third-party payment platform, and deducting the corresponding consumption amount from the user by the third-party payment platform.

Description

Technical Field

[0001] The present invention relates to the field of electronic payment technology, and in particular to methods, devices and equipment for processing transportation payment services. Background Art

[0002] In daily life, many users pay for transportation costs such as buses and subways by scanning codes. However, in actual applications, some users still find it cumbersome to operate the code scanning method, and the reliability will be reduced when the network is weak or even no network, which may delay the user's time or even make it impossible to use the code scanning method. Some users simply do not use the code scanning method, but use the previous transportation cards, such as bus cards and subway cards, which also have problems such as needing to be recharged and low security, but are easy to operate and can pay efficiently.

[0003] Based on the above situation, there is a need for a transportation payment solution that can help further improve the user experience. Summary of the invention

[0004] One or more embodiments of the present specification provide a method, device, and apparatus for processing transportation payment services to solve the following technical problems: a transportation payment solution is needed that helps to further improve user experience.

[0005] To solve the above technical problems, one or more embodiments of this specification are implemented as follows: One or more embodiments of this specification provide a method for processing a transportation payment service, which is applied to a user's card swiping card, and the method includes: Receiving the consumption deduction instruction sent by the acceptance terminal corresponding to the transportation after the card is swiped; In response to the consumption deduction instruction, by running the customized logic pre-deployed in the card, the corresponding consumption amount is not actually deducted from the balance in the card, but the instruction completion result is returned, so that the acceptance terminal or its service end is triggered to interact with the third-party payment platform through the instruction completion result, and the third-party payment platform actually deducts the corresponding consumption amount from the user.

[0006] One or more embodiments of this specification provide a transportation payment service processing device, which is applied to a user's card swiping card, and the device includes: A deduction instruction receiving module receives a consumption deduction instruction sent by an acceptance terminal corresponding to a transportation means after the card is swiped; The disguised deduction response module responds to the consumption deduction instruction by running the customized logic pre-deployed in the card swiping card. It does not actually deduct the corresponding consumption amount from the balance in the card swiping card, but returns the instruction completion result, so that the acceptance terminal or its service end is triggered to interact with the third-party payment platform through the instruction completion result, and the third-party payment platform actually deducts the corresponding consumption amount from the user.

[0007] One or more embodiments of this specification provide a transportation payment service processing device, which is applied to a user's card swiping card, and the device includes: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute: Receiving the consumption deduction instruction sent by the acceptance terminal corresponding to the transportation after the card is swiped; In response to the consumption deduction instruction, by running the customized logic pre-deployed in the card, the corresponding consumption amount is not actually deducted from the balance in the card, but the instruction completion result is returned, so that the acceptance terminal or its service end is triggered to interact with the third-party payment platform through the instruction completion result, and the third-party payment platform actually deducts the corresponding consumption amount from the user.

[0008] At least one of the above-mentioned technical solutions adopted in one or more embodiments of the present specification can achieve the following beneficial effects: it can realize the cloud-based payment upgrade of card swipe cards such as transportation cards, while basically avoiding the transformation of the acceptance terminals corresponding to the transportation tools, and the cost is very low. The cloud-based payment upgrade is mainly implemented on the card swipe card through customized logic, which changes the main purpose of the balance in the card swipe card so that it only formally supports the response to consumption deduction instructions, thereby avoiding abnormalities in the existing logic related to the balance. In fact, the deduction is not deducted from the balance, but based on the completion result of the instruction as the response, the cloud-based third-party payment platform is triggered to deduct the user. This can respond to the user's card swiping action more flexibly and efficiently, and it also helps to complete the deduction more safely and conveniently. Users do not need to frequently recharge the card swipe card, thereby achieving a better user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0010] Figure 1 A flow chart of a method for processing a transportation payment service provided in one or more embodiments of this specification; Figure 2 A schematic diagram of a consumption deduction instruction response principle provided in one or more embodiments of this specification; Figure 3 A flowchart of a card swiping card binding solution provided for one or more embodiments of this specification; Figure 4 A flowchart of a solution for processing the accumulated amount of the day based on a disguised updated balance provided in one or more embodiments of this specification; Figure 5 A flowchart of a card-swipe-for-train business processing solution provided in one or more embodiments of this specification; Figure 6 A flowchart of a balance maintenance processing scheme for a credit card provided in one or more embodiments of this specification; FIG. 7 (a) and FIG. 7 (b) are schematic diagrams showing the principles of other systemic improvements other than the card swiping card provided in one or more embodiments of this specification; Figure 8 One or more embodiments of this specification provide corresponding Figure 1 A schematic diagram of the card reconciliation and fund flow principle of the scheme; Fig. 9 A schematic diagram of the structure of a transportation payment service processing device provided in one or more embodiments of this specification; Fig.10 A schematic diagram of the structure of a transportation payment service processing device provided in one or more embodiments of this specification. DETAILED DESCRIPTION

[0011] The embodiments of this specification provide a transportation payment service processing method, device, equipment and storage medium.

[0012] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this application, not all of them. Based on the embodiments of this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this application.

[0013] Since transportation cards such as bus cards and subway cards have the advantage of convenient card swiping, and the issuance and ownership of cards are still huge, this application considers continuing to take advantage of this advantage and upgrading the transportation cards to cloud payment, which is mainly reflected in the clever transformation of the built-in logic in the transportation cards. For the acceptance terminals corresponding to the transportation tools (for the sake of ease of understanding, they can also be called machines), such as the card swiping machines on buses and the card swiping gates at subway stations, no transformation is required, and there is little impact on the existing transportation backend system and the card issuing company system. It mainly involves the active access to cloud services (provided by third-party payment platforms), and the cost of mutual cooperation and implementation is relatively low, which can better avoid abnormal operations of existing business.

[0014] Based on this general idea, the solution of this application will be further described below.

[0015] Figure 1 A flow chart of a method for processing a transportation payment service provided in one or more embodiments of this specification, the method is applied to a user's swipe card. The user mainly refers to a passenger who uses a swipe card to swipe a card to take a means of transportation. The swipe card mainly refers to a transportation card such as a bus card or a subway card that is used by swiping a card. The swipe card mentioned in this application is an integrated circuit card, i.e., an IC card.

[0016] The business logic that can be run in the IC card, this application customizes at least part of the business logic for the card, which is called customized logic. The customized logic can be deployed in the card at the card making stage, that is, it comes with the card at the factory. In this way, it is very convenient for users. The card can be used as soon as it is in hand (for example, it can still be purchased at the transportation card sales point), realizing a weak or even close to non-sensitive upgrade; or, users can also be provided with corresponding card writing upgrade channels (for example, dedicated card writing upgrade equipment at designated sites, users' own mobile terminals such as smart phones, or some bus card machines, subway gates, etc.) to write and upgrade existing card cards, and write customized logic into the card. In this way, it is more convenient to implement the solution of this application on a large number of existing stock cards.

[0017] Figure 1 The process in includes the following steps: S102: receiving a consumption deduction instruction sent by the acceptance terminal corresponding to the transportation means after the card is swiped.

[0018] The acceptance terminal refers to the machine where users swipe their cards, such as bus card machines, subway gates, etc. When a user swipes his card to take a ride, the corresponding transportation consumption is generated. The acceptance terminal will send a consumption deduction instruction to the card to trigger the execution of the deduction process.

[0019] S104: In response to the consumption deduction instruction, by running the customized logic pre-deployed in the card, the corresponding consumption amount is not actually deducted from the balance in the card, but the instruction completion result is returned, so that the acceptance terminal or its service end is triggered to interact with the third-party payment platform through the instruction completion result, and the third-party payment platform actually deducts the corresponding consumption amount from the user.

[0020] In the prior art, users need to recharge the card in advance, and the recharged amount will be written into the card. Of course, the corresponding traffic background system will also have data records for verification and maintenance. When swiping the card, the specific interaction process between the card and the acceptance terminal can refer to some specifications or standards, such as the technical specifications of urban public transportation IC cards. In a current standard logic, it involves application selection, card information reading verification, balance inquiry, sending consumption deduction instructions, message authentication code and transaction verification code verification, etc.

[0021] Here we focus on the consumption deduction instruction. This application has modified the response logic so that it only responds to the consumption deduction instruction in form, but does not actually deduct the balance in the card, so that the balance can remain unchanged. In this case, the main purpose of the balance is no longer for consumption deduction, but to prevent the logic outside the modification from still running normally, so as to ensure the necessary degree of standardization and standardization, especially to avoid increasing the cost of modification. Moreover, since the balance in the card can be obtained without the user's top-up, it is not easy or even impossible to be directly consumed, so it helps to protect the interests of users.

[0022] For ease of understanding, combined Figure 2 Explain by way of example. Figure 2 A schematic diagram of a consumption deduction instruction response principle provided for one or more embodiments of this specification.

[0023] exist Figure 2In this case, the acceptance terminal is a public transportation POS, and the card is a public transportation CPU card. The CPU card is a type of IC card. In layman's terms, a CPU card chip contains a microprocessor, and its function is equivalent to that of a microcomputer. In this case, the card can be an IC card that uses a customized chip operating system, and the customized logic can be included in the customized chip operating system, which is COS (Chip Operating System).

[0024] The bus CPU card mainly includes a loop antenna for card swiping induction and a chip customized with COS. In addition, it also has a storage unit for storing data such as balance. The storage unit can be an independent component or included in the chip. It can be seen that the figure compares an existing actual processing method with the processing method modified based on this application. The user swipes the bus CPU card close to the bus POS. After the bus CPU card is successfully identified (some interactive actions involved here are omitted), the bus POS sends a consumption deduction instruction to the bus CPU card (assuming that the bus fare is 2 yuan). Assuming that the existing actual processing method is adopted, 2 yuan will be deducted from the balance saved in the storage unit. Assuming that the processing method modified by this application is adopted, it is actually possible not to deduct the balance, leaving the balance unchanged (so as to ensure that the balance continues to be available), and directly return the instruction completion result as a response, as if it is disguised as having completed the deduction of the balance, so that the interaction can continue to proceed.

[0025] In one or more embodiments of the present specification, the balance in the card swiped may be non-zero, which helps prevent actions such as balance query and verification from causing abnormalities, such as failure due to a determination that the charge cannot be deducted, automatic triggering of a recharge request, etc.

[0026] From the above ideas, it can be seen that since the main purpose of the balance in the card has changed and it can no longer be used directly for consumption deduction, the user does not need to frequently recharge or even recharge. Based on this, before receiving the consumption deduction instruction sent by the acceptance terminal corresponding to the transportation tool, a non-zero amount pre-written in the card can be received in advance (for example, when the card is shipped out of the factory) without the user recharging the card, as the balance of the card.

[0027] The specific setting of the non-zero amount can be determined based on factors such as balance-related consumption needs or verification rules, so that the transaction can proceed normally. For example, the non-zero amount can be set so that it is not less than the maximum single consumption amount that may occur in the business scenario corresponding to the card (for example, the maximum fare for a single bus ride, the maximum subway fare, etc.); for another example, assuming that an overdraft limit is set for the card, in this case, the non-zero amount can be set so that the sum of it and the overdraft limit is not less than the maximum single consumption amount that may occur in the business scenario corresponding to the overdraft limit and the card; in this way, the relevant verification can be successfully passed.

[0028] In one or more embodiments of this specification, the third-party payment platform can cooperate with the traffic background system (for example, the service end of the acceptance terminal, or the service end of other parties such as the card issuing company or the card issuing company connected to the service end) in advance to connect the service. After the acceptance terminal receives the instruction completion result returned by the card swiping card, the third-party payment platform can obtain the user information and the amount to be deducted (that is, the corresponding consumption amount) corresponding to the instruction completion result, and then deduct the amount to be deducted through the user's payment account on the third-party payment platform (called the third-party payment user account). It can be seen that the third-party payment platform does not deduct the balance of the card swiping card.

[0029] In order to facilitate the third-party payment platform to deduct money efficiently and correctly, the card can be bound to the third-party payment platform in advance. For example, before receiving the consumption deduction instruction sent by the acceptance terminal corresponding to the transportation tool, the card is close to the user's mobile terminal for near-field communication in advance, and the mobile terminal is equipped with the user-side program of the third-party payment platform; through near-field communication, it is bound to the third-party payment user account logged in on the user-side program, so that the corresponding consumption amount can be deducted through the third-party payment user account; the public file parameters written to the card by the receiving mobile terminal through near-field communication are so that the card can be used normally in the acceptance terminal.

[0030] Intuitively, see Figure 3 . Figure 3 A flowchart of a card swiping card binding solution provided in one or more embodiments of this specification.

[0031] Assuming that the card is customized with logic based on the solution of this application at the factory stage, the initial non-zero balance (for example, 50 yuan) can be written in at the same time, so that the user does not need to recharge. In this case, the card can be used normally after binding, otherwise it cannot be used. If the card is originally an existing transportation card, and the customized logic is written in through subsequent upgrades, then the user may have already recharged and used it before the upgrade. In order to avoid losses to the user, the balance in the card can be refunded to the user during the upgrade, and the balance mentioned in step S102 can be automatically written without recharging during the upgrade; or, no refund can be made and the amount recharged by the user can be used as the balance. After the card is bound, the solution of this application is executed, and the user is allowed to use the amount recharged before the card is unbound.

[0032] exist Figure 3 In the figure, the mini program can be a program of the relevant transportation department or card issuing company, or it can be the mini program of the third-party payment platform itself. In the latter case, the mini program backend and the third-party payment platform can be the same entity. In addition, the mini program in the figure can also be replaced by an independent application client.

[0033] Assume that the mini program is installed in the client of the third-party payment platform. The equipment can at least include the above-mentioned acceptance terminal. When binding a card, the user first starts the mini program on his mobile terminal, triggers the card binding function, and brings the mobile terminal and the card close to each other for induction. Based on near-field communication, the mini program obtains the card number of the card, and verifies whether the card number is valid through the background of the mini program. If the verification is passed, a deduction contract request is initiated to the third-party payment platform. The third-party payment platform signs for the corresponding user account and returns the result of the successful contract to the background of the mini program. After that, the mini program writes public file parameters (for example, basic information such as institution type, startup identifier, cardholder basic file, etc.) to the card so that the equipment can normally sense the card. Optionally, there can also be an activation step, thereby realizing the binding of the card. After that, the user can use the card to pay in the cloud by swiping the card to take the corresponding means of transportation.

[0034] After binding, if the card is lost, you can conveniently report the loss, unbind it, and other operations on the mini program. In addition, as mentioned earlier, you can also set a spending limit as needed, which helps improve security.

[0035] pass Figure 1The method can realize the cloud-based payment upgrade of card swipe cards such as transportation cards, and basically avoids the transformation of the acceptance terminals corresponding to the transportation tools, with very low cost. The cloud-based payment upgrade is mainly realized on the card swipe card through customized logic, which changes the main purpose of the balance in the card swipe card, so that it only formally supports the response to the consumption deduction instruction, thereby avoiding the abnormality of the existing logic related to the balance. In fact, the deduction is not deducted from the balance, but based on the completion result of the instruction as the response, the third-party payment platform in the cloud is triggered to deduct the user (here, the card swipe card, which is originally a transportation card, is used as a convenient operation bridge, and the user does not even need to recharge the transportation card). In this way, it can respond to the user's card swipe action more flexibly and efficiently, and it also helps to complete the deduction more safely and conveniently, and the user does not need to frequently recharge the card swipe card, thereby achieving a better user experience.

[0036] based on Figure 1 This specification also provides some specific implementation plans and extension plans of the method, which will be described below.

[0037] In one or more embodiments of the present specification, regardless of whether the balance is pre-written into the card without recharge or is recharged into the card by the user, a balance query step is involved when the card is swiped. In this step, taking the acceptance terminal of a bus as an example, after the acceptance terminal initiates a balance query, it will receive the balance returned by the card; the acceptance terminal can compare the minimum fare amount configured by the system (or the minimum amount threshold established by the business rules) with the balance. If the balance is not less than the minimum fare amount, the subsequent business logic will continue to execute; if the balance is less than the minimum fare amount, the acceptance terminal can report an error, terminate the transaction process, and can remind that the balance is insufficient.

[0038] It should be noted that for rail transit modes such as subways, this application further supports the setting of overdraft limits, which can be determined by adopting a strict entry and loose exit decision-making method. Taking subway fares as an example, if a stricter strategy is adopted, the sum of the balance and the overdraft limit must not be less than the maximum subway trip fare. If a looser strategy is adopted, the sum of the balance and the overdraft limit must not be less than the minimum subway trip fare.

[0039] Furthermore, it also supports periodic limits, such as daily limits. In this case, if the user's cumulative amount on that day is greater than the daily limit, the return value of the card needs to be processed separately and specially. This application has made corresponding processing for this, combined with Figure 4 illustrate.

[0040] Figure 4 A flowchart of a solution for processing the accumulated amount of the day based on a disguised updated balance provided in one or more embodiments of this specification.

[0041] It should be emphasized that in the prior art, since the balance in the transportation card will be deducted accordingly as the user's riding behavior, if the user does not further recharge, the most that can be done is to use up the balance. There is naturally such a limitation, so there is basically no overuse (even the overdraft limit is usually limited to one overdraft). If the card is lost, at most only this part of the balance will be lost.

[0042] However, in this application, since the main purpose of the balance of the card is changed, the balance can be substantially deducted. Then, in this case, in order to prevent the card from being used abnormally and unlimited rides, the Figure 4 The process in the above is used as a risk control mechanism to deal with special problems in special scenarios such as this application. Specifically, two variables, the accumulated amount on the day and the daily limit (here we use the day as an example, and a shorter or longer period can be used as needed) are introduced for control.

[0043] In this process, a formal deduction operation will be performed on the balance to make the customized logic better match the specification. Specifically, by running the customized logic pre-deployed in the card, a zero amount deduction can be performed on the balance in the card, without actually performing a deduction of the corresponding consumption amount on the balance in the card; in this way, if necessary, the original logic other than the customized logic in the card can be run normally based on the zero amount deduction result (the corresponding balance deduction action is performed, making the process more complete in form and improving the degree of standardization), thereby helping to avoid abnormal situations.

[0044] exist Figure 4 In the process, by running the custom logic pre-deployed in the card, the current consumption date (recorded as T1) and the date of the most recent consumption completed in the card transaction record in the card are read respectively (recorded as T0), and the current consumption date is compared with the date of the most recent consumption completed recorded in the card; if the current consumption date is the same as the most recent consumption date (i.e., T0 = T1), it means that it is still the current day consumption that is still being accumulated, and the balance in the card is deducted by zero (i.e., deducted by 0), and it is determined whether the current cumulative amount corresponding to the card is less than the set daily limit. If so, the current cumulative amount is updated according to the corresponding consumption amount, and the current consumption amount is added to it. If it is not less than, the transaction can be terminated, and the card returns an error; if the current consumption date is different from the most recent consumption date, the balance in the card is deducted by zero, the current cumulative amount corresponding to the card is cleared, and the current cumulative amount is updated according to the corresponding consumption amount.

[0045] In this way, after the amount is processed correctly, the card can follow the normal processing flow to perform actions such as generating a transaction verification code, a message authentication code, and continue to interact with the acceptance terminal to generate a travel record and display information on the acceptance terminal.

[0046] pass Figure 4 The solution can follow up the actual application scenarios to control the limit, and can automatically restore the limit data in the card on T+1 day, allowing users to ride normally at the scene end, improving safety imperceptibly; it can decouple the offline payment capability of the transportation card, and upgrade the payment deduction to the cloud, making the deduction simpler, more convenient and safer.

[0047] According to the previous description, taking the bus as an example, Figure 5 A flowchart of a card-swipe boarding business processing solution is provided for one or more embodiments of this specification.

[0048] exist Figure 5 In the process, the user pre-binds and activates the card to support cloud payment. When the user swipes the card to take the bus, the machine deducts the fee according to the processing logic of the physical card. Here, the balance in the card is not actually deducted. After the formal response is completed, the machine can first report the successful transaction to the user. It should be noted that the machine can prioritize the display of the balance, such as hiding it, and prompting the user to use the cloud payment method for this deduction. The machine or the machine service end determines whether the card swiped this time is a card used for cloud payment. If so, it will trigger the cloud payment processing. If not, the balance can be directly deducted according to the processing logic of ordinary physical cards. In the case of cloud payment processing, the mini program backend can receive the trip information of this time from the machine service end, and then determine the amount to be deducted, determine the deduction and account entry, and send a cloud payment request to the third-party payment platform accordingly. The third-party payment platform actually creates a transaction, deducts and records the user's third-party payment account (usually bound to a bank card), and sends an account movement reminder message to the user.

[0049] In one or more embodiments of the present specification, the purpose of the balance in the credit card is further fully changed so that it is not mainly used for deduction and payment, but is used to dynamically maintain and express the credit level (compared to ordinary credit cards, this credit level is highly changeable in real time). With the help of the credit card, the balance can be used to quickly provide or exchange credit data, avoiding the tedious query and verification of user credit in the cloud.

[0050] Based on this idea, one or more embodiments of this specification provide a flow chart of a balance maintenance processing scheme for a credit card, see Figure 6 .

[0051] Figure 6The process in includes the following steps: S602: After the third-party payment platform actually deducts the corresponding consumption amount from the user, if the deduction of the corresponding consumption amount is successful, the balance increase operation is performed on the card by running the customized logic pre-deployed in the card, so that the balance in the card increases.

[0052] In one or more embodiments of the present specification, successful deduction will not only not reduce the balance in the card, but will accumulate the balance to show the credit level of the user's cloud payment, and the higher the balance, the higher the credit level.

[0053] In this case, the balance can be used to decide how to proceed with the cloud payment process, so as to reduce the pressure on the third-party payment platform and avoid risks as much as possible. For example, according to the balance of the card, the corresponding instruction completion result is returned, so that when the balance is high enough (the corresponding threshold can be set for comparison and judgment), the decision is made to deduct the corresponding consumption amount through delayed deduction, thereby alleviating the traffic pressure, and / or when the balance is low enough, the decision is made to deduct the corresponding consumption amount through immediate deduction.

[0054] S604: If the card is swiped at a payment terminal of a designated merchant, the balance of the card or the credit data calculated based on the balance is sent to the payment terminal, so that the payment terminal processes the transaction of the user at the designated merchant in a credit payment manner.

[0055] In one or more embodiments of the present specification, especially when the swipe card is upgraded to cloud payment based on an existing transportation card, the solution of steps S604 to S606 can be implemented. This can conveniently expand the usage scenarios of the swipe card and avoid the user having to take out the mobile phone to perform more cumbersome operations to complete the payment. In this scenario, even if there is no network, the payment terminal can read the balance normally, so offline credit payment can be completed very efficiently.

[0056] The balance itself can be used directly as credit data, or as a major factor in calculating credit data. The former method is more direct and efficient.

[0057] S606: In response to the transaction, a portion of the balance in the card is locked, and after the repayment operation corresponding to the credit payment is successful, the portion of the balance is unlocked.

[0058] The repayment operation can be especially performed automatically, for example, the repayment is completed by the third-party payment platform through delayed automatic deduction. As needed, this delay process can be more dynamic and short, for example, within a few minutes, a few hours, a day, etc., so that the locked balance of the card can be unlocked and released more quickly, which helps to improve the utilization rate of the card, and helps to improve security and reduce platform risks. It is especially suitable for a large number of small payment scenarios within a day. Based on such a solution, users do not need to apply for a credit card specifically. They can use this special credit payment method conveniently by upgrading some existing transportation cards to cloud payment, and can more conveniently and widely accumulate credit data in the form of balances that are easy to provide.

[0059] The corresponding relationship between the locked balance and the consumption amount involved in the credit payment transaction can be set as needed. Here, it can be an amplified corresponding relationship, that is, part of the balance mentioned above is smaller than or even much smaller than the consumption amount corresponding to the transaction. For example, if the consumption amount is 100 yuan, the locked balance of 10 yuan can make more credit consumption with a small amount of balance (not only that, but the balance will not actually be consumed), while keeping the risk within a controllable range.

[0060] In addition, in order to allow users to still use swipe cards for transportation, a portion of the balance can be retained for verification in transportation payment scenarios.

[0061] In one or more embodiments of this specification, if the third-party payment user account is unbound from the third-party payment user account, the balance in the swipe card is converted into a free balance (referring to a balance that can be freely used like the recharge amount in an ordinary transportation card) that is less than the balance by running the custom logic pre-deployed in the card; after the card is swiped, the corresponding consumption deduction instruction is sent by the acceptance terminal corresponding to the transportation tool; in response to the consumption deduction instruction, the free balance in the card is directly deducted for the corresponding consumption amount. Therefore, even if cloud payment is temporarily no longer used, the accumulated balance is still practical, which helps to improve the enthusiasm of users.

[0062] In one or more embodiments of this specification, according to Figure 6 The idea of ​​the middle plan is Figure 1Step S104 in the above method, for returning the instruction completion result, may specifically include: returning the corresponding instruction completion result according to the balance in the card, so that when the balance is high enough, a decision is made to deduct the corresponding consumption amount by delayed deduction, so that the credit is guaranteed and it helps to reduce the system pressure; and / or when the balance is low enough, a decision is made to deduct the corresponding consumption amount by immediate deduction.

[0063] The above mainly describes the card swipe card. In addition to the card swipe card, in order to better implement the solution of this application, some other systemic improvements are also made. For intuitive reference, see Figure 7 (a) and Figure 7 (b), which are schematic diagrams of the principles of these other systemic improvements. In general, this application has a relatively small impact on systems other than the card swipe card, has a low improvement cost, is easy to implement in real time, and helps avoid abnormalities in the existing system.

[0064] Figure 7 (a) corresponds to the rail (subway, light rail, etc.) transaction scenario. In the five-layer architecture in Figure 7 (a), the adaptation system and the third-party payment platform are introduced in this application, and the other parts can be implemented according to the existing architecture. Here we mainly describe the differences from the existing architecture.

[0065] In terms of transaction processing: The above-mentioned cloud payment-supported card swipe cards can still be regarded as normal transportation cards, so the rail gates and rail clearing and settlement systems do not need to perceive their changes. In the rail five-layer architecture information link processing, no modification is required, and the transactions perceived by ACC can be consistent with those of ordinary physical cards.

[0066] It should be noted that since the card used in this application is non-prepaid (no user recharge is required), the fees can be deducted in real time according to the transaction (i.e. the instant deduction mentioned above, of course delayed deduction is also supported). In order to achieve real-time performance, two exemplary solutions are provided here: The first one, with the corresponding steps marked with numbers ① and ② in the figure, includes creating a bypass branch from the card reader host computer and sending the physical card transaction to the card issuing company's adapter system in real time (here, corresponding improvements and adaptations are needed to support it).

[0067] The second method is to reuse the links between the existing rail ACC system and the card management system of the card issuing company for real-time synchronization.

[0068] After receiving the transaction generated by the card, the card issuing company will initiate transaction deductions based on the third-party payment account bound to the card, or initiate deductions from the corresponding online wallet.

[0069] In terms of the card management blacklist process: For cards with outstanding fees (or failed deductions), the card management system needs to manage a blacklist and send the blacklist to the rail gate. Two exemplary solutions are also provided here: The first is to reuse the existing physical card blacklist delivery link, timeliness, and capacity. Through the rail ACC system parameter configuration, the five-layer architecture is transparently transmitted layer by layer, and the transparent transmission link is shown by dotted lines in the figure.

[0070] The second method is to establish an independent list distribution mechanism through the Internet ticketing link.

[0071] Figure 7(b) corresponds to the bus transaction scenario.

[0072] Similarly, in terms of transaction processing: For the above-mentioned card swipe cards that support cloud payment, the bus swipe card machines and other public transportation equipment can be charged and deducted according to the ordinary physical card logic, because the differentiated customized logic is mainly executed in the card swipe card.

[0073] Since it is a non-prepaid transaction, the fees can be deducted in real time according to the transaction. The bus equipment can send the deductions to the bus backend system in real time, and the bus backend system reuses the bus code transaction link and sends it to the card issuing company.

[0074] After receiving the transaction, the card issuing company will initiate transaction deductions based on the third-party payment account bound to the card, or initiate deductions from the corresponding online wallet.

[0075] Further, one or more embodiments of this specification also provide corresponding Figure 1 A schematic diagram of the card reconciliation and fund flow principle of the scheme, see Figure 8 . exist Figure 4 In the financial (for example, rail operators) reconciliation: the above-mentioned card swipe cards that support cloud payment are similar to ordinary physical cards, including card type, transaction amount and other data. The rail ACC system issues a physical card transaction bill for day T-1 according to business rules on day T, including transactions of swipe cards. Rail finance records accounts according to accounts receivable. After receiving the payment receipt from the issuing company to the public bank, the accounting processing is completed.

[0076] In terms of Tongka Company's reconciliation: Tongka Company obtains the full amount of physical card deduction transaction bills on T-1 from the third-party payment platform on T day, and internally checks the deductible transactions of the third-party payment platform. Check the deduction transactions, total receivable amount, and actual total amount of receipts of transactions on the third-party payment platform. And withdraw the merchant balance on the third-party payment platform to Tongka Company's reserve fund account. Check according to the track payment transaction details, and after eliminating illegal transactions, issue a track settlement bill. Tongka Company's financial accounting, accounts payable XX million, and remit the money to the track accounts receivable account through the bank.

[0077] It can be seen that the implementation of the solution of this application has little impact on systems other than swiping cards, and the implementation is relatively convenient and low-cost. Moreover, it is clear and efficient in financial reconciliation, which helps to improve the implementation enthusiasm of relevant partners.

[0078] Based on the same idea, one or more embodiments of this specification also provide devices and apparatuses corresponding to the above methods, such as Fig. 9 , Fig.10 The apparatus and device can accordingly execute the above method and related optional solutions.

[0079] Fig. 9 A schematic diagram of a transportation payment service processing device provided in one or more embodiments of this specification, which is applied to a user's card swiping card, includes: A deduction instruction receiving module 902 receives a consumption deduction instruction sent by an acceptance terminal corresponding to the transportation means after the card is swiped; The disguised deduction response module 904 responds to the consumption deduction instruction and, by running the customized logic pre-deployed in the card, does not actually deduct the corresponding consumption amount from the balance in the card, but returns the instruction completion result, so that the instruction completion result triggers the acceptance terminal or its service end to interact with the third-party payment platform, and the third-party payment platform actually deducts the corresponding consumption amount from the user.

[0080] Optionally, the fake deduction response module 904 executes a deduction of zero amount on the balance in the card by running a custom logic pre-deployed in the card, but does not actually deduct the corresponding consumption amount from the balance in the card; Based on the deduction result of zero amount, the original logic other than the customized logic in the card swiping card is run normally.

[0081] Optionally, the fake deduction response module 904 compares the current consumption date with the latest completed consumption date recorded in the card by running a custom logic pre-deployed in the card; If the current consumption date is the same as the most recent consumption date, the balance in the card is deducted to zero, and it is determined whether the accumulated amount on the day corresponding to the card is less than the set daily limit. If so, the accumulated amount on the day is updated according to the corresponding consumption amount; If the current consumption date is different from the most recent consumption date, a zero amount will be deducted from the balance in the card, the accumulated amount on the day corresponding to the card will be cleared, and the accumulated amount on the day will be updated based on the corresponding consumption amount.

[0082] Optionally, it also includes: The free-recharge balance writing module 906 receives a non-zero amount pre-written in the card as the balance of the card, without the need for the user to recharge the card, before receiving the consumption deduction instruction sent by the acceptance terminal corresponding to the transportation vehicle.

[0083] Optionally, the non-zero amount is not less than the single maximum consumption amount that may occur in the business scenario corresponding to the card swiping card, or, when an overdraft limit is set for the card swiping card, the sum of the non-zero amount and the overdraft limit is not less than the overdraft limit and the single maximum consumption amount that may occur in the business scenario corresponding to the card swiping card.

[0084] Optionally, it also includes: The card binding module 908, before receiving the consumption deduction instruction sent by the acceptance terminal corresponding to the transportation means, approaches the mobile terminal of the user to perform near field communication, and the mobile terminal is equipped with the user terminal program of the third-party payment platform; Through the near field communication, the third-party payment user account logged in on the user terminal program is bound so as to deduct the corresponding consumption amount through the third-party payment user account; The public file parameters written into the card by the mobile terminal through the near field communication are received, so that the card can be used normally in the acceptance terminal.

[0085] Optionally, it also includes: The free-recharge balance writing module 906, after the third-party payment platform actually deducts the corresponding consumption amount from the user, if the deduction of the corresponding consumption amount is successful, executes the balance increase operation on the swiping card by running the customized logic pre-deployed in the swiping card, so that the balance in the swiping card is increased.

[0086] Optionally, the disguised deduction response module 904 returns a corresponding instruction completion result according to the balance in the card, so that when the balance is high enough, a decision is made to deduct the corresponding consumption amount through delayed deduction, and / or when the balance is low enough, a decision is made to deduct the corresponding consumption amount through immediate deduction.

[0087] Optionally, the free-recharge balance writing module 906 sends the balance of the card or the credit data calculated based on the balance to the payment terminal if the card is swiped at the payment terminal of the designated merchant, so that the payment terminal processes the transaction of the user at the designated merchant in a credit payment manner; In response to the transaction, a portion of the balance in the credit card is locked, and after the repayment operation corresponding to the credit payment is successful, the portion of the balance is unlocked.

[0088] Optionally, the free-recharge balance writing module 906, if the third-party payment user account is unbound from the third-party payment user account, converts the balance in the swiping card into a free balance less than the balance by running a custom logic pre-deployed in the swiping card; The deduction instruction receiving module 902 receives the consumption deduction instruction sent by the acceptance terminal corresponding to the transportation means after the card is swiped; In response to the consumption deduction instruction, the free balance in the card is directly deducted for the corresponding consumption amount.

[0089] Optionally, the portion of the balance is less than the consumption amount corresponding to the transaction.

[0090] Optionally, the swiping card is an IC card using a customized chip operating system, and the customized logic is included in the customized chip operating system.

[0091] Fig.10 A schematic diagram of a transportation payment service processing device provided in one or more embodiments of this specification, which is applied to a user's card swiping card, includes: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute: Receiving the consumption deduction instruction sent by the acceptance terminal corresponding to the transportation after the card is swiped; In response to the consumption deduction instruction, by running the customized logic pre-deployed in the card, the corresponding consumption amount is not actually deducted from the balance in the card, but the instruction completion result is returned, so that the acceptance terminal or its service end is triggered to interact with the third-party payment platform through the instruction completion result, and the third-party payment platform actually deducts the corresponding consumption amount from the user.

[0092] Based on the same idea, one or more embodiments of this specification also provide a non-volatile computer storage medium, which is applied to a user's card swipe card, and the medium stores computer executable instructions, and the computer executable instructions are set to: Receiving the consumption deduction instruction sent by the acceptance terminal corresponding to the transportation after the card is swiped; In response to the consumption deduction instruction, by running the customized logic pre-deployed in the card, the corresponding consumption amount is not actually deducted from the balance in the card, but the instruction completion result is returned, so that the acceptance terminal or its service end is triggered to interact with the third-party payment platform through the instruction completion result, and the third-party payment platform actually deducts the corresponding consumption amount from the user.

[0093] In the 1990s, it was very clear whether the improvement of a technology was hardware improvement (for example, improvement of the circuit structure of diodes, transistors, switches, etc.) or software improvement (improvement of the method flow). However, with the development of technology, many improvements of the method flow today can be regarded as direct improvements of the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be implemented with hardware entity modules. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask chip manufacturers to design and make dedicated integrated circuit chips. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one kind of HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0094] The controller may be implemented in any suitable manner, for example, the controller may take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (e.g., software or firmware) executable by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, and the memory controller may also be implemented as part of the control logic of the memory. It is also known to those skilled in the art that, in addition to implementing the controller in a purely computer-readable program code manner, the controller may be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, such a controller may be considered as a hardware component, and the devices for implementing various functions included therein may also be considered as structures within the hardware component. Or even, the devices for implementing various functions may be considered as both software modules for implementing the method and structures within the hardware component.

[0095] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0096] For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing this specification, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0097] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0098] This specification is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of this specification. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0099] These computer program instructions may also be stored in a computer readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0100] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0101] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0102] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0103] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0104] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, an element defined by the sentence "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity or device including the element.

[0105] This specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. This specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0106] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device, equipment, and non-volatile computer storage medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0107] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0108] The above description is only one or more embodiments of this specification and is not intended to limit this specification. For those skilled in the art, one or more embodiments of this specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of one or more embodiments of this specification shall be included in the scope of the claims of this specification.

Claims

1. A method for processing transportation payment services, applied to a user's card swiping card, the method comprising: Receiving the consumption deduction instruction sent by the acceptance terminal corresponding to the transportation after the card is swiped; In response to the consumption deduction instruction, by running the customized logic pre-deployed in the card, the corresponding consumption amount is not actually deducted from the balance in the card, but the instruction completion result is returned, so that the acceptance terminal or its service end is triggered to interact with the third-party payment platform through the instruction completion result, and the third-party payment platform actually deducts the corresponding consumption amount from the user.

2. The method according to claim 1, wherein the running of the custom logic pre-deployed in the card to not actually deduct the corresponding consumption amount from the balance in the card, specifically comprises: By running the custom logic pre-deployed in the card, a zero amount is deducted from the balance in the card, but no deduction of the corresponding consumption amount is actually performed on the balance in the card; Based on the deduction result of zero amount, the original logic other than the customized logic in the card swiping card is run normally.

3. The method according to claim 2, wherein the step of executing a zero amount deduction on the balance in the card by running a custom logic pre-deployed in the card comprises: By running the custom logic pre-deployed in the card, the current consumption date is compared with the date of the most recent consumption completed recorded in the card; If the current consumption date is the same as the most recent consumption date, the balance in the card is deducted to zero, and it is determined whether the accumulated amount on the day corresponding to the card is less than the set daily limit. If so, the accumulated amount on the day is updated according to the corresponding consumption amount; If the current consumption date is different from the most recent consumption date, a zero amount will be deducted from the balance in the card, the accumulated amount on the day corresponding to the card will be cleared, and the accumulated amount on the day will be updated based on the corresponding consumption amount.

4. The method according to claim 1, before receiving the consumption deduction instruction sent by the acceptance terminal corresponding to the transportation means, the method further comprises: In the case where the user does not need to recharge the card, a non-zero amount pre-written in the card is received as the balance of the card.

5. As described in the method of claim 4, the non-zero amount is not less than the single maximum consumption amount that may occur in the business scenario corresponding to the card swiping card, or, when an overdraft limit is set for the card swiping card, the sum of the non-zero amount and the overdraft limit is not less than the overdraft limit and the single maximum consumption amount that may occur in the business scenario corresponding to the card swiping card.

6. The method according to claim 1, before receiving the consumption deduction instruction sent by the acceptance terminal corresponding to the transportation means, the method further comprises: approaching the mobile terminal of the user to perform near field communication, the mobile terminal being equipped with the user-side program of the third-party payment platform; Through the near field communication, the third-party payment user account logged in on the user terminal program is bound so as to deduct the corresponding consumption amount through the third-party payment user account; The public file parameters written into the card by the mobile terminal through the near field communication are received, so that the card can be used normally in the acceptance terminal.

7. The method according to claim 6, after the third-party payment platform actually deducts the corresponding consumption amount from the user, the method further comprises: If the deduction of the corresponding consumption amount is successful, the balance increase operation is performed on the card by running the customized logic pre-deployed in the card, so that the balance in the card increases.

8. The method according to claim 7, wherein the returning the instruction completion result specifically comprises: According to the balance in the card, the corresponding instruction completion result is returned, so that when the balance is high enough, a decision is made to deduct the corresponding consumption amount through delayed deduction, and / or when the balance is low enough, a decision is made to deduct the corresponding consumption amount through immediate deduction.

9. The method of claim 7, further comprising: If the card is swiped at a payment terminal of a designated merchant, the balance of the card or the credit data calculated based on the balance is sent to the payment terminal, so that the payment terminal processes the transaction of the user at the designated merchant in a credit payment manner; In response to the transaction, a portion of the balance in the credit card is locked, and after the repayment operation corresponding to the credit payment is successful, the portion of the balance is unlocked.

10. The method of claim 9, further comprising: If the third-party payment user account is unbound from the third-party payment user account, the balance in the swiping card is converted into a free balance less than the balance by running the custom logic pre-deployed in the swiping card; Receiving the consumption deduction instruction sent by the acceptance terminal corresponding to the transportation after the card is swiped; In response to the consumption deduction instruction, the free balance in the card is directly deducted for the corresponding consumption amount.

11. The method as claimed in claim 9, wherein the portion of the balance is less than the consumption amount corresponding to the transaction.

12. The method as claimed in claim 1, wherein the card swiping card is an IC card using a customized chip operating system, and the customized logic is contained in the customized chip operating system.

13. A transportation payment service processing device, applied to a user's card swiping card, the device comprising: A deduction instruction receiving module receives a consumption deduction instruction sent by an acceptance terminal corresponding to a transportation means after the card is swiped; The disguised deduction response module responds to the consumption deduction instruction by running the customized logic pre-deployed in the card swiping card. It does not actually deduct the corresponding consumption amount from the balance in the card swiping card, but returns the instruction completion result, so that the acceptance terminal or its service end is triggered to interact with the third-party payment platform through the instruction completion result, and the third-party payment platform actually deducts the corresponding consumption amount from the user.

14. The device of claim 13, wherein the fake deduction response module executes a zero amount deduction on the balance in the card by running a custom logic pre-deployed in the card, but does not actually deduct the corresponding consumption amount from the balance in the card; Based on the deduction result of zero amount, the original logic other than the customized logic in the card swiping card is run normally.

15. The device of claim 14, wherein the fake deduction response module compares the current consumption date with the date of the most recent consumption recorded in the card by running the custom logic pre-deployed in the card; If the current consumption date is the same as the most recent consumption date, the balance in the card is deducted to zero, and it is determined whether the accumulated amount on the day corresponding to the card is less than the set daily limit. If so, the accumulated amount on the day is updated according to the corresponding consumption amount; If the current consumption date is different from the most recent consumption date, a zero amount will be deducted from the balance in the card, the accumulated amount on the day corresponding to the card will be cleared, and the accumulated amount on the day will be updated based on the corresponding consumption amount.

16. The apparatus of claim 13, further comprising: The free-recharge balance writing module receives a non-zero amount pre-written in the card as the balance of the card, without the need for the user to recharge the card, before receiving the consumption deduction instruction sent by the acceptance terminal corresponding to the transportation vehicle.

17. In the device as described in claim 16, the non-zero amount is not less than the single maximum consumption amount that may occur in the business scenario corresponding to the card swiping card, or, when an overdraft limit is set for the card swiping card, the sum of the non-zero amount and the overdraft limit is not less than the overdraft limit and the single maximum consumption amount that may occur in the business scenario corresponding to the card swiping card.

18. The apparatus of claim 13, further comprising: The card binding module is used to perform near field communication with the user's mobile terminal before receiving the consumption deduction instruction sent by the acceptance terminal corresponding to the transportation means, and the mobile terminal is equipped with the user-side program of the third-party payment platform; Through the near field communication, the third-party payment user account logged in on the user terminal program is bound so as to deduct the corresponding consumption amount through the third-party payment user account; The public file parameters written into the card by the mobile terminal through the near field communication are received, so that the card can be used normally in the acceptance terminal.

19. The apparatus of claim 18, further comprising: The free-recharge balance writing module, after the third-party payment platform actually deducts the corresponding consumption amount from the user, if the deduction of the corresponding consumption amount is successful, executes the balance increase operation on the card swiping card by running the customized logic pre-deployed in the card swiping card, so that the balance in the card swiping card is increased.

20. In the device as described in claim 19, the disguised deduction response module returns the corresponding instruction completion result according to the balance in the card, so that when the balance is high enough, it is decided to deduct the corresponding consumption amount by delayed deduction, and / or when the balance is low enough, it is decided to deduct the corresponding consumption amount by immediate deduction.

21. The device of claim 19, wherein the free-recharge balance writing module sends the balance of the card or the credit data calculated based on the balance to the payment terminal if the card is swiped at the payment terminal of the designated merchant, so that the payment terminal processes the transaction of the user at the designated merchant in a credit payment manner; In response to the transaction, a portion of the balance in the credit card is locked, and after the repayment operation corresponding to the credit payment is successful, the portion of the balance is unlocked.

22. The apparatus of claim 21, wherein the free-recharge balance writing module converts the balance in the swipe card into a free balance less than the balance by running a custom logic pre-deployed in the swipe card if the third-party payment user account is unbound from the third-party payment user account; The deduction instruction receiving module receives the consumption deduction instruction sent by the acceptance terminal corresponding to the transportation means after the card is swiped; In response to the consumption deduction instruction, the free balance in the card is directly deducted for the corresponding consumption amount.

23. The apparatus of claim 21, wherein the portion of the balance is less than the consumption amount corresponding to the transaction.

24. The device as described in claim 13, wherein the card swiping card is an IC card using a customized chip operating system, and the customized logic is included in the customized chip operating system.

25. A transportation payment service processing device, applied to a user's card swiping card, the device comprising: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute: Receiving the consumption deduction instruction sent by the acceptance terminal corresponding to the transportation after the card is swiped; In response to the consumption deduction instruction, by running the customized logic pre-deployed in the card, the corresponding consumption amount is not actually deducted from the balance in the card, but the instruction completion result is returned, so that the acceptance terminal or its service end is triggered to interact with the third-party payment platform through the instruction completion result, and the third-party payment platform actually deducts the corresponding consumption amount from the user.

Images