Payment processing method and apparatus, electronic device, storage medium, and program product

Abstract

This application provides a payment processing method, apparatus, electronic device, storage medium, and program product. The method includes: receiving a payment transaction request from an acquiring node, the payment transaction request being triggered by a contactless payment operation of the acquiring node based on a payment terminal; processing the payment based on the payment transaction request, and determining whether the payment terminal meets the object distribution conditions of the target merchant based on the payment transaction request; when the object distribution conditions are met, sending a payment transaction response to the payment terminal, the payment transaction response including payment completion notification information and the target object of the target merchant, so that the payment terminal displays the payment completion notification information and the target object of the target merchant on the user interface. The payment result and target object distribution are completed in a single response, reducing the downlink message volume and thus significantly reducing the peak QPS pressure on the central gateway; secondly, target description information can be obtained without a secondary request, simplifying system interaction logic and network overhead.

Description

Technical Field

[0001] This application relates to the field of electronic payment technology, and in particular to a payment processing method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] With the widespread adoption of mobile payment technology, NFC (Near Field Communication) payment has become one of the core scenarios for users' daily consumption. System-level NFC payment solutions, represented by Apple Pay, greatly simplify the traditional bank card payment process through a seamless "tap" operation.

[0003] However, the existing system still requires a secondary interaction (push or scan) after the payment channel is established to write the new coupon into the terminal's local coupon package, resulting in additional channel bandwidth consumption and increasing the downlink message volume of the server by more than 30%; a secondary wake-up of the terminal's Bluetooth or Wi-Fi increases power consumption; and in high-concurrency scenarios, the secondary request increases the query rate per second (QPS) of the central network management system, causing thread backlog. Summary of the Invention

[0004] This application provides a payment processing method, apparatus, electronic device, storage medium, and program product to achieve the effects of saving network round trips, saving channel bandwidth, and reducing power consumption.

[0005] In a first aspect, an embodiment of this application provides a payment processing method, including:

[0006] Receive payment transaction requests sent by the acquiring node. The payment transaction requests are triggered by the acquiring node's contactless payment operation based on the payment terminal.

[0007] Payment processing is performed based on payment transaction requests, and based on payment transaction requests, it is determined whether the payment terminal meets the object distribution conditions of the target merchant.

[0008] If the object distribution conditions of the target merchant are met, a payment transaction response is sent to the payment terminal. The payment transaction response includes payment completion notification information and the target object of the target merchant, so that the payment terminal displays the payment completion notification information and the target object of the target merchant on the user interface.

[0009] In one embodiment, determining whether the payment terminal meets the target merchant's object distribution conditions based on the payment transaction request includes:

[0010] Obtain at least one distribution strategy corresponding to the target merchant from the distribution strategy library;

[0011] Based at least on the payment data of the payment terminal carried in the payment transaction request, and the distribution strategy, it is determined whether the payment terminal meets the object distribution conditions of the target merchant.

[0012] In one embodiment, determining whether a payment terminal meets the target merchant's object distribution conditions is based at least on payment data from the payment terminal carried in the payment transaction request and a distribution strategy, including:

[0013] Based on the payment data of the payment terminal carried in the payment transaction request, the historical payment data generated by the payment terminal at the target merchant, and the distribution strategy, it is determined whether the payment terminal meets the object distribution conditions of the target merchant.

[0014] In one embodiment, based on the payment data of the payment terminal carried in the payment transaction request, the historical payment data generated by the payment terminal at the target merchant, and the distribution strategy, it is determined whether the payment terminal meets the target merchant's object distribution conditions, including:

[0015] If the historical payment data reaches a preset number of transactions or a preset amount, then the payment terminal is determined to meet the target merchant's distribution criteria; or,

[0016] If the transaction time of the payment data falls within a preset time period, it is determined that the payment terminal meets the target merchant's object distribution conditions.

[0017] In one embodiment, based on the payment data of the payment terminal carried in the payment transaction request, the historical payment data generated by the payment terminal at the target merchant, and the distribution strategy, it is determined whether the payment terminal meets the target merchant's object distribution conditions, including:

[0018] Based on the payment data of the payment terminal carried in the payment transaction request, the historical payment data generated by the payment terminal at the target merchant, the historical usage data of the payment terminal for the target merchant's objects, and the distribution strategy, it is determined whether the payment terminal meets the object distribution conditions of the target merchant.

[0019] In one embodiment, the distribution strategy includes descriptive information about the object;

[0020] Based on the payment data from the payment terminal carried in the payment transaction request, the historical payment data generated by the payment terminal at the merchant, and the distribution strategy, it is determined whether the payment terminal meets the target merchant's object distribution conditions, including:

[0021] If the payment data of the payment terminal carried in the payment transaction request and the historical payment data generated by the payment terminal in the merchant match the target distribution strategy, it is determined that the payment terminal meets the target merchant's object distribution conditions.

[0022] The method also includes:

[0023] The target object is obtained based on the description information of the target object carried by the target distribution strategy.

[0024] In one embodiment, obtaining the target object based on the description information of the target object carried by the target distribution strategy includes:

[0025] Based on the description information of the target object, a target object that meets the description information is generated and synchronized to the target merchant's payment system.

[0026] In one embodiment, generating a target object that satisfies the description information based on the description information of the target object includes:

[0027] Based on the description information, search for target objects that match the description information from the available object database of the target merchant's payment system;

[0028] The method also includes:

[0029] After sending a payment transaction response to the payment terminal, a notification message is sent to the target merchant's payment system to trigger the target merchant's payment system to delete the target object from the available object database.

[0030] In one embodiment, before determining whether the payment terminal meets the object distribution conditions of the target merchant based on the payment transaction request, the method further includes:

[0031] Identify candidate merchants with object distribution strategies;

[0032] Based on the historical payment transaction data of the payment terminal for the candidate merchants, the target merchant is determined from the candidate merchants.

[0033] In one embodiment, the method further includes:

[0034] Call the target interface of the candidate merchant to obtain the distribution strategy of the candidate merchant;

[0035] Update the distribution strategy library based on the distribution strategies of the acquired candidate merchants;

[0036] Alternatively, update the distribution strategy library based on the updated distribution strategies reported by candidate merchants.

[0037] In one embodiment, determining whether a payment terminal meets the target merchant's object distribution conditions is based at least on payment data from the payment terminal carried in the payment transaction request and a distribution strategy, including:

[0038] If the timestamp of the distribution strategy has not expired, at least based on the payment data of the payment terminal carried in the payment transaction request and the distribution strategy, determine whether the payment terminal meets the object distribution conditions of the target merchant.

[0039] Alternatively, the method may also include:

[0040] Timestamps of the distribution strategies for polling candidate merchants;

[0041] If a candidate merchant is identified with an expired distribution policy, the expired distribution policy will be deleted.

[0042] Secondly, embodiments of this application provide a payment processing apparatus, comprising:

[0043] The receiving module is used to receive payment transaction requests sent by the acquiring node. The payment transaction request is triggered by the acquiring node's contactless payment operation based on the payment terminal.

[0044] The determination module is used to process payments based on payment transaction requests and, based on payment transaction requests, determine whether the payment terminal meets the object distribution conditions of the target merchant.

[0045] The processing module is used to send a payment transaction response to the payment terminal when the object distribution conditions of the target merchant are met. The payment transaction response includes payment completion notification information and the target object of the target merchant, so that the payment terminal can display the payment completion notification information and the target object of the target merchant on the user interface.

[0046] Thirdly, embodiments of this application provide a payment processing method, including:

[0047] Based on contactless payment operations, the acquiring node is triggered to generate a payment transaction request;

[0048] Receive payment transaction response sent by UnionPay, which includes payment completion notification information and the target object of the target merchant, so as to display the payment completion notification information and the target object of the target merchant on the user interface;

[0049] The payment transaction response is initiated by UnionPay based on the payment transaction request sent by the acquiring node, and then sent based on the payment transaction request, provided that the object distribution conditions of the target merchant are met.

[0050] Fourthly, embodiments of this application provide a payment processing method, including:

[0051] A payment transaction request is triggered by a contactless payment operation based on a payment terminal.

[0052] Send the payment transaction request to UnionPay;

[0053] UnionPay processes the payment based on the payment transaction request and, if the object distribution conditions of the target merchant are met, sends a payment transaction response to the payment terminal. The payment transaction response includes a payment completion notification and the target object of the target merchant, so that the payment terminal can display the payment completion notification and the target object of the target merchant on the user interface.

[0054] Fifthly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0055] The memory stores instructions that the computer executes;

[0056] The processor executes computer execution instructions stored in memory, causing the processor to perform any of the methods described above.

[0057] Sixthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement any of the methods described above.

[0058] In a seventh aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements any of the methods described above.

[0059] This application provides a payment processing method, apparatus, electronic device, storage medium, and program product. The method includes: receiving a payment transaction request sent by an acquiring node, the payment transaction request being triggered by a contactless payment operation of the acquiring node based on a payment terminal; performing payment processing based on the payment transaction request, and determining whether the payment terminal meets the object distribution conditions of the target merchant based on the payment transaction request; if the object distribution conditions of the target merchant are met, sending a payment transaction response to the payment terminal, the payment transaction response including payment completion notification information and the target object of the target merchant, so that the payment terminal displays the payment completion notification information and the target object of the target merchant on the user interface. In this application, when processing a payment transaction, the determination of whether the object (such as a coupon) distribution conditions of the target merchant are met is performed in the same processing stage, and only one payment transaction response is sent, which includes the payment completion notification and the target object of the target merchant (such as a coupon code, benefits information, etc.); the payment result and target object distribution are completed in a single response, reducing the downlink message volume by about 50%, thereby significantly reducing the peak QPS pressure of the central gateway. Meanwhile, since the payment terminal can obtain the target description information without making a second request, the user experience is smoother, and the system interaction logic and network overhead are also simplified. Attached Figure Description

[0060] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0061] Figure 1 A flowchart illustrating a payment processing method provided in an embodiment of this application;

[0062] Figure 2 A flowchart illustrating a payment processing method provided in another embodiment of this application;

[0063] Figure 3 A schematic diagram illustrating the interaction between a payment terminal and an acquiring node according to an embodiment of this application;

[0064] Figure 4 This is a schematic diagram of the structure of a payment processing device provided in an embodiment of this application;

[0065] Figure 5 A schematic diagram of the structure of the electronic device provided in this application.

[0066] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0067] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0068] First, let me explain the terms used in this application:

[0069] PassKit Configuration: Ensure that the associated StoreIdentifiers or locations fields are correctly set in PassKit to match merchants.

[0070] VAS processing: In the Apple Pay payment process, the iPhone automatically recognizes and responds to the VAS probe command sent by the POS, and returns an NDEF message containing coupon information.

[0071] HCE Configuration: The application needs to register as an HCE service and listen for a specific AID. Simultaneously, the background service must be prepared to respond to custom APDU commands.

[0072] NDEF Construction: Construct an NDEF message conforming to the UCTP standard based on the current transaction context and return it to the POS machine via HCE.

[0073] In existing NFC near-field communication payments, a secondary interaction (push or scan) is still required after the payment channel is established to write the new voucher into the terminal's local voucher package. This results in additional channel bandwidth usage and increases the downlink message volume by more than 30%. It also requires a secondary wake-up of the terminal's Bluetooth or Wi-Fi, increasing power consumption. Furthermore, in high-concurrency scenarios, the secondary request increases the query rate per second (QPS) of the central network management system, leading to thread backlog.

[0074] To address the shortcomings of existing technologies, the inventors of this solution have creatively designed a new approach. This solution provides a payment processing method that solves the problems of excessive channel bandwidth consumption and increased power consumption associated with existing technologies. The specific application scenario for this application is NFC payment processing, including high-frequency consumption areas such as catering, retail, and transportation. The system architecture of this application encompasses payment terminal devices (iOS or Android phones), acquiring nodes, mainstream payment networks and clearing organizations such as Visa and MasterCard; mobile payment and wallet service providers such as Apple Pay, Google Pay, Samsung Pay, and mobile banking apps from major banks; large acquiring institutions and payment aggregators; and commercial banks and card issuers.

[0075] This application provides a payment processing method that, during payment transaction processing, determines whether the target merchant's object (e.g., coupon) distribution conditions are met in the same processing stage, and sends only one payment transaction response, which includes a payment completion notification and the target merchant's target object (e.g., coupon code, benefits information). By completing the payment result and target object distribution in a single response, the downlink message volume is reduced by approximately 50%, significantly lowering the peak QPS pressure on the central gateway. Furthermore, since the payment terminal can obtain the target description information without a secondary request, the user experience is smoother, and the system interaction logic and network overhead are simplified.

[0076] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0077] like Figure 1 As shown, Figure 1This is a flowchart illustrating a payment processing method provided in an embodiment of this application. The method involves a payment terminal, an acquiring node, and a UnionPay terminal, and specifically includes the following steps:

[0078] Step S101: The acquiring node triggers a payment transaction request based on the contactless payment operation of the payment terminal.

[0079] In one embodiment, the contactless payment operation is performed via a near-field communication control module.

[0080] Specifically, Near Field Communication (NFC) refers to short-range wireless communication technology used for data exchange between devices, such as the ISO / IEC 14443-A standard. Payment terminals use NFC to conduct payment transactions with POS terminals. The POS terminal uploads the payment message to the acquiring node, which parses the message to obtain the payment transaction data. This data includes merchant information, payment terminal identifier, payment amount, and payment time. For example, if a user uses Apple Pay to spend 50 yuan at a merchant, the transaction data includes the merchant ID, transaction amount, and device SEID (payment terminal identifier).

[0081] Step S102: The acquiring node sends a payment transaction request to UnionPay.

[0082] Step S103: UnionPay processes the payment based on the payment transaction request and determines whether the payment terminal meets the target merchant's object distribution conditions based on the payment transaction request.

[0083] Specifically, upon receiving a payment transaction request, UnionPay performs two key actions simultaneously: first, it completes traditional payment processing (including transaction routing, issuing bank authorization, and risk control); second, within the same processing stage, based on the merchant, transaction, user, and terminal information carried in the payment transaction request, it determines in real time whether the transaction meets the target merchant's preset object distribution conditions. For example, when a user successfully pays a sum of money at Starbucks using NFC, UnionPay, while notifying the issuing bank of the deduction, triggers the object distribution conditions to verify whether the transaction meets the condition of "contactless payment for coupons at catering merchants."

[0084] Step S104: When the object distribution conditions of the target merchant are met, UnionPay sends a payment transaction response to the payment terminal. The payment transaction response includes payment completion notification information and the target object of the target merchant, so that the payment terminal displays the payment completion notification information and the target object of the target merchant on the user interface.

[0085] Specifically, once the conditions are met, UnionPay will package the payment completion notification and the target recipient (such as an e-coupon) into a single payment transaction response message and send it to the payment terminal. For example, the user's mobile phone will immediately see a "Buy One Get One Free Coupon" display on the payment success notification page, and the e-coupon will be automatically added to their wallet. This example completes two previously sequential and separate actions, such as payment and target recipient distribution, into a single transaction, a single process, and a single message. This not only optimizes the user experience but also reduces additional inter-system interface calls, network round trips, and the number of downlink messages from a technical architecture perspective, directly resolving the technical bottlenecks you initially mentioned regarding doubling QPS and doubling downlink message volume.

[0086] This application reduces the amount of downlink messages by determining whether a payment transaction meets the target merchant's criteria (such as coupons) within the same processing stage, and sends only one payment transaction response. This response includes a payment completion notification and the target merchant's target object (such as coupon codes, benefits information, etc.). By completing the payment result and target object distribution in a single response, the application significantly reduces the peak QPS pressure on the central gateway by approximately 50%. Furthermore, since the payment terminal can obtain the target description information without a secondary request, the user experience is smoother, and the system interaction logic and network overhead are simplified.

[0087] In one embodiment, after sending the target object, such as a coupon, to the user's payment terminal, the payment terminal transmits the target object and payment transaction data to the acquiring node via NFC during the user's next payment. Specifically, the user device (e.g., an iPhone) sends the target object data (including the target object type identifier Pass TypeID and the target object identifier Pass ID) and EMV payment data simultaneously to the acquiring node (e.g., a POS terminal) via the NFC interface. The POS terminal parses the NDEF message and extracts the coupon information. For example, when a user double-clicks the power button to activate Apple Pay, the iPhone automatically returns the Pass data and payment data to the POS terminal.

[0088] In one embodiment, step S103 specifically includes the following steps:

[0089] Obtain at least one distribution strategy corresponding to the target merchant from the distribution strategy library.

[0090] Specifically, UnionPay will obtain at least one distribution strategy corresponding to the target merchant from the distribution strategy library. These strategies are a set of rules pre-configured by the merchant to determine under what conditions coupons or benefits are issued to users.

[0091] Based at least on the payment data of the payment terminal carried in the payment transaction request, and the distribution strategy, it is determined whether the payment terminal meets the object distribution conditions of the target merchant.

[0092] Specifically, UnionPay will at least use the payment data of the payment terminal carried in the payment transaction request, such as transaction amount, payment time, terminal location, and user identifier, and combine it with the acquired distribution strategy to perform real-time matching and judgment to determine whether the payment transaction meets the distribution conditions. For example, if the target merchant includes multiple distribution strategies, if the first strategy condition is matched, the system determines that the payment terminal meets the object distribution conditions, thus triggering the subsequent coupon issuance process; if no strategy is matched, only payment processing is completed, and no coupon issuance is attached. This example combines distribution strategies for automatic matching, simplifying system interaction logic and network overhead, and automating the object distribution process.

[0093] In one embodiment, determining whether a payment terminal meets the target merchant's object distribution conditions is based at least on the payment data of the payment terminal carried in the payment transaction request and the distribution strategy, including the following steps:

[0094] Based on the payment data of the payment terminal carried in the payment transaction request, the historical payment data generated by the payment terminal at the target merchant, and the distribution strategy, it is determined whether the payment terminal meets the object distribution conditions of the target merchant.

[0095] Specifically, when determining whether a payment terminal meets the conditions for object distribution, the system not only considers the real-time payment data carried in the current payment transaction request, such as the transaction amount, time, and product information, but also comprehensively calls upon the historical payment data generated by the payment terminal at the same target merchant, such as past transaction frequency, cumulative consumption amount, and previously claimed discounts. This data, combined with distribution strategies obtained from the strategy library, enables multi-dimensional condition matching and decision-making. This example, by integrating real-time and historical behavioral data, achieves more accurate target object distribution and increases user stickiness, rather than making judgments based solely on a single transaction.

[0096] In one embodiment, determining whether a payment terminal meets the target merchant's object distribution conditions based on payment data carried in the payment transaction request, historical payment data generated by the payment terminal at the target merchant, and a distribution strategy includes the following steps:

[0097] If the historical payment data reaches the preset number of transactions or the preset amount, the payment terminal is determined to meet the target merchant's object distribution conditions; or, if the transaction time of the payment data is within the preset time period, the payment terminal is determined to meet the target merchant's object distribution conditions.

[0098] Specifically, UnionPay uses a distribution strategy to determine whether the object distribution conditions are met. This strategy matches historical payment data with real-time payment data, and involves two typical determination paths: the first path checks if historical payment data has reached a preset threshold for the number of transactions or cumulative amount; if so, the condition is triggered. The second path checks if the transaction time of the current payment falls within a preset time period; if so, the condition is triggered. These two paths are typically implemented independently or in combination in the merchant's distribution strategy. In this example, the object distribution conditions are determined and distributed seamlessly during the user's payment process.

[0099] In one embodiment, determining whether a payment terminal meets the target merchant's object distribution conditions based on payment data carried in the payment transaction request, historical payment data generated by the payment terminal at the target merchant, and a distribution strategy includes the following steps:

[0100] Based on the payment data of the payment terminal carried in the payment transaction request, the historical payment data generated by the payment terminal at the target merchant, the historical usage data of the payment terminal for the target merchant's objects, and the distribution strategy, it is determined whether the payment terminal meets the object distribution conditions of the target merchant.

[0101] Specifically, this example not only relies on real-time payment data and historical transaction data, but also incorporates historical usage data of the payment terminal's distribution to the target merchant as a key decision-making basis. The system tracks whether previously claimed coupons and benefits have been actually redeemed and incorporates this behavior into the logic for determining whether to reissue similar benefits. For example, suppose a gym's distribution strategy is to "send a reinforced incentive coupon to users who have claimed a trial coupon in the past 30 days but have not actually used it." If a user claimed a "free trial week pass" two weeks ago but never used it, and now makes a purchase at the gym, UnionPay will simultaneously retrieve three pieces of data: the current payment data (such as the purchased item), the user's historical spending records at the gym, and the key historical usage data, i.e., system records showing that the user claimed but did not redeem a trial coupon. By matching this data with the above strategy, the system determines that the user meets the specific condition of "claimed but not used," and thus issues a benefit coupon along with the current payment response. This facilitates dynamic precision and efficiency optimization for targeted applications. In this example, the complex strategy judgment is also seamlessly completed during the payment process, ensuring the consistency of user experience and the overall efficiency of the system.

[0102] In one embodiment, the distribution strategy includes object description information; based on the payment data of the payment terminal carried in the payment transaction request, the historical payment data generated by the payment terminal at the merchant, and the distribution strategy, determining whether the payment terminal meets the object distribution conditions of the target merchant includes the following steps:

[0103] If the payment data from the payment terminal carried in the payment transaction request, and the historical payment data generated by the payment terminal in the merchant's transaction match the target distribution strategy, it is determined that the payment terminal meets the target merchant's object distribution conditions.

[0104] The method also includes the following steps:

[0105] The target object is obtained based on the description information of the target object carried by the target distribution strategy.

[0106] Specifically, the system retrieves real-time payment data carried in the payment transaction request, along with historical payment data generated by the payment terminal at the merchant. If these match the trigger conditions of a specific distribution strategy, the payment terminal is deemed to meet the object distribution conditions, and the matched strategy becomes the target distribution strategy. Subsequently, the system uses the description information of the target object carried in the target distribution strategy to obtain or generate the corresponding specific object instance. The description information might be an object template ID, a set of object attribute definitions (such as face value, validity period, usage rules), or an index pointing to an object resource. For example, suppose a merchant has formulated a distribution strategy whose trigger condition is "the user has accumulated 10 cups of consumption in the current month," and the embedded object description information of this strategy is "gift coupon: one large latte, valid for 30 days, coupon code generation rule is COFFEE_GIFT_{serial number}". When a user makes their tenth payment this month, UnionPay retrieves their historical payment data, confirming that the accumulated number of cups has reached 10, thus matching the strategy. At this point, the system determines that the distribution conditions are met and, based on the description of the "Large Latte Gift Coupon" in the strategy, immediately invokes the coupon code generation service to generate a unique electronic coupon code (e.g., COFFEE_GIFT_1001) according to preset rules. This complete coupon, along with payment success information, is then encapsulated and returned to the user's terminal. This example ensures that the distribution of the target object and its content are flexibly configurable and dynamically bound, and that object generation and distribution are fully automated. There is no need to query object details from external systems after the conditions are met, further improving processing efficiency and system cohesion.

[0107] In one embodiment, obtaining the target object based on the description information of the target object carried by the target distribution strategy includes the following steps:

[0108] Based on the description information of the target object, a target object that meets the description information is generated and synchronized to the target merchant's payment system.

[0109] Specifically, the system instantly generates a specific object instance that perfectly matches the object description information carried in the target distribution strategy, such as "customized 10% off coupon, valid for 30 days." This includes creating an electronic coupon with a unique coupon code and specified attributes. Key information of this newly generated object (such as coupon code, rules, and associated user) is then synchronized in real-time to the target merchant's payment or verification system. For example, when a user makes a single purchase of 888 yuan or more at a merchant, triggering the coupon policy, UnionPay dynamically generates a 10% off coupon with a unique code and immediately synchronizes it to the merchant's POS system (acquiring node). This allows the user to receive the coupon immediately upon payment completion, and the merchant system can verify its validity in real-time during in-store verification. This example achieves full automation and seamless integration of the target object's generation, distribution, and verification preparation, ensuring real-time performance and flexibility, eliminating the need to pre-generate a large number of coupon codes, and completely avoiding verification failures due to data asynchrony, thus significantly improving the user experience.

[0110] In one embodiment, generating a target object that satisfies the description information based on the description information of the target object includes the following steps:

[0111] Based on the description information, the system searches for target objects that match the description information in the available object database of the target merchant's payment system.

[0112] The method also includes the following steps:

[0113] After sending a payment transaction response to the payment terminal, a notification message is sent to the target merchant's payment system to trigger the target merchant's payment system to delete the target object from the available object database.

[0114] Specifically, this example, based on the description information, searches for and matches a ready-made target object that matches the description from an available object database maintained by the target merchant's payment system. After successfully sending a payment transaction response containing the target object to the payment terminal, the system sends a notification to the target merchant's payment system to trigger it to delete the target object that was just matched and issued from the available object database or mark it as "occupied," thereby ensuring that the object is not issued repeatedly. This example ensures precise control and anti-reuse of target objects (such as cash red envelopes, physical coupon inventory), and is particularly suitable for scenarios involving the issuance of physical goods or high-value virtual benefits with limited total quantities and requiring precise verification.

[0115] In one embodiment, before determining whether the payment terminal meets the target merchant's object distribution conditions based on the payment transaction request, the method further includes the following steps: Figure 2 As shown, Figure 2 A flowchart illustrating a payment processing method provided in another embodiment of this application.

[0116] Step S201: Determine candidate merchants with object distribution strategies.

[0117] Step S202: Based on the historical payment transaction data of the candidate merchants by the payment terminal, determine the target merchant from the candidate merchants.

[0118] Specifically, the system filters out all candidate merchants with targeted distribution strategies from a massive pool of merchants. These merchants are potential benefit providers who have pre-configured targeted distribution rules such as coupons and points on the marketing platform. Secondly, after determining the candidate merchant pool, the system further analyzes the historical payment transaction data of payment terminals (i.e., users) for these candidate merchants, and based on this data, accurately determines the final target merchants from among the candidate merchants. This example ensures that the targeting is not only based on a single transaction, but also deeply linked to the user's long-term consumption preferences, thereby significantly improving the relevance and effectiveness of marketing campaigns, avoiding pushing merchant benefits that users are not interested in or never consume, and optimizing configuration efficiency.

[0119] In one embodiment, the UnionPay terminal also includes a mobile Pay operating system and a Smart Pass system. The mobile Pay operating system obtains the corresponding activity identifier based on the merchant's signal. It then checks a preset rule table to see if the activity identifier matches the payment terminal identifier (SEID). If the match is found, it requests the Smart Pass system to generate a target object. The Smart Pass system records the mapping relationship between the target object and the payment terminal identifier (SEID) and returns a PassKit coupon package to the mobile Pay operating system. For example, if the mobile Pay operating system obtains the activity identifier "A123" and the payment terminal identifier "SE-9876", the Smart Pass system generates a target object Pass with a PassType ID of "coupon-A123" and a target object identifier Pass ID of "123456", and records that this target object Pass can only be used by a device with the payment terminal identifier SE-9876. The payment device identifier (such as SEID) serves as a unique identifier and is bound to the target object generation process, preventing the target object from being copied or used across devices, significantly reducing the risk of coupon theft, and enhancing the association between the payment device and the target object.

[0120] In one embodiment, the method further includes the following steps:

[0121] Call the target interface of the candidate merchant to obtain the distribution strategy of the candidate merchant.

[0122] Update the distribution strategy library based on the distribution strategies of the acquired candidate merchants.

[0123] Alternatively, update the distribution strategy library based on the updated distribution strategies reported by candidate merchants.

[0124] Specifically, to ensure the timeliness and accuracy of the distribution strategy, this example designs two mechanisms for dynamically updating the strategy library. The first is an active pull mode: the system calls the target interface (such as a standard API) provided by each candidate merchant to actively obtain the merchant's latest configured or modified distribution strategy, and then updates the central distribution strategy library based on this information. The second is a passive receiving mode: the system synchronously updates its own strategy library based on the distribution strategy information actively reported by candidate merchants and updated in their backend. These two methods can be used independently or in combination to ensure consistency between the UnionPay strategy library and the actual marketing rules on the merchant's side. This example achieves centralized, real-time management and synchronization of marketing strategies, allowing merchants to flexibly and autonomously adjust their marketing activities in their backend. UnionPay, as the distribution execution center, can perceive and apply these changes in near real-time, ensuring the consistency of rules throughout the entire payment-as-marketing chain and avoiding marketing failures or user disputes caused by strategy asynchrony.

[0125] In one embodiment, determining whether a payment terminal meets the target merchant's object distribution conditions is based at least on the payment data of the payment terminal carried in the payment transaction request and the distribution strategy, including the following steps:

[0126] If the timestamp of the distribution strategy has not expired, at least based on the payment data of the payment terminal carried in the payment transaction request and the distribution strategy, determine whether the payment terminal meets the object distribution conditions of the target merchant.

[0127] Alternatively, the method may include the following steps:

[0128] Timestamps of the distribution strategies for polling candidate merchants.

[0129] If a candidate merchant is identified with an expired distribution policy, the expired distribution policy will be deleted.

[0130] Specifically, this example introduces a clear timestamp management mechanism to ensure the effectiveness of the distribution strategy. First, when performing condition matching, the system checks whether the timestamp of the called distribution strategy has expired. Only if the strategy is within its validity period (timestamp not expired) will the condition matching based on payment data and the strategy continue. If the strategy has expired, it is directly considered that the distribution conditions are not met, and the process terminates. Second, to maintain the cleanliness and efficiency of the strategy library, the system also has an independent background polling and cleanup task: it periodically or continuously polls the timestamps of the distribution strategies of all candidate merchants. Once it identifies an expired distribution strategy under a candidate merchant, it automatically deletes it from the distribution strategy library. This example achieves automated management of the strategy lifecycle, ensuring the accuracy and timeliness of marketing activities, avoiding customer complaints caused by issuing expired benefits to users, and reducing the ineffective load on system storage and computing resources by automatically cleaning up expired strategies, thus ensuring the real-time effectiveness and query performance of the strategy library.

[0131] When the target object is used, the method also includes the following steps:

[0132] The receiving node sends a payment transaction request; the payment transaction request includes the payment transaction request and the target object.

[0133] Specifically, such as Figure 3 As shown, Figure 3This is a schematic diagram illustrating the interaction process between a payment terminal and an acquiring node according to an embodiment of this application. The interaction process between the payment terminal and the acquiring node is as follows: Step 1: The user brings their mobile phone (payment terminal) close to the POS terminal (acquiring node), triggering the NFC radio frequency field (ISO / IEC 14443-A). The mobile phone enters Card Emulation mode (Apple Pay / Google Pay / HCE) to prepare to simulate a bank card. Step 2: An RF radio frequency connection is established and a payment application is selected. The POS terminal establishes an ISO / IEC 14443-A connection with the mobile phone and sends a SELECT AID command, such as A0000000041010, to select a payment application, such as Visa, Mastercard, or a bank-customized AID. Step 3: EMV payment data interaction is completed. The mobile phone returns File Control Information (FCI) (including AIP and AFL). The POS terminal sends instructions such as Obtain Processing Options (GPO), Read Record, and Generate Application Ciphertext (AC). The mobile phone finally returns the EMV ciphertext Cryptogram and Device Master Account (DPAN) (Tokenized Card Number), completing the standard EMV L2 payment process. Step 4: POS probes the target object's transmission capability (platform adaptation). For iOS devices: POS sends the Apple VAS probe command FF 4C 00 00 07 A0 00 00 00 03 10 10. The iPhone automatically matches the matching Pass in the Wallet and returns an NDEF message containing coupon information (MIME type: application / vnd.coupon+json). For Android devices: POS sends a custom UCTP query command FF CA FE 00 00. Applications registered with HCE listen to this APDU, construct and return an NDEF target object payload conforming to the UCTP format. Step 5: POS terminal uploads transaction and coupon data. The POS terminal parses the NDEF message, extracts the target object's type identifier (passType) and target object identifier (passId), appends them to the original EMV transaction message, and uploads them to UnionPay, for example, via ISO 8583 messages or a private API.

[0134] Parse the target object to obtain the corresponding face value field; modify the transaction amount in real time based on the face value field, and change the status of the target object from "unused" to "used".

[0135] Specifically, the target object is parsed to obtain its corresponding face value field. The transaction amount is then modified based on this face value field to obtain the final transaction amount, which is written into the payment message. Simultaneously, a status write-back is performed, changing the target object's status from "unused" to "used" for timely updates and to prevent rollback in case of power failure. This application calculates the transaction in real-time based on the target object during the next payment, requiring no additional user intervention. Furthermore, the timely synchronization of the target object's status prevents rollback in case of power failure. There is zero increase in system downlink messages and zero increase in terminal power consumption. Since the status bit is already set to "used," subsequent decryption will immediately detect Bit0=1, directly rejecting any second deduction.

[0136] In one embodiment, the target object is parsed to obtain a type identification code; based on the type identification code, a lookup is performed in a pre-stored rule mapping table to obtain the discount algorithm identifier corresponding to the type identification code; based on the discount algorithm identifier and the face value field, the amount correction is calculated, and the transaction amount is modified in real time.

[0137] Specifically, the system looks up the target object's type identification code in a pre-stored rule mapping table. This table contains the target object's type identification code and discount algorithm identifier, which is hard-coded. For example, 0x01 represents a fixed amount reduction; 0x02 represents a full reduction; and 0x03 represents a percentage discount. The amount adjustment is subtracted from the original amount, and the result is written into the final amount of the payment message. In this application, there is zero increase in system downlink messages and zero increase in terminal power consumption; the status bit is already set to "used," and subsequent decryption will immediately reveal Bit0=1, directly rejecting the second deduction.

[0138] In one embodiment, the amount of amount adjustment is calculated based on the discount algorithm identifier and the face value field, specifically including the following steps: verifying whether the status bit of the target object is "unused".

[0139] If the status is "unused", the amount adjustment is calculated based on the discount algorithm identifier and the face value field; if the status is "used", the original transaction amount remains unchanged.

[0140] In one embodiment, the method further includes the following steps:

[0141] Obtain the user's payment terminal information; the payment terminal information includes the payment terminal identifier, geographical location information, and IP address information.

[0142] The payment terminal information is matched and verified against the preset risk control rules. If the preset risk control rules are met, the signature verification is successful.

[0143] Specifically, the risk control rules include: geographical restriction rules, frequency restriction rules, and user risk level rules; geographical restriction rules are used to verify whether the user's geographical location is within the geofence where the coupon can be used; frequency restriction rules are used to verify whether the number of times a user claims or uses the same coupon within a preset time period exceeds a preset threshold; user risk level rules are used to determine whether to allow the user to claim or use the coupon based on the user's risk level determined by the user's historical transaction data.

[0144] The signature verification is successful when the payment terminal information simultaneously meets the regional restriction rules, frequency restriction rules, and user risk level rules. Specifically, after the target object undergoes the above verification and the signature verification is successful, the target object is determined to be valid and can then be used. If the signature verification fails, the payment process is not interrupted; the target object is simply ignored, and the payment continues.

[0145] In one embodiment, the method further includes the following steps: receiving a return transaction completion instruction; parsing the corresponding cancelled target object identifier code based on the return transaction completion instruction; changing the target object's status bit from "used" to "unused" and generating a timestamped revocation ciphertext.

[0146] The revocation message is uploaded to the acquiring node in one go via a return message to complete the status synchronization.

[0147] Specifically, when a return occurs, the UnionPay mobile Pay operating system learns that the return transaction has been completed by subscribing to the big data transaction database. It then notifies the Smart Pass system to restore the status of the already cancelled target Pass to "usable" and generates a timestamped revocation ciphertext to complete the status synchronization.

[0148] like Figure 4 As shown, Figure 4 This is a schematic diagram of the structure of a payment processing device provided in an embodiment of this application. The payment processing device 400 includes: a receiving module 401, used to receive a payment transaction request sent by an acquiring node, the payment transaction request being triggered by a contactless payment operation of the acquiring node based on a payment terminal; a determining module 402, used to perform payment processing based on the payment transaction request, and determine whether the payment terminal meets the object distribution conditions of the target merchant based on the payment transaction request; and a processing module 403, used to send a payment transaction response to the payment terminal if the object distribution conditions of the target merchant are met, the payment transaction response including payment completion notification information and the target object of the target merchant, so that the payment terminal displays the payment completion notification information and the target object of the target merchant on the user interface.

[0149] In one embodiment, the determining module 402 is used to obtain at least one distribution strategy corresponding to the target merchant from the distribution strategy library; and determine whether the payment terminal meets the object distribution conditions of the target merchant based at least on the payment data of the payment terminal carried in the payment transaction request and the distribution strategy.

[0150] In one embodiment, the determining module 402 is used to determine whether the payment terminal meets the object distribution conditions of the target merchant based on the payment data of the payment terminal carried in the payment transaction request, the historical payment data generated by the payment terminal at the target merchant, and the distribution strategy.

[0151] In one embodiment, the determining module 402 is used to determine that the payment terminal meets the target merchant's object distribution conditions if the historical payment data reaches a preset number of transactions or a preset amount; or, if the transaction time of the payment data is within a preset time period, then the payment terminal meets the target merchant's object distribution conditions.

[0152] In one embodiment, the determining module 402 is used to determine whether the payment terminal meets the object distribution conditions of the target merchant based on the payment data of the payment terminal carried in the payment transaction request, the historical payment data generated by the payment terminal at the target merchant, the historical usage data of the payment terminal for the target merchant's object, and the distribution strategy.

[0153] In one embodiment, the distribution strategy includes object description information; the determining module 402 is used to determine that the payment terminal meets the object distribution conditions of the target merchant when the payment data of the payment terminal carried in the payment transaction request and the historical payment data generated by the payment terminal in the merchant match the target distribution strategy; the processing module 403 is used to obtain the target object based on the target object description information carried in the target distribution strategy.

[0154] In one embodiment, the processing module 403 is used to generate a target object that meets the description information based on the description information of the target object, and synchronize it to the payment system of the target merchant.

[0155] In one embodiment, the processing module 403 is used to search for a target object that matches the description information from the available object database of the target merchant's payment system; the processing module 403 is also used to send a notification message to the target merchant's payment system after sending a payment transaction response to the payment terminal, so as to trigger the target merchant's payment system to delete the target object from the available object database.

[0156] In one embodiment, the determining module 402 is used to determine candidate merchants with an object distribution strategy; and to determine the target merchant from the candidate merchants based on the historical payment transaction data of the payment terminal for the candidate merchants.

[0157] In one embodiment, the determining module 402 is used to call the target interface of the candidate merchant to obtain the distribution strategy of the candidate merchant; update the distribution strategy library based on the obtained distribution strategy of the candidate merchant; or update the distribution strategy library based on the updated distribution strategy reported by the candidate merchant.

[0158] In one embodiment, the determining module 402 is configured to determine whether the payment terminal meets the object distribution conditions of the target merchant, based at least on the payment data of the payment terminal carried in the payment transaction request and the distribution strategy, if the timestamp of the distribution strategy has not expired; or, poll the timestamps of the distribution strategies of candidate merchants; and delete the expired distribution strategy if a candidate merchant with an expired distribution strategy is identified.

[0159] The payment processing device 400 provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0160] This application provides an electronic device, including: a memory and a processor;

[0161] The memory stores instructions that the computer executes;

[0162] The processor executes computer execution instructions stored in memory, causing the processor to perform any of the methods described above.

[0163] Figure 5 A schematic diagram of the structure of the electronic device provided in this application. Figure 5 As shown, the electronic device 500 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the electronic device 500 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0164] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0165] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0166] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0167] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0168] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0169] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0170] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0171] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0172] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0173] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0174] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0175] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0176] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0177] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0178] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A payment processing method, characterized in that, include: Receive a payment transaction request sent by the acquiring node, wherein the payment transaction request is triggered by the acquiring node's contactless payment operation based on the payment terminal; Payment processing is performed based on the payment transaction request, and based on the payment transaction request, it is determined whether the payment terminal meets the object distribution conditions of the target merchant; If the object distribution conditions of the target merchant are met, a payment transaction response is sent to the payment terminal. The payment transaction response includes payment completion notification information and the target object of the target merchant, so that the payment terminal displays the payment completion notification information and the target object of the target merchant on the user interface.

2. The method according to claim 1, characterized in that, The step of determining whether the payment terminal meets the target merchant's object distribution conditions based on the payment transaction request includes: Obtain at least one distribution strategy corresponding to the target merchant from the distribution strategy library; Based at least on the payment data of the payment terminal carried in the payment transaction request, and the distribution strategy, it is determined whether the payment terminal meets the object distribution conditions of the target merchant.

3. The method according to claim 2, characterized in that, The determination of whether the payment terminal meets the target merchant's object distribution conditions, based at least on the payment data of the payment terminal carried in the payment transaction request and the distribution strategy, includes: Based on the payment data of the payment terminal carried in the payment transaction request, the historical payment data generated by the payment terminal at the target merchant, and the distribution strategy, it is determined whether the payment terminal meets the object distribution conditions of the target merchant.

4. The method according to claim 3, characterized in that, The determination of whether the payment terminal meets the target merchant's object distribution conditions based on the payment data of the payment terminal carried in the payment transaction request, the historical payment data generated by the payment terminal at the target merchant, and the distribution strategy includes: If the historical payment data reaches a preset number of transactions or a preset amount, then the payment terminal is determined to meet the target merchant's object distribution conditions; or, If the transaction time of the payment data falls within a preset time period, then the payment terminal is determined to meet the target merchant's object distribution conditions.

5. The method according to claim 3, characterized in that, The determination of whether the payment terminal meets the target merchant's object distribution conditions based on the payment data of the payment terminal carried in the payment transaction request, the historical payment data generated by the payment terminal at the target merchant, and the distribution strategy includes: The payment terminal is determined to meet the object distribution conditions of the target merchant based on the payment data carried in the payment transaction request, the historical payment data generated by the payment terminal at the target merchant, the historical usage data of the payment terminal for the target merchant, and the distribution strategy.

6. The method according to claim 3, characterized in that, The distribution strategy includes the object's description information; The determination of whether the payment terminal meets the target merchant's object distribution conditions based on the payment data of the payment terminal carried in the payment transaction request, the historical payment data generated by the payment terminal at the merchant, and the distribution strategy includes: If the payment data of the payment terminal carried in the payment transaction request and the historical payment data generated by the merchant match the target distribution strategy, the payment terminal is determined to meet the object distribution conditions of the target merchant. The method further includes: The target object is obtained based on the description information of the target object carried by the target distribution strategy.

7. The method according to claim 6, characterized in that, The step of obtaining the target object based on the description information of the target object carried by the target distribution strategy includes: Based on the description information of the target object, a target object that meets the description information is generated and synchronized to the payment system of the target merchant.

8. The method according to claim 7, characterized in that, The step of generating a target object that satisfies the description information of the target object includes: Based on the description information, search the available object database of the target merchant's payment system for a target object that matches the description information; The method further includes: After sending a payment transaction response to the payment terminal, a notification message is sent to the target merchant's payment system to trigger the target merchant's payment system to delete the target object from the available object database.

9. The method according to any one of claims 1-5, characterized in that, Before determining whether the payment terminal meets the target merchant's object distribution conditions based on the payment transaction request, the method further includes: Identify candidate merchants with object distribution strategies; The target merchant is determined from the candidate merchants based on the historical payment transaction data of the payment terminal for the candidate merchants.

10. The method according to any one of claims 2-5, characterized in that, The method further includes: Call the target interface of the candidate merchant to obtain the distribution strategy of the candidate merchant; Update the distribution strategy library based on the obtained distribution strategies of candidate merchants; Alternatively, the distribution strategy library can be updated based on the updated distribution strategies reported by the candidate merchants.

11. The method according to any one of claims 2-5, characterized in that, The determination of whether the payment terminal meets the target merchant's object distribution conditions, based at least on the payment data of the payment terminal carried in the payment transaction request and the distribution strategy, includes: If the timestamp of the distribution strategy has not expired, at least based on the payment data of the payment terminal carried in the payment transaction request and the distribution strategy, it is determined whether the payment terminal meets the object distribution conditions of the target merchant. Alternatively, the method may further include: Timestamps of the distribution strategies for polling candidate merchants; If a candidate merchant is identified as having an expired distribution policy, the expired distribution policy is deleted.

12. A payment processing device, characterized in that, include: The receiving module is used to receive payment transaction requests sent by the acquiring node, wherein the payment transaction request is triggered by the acquiring node based on a contactless payment operation of the payment terminal; The determination module is used to process payment based on the payment transaction request and, based on the payment transaction request, determine whether the payment terminal meets the object distribution conditions of the target merchant. The processing module is configured to send a payment transaction response to the payment terminal when the object distribution conditions of the target merchant are met. The payment transaction response includes payment completion notification information and the target object of the target merchant, so that the payment terminal displays the payment completion notification information and the target object of the target merchant on the user interface.

13. A payment processing method, characterized in that, include: Based on contactless payment operations, the acquiring node is triggered to generate a payment transaction request; Receive a payment transaction response sent by UnionPay, the payment transaction response including payment completion notification information and the target object of the target merchant, so as to display the payment completion notification information and the target object of the target merchant on the user interface; The payment transaction response is initiated by UnionPay based on the payment transaction request sent by the acquiring node, and then sent based on the payment transaction request, provided that the object distribution conditions of the target merchant are met.

14. A payment processing method, characterized in that, include: A payment transaction request is triggered by a contactless payment operation based on a payment terminal. The payment transaction request is sent to UnionPay. The UnionPay terminal processes the payment based on the payment transaction request, and, if the object distribution conditions of the target merchant are met, sends a payment transaction response to the payment terminal. The payment transaction response includes payment completion notification information and the target object of the target merchant, so that the payment terminal displays the payment completion notification information and the target object of the target merchant on the user interface.

15. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-11.

16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-11.

17. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-11.

Images