A method and apparatus for facilitating the initiation of an on-line transaction

Abstract

The present application is a convenient way of initiating online transactions and application, the technical field belongs to the field of online and offline transactions, the implementation of the transaction mode is based on the application of a set of transaction system. The problem to be solved is to solve the convenience of online and offline transactions and reduce the transaction cost of both parties.

Description

Technical Field

[0001] This manual describes a convenient method for initiating online transactions and its application. The technical field is internet e-commerce and payment. Background Technology

[0002] Current commodity trading lacks group payment functionality, and buyers and sellers cannot easily initiate online transactions. However, this functional architecture (system) can easily implement these functions. Summary of the Invention

[0003] This manual introduces a convenient method for initiating online transactions and its application. Furthermore, it excels at group payments and group collections, making it suitable for various complex multi-person payment and collection scenarios. The implementation of this function is based on a payment function architecture (system) and its application. This architecture (system) mainly consists of three components: a collection box, a payment box, and a payment group. This architecture also includes the framework, modules, and functional units within each component.

[0004] Component 1: Payment Box The payment function of a payment collection box only allows users to receive payments and process refunds after receiving payments. Payment collection boxes can be categorized based on the market entity, including personal (private) payment collection boxes, personal commercial payment collection boxes, enterprise / institutional user payment collection boxes, and sole proprietorship user payment collection boxes, etc. Personal commercial payment collection boxes, enterprise / institutional user payment collection boxes, and sole proprietorship user payment collection boxes can be collectively referred to as commercial payment collection boxes. Personal (private) payment collection boxes are simply called personal payment collection boxes. The functional architecture, framework, and operation methods of commercial payment collection boxes from various market entities are largely the same; only the specific functional modules within each type of payment collection box differ slightly. The biggest difference between personal and commercial payment collection boxes is that personal payment collection boxes cannot initiate online transactions, while commercial versions can. Personal payment collection boxes allow recipients to create payment groups and import payment group members themselves, while commercial versions cannot. However, commercial versions can initiate online goods transactions (such as group buying) and allow externally imported payment groups within the payment collection box to initiate online transactions, while payment groups within personal payment collection boxes cannot. Personal (private) payment collection can only use (be bound to) the personal (private) version of the payment collection box; personal commercial payment collection can only use (be bound to) the personal commercial version of the payment collection box; corporate legal entity payment collection can only use (be bound to) the enterprise / institution version of the payment collection box; sole proprietorship payment collection can only use (be bound to) the sole proprietorship version of the payment collection box, and so on. Because there are various types of payment collection entities in the market, and their respective payment collection rights differ, different payment collection boxes are set up for different entities. A payment collection entity (such as an individual user) can own (copy) multiple payment collection boxes (of the same type). When there are multiple payment collection boxes of the same type, these payment collection boxes all have the same entity number, which is equivalent to a unique identifier for the payment collection entity. However, the sub-numbers are different and are used to distinguish these payment collection boxes of the same type.

[0005] Component 2: Payment Box The payment box is the primary tool used by market entities for making payments, and it also has a receiving function, particularly excelling in group payments. For example, a payment initiated by one person can be received by any number of people simultaneously, according to any set amount or rules. Group payments are currently the most efficient, the most convenient to use, and have the widest range of applications.

[0006] Online transactions can also be initiated within the payment box. A prerequisite for initiating an online transaction using the payment box is that it must be connected to the commercial version of the payment collection box.

[0007] A payment entity (such as an individual user) can have (copy) multiple payment boxes. When there are multiple payment boxes, these payment boxes all have the same entity number, which is equivalent to a unique identifier for the payment entity. However, each payment box has a different sub-number, which is used to distinguish these multiple payment boxes.

[0008] Component 3, Payment Group A payment group is a multi-person payment group generated within the payment collection box. Each payment group can have its own payment discount and settlement method set independently. In this case, the payment group is not affected by the payment discount method set in the payment collection box. If a payment group does not have a separate payment discount method set, it may be affected by the payment discount method set in the payment collection box. Payment groups are also one of the tools for initiating online transactions. There are two types of payment groups: one is a payment group created by the payee using the payment collection box, and the other is a payment group imported into the payment collection box by an external payer. Only personal (private) payment collection boxes have the function of creating payment groups and importing group members. Self-imported payment groups are not controlled by the personal payment collection box's discount rules by default, while externally imported payment groups are affected by the payment collection box's payment rules after import, unless payment rules are set separately within the payment group. The commercial version of the payment collection box currently does not allow self-creation of payment groups or importing of group members, but the commercial version can initiate online goods transactions. A group purchase initiated by the payee is equivalent to a "payment group" created by the payee within the payment collection box.

[0009] Because multiple payment entities can be imported into the payment box, payment box, and payment group, it excels at group payments. This interconnected payment architecture (system) of "payment box, payment box, and payment group" broadens the application scope of group payments, maximizes speed and efficiency, and meets various group payment scenarios. It also facilitates statistics and display, making transaction data clear to both parties and simplifying refund operations. The interconnectivity of the three components allows payers to pay directly from the payment box, transfer funds to the payee's payment box, and create payment groups within the payment box. Payers can also transfer funds from the payee's payment box to the payment box, and so on.

[0010] Another advantage of adopting a payment architecture system that allows the three parties to work together is that it makes it easy for payers and payees to initiate online transactions. In other words, this payment architecture system gives payers and payees e-commerce functions, enabling them to initiate group purchases and allow more people to participate in transactions, thereby reducing transaction costs.

[0011] Let's take the example of a consumer, A, buying apples at a physical fruit store to illustrate the application of this payment architecture (system).

[0012] B, the owner of a fruit shop, is a sole proprietor. He sells a certain type of apple for 10 yuan per jin (approximately 0.5 catties). B tells customer A that if A buys 30 jin of apples, he can give him a discount of 6 yuan per jin; if A only buys 1 jin, the price is 10 yuan per jin. A finds this offer very tempting, but he can't finish 30 jin of apples by himself, and many customers don't need to buy that much. A says he only needs 5 jin, but if he buys 5 jin, the price is still 10 yuan per jin, and he won't get the discount. Therefore, A can use the group-buying function of this payment system to initiate a group-buying transaction online.

[0013] So A opened his payment window and scanned the QR code in boss B's (sole proprietorship) payment window to make a payment. A can also search to access the payment window to make a payment.

[0014] Operation Method 1 A chose to use the "Add" button in their payment box. When A scanned the code in B's (sole proprietorship version) payment box, they were added to B's (sole proprietorship version) payment box. A being in B's payment box means A is now in a pending payment state to B. After entering B's payment box, A can see the entire interface of B's ​​payment box, including the name and address of B's ​​fruit shop. If the fruit shop is a company, the company name will also be displayed. Having the recipient's identity information provides consumers with a sense of transaction security. After joining, A can directly complete the transaction in the pending payment section of B's ​​payment box, or choose to create a payment group. A then creates a payment group in B's payment box. B can further customize the payment rules for this payment group based on negotiations with customers. After customizing the rules, the group is no longer affected by B's overall payment box rules; otherwise, it would be controlled by the payment box rules. This payment architecture, which allows for the re-establishment of payment groups within the payment collection box, can meet various payment and collection requirements, which is precisely its unique advantage.

[0015] Once a payment group initiated by A is generated in B's payment box, both A and B can see and edit the product information within this group, which includes a section for initiating online transactions. This section allows them to edit details such as the product name (e.g., apples), quantity, unit price, brand, specifications, material, shelf life, and shipping method. Both the payee and payer can jointly edit the product name, brand, specifications, material, shelf life, reason for the group purchase, product details, and photos or videos. Only the payee (seller) can edit the quantity, unit price, and shipping method. After editing the necessary product information, the payer confirms, generating the group purchase order. Both the payee and payer can then publish the order on a public platform, and both can withdraw the published order. There are other methods for creating and publishing products. It's important to note that the quantity entered here is the total quantity that the group members set by B to purchase. The order (group purchase) is completed when the total quantity purchased by the members of the payment group equals the quantity set by the business owner; otherwise, the group purchase is not successful. There is another type of group purchase where, even if the set quantity has not been reached, the group purchase is successful as long as a member successfully pays. This method involves the recipient setting two unit prices for the group purchase (one for reaching the set quantity and one for not reaching the set quantity).

[0016] In other words, if the boss wants A to buy 30 jin of apples at once, he will give A a discount (6 yuan / jin). A can use this payment system to achieve the effect of group buying these 30 jin of apples.

[0017] So the question is, how can A or B quickly let others know about and participate in this group purchase? Besides involving other customers in the store, as mentioned before, B or A can also share the group purchase information on a public platform (transaction platform), allowing more people to see the group purchase and its discounts, thereby encouraging more people to participate in the payment group.

[0018] When the entire order (30 catties of apples purchased at once) is completed, if the seller selects in-store pickup as the delivery method, the payment system will assign a (in-store pickup) verification code to all group members who have successfully paid, making it convenient for customers to pick up and verify their orders in-store. If some customers need to choose express delivery separately, they can make a note separately or discuss the delivery method with the seller.

[0019] Operation Method Two Instead of using the "Add" button in A's payment box, A directly uses the payment button to scan and pay B's (individual business version) payment box. In this case, no payment group is generated in B's (individual business version) payment box; the payment is processed within A's own payment box. B can also see A's payment box linked to B's. Because it's A's payment box, B cannot make or receive payments through it. B can only access the online goods trading section within A's payment box, where they can set and edit information about the goods for sale. Both the payer and payee can set and edit this information. The process is similar to how A and B set and edit information in the payment group. Only after A's payment box is linked to B's payment box, and the necessary product information is set in A's payment box, and after the payee confirms, can A share the payment box on a public platform to find group buyers. For logical reasons, the payment box should be used to initiate a group purchase only by the person making the payment.

[0020] After A scans the QR code to pay in B's payment box, A can see the seller's identity information in A's payment box, such as the name and address of B's ​​fruit shop. If the fruit shop is a company, the company name and other information will also be displayed. Having the payee's (seller's) identity information provides the buyer with a sense of security in the transaction.

[0021] This payment system and architecture offers numerous methods for group payments and collections, excelling particularly in complex multi-person payment and collection scenarios, and currently boasting the highest efficiency in group payments and collections. This is a unique advantage of this payment architecture system.

[0022] Since this payment system can handle complex group payment and collection operations, it can also support individual payment and collection operations. Taking individual payments as an example, there are two main methods.

[0023] Single-person payment method 1: Pay using the personal payment function (not using the personal payment box). When making a payment using the personal payment function, simply open the payment QR code (not the personal payment box) or scan the code. For example, use the personal payment QR code scanning function to scan the QR code of the recipient's payment box. After scanning, the payer is automatically directed to the recipient's payment box to make the payment. Once the transaction is successful, the transaction record will be displayed in the payment box, making it simple and clear.

[0024] The personal payment function (without opening the personal payment box) can also be used to make and receive payments with the recipient's personal payment function (without opening the personal payment box). After scanning the code, the payer is automatically taken to the recipient's personal payment box to make the payment. After a successful personal payment, the transaction record will be displayed in the recipient's personal payment box.

[0025] Payment Method 2: Pay using the personal payment box When using a personal payment box for payment, you can open the payment scanning function within the payment box and scan the QR code in the recipient's personal payment function or the payment code in the personal payment box. After scanning, if the payment box contains only the recipient and the recipient has not set any conditions for multi-person payment, then the entire payment box is completed once the recipient successfully pays. After successful payment, the individual's transaction record will be displayed in the recipient's payment box. If there are other paying members besides the recipient in the payment box, then the payment for the entire payment box is not yet successful only after all members in the payment box have completed their payments (except for members whose payment amounts are set to zero). In this payment architecture, there are two ways to use payment boxes for payment pooling. One is that members of the payment box split and pool the same order. The other is that each member of the payment box pays for their own order, and then the payment box completes the payment according to the set payment rules (if payment rules have been set). The payment box can only be completed if the payment rules are met.

[0026] In addition, payment can also be completed using the personal payment function or the payment box function in the personal payment box, along with the receiving function in the counterparty's payment box. Since this method is not commonly used, it will not be described in this manual.

[0027] It must be said that this payment function architecture (system) can derive many payment and collection methods, with wide applications. It can also enable payers to complete payments without using any of their devices, and provide a series of convenient and fast payment and collection functions such as assistance with collection. Attached Figure Description Instruction manual attached Figure 1This is a basic functional diagram of the commercial version of the payment collection box. Instruction manual attached Figure 2 This is a basic functional diagram of the payment box. Instruction manual attached Figure 3 This is a basic functional diagram of the payment group within the payment collection box.

[0028] Instruction manual attached Figure 1 This is a basic framework diagram of the commercial version of the payment collection box. Although payment collection boxes are divided into different types depending on the type of user receiving the payment, the basic framework and functional model of the commercial version payment collection box are similar, with only some differences in the configuration functions under the basic framework section. The basic framework and functions of the personal version payment collection box can be referenced from the commercial version.

[0029] The section marked 1 displays the recipient's name, address, introductory information, or product information. Figure 1 The area above Line 1 is the main area. The main function of this area is for the payee to publicly introduce themselves and showcase their platform to the outside world, including introducing company information, product information, etc. It serves as a bridge for the payee to get to know and communicate with the outside world.

[0030] The section marked 2 is where the recipient initiates an online sale of goods. The illustration only shows the function module for initiating a group purchase. Clicking the "Initiate Group Purchase" button will bring up a drop-down menu for group purchase items. The input includes, but is not limited to, product name, brand, specifications, material, quantity to be purchased, unit price, product details, reason for initiating the group purchase, and shipping method. When entering the quantity to be purchased, this quantity represents the total quantity that all members in the group should purchase and must be equal to this quantity. If the total quantity purchased by members is less than the quantity to be purchased, the group purchase fails. When a group purchase fails, there are two settlement methods. One is that members who have already paid can immediately complete the order at the set unsuccessful group purchase unit price, and when the group purchase succeeds, the settlement will be based on the successful group purchase unit price. The other is that if the group purchase fails (the required quantity is not met), the paid members' orders are not completed, and the payment is unsuccessful.

[0031] Group buy orders that have been set up by the recipient can be sent to public domain trading platforms for exposure, allowing more people to see them. If they are not sent to public domain trading platforms, the group buy orders will only be seen by people who enter the store or the payment box.

[0032] Label 3 indicates the inverted triangle drop-down button for initiating online sales (or group buying). Clicking this button will bring up the fields for entering product information; otherwise, these fields are hidden. In the attached image, fields for directly entering text or numbers are indicated by a "—" below the text.

[0033] The inverted triangle symbol to the right of the product name (marked 4) is a drop-down menu for the product name. The product name options that automatically appear in the drop-down menu are the names of items already set for sale in the recipient's store. When the recipient selects an item name from the drop-down menu, the corresponding brand, specifications, material, warranty period, product image, and product details are automatically populated into the corresponding item information fields. In other words, in addition to manually entering item information, the recipient can also select a pre-set item name from the drop-down menu to automatically retrieve and fill in the relevant item information fields.

[0034] Label 5 shows the QR code for product information in the online sales section. The recipient can use this QR code to automatically import the item information and fill it into the corresponding item information field in this section, saving both the payer and recipient the trouble of manually filling it in.

[0035] The section marked 6 is located between lines 2 and 3. This section mainly configures various operational function modules to complete the payment process. These include, but are not limited to, a value copy key, a serial number selection key, a payment discount setting key in the payment box, a key to add a payment group and members, a key to add payment personnel, a refund key, and a user name search function, etc. In the accompanying drawings, the text "×× key" indicates that this is a function key, or a box is added around the text to indicate that this is a function key. Since this manual mainly introduces the architecture system, functional framework, functional logic relationships, and applications of the payment function, the functions or function keys configured in the architecture framework only serve the architecture and various practical applications. Therefore, the descriptions of some function keys in this manual are not detailed. The various payment function keys or modules in the payment box can be added, removed, and continuously improved according to application needs.

[0036] The section shown in label 7 covers all areas below line 3. This section is used to list and display users in various payment states in the payment box.

[0037] The section marked 8 is the area between double solid lines 1 and 2 on the diagram. This section lists individual users and payment group users who have completed payments and executed the set payment rules. Payment users listed within the same set of double solid lines represent users who jointly executed the same payment rule.

[0038] The section marked 9 is the area between the double solid line 2 and the single solid line 1 on the diagram. This section lists individual users and payment group users who have completed payments but whose payment rules have not yet been fully executed. Of course, individual users and payment group users can also be listed separately in different sections; this only changes the visual effect.

[0039] The section marked 10 is the area below the single solid line 1 on the diagram. This section lists individual users and payment group users awaiting payment. Individual users are in a pending payment state as soon as they enter the payment box and will be displayed below the single solid line. Within a payment group, as long as there are still unpaid group members, the entire payment group, even if still in a pending payment state, will be listed below the single solid line, but this does not affect the payment rules for group members who have completed their payments. Among the individual users and payment group users awaiting payment under the single solid line 1, the payment group is listed before the individual users. Of course, individual users and payment group users awaiting payment can also be listed separately in different sections; this only changes the visual effect.

[0040] The checkbox labeled 11 is for individual user 1 who is yet to receive payment.

[0041] Mark 12 shows the QR code for payment data in the payment slip for user 1, which the merchant can use to import the user's payment order data. The imported order payment amount can be set to correspond to the amount due in the payment slip field and can be adjusted according to actual requirements.

[0042] The button marked 13 in the payment slip for user 1 who is waiting to pay is used to confirm the payment.

[0043] Label 14 indicates the "Create Payment Group" button in the payment section for user 1 who is pending payment. Individual users in the "Pending Payment" state in the payment box can also click the "Create Payment Group" function in their payment section. After creation, a payment group initiated by that user will be generated in the payment box.

[0044] Label 15 is the "Go to Payment Box Joint Payment (Group Payment)" button in the payment bar for user 1 who is waiting to pay.

[0045] Label 16 is the "Go to Payment Box for Individual Payment (Group Payment)" button in the payment bar for user 1 who is waiting to pay.

[0046] Instruction manual attached Figure 2 This is a basic functional diagram of the payment box.

[0047] The section shown in label 1 is the area above line 1. The main function of this section is to display the recipient's identity, address, and other information in this area of ​​the payment box when the payment box is linked to the recipient's payment box. The recipient can show and introduce their information to the payer, including company information, product information, etc.

[0048] The section marked 2 is located between lines 1 and 2 on the diagram. Its main function is to allow both the payer and payee to edit the item information in the payer's payment box. After editing and confirmation by the payer, a group order is generated, automatically producing an order number. Each member of the group order will generate their own sub-order upon successful group order placement. Both the payer and payee can publish the group order on the platform. When editing product information, both the payer and payee can jointly edit the product name, brand, specifications, material, warranty period, reason for initiating the group order, product details, and product photos or videos. Only the payee (seller) can edit the group order quantity, group order price, and shipping method. After editing the necessary product information, the group order is generated upon confirmation by the payer. Both the payer and payee can publish the group order on the public platform, and both can withdraw published group orders. Of course, there are other ways to create and publish products, which will not be elaborated here.

[0049] Label 3 shows the QR code for the product information in the "Initiate Online Sale" section of the payment form. The recipient can use this QR code to import the product information, which will be automatically filled into the corresponding product information field in this section, saving both the payer and recipient the trouble of manually filling it in.

[0050] Label 4 refers to the "Group Purchase Quantity" field in the section for editing and posting items for sale. When the recipient enters the group purchase quantity, this quantity represents the total quantity that all members in the group should purchase. The group purchase will only be successful if it equals this quantity, meaning the payment will be successful. If the total quantity purchased by the members is less than the group purchase quantity, the group purchase will not be successful, and the payment will also not be successful. Figure 2 The horizontal line "—" below the words "Quantity for Bundled Purchase" in the middle of the illustration indicates that this is a function field. The content to be filled in this field is the text indicated above the "—" symbol; that is, the quantity of the bundled items should be entered. The same method is used to represent other function fields in the accompanying illustrations.

[0051] The section marked 5 is located between lines 2 and 3. This section mainly contains various operation modules and function buttons for completing payments. For example, there are buttons for adding payment members, selecting all, selecting serial numbers, copying values, distributing payment equally, setting the total payment amount, setting the total receipt amount, adding to the receipt box, adding to the payment box, etc.

[0052] The section marked 6 is located below line 3. This section is where each member of the group pays out and receives their own payment function or payment entry. The group pays out number can be automatically generated. The group pays out name is set by the group leader (the person who initiated the group pays out). Each member's payment entry includes inputting the quantity of goods, the payment amount, the payment percentage, the amount to be received, the payment percentage, the order module, and clicking the payment button, etc.

[0053] The checkbox marked 7 is for Member 1 (Group Leader) in the payment section. It allows for batch editing and modification of payment data for multiple members who are simultaneously selected. Clicking the checkbox again after selecting a member will deselect it.

[0054] Label 8 is the QR code for payment data in the member payment entry. The payee can import the user's payment order data through this QR code.

[0055] Mark 9 is the module where members input the quantity of goods they want to purchase. This module is only unlocked when a group purchase is generated or a payment box is set up to pay the total amount; otherwise, members cannot input the quantity.

[0056] The button marked 10 is used by each member to confirm payment.

[0057] Instruction manual attached Figure 3 This is a basic functional diagram of the payment group within the payment collection box.

[0058] The section marked 1 is located above line 1 on the map. For an explanation of the main functions of this section, please refer to [link / reference needed]. Figure 1 Note 1 explains.

[0059] The section marked 2 is located between line 1 and line 2 on the diagram. Its main function is to initiate online product transactions. Both the payee and payer can edit the product information in the payment group. After the payer confirms the edited information, a group order is generated, and an order number is automatically generated. Each member of the group order will generate their own sub-order upon successful group order formation. Both the payee and payer can publish the group order on the platform for sale. When editing product information, the payee and payer can jointly edit the product name, brand, specifications, material, warranty period, reason for initiating the group order, product details, and product photos or videos. Only the payee (seller) can edit the group order quantity, unit of quantity, group order price, and shipping method. After editing the necessary product information, the group order is generated upon the payer's confirmation. Both the payee and payer can choose to publish the group order on a public platform, and both can withdraw published group orders. Of course, there are other methods for editing and publishing products, which will not be elaborated here.

[0060] Label 3 shows the fields for "Successful Group Purchase Price" and "Unsuccessful Group Purchase Price" in the online sales section of the payment group. These two fields also appear in the online sales section of the payment box, but not in the online sales section of the payment box.

[0061] Mark 4 is a QR code for product information, for reference. Figure 1 Explanation of label 5.

[0062] The section marked 5 is located in the area between lines 2 and 3 on the diagram. This section mainly contains various functional modules and keys for completing group payment operations. For a description of the functions of this section, please refer to [link / reference needed]. Figure 1 The label 6 and Figure 2 Mark 5.

[0063] The section marked 6 represents all areas below line 3. This section lists and displays users in various payment statuses within the payment group.

[0064] The section marked 7 is the area between double solid lines 1 and 2 on the diagram. This section lists individual users who have completed payments and whose set payment rules have been executed.

[0065] The section marked 8 is the area between the double solid line 2 and the single solid line 1 on the diagram. This section lists individual users who have completed payments but whose payment collection rules have not yet been fully executed.

[0066] The section marked 9 is the area below the single solid line 1 on the diagram. This section lists individual users whose payments are pending. Individual users are in a pending payment state as soon as they join the payment group, and will be displayed below the single solid line. As long as there are still unpaid group members in the payment group, the entire payment group is considered to be in a pending payment state, and will be listed below the single solid line of the payment box.

[0067] The box marked 10 is for users who are yet to receive payment.

[0068] Label 11 is the field for entering the quantity of goods in the payment slip for user M who is to pay.

Claims

1. A convenient method for initiating online transactions and its application, which, moreover, excels at group payments and group collections, and is applicable to various complex multi-person payment and collection scenarios. The implementation of this function is based on a payment function architecture (system) and its application. This architecture (system) mainly consists of three components: a collection box, a payment box, and a payment group. Within this architecture, each component also includes its own framework, modules, functional modules, etc. See Figures 1, 2, and 3 in the specification for illustrations and annotations. All components, functions, functional module extensions, functional applications, system operation methods, procedures, and steps based on this payment function architecture system are within the scope of the claims. The composition, functional definition, functional logical relationships between the components, and various ways, methods, and steps for their coordinated use are described for each of the three main functional architecture system components. The synergy and organic application of these three main functional components can generate various payment and collection methods, particularly excelling at group payments among multiple people. Currently, this type of group payment is the most efficient and fastest, bringing convenience to both parties in the transaction. This convenience is also reflected in the fact that the payer can complete the payment operation without using any of their devices. Furthermore, this payment functional architecture (system) can easily incorporate e-commerce functions to realize online transactions. It can easily initiate group order and group payment services, thereby reducing consumer costs. The main descriptions of these three main functional components are as follows:

1. Payment box The payment function of the payment box only allows users to receive payments and then refund them. Payment boxes can be categorized based on the market entity, such as personal (private) payment boxes, personal commercial payment boxes, enterprise / institutional user payment boxes, and sole proprietorship user payment boxes. Personal commercial payment boxes, enterprise / institutional user payment boxes, and sole proprietorship user payment boxes can be collectively referred to as commercial payment boxes, while personal (private) payment boxes are simply called personal payment boxes. The functional architecture, framework, and operation methods of commercial payment boxes from different market entities are largely the same; only the specific functional modules differ slightly. The biggest difference between personal and commercial payment boxes is that personal payment boxes cannot initiate online transactions, while commercial versions can. The personal payment collection box allows payees to create payment groups and import payment group members themselves, while the commercial version does not. However, the commercial version allows users to initiate online transactions (such as group buying) and also allows externally imported payment groups within the payment collection box to initiate online transactions, whereas payment groups within the personal payment collection box cannot. Personal (private) payments can only be made using (bound to) the personal (private) version of the payment collection box; personal commercial payments can only be made using (bound to) the personal commercial version of the payment collection box; corporate payments can only be made using (bound to) the enterprise / institution version of the payment collection box; and sole proprietorship payments can only be made using (bound to) the sole proprietorship version of the payment collection box, etc. Because there are various types of payment recipients in the market, and their respective payment rights differ, different payment collection boxes are set up for different entities. A payment recipient (such as an individual user) can own (copy) multiple payment boxes of the same type. When there are multiple payment boxes of the same type, these payment boxes all have the same main entity number, which is like a unique identifier for the payment recipient. However, the sub-numbers are different and are used to distinguish these payment boxes of the same type.

2. Payment box The payment box is the primary tool used by market participants (users) for making payments. It also has a receiving function, and its payment and receiving capabilities are particularly strong in group payments. For example, a payment initiated by one person can be received simultaneously by any number of people, according to any set amount or rules. Group payments are currently the most efficient, the most convenient to use, and have the widest range of applications. Online transactions can also be initiated within the payment box. However, the prerequisite for initiating an online transaction using the payment box is that it must be connected to the commercial version of the payment collection box. A payment entity (such as an individual user) can have (copy) multiple payment boxes. When there are multiple payment boxes, these payment boxes all share the same entity number, which serves as a unique identifier for the payment entity (user). However, each payment box has a different sub-number, which is used to distinguish these payment boxes.

3. Payment Group A payment group is a multi-person payment group generated within the payment collection box. Each payment group can have its own payment discount and settlement method set independently. In this case, the payment group is not affected by the payment discount method set in the payment collection box. However, if a payment group does not have its own payment discount method set, it may be affected by the payment discount method set in the payment collection box. Payment groups are also one of the tools for initiating online transactions. There are two types of payment groups: one is a payment group created by the payee using the payment collection box, and the other is a payment group imported into the payment collection box by an external payer or created within the payment collection box. Only... Only personal (private) payment collection boxes have the function of creating payment groups and importing group members themselves. Self-imported payment groups are not subject to the personal payment collection box's discount rules by default. However, externally imported payment groups or payment groups created by the payer within the payment collection box will be affected by the payment collection box's rules unless separate rules are set within the payment group. The commercial version of the payment collection box currently does not allow users to create payment groups or import group members themselves, but it can initiate online transactions. When a payee initiates an online transaction (such as a group-buying group), it is essentially a "payment group" created by the payee within the payment collection box. Because multiple payment entities can be imported into the payment box, payment box, and payment group, it excels at group payments. Its interconnected payment architecture (system) of "payment box, payment box, and payment group" allows for wider application, maximum speed, and highest efficiency, meeting various group payment scenarios. It also facilitates easy statistics and display, providing a clear overview of transaction data for both parties and simplifying refund operations. The interconnectivity of the three is reflected in the fact that the payer can make a payment directly using the payment box, or can transfer the payment to the payee's payment box, or can create a payment group in the payment box, and the payer can also transfer the payment to the payment box from the payee's payment box, etc.

Images