US10679207B1

US10679207B1 - Bill splitting and account delegation for NFC

Info

Publication number: US10679207B1
Application number: US14/970,139
Authority: US
Inventors: Christopher Michael Huffines; John Cronin
Original assignee: Blazer And Flip Flops Inc
Current assignee: Blazer and Flip Flops Inc dba Experience Engine; Blazer And Flip Flops Inc
Priority date: 2014-12-17
Filing date: 2015-12-15
Publication date: 2020-06-09

Abstract

The present invention includes systems and methods directed towards bill splitting and account delegation using near field communications (NFC). The systems and methods enable an NFC device to split a single bill into two or more portions, allow one or more users to apply gift cards, coupons, promotions, tips or other modifications to the amount due, and facilitate multiple different types of payment from two or more users on the same bill using NFC.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims the priority benefit of U.S. provisional application No. 62/093,101 filed Dec. 17, 2014 entitled “Bill Splitting and Account Delegation for NFC,” the disclosure of which is hereby incorporated by reference.

BACKGROUND Field of Invention

The present invention generally relates to near field communications (NFC). More specifically, the present invention relates to bill splitting and account delegation using NFC.

Description of the Related Art

Near field communication (NFC) is a form of contactless communication between devices (e.g. smartphones or tablets). Contactless communication allows a user to motion (e.g. wave or pass) the device over other NFC compatible devices to send information without the need to provide physical contact between the devices or to undergo multiple steps to set up a connection between the devices.

NFC maintains interoperability between different wireless communication methods and other NFC standards through the NFC Forum. The NFC Forum enforces strict standards that manufactures must meet when designing NFC compatible devices. These standards ensure that NFC between devices is secure and remains easy-to-use with different versions of the technology.

The technology behind NFC allows a device (also referred to as a reader, interrogator or active device) to create a radio frequency (RF) current that is used to communicate with other NFC compatible devices or a small NFC tag holding information that might be of interest to the reader. Passive devices, such as the NFC tag, can be provided in posters and other forms of media or advertising. These passive devices store information and communicate with the reader but do not actively read other devices.

Peer-to-peer communication between two active devices is also possible with NFC. This communication would allow both devices to send and receive information between the two devices.

Ways of making multi-party payments are known in the art. For example, restaurants and other service providers are capable of taking a single bill and splitting the bill into two or more portions based on a number of individuals who wish to pay for the total bill (e.g., splitting a total bill at a restaurant across four different checks). In such a scenario, each individual pays for a portion of the total bill resulting in the entire bill being paid by a collective group. U.S. patent publication number 2014/0074691 discloses an exemplary NFC device capable of splitting a bill.

There is, however, a lacking in the art whereby an NFC device is capable of splitting the bill and allowing one or more users on their NFC devices to apply gift cards, coupons, promotions, tips or other modifications to the amount due. Additionally, presently available NFC systems do not accept mixed payments (e.g., person A pays in cash and person B pays using NFC).

SUMMARY OF THE CLAIMED INVENTION

Embodiments of the present invention include systems and methods directed towards bill splitting and account delegation using near field communications (NFC). The systems and methods allow an NFC device to split a single bill into two or more portions, allow one or more users to apply gift cards, coupons, promotions, tips or other modifications to the amount due, and facilitate multiple different types of payment on the same bill using NFC.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates the process for basic payment using NFC.

FIG. 2 illustrates a diagram showing an overall system of the present invention.

FIG. 3 illustrates a diagram showing another embodiment of the overall system of the present invention.

FIG. 4 illustrates exemplary payment software found in a merchant payment device.

FIG. 5 illustrates exemplary base software of the payment software.

FIG. 6 illustrates exemplary device payment software found in a customer NFC device.

FIG. 7 illustrates an exemplary payment database.

FIG. 8 illustrates exemplary multiple payer software.

FIG. 9 illustrates an exemplary transaction database.

FIG. 10 illustrates an exemplary active payment database.

FIGS. 11-14 illustrate exemplary Customer GUI found on a customer NFC device.

FIG. 15 illustrates an exemplary merchant GUI.

FIGS. 16-17 illustrate exemplary customer GUI once the receipt software has been initiated.

FIG. 18 illustrates exemplary receipt software.

FIGS. 19-20 illustrate exemplary methods for bill splitting and account delegation using NFC.

DETAILED DESCRIPTION

FIG. 1 illustrates the process for basic payment using near field communications (NFC). In particular, the FIG. 1 shows a general credit card approval payment process and general payment process using NFC.

With reference to the basic authorization process (shown as the top figure of FIG. 1), a customer can initiate the basic authorization process by buying one or more items with an NFC compatible device (e.g., smart phone). The customer NFC compatible device communicates with a merchant point of sales (POS) terminal. This POS terminal can be a contactless terminal for NFC transactions. POS can refer to a place where a transaction (e.g. purchase transaction) can be completed (e.g., cash register in a store).

Upon receiving a purchase request from the customer, the merchant terminal provides the request to the merchant bank. The merchant bank then forwards the request to the credit card payment processing. The credit card payment processing further forwards the request to the customer bank.

At the customer bank, a determination as to whether to approve or decline the request is made. This determination can be based on a variety of different parameters. The outcome of the determination (e.g., approved or declined) can be provided back to the credit card company and the merchant bank. The merchant terminal is afterwards informed by the merchant bank about the authorization status for the recent purchases of the customer.

Also seen in FIG. 1 in the basic authorization process, two further elements are included: the Trusted Service Manager (TSM) and carrier with OTA (over-the-air) programming. The TSM acts as a neutral broker that sets up secure connections between different elements. In this case, the TSM can find the encryption codes for communications between the credit card payment systems and the customer bank. On the other hand, the carrier with OTA programming may provide various methods for distributing new software updates, configuration settings and even updating encryption keys for the system.

FIG. 1 also includes an illustration outlining the process for basic payment using NFC. Similar steps are provided between the various elements (e.g., customer, merchant, credit card, TSM, carrier with OTA programming) as identified above for the basic authorization process. In particular, a merchant first sends settlement requests to the merchant bank. That request is forwarded to the credit card payment processing and to the customer bank. The customer bank then transfers the requested funds as necessary based on the request.

FIG. 2 illustrates a diagram showing an overall system of the present invention. The system includes one or more customer NFC devices (illustrated as Customer 1 NFC device, Customer 2 NFC device and Customer n NFC device), an NFC reader, merchant payment device, a credit card reader, merchant graphical user interface (GUI), a POS terminal, merchant gift card server, other payment devices and a payment system.

Each of the customer NFC devices can be a smartphone, tablet, mobile device, smartcard, coin system or any other device that has either an active or passive NFC transceiver. The foregoing devices have the requisite processor, memory, storage, and interfaces—both communications and interface—to allow for operability as are known in the art. Each of the NFC devices may also include device payment software used to operate the NFC transactions from the device side. The NFC devices may also include a customer GUI. The customer GUI enables display of information for the user to view and facilitates receiving inputs from the user as well.

Each of the customer NFC devices in the system is communicatively attached to the NFC reader. Although embodiments described in the present disclosure may make reference to communications entirely being NFC, other embodiments of the present invention may utilize both NFC and other types of communications (e.g., Bluetooth, wireless, laser, infrared).

The NFC reader is a device for receiving and transmitting data to and from the customer NFC devices. The NFC reader is communicatively connected to the merchant payment device. The communication between the NFC reader and the merchant payment device may be a wired connection (e.g., Ethernet, coaxial) or a wireless connection (e.g., Wi-Fi, Bluetooth). It should be noted that although the NFC reader is shown separate from the merchant payment device in FIG. 2, other embodiments may have these two elements integrated into one single device having multiple modules directed at performing the functions of the two elements.

The merchant payment device is a terminal that the merchant payment system uses to communicate with credit card processing system and other outside entities. For example, the merchant payment device may be envisioned as a cash register at a retail store or as a server to which all the cash registers communicate with.

The merchant payment device may include the merchant GUI. The merchant GUI can be used by salespersons or servers at the merchant place of business to observe and input data.

The credit card reader, as shown in FIG. 2 is a device for reading the magnetic strip or other data such as a smart chip on a credit card at a POS terminal (e.g., cash register). Other payment devices (e.g., debit cards) include any payment device not yet described herein. Each of the payment devices is connected to the merchant payment device, in a similar manner as the NFC reader, either through a wired connection or wireless connection.

The merchant payment device may include payment software. The payment software governs the transactions between the various readers (e.g., credit card, NFC, other payment devices) and terminals. The payment software also governs communications to and from the credit card processing service and any other service (e.g., merchant gift card server).

The merchant bank is connected to the merchant payment device. The communication can be wired, wireless or a combination. It may also be an indirect connection through one or more servers and/or through the cloud/Internet.

The merchant bank, credit card processing and customer bank are part of the payment system used to resolve and authorize payment requests. The payment system can operate similarly as provided in the prior art and as described above in FIG. 1.

Also communicatively connected to the merchant payment device is the merchant gift card server. The merchant gift card server can represent the merchant internal or external server and houses its gift card and couponing services. In other words, the merchant gift card server is one or more devices that track, receive and authorize the use of gift cards, coupons and other merchant-specific promotions or payment means used by the customer. Although only one server is shown here, in FIG. 1, for the merchant gift card server, multiple servers operating in parallel or multiple systems (e.g., one system for gift cards, one system for coupons) may also be implemented according to the present invention.

Once the payment software has determined that the sufficient payment has been received (e.g., credit card, cash, debit) collectively from each of the customers involved, the software completes the transaction and provides a notice to each of the customers indicating such to each of the customer GUI on their NFC devices.

FIG. 3 illustrates a diagram showing another embodiment of the overall system of the present invention. In this embodiment, the elements shown are similar to the elements in FIG. 2. It should be noted, however, that now instead of each of the customer NFC devices paying directly by communicating with the NFC reader, all but one of the customer NFC devices may be paying indirectly through a directly paying NFC device. For example, there may be one customer NFC device that still communicates directly to the NFC reader to provide payment to the merchant payment device. The remaining customer NFC devices, however, provide their payments to the merchant payment device indirectly by forwarding their transaction to the one customer NFC device that directly communicates with the NFC reader. The communication between the indirectly paying NFC devices and the directly paying NFC devices can be wired, wireless or a combination.

The one directly-paying customer NFC, which communicates directly with the NFC reader, can obtain all the transactions from the other NFC devices and provide one transaction (e.g. payment information) to the merchant payment device. The system then uses all the payment information and operates in a similar manner as shown in FIG. 2.

FIG. 4 illustrates exemplary payment software found in a merchant payment device. As shown in FIG. 4, one or more customer NFC devices are in communication with the merchant payment device. For the purposes of clarity, the NFC reader and any other payment devices are omitted. The merchant payment device is connected to a main program bus. The main program bus connects to five elements for the payment software. The five elements include a transaction database, an active payment database, base software, receipt software and multiple payment software.

The transaction database contains data concerning each transaction. This data can include the price of each item purchased and any other data that the merchant may wish to store. The active payment database stores data related to the individual payments made for each transaction. For example, a transaction may be that a meal was shared by four individual people. The transaction database would store the transaction information for the meal. Payments from the four individual people would, however, be individually stored in the active payment database.

The base software is the software that operates the payment system. The base software also allows customers to select various payment and receipt options. The multiple payments software is software that is used by the customers to pay using multiple payment means. The multiple payment software can also be used to split the transaction (e.g., bill) into any number of parts. The parts themselves may be equal or proportioned based on input from one or more of the customers. The receipt software governs how customers wish to receive receipt information.

The five elements described above, although shown within one payment software, may also be implemented in one or more software modules. Furthermore, although the five elements are all implemented in the same device using a program bus, it is possible that the elements can be implemented in different device and connected using a physical bus.

FIG. 5 illustrates exemplary base software of the payment software. The base software initiates when a transaction is provided to the merchant payment device. The input can come from a merchant GUI (e.g. salesperson or server) where information has been inputted into the merchant payment device. The base software receives the transaction and a corresponding total price. The transaction may include an itemized list of all the goods and/or services that were sold in the transaction.

After the information about the transaction and the total price is obtained, they are both stored to the transaction database. The base software can also request payment for the transaction. This request is provided from the merchant payment device back to the various customer devices. Each of the customer devices can then select a particular payment type and provide payment information back to the merchant payment device to satisfy the payment request.

The base software then determines if the payment has been split over two or more customers. If only a single payment was received from one customer, the base software notifies the merchant payment device accordingly and returns the payment information for the payment request to be processed. The processing of the payment request can include providing the payment information from the merchant payment device to the payment system. The information can also be provided to other systems (e.g., the gift card server) prior to the payment system to provide modifications to the payment request from the merchant payment device (e.g., discount on the total price for the transaction). Once the payment has been processed, the receipt software (described later in FIG. 18) is initiated.

If the base software determines that the transaction has been split over two or more customers, however, the base software obtains the total cost of the transaction from the transaction database. This is to ensure that the payment information provided by the two or more customers satisfies the total cost as indicated in the payment request. Afterwards, the base software provides a multiple payer request and the total cost from the transaction database to the multiple payer software. Further details about the multiple payer software are discussed in the context of FIG. 8.

FIG. 6 illustrates exemplary device payment software found in a customer NFC device. The software initiates when a request for payment is received from the NFC reader by a customer NFC device. The payment request can be the same payment request provided by the merchant payment device described in FIG. 5 above.

After the request is received by the customer NFC device, the payment software retrieves all applicable payment from the payment database. Further details for the payment database are provided below in the context of the discussion of FIG. 7. The payment database includes the various way the customer can make a payment (e.g., credit card, debit card, gift card, coupon) all stored locally on the NFC device. The information in the payment database can be provided and/or updated by the customer. Payments that are not applicable (e.g., coupons that do not apply or are expired) are not retrieved.

From all the applicable payments retrieved, the customer is then prompted to select a payment type. The prompt can be provided on the customer GUI of the customer NFC device. The GUI may also provide an option to split the cost of the payment with other customers. If more payments are to be provided, the payment software loops until all the payment types have been obtained and sent. The customers selected payment type and information about whether the payment is split is provided to the base software of the merchant payment device (as described with respect to FIG. 5).

FIG. 7 illustrates an exemplary payment database. The payment database can include five columns that store information such as payment type, information about the payment type, locations where the payment is accepted, balance for the payment type and any additional information, if applicable, about that payment type that may be desired. The additional information may be notes about coupons or promotions or conditions for using that particular payment type. It should be noted that the database can include more or less information as well as include different types of information. The purpose of the database is to store information about the various payment types that a customer has access to on their mobile device.

FIG. 8 illustrates exemplary multiple payer software. As discussed above with respect to FIG. 5, this software is initiated if the base software detects that multiple payments have been received for a single payment request because the customers split the payments among themselves. The multiple payer software receives the total bill amount and a multiple payer software initiation from the base software as described above. The multiple payer software next prompts the two or more customers, on their customer GUI, to provide payment. The multiple payer software receives the payment from each of the customers via the payment devices (e.g., credit, debit, POS). Afterwards the multiple payer software can process the payments and any applicable coupons using the merchant payment device. Each payment is forwarded based on their payment type for authorization (e.g., credit card to the credit card system, coupon to merchant gift card server).

The multiple payer software afterwards determines if the payments were authorized. If one or more of the payments were rejected, the multiple payer software provides notice to the customer GUIs as well as to the merchant. The notice may include payment information and request for additional payment for a remaining balance of the pending transaction. The multiple payer software then polls for additional payments that are then provided for authorization in the same way as the first group of payment information provided.

Once all payments from the customers have been authorized, the multiple payer software checks to see if the sum of the recorded payments from the two or more customers is equal to or greater than the total amount that was provided to the multiple payer software from the base software. If yes, the multiple payer software initiates the receipt software. Otherwise, the multiple payer software calculates an outstanding balance that is the difference between the total amount and the amount paid. This balance is then provided to the merchant and the customer to be resolved in a similar manner as described above for situations when payments were not authorized. In other words, the multiple payer software will continue to request and process additional payments from the customers until the total amount paid is greater than or equal to the total amount for the transaction.

FIG. 9 illustrates an exemplary transaction database. The transaction database, as shown in FIG. 9, includes two columns of information: a transaction number identifying a unique transaction and a total amount for that particular transaction. As discussed above, the total amount for a transaction is helpful in determining if two or more customers have satisfied the total payment requests for the goods and/or services in a particular transaction facilitated by the multiple payer software. Also discussed above, the transaction data may include other information as well including an itemized list of items and/or services with their corresponding prices or subtotals based on groupings of items and/or services. It should be noted that the transaction database can include additional information as well as different types of information not described here.

FIG. 10 illustrates an exemplary active payment database. The active payment database, as shown in FIG. 10, can include columns containing information such as user ID, transaction number, payment type, account number for the payment type and the recorded payment. The user ID would correspond to each unique customer device submitting a payment. The transaction number identifies the transaction that the payments are being provided for. The payment type lists the method of payment that a particular customer may use (e.g., credit, debit, cash, coupon). The account number provides corresponding information for the payment type. For example, the account number may identify a particular credit card account, bank account, gift card number. The recorded payment identifies the amount that the particular customer has paid towards that transaction. Alternatively, if a coupon is used, the amount of the coupon can be provided with the “recorded payment” although no actual money was provided from the customer.

FIGS. 11-14 illustrate exemplary Customer GUI found on a customer NFC device. With reference to FIG. 11, an example of a GUI where the customer has received a prompt for payment is shown. The payment is for a meal for a total price of $100.00. The GUI provides the options to make one single payment or to split the total price among two or more other customers. In particular, an embodiment as shown in FIG. 11 may have a user who may wish to split the bill with other individuals who may have shared the meal. The decision to split the bill may be implemented by utilizing a cursor and interacting with the split option in the GUI.

FIG. 12 shows another customer GUI. In particular, the customer GUI can be one that is found subsequent to the customer GUI in FIG. 11 where the customer chose to split the bill.

In the customer GUI of FIG. 12, the customer can be prompted to select a method of payment and a payment amount. For example, as shown in the figure, the customer has the option to select between an available credit card and a gift card. This selection can be provided using a drop down menu. The amount that the customer wishes to pay can be provided through the customer GUI as well. This can be provided, for example, by using the provided keypad. Other methods of input, such as touch screen or voice recognition can also be provided to receive inputs from the customer on their NFC device.

FIG. 13 illustrates another customer GUI where the customer has selected two forms of payment: gift card and credit card. The user has also inputted two amounts for each of the forms of payment. The GUI can include information about whether the payment has already been processed (e.g., indicated as paid) or may still need to be processed. Furthermore, the customer GUI may include information about the total price that needs to be paid as well as any remaining balance that is yet to be paid by the other customers in which the bill is being split with. In fact, if the remaining balance is non-zero, meaning that the total balance has not been paid off, notification can be provided in the customer GUI that additional payments may still be necessary. Furthermore, options can be provided for the customer to provide additional payments to fulfill the remaining balance.

FIG. 14 illustrates another customer GUI on a different NFC device that is sharing the split bill with the customer device shown in FIGS. 11-13. The customer GUI can provide information about the transaction (e.g., location and total cost) as also provided in the customer GUI in FIGS. 11-13. This second customer can also provide a method of payment and payment amount in a similar manner as the customer described in FIGS. 12-13. It should be noted that the balance, noted in FIG. 14, shows that the total cost of the meal has been paid off. This coincides with the customer in FIGS. 11-13 and the customer in FIG. 14 providing payment for the combined total cost of the meal. Once the balance is zero, a notification on the customer GUI can also be provided to indicate that the total cost of the items/service has been paid off (e.g., Thank you).

It should be noted that FIGS. 11-14 illustrate an example where two customers have split the bill for a meal. Embodiments may include, however, any number of customers. Each customer GUI can operate in a similar manner as shown in the above figures whereby each customer can select payment types and amounts until the total cost has been paid for.

FIG. 15 illustrates an exemplary merchant GUI. In particular, the merchant GUI shows the different payments provided by the customers from FIGS. 11-14. The information about the different payments may include identification as to which customer paid using which payment means, account information for the payment means as well as the amount paid. The merchant GUI may also include the total cost of the transaction, the remaining balance (if any), that the bill has been split and a note that the transaction has been complete.

FIGS. 16-17 illustrate exemplary customer GUI once the receipt software has been initiated. In particular, FIG. 16 illustrates an embodiment once payment for the items and/or services has been completed and the response software is initiated. Once this happens, the customer GUI may provide an option for the customer to select how the receipt can be provided from the merchant to the customer. The customer may be able to select the option by using the customer GUI (e.g., cursor, touch screen).

Turning to FIG. 17, a customer GUI where the customer has selected to receive the receipt on their mobile device is shown. Below the receipt delivery selection, information for the payment is provided as a receipt for the customer to view in accordance to the selection above.

FIG. 18 illustrates exemplary receipt software. The receipt software can be initiated either from the base software (when there is only one customer paying) or the multiple payment software (when more than one customer is paying a split bill). Once the receipt software is initiated, the software requests information about the transaction from the active payment database. The active payment database stores all the payments that were made for this (and other) transactions.

For each customer who paid for the selected transaction, the receipt software prompts the customer to select a receipt type preference. The request can be provided either to the customer GUI on their customer NFC device or on a merchant GUI for the customer to interact with. It is also possible that the salesperson or server (e.g., merchant GUI) may also request a receipt for the same transaction using similar GUI as shown in FIGS. 16-17.

Once the receipt type preference is obtained from the customer, the receipt data is sent to the merchant payment device to be provided to, for example, the customer GUI to view or to a printer. The receipt software repeats this process for each customer who paid, asking for receipt type preference, obtaining information about the payment and then providing the information to the particular paying customer.

FIGS. 19-20 illustrate exemplary methods for bill splitting and account delegation using NFC. In particular, the first step is to provide the elements to facilitate the present invention including one or more customers with NFC enabled devices where each device has device payment software and a customer GUI, an NFC reader, payment devices (e.g., credit card reader, debit card reader, merchant POS), and a merchant payment device. The merchant payment device has payment software and is connected to the payment system and merchant gift card server. The payment system includes the merchant bank, the credit card processing and the customer bank.

The method next includes a step for receiving a total sale amount at the merchant payment device. Afterwards, the customers may be allowed to select a payment means. The selection can be performed using NFC. Next, the customer can select one or more payment means (e.g., coupon, cash, credit card, or other payment means). In other words, this is the step that allows the customers to select how they would like to pay the outstanding total.

After the payment method has been selected, the payments are processed. Subsequently, the method determines if the total payment has been satisfied. If not, additional requests are provided to the customers until the total amount has been paid. Otherwise, receipt requests will be provided to provide records to the customers recording the payments made for the transaction.

It should be noted that software may be stored in any various forms of non-transitory forms of memory as are known in the art. Software stored in memory may be executed by a processor or processing devices at a computing device. The computing device may be mobile in nature such as a mobile phone or tablet device. The computing device executing the instructions from memory may have one or more communications interfaces that allow for connection to wired or wireless networks as well as interaction with wired or wireless devices, including NFC devices.

The foregoing detailed description of the technology herein has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the technology to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. The described embodiments were chosen in order to best explain the principles of the technology and its practical application to thereby enable others skilled in the art to best utilize the technology in various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the technology be defined by the claim.

Claims

What is claimed is:

1. A method for using near field communication (NFC) for bill splitting and account delegation, the method comprising:

obtaining information about an NFC transaction initiated via an NFC interface, the information including a total transaction amount;

receiving a request via the NFC interface to split the total transaction amount of the initiated NFC transaction into two or more portions, each portion assigned to a different user device;

receiving confirmation information from the assigned user devices regarding fulfillment of each respective assigned portion of the initiated NFC transaction, wherein at least one of the assigned user devices further provides discount information;

modifying the total transaction amount based on the discount information provided by the at least one assigned user device;

identifying that a current total fulfillment amount does not yet meet the modified total transaction amount; and

sending at least one notification requesting additional payments to the assigned user devices until the current total fulfillment amount meets the modified total transaction amount.

2. The method of claim 1, wherein at least one of the assigned user devices is designated for making a direct fulfillment payment via the NFC interface.

3. The method of claim 2, wherein at least one other of the assigned user devices provides respective confirmation information to the designated user device.

4. The method of claim 3, further comprising receiving the respective confirmation information via the NFC interface as forwarded by the designated user device.

5. The method of claim 3, wherein the at least one other user device provides the respective confirmation information to the designated user device over a wireless communication network.

6. The method of claim 3, wherein the designated user device tracks the respective confirmation information in association with an identifier of the at least one other assigned user device.

7. The method of claim 2, wherein the designated user device tracks a remaining balance of the total transaction amount not met by the current total fulfillment amount.

8. The method of claim 1, wherein the notification indicates one or more options for fulfilling a remaining balance of the total transaction amount not met by the current total fulfillment amount.

9. The method of claim 1, further comprising modifying the initiated NFC transaction by splitting the modified total transaction amount of the modified NFC transaction into a plurality of NFC transactions based on a number of the assigned user devices.

10. An apparatus for using near field communication (NFC) for bill splitting and account delegation, the apparatus comprising:

an NFC interface that:

obtains information about an initiated NFC transaction that includes a total transaction amount;

receives a request to split the total transaction amount of the initiated NFC transaction into two or more portions, each portion assigned to a different user device;

receives confirmation information from the assigned user devices regarding fulfillment of each respective assigned portion of the initiated NFC transaction wherein at least one of the assigned user devices further provides discount information;

a processor that executes instructions stored in memory, wherein execution of the instructions by the processor modifies the total transaction amount based on the discount information provided by the at least one assigned user device and identifies that a current total fulfillment amount does not yet meet the modified total transaction amount; and

a wireless communication network interface that sends at least one notification requesting additional payments to the assigned user devices until the current total fulfillment amount meets the modified total transaction amount.

11. The apparatus of claim 10, wherein at least one of the assigned user devices is designated for making a direct fulfillment payment via the NFC interface.

12. The apparatus of claim 11, wherein at least one other of the assigned user devices provides respective confirmation information to the designated user device.

13. The apparatus of claim 12, wherein the NFC interface further receives the respective confirmation information as forwarded by the designated user device.

14. The apparatus of claim 12, wherein the at least one other user device provides the respective confirmation information to the designated user device over a wireless communication network.

15. The apparatus of claim 12, wherein the designated user device tracks the respective confirmation information in association with an identifier of the at least one other assigned user device.

16. The apparatus of claim 11, wherein the designated user device tracks a remaining balance of the total transaction amount not met by the current total fulfillment amount.

17. The apparatus of claim 10, wherein the notification indicates one or more options for fulfilling a remaining balance of the total transaction amount not met by the current total fulfillment amount.

18. The apparatus of claim 10, wherein the processor executes further instructions to modify the initiated NFC transaction by splitting the modified total transaction amount of the modified NFC transaction into a plurality of NFC transactions based on a number of the assigned user devices.

19. A non-transitory computer-readable storage medium, having embodied thereon a program executable by a processor to perform a method for using near field communication (NFC) for bill splitting and account delegation, the method comprising: