Payment system

Abstract

The invention discloses a payment system. The system comprises a third-party acceptance mechanism and an operation mechanism, and the third-party acceptance mechanism and the operation mechanism establish data interaction connection through a communication interface. And the third-party acceptance mechanism comprises a card issuing module and an account change module. And the card issuing module performs identity information association binding on the personal information of the user and a to-be-activated card provided by an operation mechanism and preset with a hard wallet ID to obtain an activated card, performs association mapping on the activated card and the intelligent contract sub-wallet to obtain a consumer card, and issues the consumer card to the corresponding user. The account change module responds to the account change request of the user and sends an account change message including the hard wallet ID and the account change type of the account change user to the operation mechanism. And the operation mechanism carries out fund transfer and state updating on the corresponding intelligent contract sub-wallet in combination with the account change message. According to the invention, the security guarantee of funds is enhanced, and the transparency and traceability of payment are improved.

Description

Technical Field

[0001] This application relates to the field of financial payment technology, specifically to a payment system. Background Technology

[0002] Against the backdrop of the deepening implementation of the elderly care financial strategy, how to provide more convenient payment solutions for the elderly and other special groups has become an important issue for community digital services. Community senior canteens, as meal service venues, primarily serve elderly people who have low acceptance of smart payment methods. Field research revealed that some community senior canteens operate through third-party catering companies introduced by relevant departments, receiving various subsidies. These canteens mainly rely on pre-paid meal cards for payment, using a card-swiping payment method.

[0003] However, the existing model has several problems. First, trust risks and fund security issues are prominent. Due to customers' inherent distrust of the prepaid model, the elderly population has a low tolerance for losses caused by merchants misappropriating funds or business closures for rectification, especially in cases of financial loss, which they often find difficult to bear. Second, the transparency of fund supervision is low. Under the current operating model, supervision of prepaid funds is limited to a meager 20% of the funds, and transaction details of the canteen are unavailable. The lack of effective management methods makes it difficult to ensure the safety and proper use of funds.

[0004] Therefore, how to improve the level of fund security and enhance the transparency of fund supervision in the prepayment scenario of community elderly canteens is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a payment system that can efficiently handle fluctuations in SMS traffic of different priorities while avoiding resource waste and sending delays, thereby improving overall SMS sending efficiency and user experience.

[0006] The embodiments of this application disclose the following technical solutions: A payment system includes: a third-party acceptance agency and an operating agency; the third-party acceptance agency and the operating agency establish a data interaction connection through a communication interface; the third-party acceptance agency includes a card issuance module and an account change module; The card issuance module is used to respond to a user's card activation request, associate and bind the user's personal information in the card activation request with the identity information of the card to be activated provided by the operating institution to obtain an activated card, and associate and map the activated card with a smart contract sub-wallet to obtain a consumption card and issue it to the corresponding user; the card to be activated has a preset hardware wallet identifier ID; the user's personal information includes user ID and user mobile phone number; The account change module is used to send an account change message to the operating institution in response to a user's account change request; the account change request includes a recharge request, a consumption request, a refund request, or a balance refund request; the account change message includes the hard wallet ID of the user whose account has changed and the type of account change; The operating organization is used to transfer funds and update the status of the corresponding smart contract sub-wallet based on the account change message. Any participating merchant equipped with the card recognition device of the aforementioned third-party acceptance agency can read the physical card information of the consumer card and perform transaction operations through the terminal device; the card recognition device is used to identify the physical card of the consumer card.

[0007] In one possible implementation, when the account change request includes a recharge request, the third-party processing agency is specifically used for: In response to a user's recharge request, a recharge request message is sent to the operating institution; the recharge request message includes the user's hardware wallet ID and the recharge amount; The operating organization is specifically used to: determine the corresponding smart contract sub-wallet based on the hard wallet ID of the recharge user to obtain the first target wallet, and transfer funds from the corporate advance payment account to the first target wallet based on the recharge amount.

[0008] In one possible implementation, when the account change request includes a consumption request, the third-party processing agency is specifically used for: In response to a user's consumption request, the system queries the corresponding preferential policy for the user who issued the consumption request and sends a consumption request message to the operating institution based on the preferential policy; the consumption request message includes the consumer's hardware wallet ID, the price of the consumed goods, and the preferential policy. The operating organization is specifically used to: determine the corresponding smart contract sub-wallet based on the consumer's hard wallet ID to obtain the second target wallet, calculate the consumption amount based on the preferential policy and the price of the consumer goods, deduct funds from the first target wallet based on the consumption amount and transfer the funds to the merchant's collection account.

[0009] In one possible implementation, when the account change request includes a return request, the third-party processing agency is specifically used for: In response to a user's return request, a return request message is sent to the operating organization; the return request message includes the user's hardware wallet ID and the actual purchase price of the returned goods; The operating organization is specifically used to: determine the corresponding smart contract sub-wallet based on the hard wallet ID of the returning user to obtain a third target wallet, and return the funds from the merchant settlement account to the third target wallet based on the actual consumption price of the returned goods.

[0010] In one possible implementation, when the account change request includes a balance refund request, the third-party processing agency is specifically used for: In response to a user's balance refund request, a balance refund message is sent to the operating institution; the balance refund message includes the hard wallet ID of the user whose balance is being refunded. The operating organization is specifically used to: determine the corresponding smart contract sub-wallet based on the hard wallet ID of the user whose balance is being refunded, obtain the fourth target wallet, and refund all the balance in the fourth target wallet to the original source.

[0011] In one possible implementation, the third-party acceptance agency further includes a transaction inquiry module; The transaction query module is used to send a transaction query request message to the operating institution in response to a user's transaction query request; the transaction query request includes balance query and / or transaction details query; the transaction query request message includes the transaction query user's hard wallet ID and query type; The operating organization is also used to determine the corresponding smart contract sub-wallet based on the hard wallet ID of the transaction query user to obtain the fifth target wallet, and to retrieve the balance data and / or historical transaction records in the fifth target wallet based on the query type.

[0012] In one possible implementation, the third-party acceptance agency also includes a card cancellation module; The card cancellation module is used to send a balance settlement message to the operating institution in response to a user's card cancellation request; the balance settlement message includes the hardware wallet ID of the user canceling the card; The operating organization is also used to determine the corresponding smart contract sub-wallet based on the hard wallet ID of the card-canceling user to obtain the sixth target wallet, clear the balance in the sixth target wallet to obtain the clearing balance, return the clearing balance to the original source, and cancel and clear the information of the consumption card corresponding to the sixth target wallet and the hard wallet ID of the card-canceling user.

[0013] In one possible implementation, the third-party acceptance agency further includes an anomaly detection module; The anomaly detection module is used to monitor abnormal account changes in real time. When abnormal behavior is detected, it issues a warning to the operating institution and conducts a risk assessment. The abnormal behavior includes frequent changes in a short period of time and large-scale fund flows.

[0014] In one possible implementation, the third-party receiving agency further includes a subsidy management module, which is used for: The system receives a list of user-specific preferential subsidies from the regulator and stores the subsidy rules in association with the user's hard wallet ID. When a user initiates a consumption request, the subsidy management module automatically matches the preferential policy corresponding to the current user and synchronizes the preferential parameters to the account change module. The account change module then attaches the preferential information when generating the consumption request message, so that the operating institution can calculate the actual consumption amount.

[0015] In one possible implementation, the third-party acceptance agency further includes a user authentication module; The user authentication module is used to verify the user's identity when the user makes account changes.

[0016] Compared with the prior art, this application has the following beneficial effects: This application provides a payment system comprising two core entities: a third-party acceptance agency and an operating agency. These two entities establish a real-time data interaction connection through a communication interface, forming a collaborative architecture of "front-end service - back-end control." The third-party acceptance agency is responsible for providing operational entry points to users and partner merchants, specifically including a card issuance module and an account change module. The core function of the card issuance module is to link "user identity - hardware carrier - virtual account." This involves first binding the user's personal information (including user identifier (ID) and user's mobile phone number) with a pre-configured hardware wallet ID on a card to be activated by the operating agency, generating an activated card. Then, the activated card is mapped to a smart contract sub-wallet, ultimately forming a usable consumption card that is issued to the user. The account change module handles transaction request forwarding. When a user initiates an account change request such as top-up, consumption, refund, or balance refund, this module generates an account change message containing the user's hardware wallet ID and the change type, and sends it to the operating agency. As the core of backend management, the operating institution accurately locates the corresponding smart contract sub-wallet upon receiving the message, executes fund transfer operations (such as transferring funds during top-ups and deducting funds during consumption), and simultaneously updates the sub-wallet status. Furthermore, all partner merchants equipped with third-party card recognition devices can read the physical card information and complete transactions through their terminal devices. This card recognition device is the key identification carrier ensuring interaction between the physical card and the system.

[0017] This application establishes a more standardized and transparent fund management system through data interaction between third-party acceptance agencies and operating institutions. Users' personal information and cards to be activated are linked and bound through the card issuance module, forming a clear and secure consumer card. This structure effectively avoids the trust risks and fund security issues inherent in traditional prepaid models. Secondly, third-party acceptance agencies can respond in real-time to users' various account operation requests, such as top-ups, consumption, and refunds, and accurately transfer and update funds through smart contract sub-wallets. This entire process is digital, ensuring transparency of fund flows, and each transaction is clearly recorded, reducing blind spots and loopholes in fund supervision. Furthermore, partner merchants only need to equip themselves with card recognition devices to conduct transactions, reducing the requirements for merchant hardware and improving payment convenience and accessibility. In addition, this application retains the physical consumer card form and card-swiping operation process, adapting to the lower acceptance of smart payments among the elderly, ensuring both security and supervision while also considering payment convenience. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in this embodiment or the prior art, the drawings used in the description of the embodiment or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is an interaction timing diagram of a payment system provided in an embodiment of this application. Detailed Implementation

[0020] To facilitate understanding of the technical solutions provided in the embodiments of this application, the background technology involved in the embodiments of this application will be described below.

[0021] As the strategy of elderly financial services continues to advance, creating convenient and secure payment solutions that suit the usage habits of the elderly and other special groups has become a key issue that needs to be addressed in the construction of community digital services. As a core meal service venue for the elderly, community canteens for the elderly mainly serve elderly people who have low acceptance and operational ability of smart payment methods such as mobile payment and online operation. Field research shows that these canteens often adopt an operating model in which relevant departments introduce third-party catering companies to operate and provide various subsidies such as venue and funds. The corresponding meal payment settlement is based on a pre-payment model of "users recharge to meal cards and then swipe the card to consume".

[0022] However, the existing model has obvious shortcomings. On the one hand, there are trust risks and potential risks to fund security. Due to the inherent distrust of customers towards the prepaid model, if the canteen operator misappropriates the prepaid funds and "runs away" or suspends operations for rectification due to business problems, the funds already prepaid by users will be at risk of loss. Moreover, the elderly have a lower tolerance for financial losses, so this problem has a particularly significant impact on them. On the other hand, the transparency of fund supervision is seriously insufficient. Currently, only 20% of the prepaid funds are subject to weak supervision measures, and relevant departments cannot obtain the specific transaction details of the canteen in real time or periodically, making it difficult to grasp the actual flow and use of funds. This results in a lack of effective management tools in the supervision process, making it impossible to achieve comprehensive and accurate supervision of prepaid funds.

[0023] To address this issue, this application provides a payment system comprising a third-party acceptance agency and an operating agency, connected via a communication interface for data interaction. Specifically, the third-party acceptance agency includes a card issuance module and an account change module, enabling more efficient management and processing of user payment needs. The card issuance module associates user personal information (such as user ID and mobile phone number) with the activation cards provided by the operating agency, generating activated cards. These activation cards have pre-set hardware wallet IDs, ensuring the security and accuracy of identity verification. Activated cards are further mapped to smart contract sub-wallets, generating consumption cards that are then issued to users. This approach simplifies the card issuance process and improves identity verification security. The account change module responds to user account change requests (such as top-ups, purchases, refunds, or balance refunds) and sends account change messages to the operating agency. These messages include the user's hardware wallet ID and the type of account change, allowing the operating agency to transfer funds and update the status of the smart contract sub-wallet based on this information. This design not only improves transaction transparency but also enhances fund security. Furthermore, partner merchants equipped with card recognition devices from third-party acceptance agencies can read the physical card information of the payment cards and conduct transactions through their terminal devices. This mechanism not only simplifies the merchant's operational process but also ensures the accuracy and security of real-time transactions. Therefore, this payment system significantly improves the level of fund security and transparency of fund supervision in the prepayment scenario of community senior canteens, solving the trust risks and transparency issues in the existing model.

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0025] See Figure 1 , Figure 1 This is an interaction timing diagram of a payment system provided in an embodiment of this application.

[0026] like Figure 1 The system described includes two core entities: a third-party acceptance agency and an operating institution (such as major banks). These two entities establish a real-time, secure data exchange connection through a communication interface, forming a collaborative closed loop of "front-end service implementation + back-end fund management." The third-party acceptance agency focuses on offline operations and data forwarding for users and partner merchants (such as community senior citizen canteens), specifically including two core functional modules: a card issuance module and an account change module. It should be noted that the community senior citizen canteens mentioned in this application are all partner merchants equipped with the card recognition devices of the aforementioned third-party acceptance agency.

[0027] In this payment system, the card issuance module and account change module of the third-party acceptance institution, together with the operating institution, constitute the core business processing link: The card issuance module is used to associate and bind the user's personal information with the card to be activated provided by the operating institution to obtain an activated card, and associate and map the activated card with the smart contract sub-wallet to obtain a consumption card and issue it to the corresponding user.

[0028] Specifically, when a user goes to the community senior citizens' canteen to initiate a card activation request, they need to provide personal information to the canteen staff (an ID card as the user ID and a mobile phone number for subsequent management). The staff then triggers the card activation process of the card issuance module in the third-party payment agency's cashier system. The card issuance module first sends a "card to be activated request" to the operating agency through a preset communication interface. This request includes the third-party payment agency's identity identifier (to ensure compliance). After the operating agency verifies the request, it sends the card to be activated data with a pre-configured hardware wallet identifier ID (a unique code used for subsequent account location) to the card issuance module.

[0029] Subsequently, the card issuance module enters the identity information association and binding stage: the user's provided identity information (such as ID card number), mobile phone number, and the hard wallet ID of the card to be activated are bound within the system to generate an activated card. This binding operation enables subsequent functions such as reporting lost cards, unblocking cards, and matching discounts. Moreover, the hard wallet ID is only associated with the user's mobile phone number to ensure information simplification and security. At the same time, the card issuance module strictly implements the "non-zero balance card opening" rule. Staff need to guide users to complete the recharge simultaneously (supporting multiple methods such as cash, WeChat, Alipay, and bank cards). Only after confirming that the recharge amount has been received will the module trigger the association mapping with the smart contract sub-wallet.

[0030] The card issuance module sends a "contract association request" to the operating institution. This request includes the hardware wallet ID of the activated card. Upon receiving the request, the operating institution creates a dedicated smart contract sub-wallet for the hardware wallet ID and establishes a one-to-one mapping relationship between the activated card and the smart contract sub-wallet. This ensures that subsequent user top-ups go directly into the smart contract sub-wallet, and that purchases are deducted directly from the sub-wallet. After the mapping is completed, the operating institution sends a "contract association successful" instruction to the card issuance module. The card issuance module then generates a physical consumption card (or activates a pre-made physical card), which is distributed to the user by staff. This completes the entire card activation process, and the user can then use the consumption card for subsequent top-ups and card-swiping transactions.

[0031] The account change module is used to send an account change message to the operating institution in response to a user's account change request.

[0032] Specifically, the account change module acts as an intermediary for user transaction requests. When a user initiates an account change request such as recharge, consumption, refund, or balance refund in the cafeteria, the module will generate an account change message based on the request type, which includes "the hard wallet ID of the user whose account has changed (used to locate the corresponding smart contract sub-wallet) + the account change type (such as recharge, consumption, refund, or balance refund)" and send it to the operating organization in real time through a preset communication interface.

[0033] The operating organization is used to transfer funds and update the status of the corresponding smart contract sub-wallet based on the account change message.

[0034] Specifically, the operating institution, as the core of backend fund management, will accurately match the corresponding smart contract sub-wallet according to the hard wallet ID after receiving the message, and execute the corresponding fund transfer operation (such as transferring funds from the corporate advance account to the sub-wallet when recharging, and deducting funds from the sub-wallet to the third-party acceptance institution's account when making consumption), while simultaneously updating the balance and transaction status of the sub-wallet.

[0035] Among them, all partner merchants (such as community senior citizen canteens and time-honored shops) equipped with third-party card recognition devices (such as third-party card aggregation terminals and POS machines) can read the hard wallet ID and other information of the physical consumer card through the terminal device to complete card top-up, consumption and other transaction operations. The card recognition device is the key recognition carrier to ensure the interaction between the physical card and the system and to ensure accurate transaction correspondence. It not only adapts to the elderly users' habits of using physical cards, but also achieves the unity of fund supervision and transaction convenience.

[0036] It should be noted that the user information involved in this application (including but not limited to user device information, user personal information, etc.) is all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0037] In one possible implementation, when the account change request includes a recharge request, the third-party receiving agency is specifically used to: send a recharge request message to the operating agency in response to the user's recharge request.

[0038] Specifically, when a user (elderly customer) uses their fund-supervised hard wallet at the cashier of a canteen (i.e., a partner merchant equipped with a card recognition device from a third-party payment institution) to initiate a top-up request to the third-party payment institution (supporting multiple payment methods such as cash, WeChat, Alipay, and bank cards), the account change module of the third-party payment institution first receives and verifies the top-up information. The module then reads the hard wallet ID of the hard wallet through the aggregation terminal of the third-party payment institution, displays the user's identity information (such as name and mobile phone number) and the current balance, and confirms that the top-up amount entered by the user is correct. After confirming that the top-up amount is correct, the module generates a top-up request message containing "the hard wallet ID of the top-up user (used to accurately locate the user's exclusive account) + top-up amount (the amount of funds actually topped up by the user)" and sends the message to the operating institution through a preset communication interface.

[0039] In one possible implementation, the operating organization is specifically used to: determine the corresponding smart contract sub-wallet based on the hard wallet ID of the recharge user to obtain the first target wallet, and transfer funds from the corporate advance payment account to the first target wallet based on the recharge amount.

[0040] Specifically, after receiving a recharge request message, the operating institution first queries the associated smart contract sub-wallets within the system based on the hard wallet ID in the message, matching the unique user-specific smart contract sub-wallet (i.e., the first target wallet). Then, according to the fund supervision rules preset in the digital RMB smart contract, funds equal to the recharge amount are deducted from the operating institution's corporate advance payment account and transferred to the first target wallet in real time. After the transfer is completed, the operating institution simultaneously updates the balance status of the first target wallet and generates a "recharge successful" response instruction to the third-party acceptance institution. After receiving the instruction, the third-party acceptance institution's aggregation terminal displays the user's latest balance after the recharge, thus completing the entire recharge process. This ensures that the user's recharge funds are fully supervised by the smart contract from the moment they enter the system, avoiding the risk of misappropriation caused by direct entry into the canteen account, while also adapting to the offline operation habits of elderly users.

[0041] In one possible implementation, in response to a user's consumption request, the system queries the preferential policy corresponding to the user who issued the consumption request, and sends a consumption request message to the operating institution based on the preferential policy.

[0042] Specifically, when a user selects goods and initiates a consumption request at the community senior citizens' canteen, the account change module of the third-party processing agency first coordinates with the subsidy management module to query the pre-stored user-specific preferential policies based on the user's hard wallet ID (or associated mobile phone number, ID card number). These preferential policies are entered into the third-party processing agency by relevant departments and include rules such as age-based discounts (e.g., 10% off for 60-79 years old, 20% off for 80 years old and above) or fixed amount reductions (e.g., daily discounts of 2-6 yuan). After finding a matching preferential policy, the account change module generates a consumption request message containing "the user's hard wallet ID (used to locate the smart contract sub-wallet), the price of the consumed goods (original transaction amount), and the preferential policy (specific discount percentage or reduction amount)," which is sent to the operating agency in real time through a preset communication interface.

[0043] In one possible implementation, the operating organization is specifically used to: determine the corresponding smart contract sub-wallet based on the consumer's hard wallet ID to obtain a second target wallet, calculate the consumption amount based on the preferential policy and the price of the consumer goods, and deduct funds from the first target wallet based on the consumption amount and transfer the funds to the merchant's collection account.

[0044] Specifically, after receiving the message, the operating institution first accurately matches the corresponding smart contract sub-wallet (i.e., the second target wallet) based on the hard wallet ID to ensure that the operation target is the user's dedicated supervision account. Then, it calculates the actual consumption amount according to the preferential policy and the price of the consumed goods in the message. For example, if the price of the goods is 15 yuan and the user meets the "20% discount for those over 80 years old" policy, the actual consumption amount is 12 yuan. After the calculation is completed, the operating institution deducts 12 yuan of the actual consumption amount from the second target wallet according to the rules of the digital RMB smart contract and transfers the funds to the merchant's collection account. At the same time, the operating institution updates the balance status and transaction details of the second target wallet and generates a "successful consumption" response instruction to the third-party acceptance institution. After receiving the instruction, the third-party acceptance institution's POS machine displays the user's latest balance and discount amount after the consumption. This achieves automatic verification of the preferential policy and ensures the targeted flow of funds through the smart contract, taking into account the preferential rights and fund security of elderly users, while maintaining the simple operation process of card payment.

[0045] In one possible implementation, when the account change request includes a return request, the third-party processing agency is specifically used to: send a return request message to the operating agency in response to the user's return request.

[0046] Specifically, when a user initiates a refund request (supporting partial or full refunds) after consuming at the community senior citizens' canteen, the front-end operation is first handled by a third-party processing agency. Canteen staff use the third-party processing agency's system to query the user's corresponding historical consumption orders and confirm the actual consumption price of the returned goods (i.e., the final payment amount after deducting discounts, such as the original price of the goods being 10 yuan, and the user enjoying an 80% discount, so the actual consumption price is 8 yuan). Subsequently, the third-party processing agency's account change module generates a refund request message. This message explicitly includes the "hard wallet ID of the user returning the goods (used to accurately locate the user's exclusive smart contract sub-wallet)" and the "actual consumption price of the returned goods (ensuring that the refund amount is consistent with the original payment amount)," and is sent to the operating agency in real time through a preset secure communication interface.

[0047] In one possible implementation, the operating organization is specifically used to: determine the corresponding smart contract sub-wallet based on the hard wallet ID of the returning user to obtain a third target wallet, and return the funds from the merchant settlement account to the third target wallet based on the actual consumption price of the returned goods.

[0048] Specifically, after receiving a return request message, the operating institution first matches the corresponding smart contract sub-wallet (i.e., the third target wallet) in the system based on the hard wallet ID to ensure that the refund funds accurately correspond to the original consumption account. Then, according to the refund rules preset by the digital RMB smart contract, funds equivalent to the "actual consumption price of the returned goods" are deducted from the merchant's settlement account and returned to the third target wallet. After the funds are transferred, the operating institution updates the balance status of the third target wallet (e.g., if the original balance is 20 yuan, the balance is updated to 28 yuan after the 8 yuan refund) and generates a "return successful" response instruction to be sent to the third-party acceptance institution. After receiving the instruction, the third-party acceptance institution's system displays the return result and the updated wallet balance to the user through the canteen terminal, and simultaneously updates the transaction details for regulatory authorities (such as the Civil Affairs Bureau) to query. The entire process not only ensures that the refund funds are consistent with the original consumption path, but also ensures that the flow of funds is traceable through smart contracts, avoiding refund disputes.

[0049] In one possible implementation, when the account change request includes a balance refund request, the third-party receiving agency is specifically used to: send a balance refund message to the operating agency in response to the user's balance refund request.

[0050] Specifically, when a user brings their fund-supervised hard wallet (i.e., a consumption card) to the cashier of the community senior citizens' canteen to initiate a balance refund request, the front-end operation is first handled by a third-party processing agency. The canteen staff reads the hard wallet ID of the hard wallet through the third-party processing agency's aggregation terminal. The terminal automatically displays the user's identity information (such as name and mobile phone number) and the current wallet balance. Then, the account change module of the third-party processing agency is triggered to generate a balance refund message. This message explicitly includes "the hard wallet ID of the user whose balance is being refunded (used to accurately locate the user's exclusive smart contract sub-wallet)" and is sent to the operating agency in real time through a preset secure communication interface.

[0051] In one possible implementation, the operating organization is specifically used to: determine the corresponding smart contract sub-wallet based on the hard wallet ID of the user whose balance is being refunded, obtain a fourth target wallet, and refund all the balance in the fourth target wallet to the original wallet.

[0052] Specifically, after receiving the balance refund message, the operating institution quickly matches the corresponding smart contract sub-wallet (i.e., the fourth target wallet) in the system based on the hard wallet ID and queries the current remaining balance in that sub-wallet. Then, according to the refund rules preset in the digital RMB smart contract, combined with the user's original recharge channel (such as cash recharge, WeChat / Alipay recharge, bank card recharge), a "refund to the original payment method" operation is executed. After the funds transfer is completed, the operating institution simultaneously updates the balance status (cleared) and transaction details of the fourth target wallet, generating a "balance refund successful" response instruction and sending it back to the third-party receiving institution. After receiving the instruction, the third-party receiving institution's aggregation terminal displays the balance refund result and the cleared wallet status to the user, thus completing the entire balance refund process. This implementation method not only accurately locates the user account through the hard wallet ID to ensure the accuracy of the balance refund, but also conforms to fund supervision requirements through the "refund to the original payment method" rule, while retaining the offline operation process to adapt to the usage habits of elderly users who prefer physical interaction, thus balancing security and convenience.

[0053] If a user originally topped up their account with cash, the operator will transfer the entire balance in the fourth target wallet to the account of a third-party receiving agency, and then the canteen staff will return the balance to the user in cash. If a user originally topped up their account with a bank card or other online non-cash channels, the operator will directly refund the balance to the user's original payment account.

[0054] In one possible implementation, the third-party acceptance agency also includes a transaction query module.

[0055] The transaction query module is used to send a transaction query request message to the operating institution in response to a user's transaction query request.

[0056] Specifically, when a user goes to a community senior citizens' canteen with a fund-supervised hard wallet and initiates a transaction query request to check the balance or historical consumption, recharge, and refund records in the hard wallet, the transaction query module of the third-party acceptance agency first takes over the operation. The canteen staff reads the user's hard wallet ID through the third-party acceptance agency's aggregation terminal or dedicated query device, inquires about the user's query needs (check only the balance, check only the transaction details, or both), and then the module generates a transaction query request message based on the user's needs. This message clearly includes the "hard wallet ID of the user querying the transaction (used to accurately locate the user's exclusive smart contract sub-wallet)" and the "query type (such as marked 'balance query', 'transaction details query', or 'balance + details query')," and is sent to the operating agency in real time through a preset secure communication interface.

[0057] In one possible implementation, the operating organization is further configured to determine the corresponding smart contract sub-wallet based on the hard wallet ID of the transaction query user to obtain the fifth target wallet, and retrieve the balance data and / or historical transaction records in the fifth target wallet based on the query type.

[0058] Specifically, after receiving a query request message, the operating institution first matches the corresponding smart contract sub-wallet (i.e., the fifth target wallet) in the system based on the hard wallet ID to ensure that the query target is the user's exclusive supervised account. Then, it performs the corresponding operation according to the query type indicated in the message. If it is a balance query, it directly retrieves the current real-time balance data of the fifth target wallet; if it is a transaction details query, it extracts the historical transaction records within the sub-wallet for a specified time period (such as the last 30 days or the last 3 months), including key information such as the type of each transaction (recharge, consumption, refund), amount, time, and merchant name; if it is a query for both, it retrieves the balance data and historical transaction records simultaneously. After the information retrieval is completed, the operating institution organizes the balance data and / or historical transaction records into a standardized format and generates a query response message to be sent back to the transaction query module of the third-party acceptance agency. After receiving the message, the transaction query module displays the query results to the user in clear text or simple table format through the third-party acceptance agency terminal (such as "Current balance: 85 yuan" or "Consumption of 12 yuan at the community elderly canteen on June 10, 2025"). The entire implementation method ensures the accuracy of information retrieval through hardware wallet ID, while also adapting to the characteristics of elderly users who have weaker digital information reading ability through offline terminal display and assisted interpretation, and at the same time allowing users to keep track of account dynamics in real time.

[0059] In one possible implementation, the third-party acceptance agency further includes a card cancellation module. This card cancellation module is used to send a balance settlement message to the operating agency in response to a user's card cancellation request.

[0060] Specifically, when an elderly user, no longer using the financial monitoring hardware wallet, goes to the community senior canteen cashier with their physical card to initiate a card cancellation request, the cancellation module of a third-party processing agency first handles the front-end operation. Canteen staff read the hardware wallet ID from the hardware wallet through the third-party processing agency's cashier system, simultaneously retrieving and displaying the user's identity information (such as name and mobile phone number) and the current balance of the smart contract sub-wallet. They then confirm the user's intention to cancel the card and verify the consistency of their identity (e.g., by comparing ID card information). After confirmation, the cancellation module generates a balance settlement message containing the "hard wallet ID of the user canceling the card (used to accurately locate the smart contract sub-wallet to be cancelled)," which is sent to the operating agency in real time through a pre-set secure communication interface.

[0061] In one possible implementation, the operating organization is further configured to determine the corresponding smart contract sub-wallet based on the card cancellation user's hard wallet ID to obtain a sixth target wallet, clear the balance in the sixth target wallet to obtain a clearing balance, return the clearing balance to the original source, and cancel and clear the information of the consumption card corresponding to the sixth target wallet and the card cancellation user's hard wallet ID.

[0062] Specifically, after receiving the balance settlement message, the operating institution quickly matches the corresponding smart contract sub-wallet (i.e., the sixth target wallet) based on the hard wallet ID. First, it settles the remaining funds in that sub-wallet, calculating the settlement balance to be refunded to the user. Then, following the "refund to original payment method" principle, the funds are returned. If the user's original payment method was cash, the operating institution transfers the settlement balance to the account of a third-party receiving agency, which then refunds the user in cash by cafeteria staff. If the payment method was a bank card or other online non-cash channel, the funds are directly refunded to the user's original payment account. After the funds are refunded, the operating institution cancels the sixth target wallet, freezing all its fund transfer permissions and marking it as "cancelled." Simultaneously, it removes the association mapping between the hard wallet ID and the user's identity information and smart contract sub-wallet, ensuring that the hard wallet ID cannot initiate any transaction requests after cancellation. Finally, the operating institution generates a response instruction of "balance clearing completed + account cancellation successful" and sends it to the card cancellation module of the third-party acceptance agency. After receiving the instruction, the module displays the cancellation result to the user through the terminal of the third-party acceptance agency, and informs the user that "the hard wallet after cancellation cannot restore the digital RMB payment function, but can be kept as a souvenir". This completes the entire card cancellation process.

[0063] In one possible implementation, the third-party acceptance agency also includes an anomaly detection module.

[0064] The anomaly detection module is used to monitor abnormal account changes in real time. When abnormal behavior is detected, it issues a warning to the operating institution and conducts a risk assessment.

[0065] In the "Prepayment Fund Supervision Scheme Based on Digital RMB Smart Contracts," the anomaly detection module of third-party acceptance institutions (such as third-party acceptance agencies) provides proactive protection for user account security through real-time monitoring and risk linkage mechanisms. The specific implementation logic is as follows: The anomaly detection module establishes a data synchronization channel with the account change module and transaction query module of the third-party acceptance agency to obtain real-time account change data of all users (including the time, amount, hard wallet ID, and merchant information of operations such as top-ups, consumption, refunds, and balance refunds) and historical transaction baselines (e.g., elderly users typically consume 1-2 times per day, with single consumption amounts mostly below 50 yuan, and top-up amounts concentrated in the 100-500 yuan range); the module has built-in abnormal behavior recognition. The rules define abnormal behavior when account changes are detected and triggered. Examples include "frequent changes in a short period of time" (e.g., the same hard wallet ID initiates 3 or more recharge / consumption requests within 1 hour, exceeding the frequency of normal operations for elderly users), "large amount of funds flow" (single recharge or consumption amount exceeds 500 yuan, exceeding the limit of small-amount password-free payment set by the scheme, or single balance refund amount exceeds 1,000 yuan, deviating from the daily prepayment scale of elderly users). In addition, it can also identify potential risk behaviors such as "transactions across infrequently used merchants" (e.g., the same hard wallet ID regularly consumes at cafeteria A, but suddenly initiates a large consumption at an unfamiliar merchant B) and "operations during abnormal time periods" (e.g., initiating account change requests between 2-6 am, which is not the normal activity period for elderly users).

[0066] Upon detecting abnormal behavior, the anomaly detection module immediately performs a dual response: First, it generates a risk warning message containing the "hard wallet ID of the abnormal account, the type of abnormal behavior (e.g., '3 top-ups within 1 hour'), ​​the time and amount of the abnormal operation, and the associated merchant information," which is sent in real time to the operating institution (e.g., ICBC) through a preset encrypted communication interface. Simultaneously, it suspends the processing authority for subsequent account change requests for that hard wallet ID to prevent the risk from escalating. Second, it initiates a risk assessment process, combining the hard wallet ID's historical transaction habits (e.g., average consumption frequency and amount range over the past six months), user identity association information (e.g., age of elderly users, frequently used activity areas), and the risk level of the abnormal behavior (e.g., "large consumption exceeding 500 yuan" is high risk, "2 top-ups in a short period" is medium risk) to generate a risk assessment report, marking the risk level as "high / medium / low" and suggesting handling methods (e.g., high risk requires manual verification of user identity, medium risk requires sending an SMS verification code to the user's bound mobile phone number for confirmation).

[0067] Upon receiving a risk warning message, the operating institution will activate its account management module to freeze the fund transfer permissions of the corresponding smart contract sub-wallet, and simultaneously report the risk to the third-party processing agency. The third-party processing agency will then notify on-site staff via the cafeteria's cashier terminal. The staff will then contact the user (e.g., by calling the user's registered mobile number) to verify the authenticity of the operation. If it is confirmed that the operation was performed by the user, the staff can submit a "risk removal application" through the system. After review by the anomaly detection module, the account change permissions for that hard wallet ID will be restored. If it is confirmed that the operation was not performed by the user, the anomaly detection module will assist the operating institution in initiating a fund protection process (e.g., freezing abnormal transaction funds and tracing fund flows), and support the user in reporting the loss of their account or modifying their information, thereby preventing financial losses due to misjudgment or malicious behavior.

[0068] In one possible implementation, the third-party acceptance agency further includes a subsidy management module, which is used to: receive a list of user-specific preferential subsidies entered by the regulator, and associate and store the subsidy rules with the user's hard wallet ID; when a user initiates a consumption request, the subsidy management module automatically matches the preferential policy corresponding to the current user and synchronizes the preferential parameters to the account change module, which then attaches the preferential information when generating the consumption request message, so that the operating agency can calculate the actual consumption amount.

[0069] Specifically, in the "Prepayment Fund Supervision Scheme Based on Digital RMB Smart Contracts," the subsidy management module of third-party acceptance institutions (such as third-party acceptance agencies) achieves accurate verification of exclusive discounts for elderly users and effective control of subsidy funds by regulators through a full-process operation of "list reception - rule association - discount matching - record synchronization." The specific implementation logic is as follows: First, the subsidy management module handles the subsidy information entry requests from regulators (such as the Pudong New Area Civil Affairs Bureau and neighborhood committees in various sub-districts). It receives user-specific preferential subsidy lists uploaded by regulators through the Ruyi Smart Elderly Care Platform system, a third-party acceptance agency. These lists include key information such as user identification (mobile phone number and ID card number associated with the hard wallet ID), corresponding subsidy rules (such as "10% discount on meals for users aged 60-79", "fixed daily discount of 3 yuan for users over 80 years old", and "daily discount of 6 yuan for special groups"), and the subsidy validity period. After receiving the list, the module automatically binds and associates each subsidy rule with the user's corresponding hard wallet ID and stores it in the local database, forming a one-to-one correspondence between "hard wallet ID and subsidy rule". This ensures that users can quickly locate exclusive discounts through their hard wallet ID when making subsequent purchases.

[0070] When a user initiates a consumption request at the community senior citizens' canteen, the subsidy management module and the account change module of the third-party processing agency work in real time: After obtaining the user's hard wallet ID and the price of the consumed goods, the account change module simultaneously sends a "discount matching request" to the subsidy management module. The subsidy management module queries the associated subsidy rules based on the hard wallet ID, automatically matches the applicable discount policy for the current user (e.g., if the user's age is identified as 82 years old, match the "20% discount" rule), and extracts the discount parameters (discount ratio "0.8" or fixed reduction amount "3 yuan") and synchronizes them to the account change module. When generating the consumption request message, the account change module includes the discount parameters as additional information (e.g., "discount type: age discount, discount ratio: 0.8") in the message and sends it to the operating institution (e.g., ICBC), so that the operating institution can accurately deduct the discount when calculating the actual consumption amount (e.g., if the price of the goods is 10 yuan, the actual consumption amount is 8 yuan after the 20% discount). The automatic verification of the discount can be completed without manual intervention, avoiding the inability of elderly users to enjoy subsidy benefits due to complicated operations.

[0071] In addition, the subsidy management module also undertakes the functions of synchronizing and statistically analyzing subsidy usage data: after each discount verification, the module automatically records information such as "discount usage time, associated hard wallet ID, subsidy rule type, actual discount amount, and corresponding consumption order number" to form a discount usage record; at the same time, it summarizes the subsidy amount details at fixed intervals (such as daily / weekly) (e.g., "users over 80 years old in a certain street have accumulated a discount of 5,000 yuan this week" and "special groups have accumulated a discount of 3,200 yuan this month"), and synchronizes them to the regulatory system through an encrypted interface. The regulatory authority can log in to the system to query real-time subsidy usage data, verify whether the subsidy funds are accurately distributed to the target users, and whether there are any violations, achieving transparent management of the entire subsidy fund process, solving the problems of "difficulty in tracking subsidy distribution and difficulty in supervising its use" in the traditional model, and helping the regulatory authority optimize subsidy policy formulation.

[0072] In one possible implementation, the third-party acceptance agency further includes a user authentication module; The user authentication module is used to verify the user's identity when the user performs account modification operations. The authentication includes, but is not limited to, multiple authentication methods such as username, password, fingerprint recognition, and facial recognition to ensure the security of user operations.

[0073] The payment system provided in this application has been described in detail above. The various embodiments in the specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

[0074] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0075] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A payment system, characterized in that, The system includes: a third-party acceptance agency and an operating agency; the third-party acceptance agency and the operating agency establish a data interaction connection through a communication interface; the third-party acceptance agency includes a card issuance module and an account change module; The card issuance module is used to respond to a user's card activation request, associate and bind the user's personal information in the card activation request with the identity information of the card to be activated provided by the operating institution to obtain an activated card, and associate and map the activated card with a smart contract sub-wallet to obtain a consumption card and issue it to the corresponding user; the card to be activated has a preset hardware wallet identifier ID; the user's personal information includes user ID and user mobile phone number; The account change module is used to send an account change message to the operating institution in response to a user's account change request; the account change request includes a recharge request, a consumption request, a refund request, or a balance refund request; the account change message includes the hard wallet ID of the user whose account has changed and the type of account change; The operating organization is used to transfer funds and update the status of the corresponding smart contract sub-wallet based on the account change message. Any participating merchant equipped with the card recognition device of the aforementioned third-party acceptance agency can read the physical card information of the consumer card and perform transaction operations through the terminal device; the card recognition device is used to identify the physical card of the consumer card.

2. The system according to claim 1, characterized in that, When the account change request includes a recharge request, the third-party processing agency is specifically used for: In response to a user's recharge request, a recharge request message is sent to the operating institution; the recharge request message includes the user's hardware wallet ID and the recharge amount; The operating organization is specifically used to: determine the corresponding smart contract sub-wallet based on the hard wallet ID of the recharge user to obtain the first target wallet, and transfer funds from the corporate advance payment account to the first target wallet based on the recharge amount.

3. The system according to claim 1, characterized in that, When the account change request includes a consumption request, the third-party processing agency is specifically used for: In response to a user's consumption request, the system queries the corresponding preferential policy for the user who issued the consumption request and sends a consumption request message to the operating institution based on the preferential policy; the consumption request message includes the consumer's hardware wallet ID, the price of the consumed goods, and the preferential policy. The operating organization is specifically used to: determine the corresponding smart contract sub-wallet based on the consumer's hard wallet ID to obtain the second target wallet, calculate the consumption amount based on the preferential policy and the price of the consumer goods, deduct funds from the first target wallet based on the consumption amount and transfer the funds to the merchant's collection account.

4. The system according to claim 1, characterized in that, When the account change request includes a return request, the third-party processing agency is specifically used for: In response to a user's return request, a return request message is sent to the operating organization; the return request message includes the user's hardware wallet ID and the actual purchase price of the returned goods; The operating organization is specifically used to: determine the corresponding smart contract sub-wallet based on the hard wallet ID of the returning user to obtain a third target wallet, and return the funds from the merchant settlement account to the third target wallet based on the actual consumption price of the returned goods.

5. The system according to claim 1, characterized in that, When the account change request includes a balance refund request, the third-party processing agency is specifically used for: In response to a user's balance refund request, a balance refund message is sent to the operating institution; the balance refund message includes the hard wallet ID of the user whose balance is being refunded. The operating organization is specifically used to: determine the corresponding smart contract sub-wallet based on the hard wallet ID of the user whose balance is being refunded, obtain the fourth target wallet, and refund all the balance in the fourth target wallet to the original source.

6. The system according to claim 1, characterized in that, The third-party acceptance agency also includes a transaction inquiry module; The transaction query module is used to send a transaction query request message to the operating institution in response to a user's transaction query request; the transaction query request includes balance query and / or transaction details query; the transaction query request message includes the transaction query user's hard wallet ID and query type; The operating organization is also used to determine the corresponding smart contract sub-wallet based on the hard wallet ID of the transaction query user to obtain the fifth target wallet, and to retrieve the balance data and / or historical transaction records in the fifth target wallet based on the query type.

7. The system according to claim 1, characterized in that, The third-party acceptance agency also includes a card cancellation module; The card cancellation module is used to send a balance settlement message to the operating institution in response to a user's card cancellation request; the balance settlement message includes the hardware wallet ID of the user canceling the card; The operating organization is also used to determine the corresponding smart contract sub-wallet based on the hard wallet ID of the card-canceling user to obtain the sixth target wallet, clear the balance in the sixth target wallet to obtain the clearing balance, return the clearing balance to the original source, and cancel and clear the information of the consumption card corresponding to the sixth target wallet and the hard wallet ID of the card-canceling user.

8. The system according to claim 1, characterized in that, The third-party acceptance agency also includes an anomaly detection module; The anomaly detection module is used to monitor abnormal account changes in real time. When abnormal behavior is detected, it issues a warning to the operating institution and conducts a risk assessment. The abnormal behavior includes frequent changes in a short period of time and large-scale fund flows.

9. The system according to claim 1, characterized in that, The third-party acceptance agency also includes a subsidy management module, which is used for: The system receives a list of user-specific preferential subsidies from the regulator and stores the subsidy rules in association with the user's hard wallet ID. When a user initiates a consumption request, the subsidy management module automatically matches the preferential policy corresponding to the current user and synchronizes the preferential parameters to the account change module. The account change module then attaches the preferential information when generating the consumption request message, so that the operating institution can calculate the actual consumption amount.

10. The system according to claim 1, characterized in that, The third-party acceptance agency also includes a user authentication module; The user authentication module is used to verify the user's identity when the user makes account changes.

Images