US20160071095A1 - Requesting payments for selected items or services using payment tokens - Google Patents
Requesting payments for selected items or services using payment tokens Download PDFInfo
- Publication number
- US20160071095A1 US20160071095A1 US14/483,095 US201414483095A US2016071095A1 US 20160071095 A1 US20160071095 A1 US 20160071095A1 US 201414483095 A US201414483095 A US 201414483095A US 2016071095 A1 US2016071095 A1 US 2016071095A1
- Authority
- US
- United States
- Prior art keywords
- payment
- transaction
- merchant
- payer
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/229—Hierarchy of users of accounts
- G06Q20/2295—Parent-child type, e.g. where parent has control on child rights
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
Definitions
- the present application generally relates to requesting payment for selected items or services using payment tokens and more specifically to communicating a payment token having a transaction to a payer for authorization of the transaction between another user and a merchant.
- a user such as a consumer, may wish to request payment for a transaction from another user.
- a spouse may select an item as a present or a college student may request assistance paying for various college expenses, such as books.
- another user e.g., a parent, spouse, relative, etc.
- the first user may not completely cover the costs, or the first user may misuse the funds.
- the second user may instead directly engage in the transaction, such as by purchasing the items for the first user.
- the second user must know the exact items/services the first user wishes to purchase and must either visit the merchant with the first user or have the items/services delivered after purchasing the items/services. In both scenarios, the second user is required to perform time consuming processes, which may add extra costs to a transaction or result in an incorrect transaction.
- FIG. 1 is a block diagram of a networked system suitable for implementing the processes described herein, according to an embodiment
- FIG. 2 is an exemplary system environment showing a requesters device creating a transaction with a merchant for use in generating a payment token to a payer, according to an embodiment
- FIG. 3 is an exemplary system environment showing a payer device displaying a receiving payment token for authorizing or declining the transaction in the payment token, according to an embodiment
- FIG. 4 is a flowchart of an exemplary process for requesting payment for selected items or services using payment tokens, according to an embodiment
- FIG. 5 is a block diagram of a computer system suitable for implementing one or more components in FIG. 1 , according to an embodiment.
- a first user such as a requester for a transaction, may create a transaction with a merchant by visiting a merchant website or utilizing a merchant application to select one or more items for purchase. Thus, the user may access the merchant online and shop with the merchant. Once the user has selected the item(s) for purchase, the user may checkout through the merchant.
- the merchant may offer checkout services through a payment provider on the website or in their application, or may redirect the user to the payment provider.
- the payment provider may offer the user an option to generate a payment token for the transaction, where the payment token includes information about the transaction, such as a payment/transaction request.
- the payment provider may also request information for a payer for the transaction, such as contact information including a name, account identifier, email address, phone number, messaging address, or other identifier enabling identification of the payer, and similar identifying information for the first user (e.g., the requester).
- the requester may also add a note or comment about the transaction for the payer to read.
- the payment provider may utilize the payer information, the transaction information, and/or the requester information to generate a payment token.
- the payment token may include information about the transaction, including at least a payment amount for the transaction and the requester contact information for transmitting the payment token.
- the payment token may also include further information, such as the transaction information (e.g., items/services in the transaction, prices of those items/services, the merchant for the transaction, sales/discounts for the transaction, tax information, and/or shipping information), identifying and/or contact information for the requester of the items/services in the transaction, merchant information, a time limit of the validity of the payment token (i.e., until the transaction is cancelled with the merchant if the payment token is not accepted/declined), the note or comment submitted by the requester for viewing by the payer when receiving the payment token, and/or rules that the requester user has set for payment of the transaction (e.g., where the items/services may be shipped, what the payer may request from the user when paying for the transaction,
- the payment provider may attempt to transmit the payment token to the payer using the identification information for the payer submitted by the requester. If the payer cannot be contacted, the payment provider may alert the requester and/or the merchant in order to correct the issue. The requester may attempt to add new contact/identification information for the payer. In other embodiments, the merchant may cancel the transaction with the requester if the payer cannot be contacted.
- the payer may view the information in the token and decide whether to accept the transaction and process a payment for the transaction or to decline the transaction and not pay for the transaction for the requester. If the payer declines or does not accept payment for the transaction, the transaction may be cancelled with the merchant, or the requester may view the decision to decline by the payer and decide whether the requester would like to pay for the transaction of request payment from another payer.
- the payer may directly decline the transaction by select a “No,” “Decline,” or “Deny” option with the payment token. In various embodiments, if the payer does not accept the transaction for the time period that the payment token is valid, the transaction may be declined and the merchant may not receive payment from the payer.
- the payer may be redirected to the merchant website and/or the payment provider website to process and complete a payment for the transaction.
- the payer may then provide a payment instrument, such as a payment account with the payment provider, and may complete a payment process for the transaction.
- the payer may set various rules or conditions based on their payment of the transaction, such as a request for account of expenses, a requirement to receive a certain grade or mark based on their scholastic achievements, a request for additional information about the transaction, and/or information about use of the items/services in the transaction.
- the payer may also add a note about accepting and/or declining payment for the transaction, which may be provided to the requester.
- FIG. 1 is a block diagram of a networked system 100 suitable for implementing the processes described herein, according to an embodiment.
- system 100 may comprise or implement a plurality of devices, servers, and/or software components that operate to perform various methodologies in accordance with the described embodiments.
- Exemplary device and servers may include device, stand-alone, and enterprise-class servers, operating an OS such as a MICROSOFT® OS, a UNIX® OS, a LINUX® OS, or other suitable device and/or server based OS. It can be appreciated that the devices and/or servers illustrated in FIG.
- 1 may be deployed in other ways and that the operations performed and/or the services provided by such devices and/or servers may be combined or separated for a given embodiment and may be performed by a greater number or fewer number of devices and/or servers.
- One or more devices and/or servers may be operated and/or maintained by the same or different entities.
- System 100 includes a first user 102 , a second user 104 , a requester device 110 , a merchant server 130 , a payer device 140 , and payment provider server 150 in communication over a network 170 .
- First user 102 such as a consumer, may utilize requester device 110 to initiate a transaction with merchant server 130 .
- One checkout, first user 102 may select to have second user 104 pay for the transaction.
- payment provider server 150 may be utilized to generate a payment token for transmission to payer device 140 . If second user 104 accepts responsibility to pay for the transaction, a payment to merchant server 130 may be completed using payment provider server 150 .
- Requester device 110 , merchant server 130 , payer device 140 , and payment provider server 150 may each include one or more processors, memories, and other appropriate components for executing instructions such as program code and/or data stored on one or more computer readable mediums to implement the various applications, data, and steps described herein.
- instructions may be stored in one or more computer readable media such as memories or data storage devices internal and/or external to various components of system 100 , and/or accessible over network 170 .
- Requester device 110 may be implemented using any appropriate hardware and software configured for wired and/or wireless communication with merchant server 130 , payer device 140 , and/or payment provider server 150 .
- requester device 110 may be implemented as a personal computer (PC), a smart phone, laptop/tablet computer, wristwatch with appropriate computer hardware resources, eyeglasses with appropriate computer hardware (e.g. GOOGLE GLASS ®), other type of wearable computing device, and/or other types of computing devices capable of transmitting and/or receiving data, such as an IPAD® from APPLE®.
- a requester device is shown, the requester device may be managed or controlled by any suitable processing device. Although only one requester device is shown, a plurality of requester devices may function similarly.
- Requester device 110 of FIG. 1 contains a browser application 120 , a payment provider application 112 , other applications 114 , a database 116 , and a network interface component 118 .
- Browser application 120 , payment provider application 112 , and other applications 114 may correspond to processes, procedures, and/or applications, for example, a software program, executable by a hardware processor.
- requester device 110 may include additional or different software as required.
- Browser application 120 may be used, for example, to provide a convenient interface to permit user 102 to browse the Internet, including navigation to websites and between webpages of websites. Browser application 120 may therefore be configured to transmit and receive information, such as webpage requests, input to webpages, downloads and uploads of data, such as data in database 116 of user device 110 , etc. In various embodiments, browser application 120 may be used to access a website corresponding to merchant server 130 and select one or more items and/or services for purchase in a transaction. In other embodiments, browser application 120 may correspond to a dedicated application for merchant server 130 , such as a merchant specific application (e.g., a marketplace application specific to merchant server 130 ), where first user 102 may view items/services available from merchant server 130 to purchase.
- a merchant specific application e.g., a marketplace application specific to merchant server 130
- first user 102 may generate a transaction. First user 102 may also utilize browser application 120 to initiate a checkout for the transaction. Merchant server 130 may request checkout information from first user 102 directly on the merchant website or in the merchant application through browser application 120 , may redirect first user 102 to a website of payment provider server 150 , or may utilize payment provider application 112 to request checkout information.
- first user 102 may select to having second user 104 (e.g., a payer) pay for the transaction.
- second user 104 e.g., a payer
- first user 102 may enter information enabling identification of second user 104 , such as a name, account identifier, phone number, email address, messaging contact, or other identification information during checkout.
- First user 102 may provide similar information for first user 102 's identification information enabling second user 104 to identify who is requesting payment for the transaction.
- First ser 102 may also provide other information during checkout, such as a message or comment for the transaction, rules about payment for the transaction by second user 104 , shipping information for the items/services purchased, and/or information about the transaction displayed to second user 104 when requesting payment for the transaction.
- a payment token may be transmitted to payer device 140 by payment provider server 150 , as will be explained in more detail herein.
- the identification information for second user 104 may not enable contact of second user 104 . Thus, first user 102 may be informed of the incorrect identification/contact information, and new information may be request or a notification cancellation of the transaction may be transmitted to first user 102 .
- first user 102 may view the decision using one or more of browser application 120 and/or payment provider application 112 . If second user 104 accepts payment, first user 102 may view a transaction history, payment, rules regarding payment of the transaction, rules regarding use of items/services in the transaction, and/or shipping/pickup information for completion of the transaction. If second user 104 declines payment, first user 102 may view the decision and any comments made by second user 104 . Additionally, if second user 104 declines payment, first user 102 may utilize payment provider application 112 to complete payment for the transaction, or may request a new payer to be sent the payment token for a request for payment for the transaction.
- payment provider application 112 may be used, for example, to provide a convenient interface to permit first user 102 to select payment options and provide payment for items and/or services.
- payment provider application 112 may be implemented as an application having a user interface enabling the user to enter payment options for storage by requester device 110 , provide payment to merchant server 130 , and complete a transaction for the items and/or services using a payment instrument (e.g., a payment account with payment provider server 150 ).
- payment provider application 112 may correspond more generally to a web browser configured to view information available over the Internet or access a website corresponding to a payment provider.
- one or more features of browser application 120 and/or payment provider application 112 may be incorporated in the same application so as to provide their respective features in one application.
- Requester device 110 includes other applications 114 as may be desired in particular embodiments to provide features to requester device 110 .
- other applications 114 may include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network 170 , or other types of applications.
- Other applications 114 may also include email, texting, voice and IM applications that allow a user to send and receive emails, calls, texts, and other notifications through network 170 .
- other applications 114 may include financial applications, such as banking, online payments, money transfer, or other applications associated with payment provider server 150 .
- Other applications 114 may include browser, social networking, and/or mapping applications.
- GUI graphical user interface
- Requester device 110 may further include database 116 which may include, for example, identifiers such as operating system registry entries, cookies associated with browser application 120 , payment provider application 112 , and/or other applications 114 , identifiers associated with hardware of requester device 110 , or other appropriate identifiers, such as identifiers used for payment/user/device authentication or identification.
- Identifiers in database 116 may be used by a payment/credit provider, such as payment provider server 150 , to associate requester device 110 with a particular account maintained by the payment/credit provider.
- the identifiers may also be used by a merchant, such as merchant server 130 to identify first user 102 and/or a merchant account with the merchant.
- Database 110 may include transaction information and/or payment decisions for transaction after receipt from one or more of merchant server 130 and/or payment provider server 150 .
- Requester device 110 includes at least one network interface component 118 adapted to communicate with merchant server 130 , payer device 140 , and/or payment provider server 150 .
- network interface component 118 may include a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency, infrared, Bluetooth, and near field communication devices.
- DSL Digital Subscriber Line
- PSTN Public Switched Telephone Network
- Merchant server 130 may be maintained, for example, by an online merchant, which may offer one or more items and/or services for purchase through a merchant website and/or merchant application.
- merchant server 130 includes one or more processing applications which may be configured to interact with requester device 110 and/or payer device 140 to facilitate generation of a transaction and payment for the transaction using a payment token.
- merchant server 130 may be provided by EBAY®, Inc. of San Jose, Calif., USA or STUBHUB®, Inc. of San Francisco, Calif.
- merchant server 130 may be maintained by or include any merchant, including merchants that offer offline sales of items and/or services through merchant locations.
- one or more of the applications, processes, and/or features discussed below in reference to merchant server 130 may be included in payment provider server 150 , and vice versa.
- Merchant server 130 of FIG. 1 contains a merchant application 132 , other applications 134 , a database 136 , and a network interface component 138 .
- Merchant application 132 and other applications 134 may correspond to processes, procedures, and/or applications, for example, a software program, executable by a hardware processor.
- merchant server 130 may include additional or different software as required.
- Merchant application 132 may also be utilized to, for example, provide a merchant sales and/or marketplace interface permitting user 102 to browse items for sale from a merchant corresponding to merchant server 130 .
- merchant application 132 includes one or more processes and/or features to transmit the interface over network 180 to user device 110 for display to first user 102 , for example, using browser application 120 .
- the interface may enable first user 102 to view one or more items and/or services for sale from the merchant and select one or more of the items/services for purchase.
- merchant application 132 may generate a transaction for the selected item(s)/service(s), for example, by gathering the item(s)/service(s) into a shopping basket and providing a checkout interface for completion of the transaction.
- the checkout interface may include an option for first user 102 to provide payment for the transaction, for example, using payment provider application 112 and payment provider server 150 .
- the checkout interface may further allow first user 102 to enter information to have another user (e.g., a payer, such as second user 104 ) to provide payment for the transaction.
- merchant application 132 may request information used to generate a payment token by payment provider server 150 or merchant application 132 may redirect first user 102 to payment provider server 150 for collection of the information.
- information requested for use in generating a payment token to be transmitted to the payer may include payer identification information (e.g., identification information for second user 104 , such as contact information enabling transmission of the payment token), requester identification information (e.g., identification information for first user 102 , such as sufficient information for second user 104 to identify first user 102 as transmitting the payment token), a message, note, or other comment by user 102 for second user 104 , selected transaction information to be added to the payment token and/or removed/redacted from the payment token, and/or rules regarding payment for the transaction.
- payment provider server 150 may generate a payment token, transmit the payment token to payer device 140
- merchant application 132 may suspend the transaction for first user 102 .
- the transaction may be left suspended (e.g., the items/services may be held) for an amount of time determined by the merchant corresponding to merchant server 130 and/or first user 102 when requesting payment for the transaction.
- second user 104 is not contacted successfully (e.g., the identification information does not enable payment provider server 150 to transmit the payment token) then merchant application 132 may alert first user 102 , cancel the transaction, and/or request new identification/contact information for second user 104 . If the payment token is successfully transmitted, merchant application 132 may alert first user 102 of the transmission and the amount of time the payment token is valid.
- merchant application 132 may alert first user 102 of the decision. Where second user 104 has selected to pay for the transaction, merchant application 132 may provide a transaction history (e.g., receipt) to first user 102 may begin the process of providing first user 102 with the selected item(s)/service(s) in the transaction. However, if second user 104 declines payment or if the payment token expires, merchant application 132 may request payment by first user 102 , allow first user 102 to identify another payer, or may cancel the transaction.
- a transaction history e.g., receipt
- merchant server 130 includes other applications 134 as may be desired in particular embodiments to provide features to merchant server 130 .
- other applications 134 may include security applications for implementing server-side security features, programmatic server applications for interfacing with appropriate application programming interfaces (APIs) over network 170 , or other types of applications.
- Other applications 134 may contain software programs, executable by a processor, including a graphical user interface (GUI), configured to provide an interface to a user.
- GUI graphical user interface
- merchant server 130 includes database 136 .
- First user 102 and/or second user 104 may establish one or more merchant accounts having user information with merchant server 130 .
- User accounts in database 136 may include a name, address, birthdate, payment/funding information, additional user financial information, and/or other desired user data.
- First user 102 and/or second user 104 may link to their respective accounts through a user and/or device identifier.
- first user 102 and/or second user 104 may not have previously established an account and may provide other information to merchant server 130 to generate and/or complete financial transactions, as previously discussed.
- Database 136 may further include information used by merchant application 132 to provide a merchant sales and/or marketplace interface, such as item inventory information and pricing, interface components, and/or seller information.
- merchant server 130 includes at least one network interface component 138 adapted to communicate requester device 110 , payer device 140 , and/or payment provider server 150 over network 170 .
- network interface component 138 may comprise a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency (RF), and infrared (IR) communication devices.
- DSL Digital Subscriber Line
- PSTN Public Switched Telephone Network
- Payer device 140 may be implemented using any appropriate hardware and software configured for wired and/or wireless communication with requester device 110 , merchant server 130 , and/or payment provider server 150 .
- Payer device 140 may correspond to a device utilized by user 104 to receive a payment token for a transaction and make a decision on whether to pay for the transaction.
- payer device 140 may be implemented as a personal computer (PC), a smart phone, laptop computer, wristwatch with appropriate computer hardware resources, eyeglasses with appropriate computer hardware (e.g. GOOGLE GLASS ®), other type of wearable computing device, and/or other types of computing devices capable of transmitting and/or receiving data, such as an IPAD® from APPLE®.
- a payer device is shown, the payer device may be managed or controlled by any suitable processing device. Although only one payer device is shown, a plurality of payer devices may function similarly
- Payer device 140 of FIG. 1 contains a payment application 142 , other applications 144 , a database 146 , and a network interface component 148 .
- Payment application 142 and other applications 144 may correspond to processes, procedures, and/or applications, for example, a software program, executable by a hardware processor.
- payer device 140 may include additional or different software as required.
- Payment application 142 may be used, for example, to provide a convenient interface to permit second user 104 to select payment options and provide payment for received payment tokens.
- payment application 142 may be implemented as an application having a user interface enabling the user to enter payment options for storage by payer device 140 , provide payment to merchant server 130 , and complete payment for a transaction in a payment token.
- payment application 142 may correspond more generally to a web browser configured to view information available over the Internet or access a website corresponding to a payment provider.
- payment application 142 may first receive a payment token generated by payment provider server 150 , as will be explained in more detail herein.
- payment application 142 may correspond to an application that may provide an interface where first user 102 may view a received payment token.
- the interface may display to second user 104 the payment token information, including at least a payment amount and the submitted identification information for second user 104 .
- the payment token may further include transaction details (e.g., items/services selected, cost of each selected item/service, tax costs, discounts or benefits applied to the transaction, merchant name for the transaction, etc.), identification information for first user 102 , a message, comment or note by first user 102 , a time until expiration of the payment token, and/or merchant information.
- payee device 140 may receive the payment token after the payment token is generated by payment provider server 150 using the aforementioned information, as will be discussed in more detail herein. Second user 104 may then decide to accept responsibility to pay for the transaction through the payment token or may decline to pay for the transaction. If second user 104 does not view or accept by expiration of the payment token, the payment token may become invalid and it may be considered that second user 104 has declined to pay for the transaction in the payment token, which may be transmitted to payment provider server 150 . Additionally, if second user 104 declines payment, the decision to decline may be similarly transmitted to payment provider server 150 .
- a payment request for the transaction may be communicated to payment provider server 150 by payment application 142 .
- the payment request may instruct payment provider server 150 to provide payment for the transaction.
- the payment request may denote a payment instrument that payment provider server 150 may utilize to provide the payment for the transaction.
- Payment application 142 may utilize a credit/debit card, a bank account, payment account with payment provider server 150 , etc.
- second user 104 may further enter a note, comment, or other free text for transmission to first user 102 and/or add rules regarding payment of the transaction for first user 102 .
- the payment request may correspond to a token including the selected payment instrument for first user 102 as well as identification of the payment token and/or transaction in the payment token.
- second user 104 may authorize the payment request for transmission to payment provider server 150 in order to effectuate a payment to merchant server 130 for the transaction.
- payment application 142 may transmit the payment request as a token with a payment instrument, an identifier for second user 104 , and/or an identifier for the transaction to merchant server 130 for processing a payment for the transaction.
- payment application 142 may receive a transaction history documenting completion of the payment.
- Payment application 142 may correspond to a dedicated application for payment provider server 150 (e.g., a specific device application) or may correspond to a browser application.
- Payer device 140 includes other applications 144 as may be desired in particular embodiments to provide features to payer device 140 .
- other applications 144 may include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network 170 , or other types of applications.
- other applications 144 may include financial applications, such as banking, online payments, money transfer, or other applications associated with payment provider server 150 .
- Other applications 144 may include browser, social networking, and/or mapping applications.
- Various applications, features, and/or processes of other applications 144 may be used in conjunction with payment application 142 .
- Other applications 144 may contain other software programs, executable by a processor, including a graphical user interface (GUI) configured to provide an interface to the user.
- GUI graphical user interface
- Payer device 140 may further include database 146 which may include, for example, identifiers such as operating system registry entries, cookies associated with payment application 142 and/or other applications 144 , identifiers associated with hardware of payer device 140 , or other appropriate identifiers, such as identifiers used for payment/user/device authentication or identification.
- identifiers in database 146 may be used by merchant server 130 and/or payment provider server 150 to associate payer device 140 with a particular account maintained by merchant server 130 and/or payment provider server 150 .
- Database 146 may also store received payment tokens and associated information, such as decisions on payment tokens and/or transaction histories for paid transaction and their associated payment tokens.
- Database 146 may also store financial information used by payment application 142 to process payments.
- Payer device 140 includes at least one network interface component 148 adapted to communicate with requester device 110 , merchant server 130 , and/or payment provider server 150 .
- network interface component 148 may include a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency, infrared, Bluetooth, and near field communication devices.
- DSL Digital Subscriber Line
- PSTN Public Switched Telephone Network
- Payment provider server 150 may be maintained, for example, by an online payment service provider, which may provide payment services and/or processing for financial transactions on behalf of users, including generation of tokens for use in requesting and completing payments by two or more users.
- payment provider server 150 includes one or more processing applications which may be configured to interact with requester device 110 , merchant server 130 , and/or payer device 140 to facilitate payment for a transaction.
- payment provider server 150 may be provided by PAYPAL®, Inc. of San Jose, Calif., USA.
- payment provider server 150 may be maintained by or include a credit provider, financial services provider, financial data provider, and/or other service provider, which may provide payment services to user 102 and/or the merchant Moreover, in various embodiments, one or more of the applications, processes, and/or features discussed below in reference to payment provider server 150 may be included in merchant server 130 , and vice versa.
- Payment provider server 150 of FIG. 1 includes a payment request application 160 , a transaction processing application 152 , other applications 154 , a database 156 , and a network interface component 158 .
- Payment request application 160 , transaction processing application 152 and other applications 154 may correspond to processes, procedures, and/or applications, for example, a software program, executable by a hardware processor.
- payment provider server 150 may include additional or different software as required.
- Payment request application 160 may correspond to an application configured to receive information used to generate a payment token for a transaction, verify identification and/or contact information for the payer of the transaction (e.g., second user 104 ), transmit the payment token to the payer, and take additional steps necessary after a decision is made regarding payment corresponding to the payment token.
- payment request application 160 may receive information from first user 102 (e.g., through user device 110 ) for a transaction and the associated payer for the transaction, or may receive such information from merchant server 130 after collection by merchant server 130 .
- the information necessary to generate a payment token may include at least a payment amount for the transaction and a payer for the transaction (e.g. identification/contact information for second user 104 ).
- the information may further include transaction details (e.g., items/services selected, cost of each selected item/service, tax costs, discounts or benefits applied to the transaction, merchant name for the transaction, etc.), identification information for first user 102 , a message, comment or note by first user 102 , a time until expiration of the payment token, and/or merchant information.
- transaction details e.g., items/services selected, cost of each selected item/service, tax costs, discounts or benefits applied to the transaction, merchant name for the transaction, etc.
- identification information for first user 102 e.g., a message, comment or note by first user 102 , a time until expiration of the payment token, and/or merchant information.
- payment request application 160 may attempt to transmit the payment token to second user 104 , the designated payer for the transaction. If the contact information cannot be determined for second user 104 using the supplied identification information, payment request application 160 may alert first user 102 and/or merchant server 130 of the failure to communicate the payment token to second user 104 . Merchant server 130 may then cancel the transaction. However, new information identifying second user 104 may also be supplied to payment request application 160 , which may further attempt to communicate the payment token. Once the payment token is communicated to payer device 140 for viewing by second user 104 , payment request application 160 may await a response from second user 104 .
- payment request application 160 may alert user 102 and/or merchant server 130 of the failure to receive payment.
- first user 102 and/or merchant server 130 may take further actions, such as cancellation of the transaction, payment by first user 102 , and/or payment by another payer.
- payment request application 160 may receive the payment request for the transaction and begin processing the payment request using transaction processing application 152 .
- Payment request application 160 may notify first user 102 and/or merchant server 130 that second user 104 has accepted responsibility to pay for the transaction.
- Transaction processing application 152 may be configured to receive information from and/or transmit information to requester device 110 , merchant server 130 , and/or payer device 140 for processing and completion of transactions generated by user 102 and paid for by user 104 .
- Transaction processing application 152 may include one or more applications to process the transaction from first user 102 and merchant server 130 by receiving a payment request to complete payment for the transaction of items and/or services offered by the merchant corresponding to merchant server 130 .
- the payment request may correspond to a payment from second user 104 to the merchant.
- the payment may include a user account identifier or other payment information (e.g. a credit/debit card or checking account) for second user 104 and a receiving account for the merchant.
- the payment request may include a payment amount and terms of payment (e.g., notes from second user 104 and/or rules set for second user 104 for payment of the transaction).
- Transaction processing application 152 may complete the transaction by providing payment to the merchant through the receiving account/payment information. Additionally, transaction processing application 152 may provide transaction histories, including receipts, to requester device 110 , merchant server 130 , and/or payer device 140 for completion and documentation of the transaction. For example, a transaction history may be provided to requester device 110 , merchant server 130 , and/or payer device 140 to allow for the respective users and/or merchants to view the transaction and provide the items and/or services to first user 102 .
- payment provider server 150 includes other applications 154 as may be desired in particular embodiments to provide features to payment provider server 150 .
- other applications 154 may include security applications for implementing server-side security features, programmatic server applications for interfacing with appropriate application programming interfaces (APIs) over network 170 , or other types of applications.
- Other applications 154 may contain software programs, executable by a processor, including a graphical user interface (GUI), configured to provide an interface to a user.
- GUI graphical user interface
- payment provider server 150 includes database 156 .
- first user 102 , second user 104 , and/or the merchant corresponding to merchant server 130 may establish one or more payment accounts with payment provider server 150 .
- User accounts in database 156 may include user/merchant information, such as name, address, birthdate, payment/funding information, additional user financial information, and/or other desired user data.
- First user 102 , second user 104 , and/or the merchant may link to their respective payment accounts through a user, merchant, and/or device identifier.
- an identifier is transmitted to payment provider server 150 , e.g.
- Database 156 may further include information received for use in generated payment tokens, generated payment tokens and their respective information, and/or decisions regarding payment tokens. Transaction histories used to document payment for transactions corresponding to payment tokens may also be stored by database 156 for distribution to first user 102 , second user 104 , and/or the merchant.
- payment provider server 150 includes at least one network interface component 158 adapted to communicate requester device 110 , merchant server 130 , and/or payer device 140 over network 170 .
- network interface component 158 may comprise a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency (RF), and infrared (IR) communication devices.
- DSL Digital Subscriber Line
- PSTN Public Switched Telephone Network
- Network 170 may be implemented as a single network or a combination of multiple networks.
- network 170 may include the Internet or one or more intranets, landline networks, wireless networks, and/or other appropriate types of networks.
- network 170 may correspond to small scale communication networks, such as a private or local area network, or a larger scale network, such as a wide area network or the Internet, accessible by the various components of system 100 .
- FIG. 2 is an exemplary system environment showing a requesters device creating a transaction with a merchant for use in generating a payment token to a payer, according to an embodiment.
- Environment 200 of FIG. 2 includes a requester device 210 , a payment provider server 250 , and a network 270 corresponding generally to requester device 110 , payment provider server 150 , and network 170 , respectively, of FIG. 1 .
- Requester device 210 displays a browser application interface 220 corresponding generally to the processes and features described in reference to browser application 120 of FIG. 1 .
- a user device executing a browser application may display a merchant's sales website or marketplace where a user may select items and/or services for purchase in a transaction.
- the browser application may instead correspond to a dedicated application for the merchant.
- browser application interface 220 displays item 221 , such as a selected item for purchase in a transaction, a price 222 , and a checkout 223 process.
- Item 221 may correspond to an item offered for sale from a merchant (not shown) via the merchant's server and/or a physical merchant location where the user may pick up the product and/or have delivered from.
- Price 222 corresponds to a price for item 221 , such as a transaction price, shown as $109.99.
- Checkout 223 includes a requester field 224 , a payer field 225 , a text field 226 , and a submit button 227 .
- Requester field 224 may include a field to enter identification information for the requester of payment for a transaction including item 221 and price 222 .
- Payer field 225 may have similar identification information and/or contact information for the payer of the transaction, such as a person/user that requester 224 is requesting payment from for the transaction.
- the requester (e.g., the user of requester device 210 ) may enter a message, comment, or note to the transaction for transmission to the payer into text field 226 . Additional information may also be selected and/or entered under checkout 223 in various embodiments. Once the requester is satisfied with their entries, the requester may select submit button 227 to transmit the request for payment to payment provider server 250 over network 270 .
- Payment provider server 250 executes a payment request application 260 corresponding generally to the processes and features described in reference to payment request application 160 of FIG. 1 .
- Payment request application 260 may be configured to generate a payment token for the transaction and request to pay for the transaction generated and submitted to payment provider server 250 during checkout 223 .
- payment request application 260 includes a transaction request 261 corresponding to the transaction and the request to pay the transaction by a payer.
- Transaction request 261 includes requester information 262 and payer information 263 corresponding generally to the payment requester and the payment payer, respectively.
- Requester information 262 and payer information 263 may include contact information enabling payment request application 260 to contact the requester and payer.
- Transaction request 261 further include transaction 264 having details of the transaction, such as the items/service (e.g., item 221 ), prices (e.g., 222 ), and other transaction information. Using this information, payment token 264 may be generated. Once generated, payment request application 260 may verify the contact information for the payer by determining contact information verification 266 . Payment request application 260 may further include merchant information 267 used to communicate the result of contact information verification to and any decisions regarding payment token 264 .
- FIG. 3 is an exemplary system environment showing a payer device displaying a receiving payment token for authorizing or declining the transaction in the payment token, according to an embodiment.
- Environment 300 includes a payer device 340 , a payment provider server 350 , and a network 370 corresponding generally to payer device 140 , payment provider server 150 , and network 170 , respectively, of FIG. 1 .
- Payer device 340 displays a payment application interface 342 corresponding generally to the processes and features described in reference to payment application 142 of FIG. 1 .
- Payment application interface 342 displays a payment application where the payer (e.g., the user of payer device 340 , not shown) may view a payment token and make a decision on whether to pay for the purchase represented by the payment token.
- payment application interface 342 displays a payment token 1000 , payment instruments 1010 , and account details 1012 .
- Payment token 1000 includes a received payment token from a requester, and may include a transaction field 1002 , a cost field 1004 , a description field 1006 , and an approve/deny button 1008 .
- Transaction field 1002 may display the selected items/service (e.g., item 221 of FIG. 2 ) and may have further information about the items/services, such as descriptions, per unit cost, discounts, etc.
- Cost field 1004 may include a total accrued cost that the payer will pay if the payer accepts the transaction.
- Description field 1006 include further information submitted by the requester, such as a note, comment, etc., a time limit for validity of payment token 1000 , and/or any rules or other settings they have set for accepting or declining payment for the transaction.
- Approve/deny button 1008 initiates processes to accept payment for the transaction and/or decline payment for the transaction, and may enable the payer to set rules, add notes, or perform other actions when initiating a further process.
- the payer may select one or more payment instruments used to process a payment for the transaction under payment instrument 1010 , and may view their account details (e.g., account balances) under account details 1012 .
- the decision may be transmitted to payment provider server 350 over network 370 .
- the payer has accepted payment for a transaction associated with transaction field 1002 in payment token 1000 , thus a payment is being processed by payment provider server 350 .
- Payment provider server 350 executes a transaction processing application 352 corresponding generally to the processes and features described in reference to transaction processing application 152 of FIG. 1 .
- transaction processing application 352 is processing a payment for payment token 1000 , which includes payment status 1020 (e.g., information identifying that the payer has accepted payment for transaction 1002 ), requester information enabling transaction processing application 352 to alert the requester that payment has been made for transaction 1002 , merchant information 1024 enabling transaction processing application 352 to alert the merchant that payment has been made for transaction 1002 , and the transaction 1026 information enabling transaction processing application to process payment for transaction 1002 using payment instrument 1010 .
- payment status 1020 e.g., information identifying that the payer has accepted payment for transaction 1002
- requester information enabling transaction processing application 352 to alert the requester that payment has been made for transaction 1002
- merchant information 1024 enabling transaction processing application 352 to alert the merchant that payment has been made for transaction 1002
- the transaction 1026 information enabling transaction processing application to process payment for transaction 1002
- FIG. 4 is a flowchart of an exemplary process for requesting payment for selected items or services using payment tokens, according to an embodiment. Note that one or more steps, processes, and methods described herein may be omitted, performed in a different sequence, or combined as desired or appropriate.
- a transaction request for an item or service available with a merchant is accessed, wherein the transaction request identifies a request for the item or service, and wherein the transaction request identifies a payer for the item or service.
- the requester may utilize a payment provider website to submit the transaction request with the merchant or may use a merchant website and/or merchant application to submit the request.
- the merchant may hold the item or service for purchase for a period of time, which may be denoted in the transaction request.
- the transaction request may include transaction information, which may comprise at least one of a name for the payer, an email address for the payer, a phone number for the payer, an account of the payer, and a messaging identifier for the payer.
- a payment token is generated using the transaction request, at step 404 , wherein the payment token comprises requester identification information for the requester and a payment amount of the item or service.
- the payment token may further comprise at least one of information for the item or service, merchant identification information for the merchant, and validity information for the payment token.
- the validity information may comprise at least one of a time limit for validity of the payment token, a rule associated with the payment of the payment amount, and a rule associated with receipt and use of the item or service.
- contact information for the payer may be determined using the transaction request, wherein the contact information comprises one of a messaging account, an email address, a payment account with a payment provider, and a phone number, wherein the payment token to the payer using the contact information.
- a validity of the contact information may also be determined, and the requester alerted based on the validity of the contact information.
- the merchant for the transaction request may also be alerted of the validity of the contact information.
- the contact information may be verified and the merchant may be alerted to cancel the transaction if the contact information is not verified, in certain embodiments.
- a notification that the payment token was not successfully communicated to the payer may be received, and the notification may be communicated to at least one of the merchant and the requester. However, if the contact information is verified, the payment token may be transmitted to the payer using the contact information.
- the payment token is communicated to the payer for payment of the payment amount.
- the requester may be redirected to a merchant website for the merchant after the requester submits the transaction request.
- Authorization to pay for the transaction in the transaction request may be received from the payer, and a payment for the transaction may be processed.
- the authorization may comprise at least one rule for the requester based on the payment of the transaction.
- the authorization may be communicated to at least one of the merchant and the requester.
- a notification that the payer has viewed the token may be received and may be communicated to the merchant. If the payer decides to decline the transaction, a denial of the transaction may be received from the payer and may be communicated to the merchant and/or the requester.
- FIG. 5 is a block diagram of a computer system suitable for implementing one or more components in FIG. 1 , according to an embodiment.
- the user device may comprise a personal computing device (e.g., smart phone, a computing tablet, a personal computer, laptop, a wearable computing device such as glasses or a watch, Bluetooth device, key FOB, badge, etc.) capable of communicating with the network.
- the service provider may utilize a network computing device (e.g., a network server) capable of communicating with the network.
- a network computing device e.g., a network server
- each of the devices utilized by users and service providers may be implemented as computer system 500 in a manner as follows.
- Computer system 500 includes a bus 502 or other communication mechanism for communicating information data, signals, and information between various components of computer system 500 .
- Components include an input/output (I/O) component 504 that processes a user action, such as selecting keys from a keypad/keyboard, selecting one or more buttons, image, or links, and/or moving one or more images, etc., and sends a corresponding signal to bus 502 .
- I/O component 504 may also include an output component, such as a display 511 and a cursor control 513 (such as a keyboard, keypad, mouse, etc.).
- An optional audio input/output component 505 may also be included to allow a user to use voice for inputting information by converting audio signals.
- Audio I/O component 505 may allow the user to hear audio.
- a transceiver or network interface 506 transmits and receives signals between computer system 500 and other devices, such as another user device, service device, or a service provider server via network 170 . In one embodiment, the transmission is wireless, although other transmission mediums and methods may also be suitable.
- One or more processors 512 which can be a micro-controller, digital signal processor (DSP), or other processing component, processes these various signals, such as for display on computer system 500 or transmission to other devices via a communication link 518 . Processor(s) 512 may also control transmission of information, such as cookies or IP addresses, to other devices.
- DSP digital signal processor
- Components of computer system 500 also include a system memory component 514 (e.g., RAM), a static storage component 516 (e.g., ROM), and/or a disk drive 517 .
- Computer system 500 performs specific operations by processor(s) 512 and other components by executing one or more sequences of instructions contained in system memory component 514 .
- Logic may be encoded in a computer readable medium, which may refer to any medium that participates in providing instructions to processor(s) 512 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media.
- non-volatile media includes optical or magnetic disks
- volatile media includes dynamic memory, such as system memory component 514
- transmission media includes coaxial cables, copper wire, and fiber optics, including wires that comprise bus 502 .
- the logic is encoded in non-transitory computer readable medium.
- transmission media may take the form of acoustic or light waves, such as those generated during radio wave, optical, and infrared data communications,
- Computer readable media includes, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EEPROM, FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer is adapted to read.
- execution of instruction sequences to practice the present disclosure may be performed by computer system 500 .
- a plurality of computer systems 500 coupled by communication link 518 to the network may perform instruction sequences to practice the present disclosure in coordination with one another.
- various embodiments provided by the present disclosure may be implemented using hardware, software, or combinations of hardware and software.
- the various hardware components and/or software components set forth herein may be combined into composite components comprising software, hardware, and/or both without departing from the spirit of the present disclosure.
- the various hardware components and/or software components set forth herein may be separated into sub-components comprising software, hardware, or both without departing from the scope of the present disclosure.
- software components may be implemented as hardware components and vice-versa.
- Software in accordance with the present disclosure, such as program code and/or data, may be stored on one or more computer readable mediums. It is also contemplated that software identified herein may be implemented using one or more general purpose or specific purpose computers and/or computer systems, networked and/or otherwise. Where applicable, the ordering of various steps described herein may be changed, combined into composite steps, and/or separated into sub-steps to provide features described herein.
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Finance (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- Strategic Management (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Health & Medical Sciences (AREA)
- Child & Adolescent Psychology (AREA)
- General Health & Medical Sciences (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Description
- The present application generally relates to requesting payment for selected items or services using payment tokens and more specifically to communicating a payment token having a transaction to a payer for authorization of the transaction between another user and a merchant.
- A user, such as a consumer, may wish to request payment for a transaction from another user. For example, a spouse may select an item as a present or a college student may request assistance paying for various college expenses, such as books. In order to provide payment for the transaction, another user (e.g., a parent, spouse, relative, etc.) may provide the first user with funds to complete the purchase. However, the funds may not completely cover the costs, or the first user may misuse the funds. Thus, in order to insure proper completion of the transaction, the second user may instead directly engage in the transaction, such as by purchasing the items for the first user. In doing so, however, the second user must know the exact items/services the first user wishes to purchase and must either visit the merchant with the first user or have the items/services delivered after purchasing the items/services. In both scenarios, the second user is required to perform time consuming processes, which may add extra costs to a transaction or result in an incorrect transaction.
-
FIG. 1 is a block diagram of a networked system suitable for implementing the processes described herein, according to an embodiment; -
FIG. 2 is an exemplary system environment showing a requesters device creating a transaction with a merchant for use in generating a payment token to a payer, according to an embodiment; -
FIG. 3 is an exemplary system environment showing a payer device displaying a receiving payment token for authorizing or declining the transaction in the payment token, according to an embodiment; -
FIG. 4 is a flowchart of an exemplary process for requesting payment for selected items or services using payment tokens, according to an embodiment; and -
FIG. 5 is a block diagram of a computer system suitable for implementing one or more components inFIG. 1 , according to an embodiment. - Embodiments of the present disclosure and their advantages are best understood by referring to the detailed description that follows. It should be appreciated that like reference numerals are used to identify like elements illustrated in one or more of the figures, wherein showings therein are for purposes of illustrating embodiments of the present disclosure and not for purposes of limiting the same.
- Provided are methods that provide for requesting payment for selected items or services using payment tokens, referred to collectively as “item” or “items.” Systems suitable for practicing methods of the present disclosure are also provided.
- A first user, such as a requester for a transaction, may create a transaction with a merchant by visiting a merchant website or utilizing a merchant application to select one or more items for purchase. Thus, the user may access the merchant online and shop with the merchant. Once the user has selected the item(s) for purchase, the user may checkout through the merchant. The merchant may offer checkout services through a payment provider on the website or in their application, or may redirect the user to the payment provider. The payment provider may offer the user an option to generate a payment token for the transaction, where the payment token includes information about the transaction, such as a payment/transaction request. The payment provider may also request information for a payer for the transaction, such as contact information including a name, account identifier, email address, phone number, messaging address, or other identifier enabling identification of the payer, and similar identifying information for the first user (e.g., the requester). The requester may also add a note or comment about the transaction for the payer to read.
- The payment provider may utilize the payer information, the transaction information, and/or the requester information to generate a payment token. The payment token may include information about the transaction, including at least a payment amount for the transaction and the requester contact information for transmitting the payment token. The payment token may also include further information, such as the transaction information (e.g., items/services in the transaction, prices of those items/services, the merchant for the transaction, sales/discounts for the transaction, tax information, and/or shipping information), identifying and/or contact information for the requester of the items/services in the transaction, merchant information, a time limit of the validity of the payment token (i.e., until the transaction is cancelled with the merchant if the payment token is not accepted/declined), the note or comment submitted by the requester for viewing by the payer when receiving the payment token, and/or rules that the requester user has set for payment of the transaction (e.g., where the items/services may be shipped, what the payer may request from the user when paying for the transaction, etc.). Once the payment token is generated, the payment provider may attempt to transmit the payment token to the payer using the identification information for the payer submitted by the requester. If the payer cannot be contacted, the payment provider may alert the requester and/or the merchant in order to correct the issue. The requester may attempt to add new contact/identification information for the payer. In other embodiments, the merchant may cancel the transaction with the requester if the payer cannot be contacted.
- Once the payment token is transmitted to the payer, the payer may view the information in the token and decide whether to accept the transaction and process a payment for the transaction or to decline the transaction and not pay for the transaction for the requester. If the payer declines or does not accept payment for the transaction, the transaction may be cancelled with the merchant, or the requester may view the decision to decline by the payer and decide whether the requester would like to pay for the transaction of request payment from another payer. The payer may directly decline the transaction by select a “No,” “Decline,” or “Deny” option with the payment token. In various embodiments, if the payer does not accept the transaction for the time period that the payment token is valid, the transaction may be declined and the merchant may not receive payment from the payer.
- If the payer accepts the transaction in the payment token, the payer may be redirected to the merchant website and/or the payment provider website to process and complete a payment for the transaction. The payer may then provide a payment instrument, such as a payment account with the payment provider, and may complete a payment process for the transaction. When completing the payment process, the payer may set various rules or conditions based on their payment of the transaction, such as a request for account of expenses, a requirement to receive a certain grade or mark based on their scholastic achievements, a request for additional information about the transaction, and/or information about use of the items/services in the transaction. The payer may also add a note about accepting and/or declining payment for the transaction, which may be provided to the requester. Once the transaction is accepted and payment for the transaction is processed, the merchant may be informed and may begin the process of providing the items/services in the transaction to the requester.
-
FIG. 1 is a block diagram of a networkedsystem 100 suitable for implementing the processes described herein, according to an embodiment. As shown,system 100 may comprise or implement a plurality of devices, servers, and/or software components that operate to perform various methodologies in accordance with the described embodiments. Exemplary device and servers may include device, stand-alone, and enterprise-class servers, operating an OS such as a MICROSOFT® OS, a UNIX® OS, a LINUX® OS, or other suitable device and/or server based OS. It can be appreciated that the devices and/or servers illustrated inFIG. 1 may be deployed in other ways and that the operations performed and/or the services provided by such devices and/or servers may be combined or separated for a given embodiment and may be performed by a greater number or fewer number of devices and/or servers. One or more devices and/or servers may be operated and/or maintained by the same or different entities. -
System 100 includes a first user 102, asecond user 104, arequester device 110, amerchant server 130, apayer device 140, andpayment provider server 150 in communication over anetwork 170. First user 102, such as a consumer, may utilizerequester device 110 to initiate a transaction withmerchant server 130. One checkout, first user 102 may select to havesecond user 104 pay for the transaction. Thus,payment provider server 150 may be utilized to generate a payment token for transmission topayer device 140. Ifsecond user 104 accepts responsibility to pay for the transaction, a payment tomerchant server 130 may be completed usingpayment provider server 150. -
Requester device 110,merchant server 130,payer device 140, andpayment provider server 150 may each include one or more processors, memories, and other appropriate components for executing instructions such as program code and/or data stored on one or more computer readable mediums to implement the various applications, data, and steps described herein. For example, such instructions may be stored in one or more computer readable media such as memories or data storage devices internal and/or external to various components ofsystem 100, and/or accessible overnetwork 170. -
Requester device 110 may be implemented using any appropriate hardware and software configured for wired and/or wireless communication withmerchant server 130,payer device 140, and/orpayment provider server 150. For example, in one embodiment,requester device 110 may be implemented as a personal computer (PC), a smart phone, laptop/tablet computer, wristwatch with appropriate computer hardware resources, eyeglasses with appropriate computer hardware (e.g. GOOGLE GLASS ®), other type of wearable computing device, and/or other types of computing devices capable of transmitting and/or receiving data, such as an IPAD® from APPLE®. Although a requester device is shown, the requester device may be managed or controlled by any suitable processing device. Although only one requester device is shown, a plurality of requester devices may function similarly. -
Requester device 110 ofFIG. 1 contains abrowser application 120, apayment provider application 112,other applications 114, adatabase 116, and anetwork interface component 118.Browser application 120,payment provider application 112, andother applications 114 may correspond to processes, procedures, and/or applications, for example, a software program, executable by a hardware processor. In other embodiments,requester device 110 may include additional or different software as required. -
Browser application 120 may be used, for example, to provide a convenient interface to permit user 102 to browse the Internet, including navigation to websites and between webpages of websites.Browser application 120 may therefore be configured to transmit and receive information, such as webpage requests, input to webpages, downloads and uploads of data, such as data indatabase 116 ofuser device 110, etc. In various embodiments,browser application 120 may be used to access a website corresponding tomerchant server 130 and select one or more items and/or services for purchase in a transaction. In other embodiments,browser application 120 may correspond to a dedicated application formerchant server 130, such as a merchant specific application (e.g., a marketplace application specific to merchant server 130), where first user 102 may view items/services available frommerchant server 130 to purchase. Usingbrowser application 120, first user 102 may generate a transaction. First user 102 may also utilizebrowser application 120 to initiate a checkout for the transaction.Merchant server 130 may request checkout information from first user 102 directly on the merchant website or in the merchant application throughbrowser application 120, may redirect first user 102 to a website ofpayment provider server 150, or may utilizepayment provider application 112 to request checkout information. - During the checkout processing using one or more of
browser application 120 and/orpayment provider application 112, first user 102 may select to having second user 104 (e.g., a payer) pay for the transaction. Thus, first user 102 may enter information enabling identification ofsecond user 104, such as a name, account identifier, phone number, email address, messaging contact, or other identification information during checkout. First user 102 may provide similar information for first user 102's identification information enablingsecond user 104 to identify who is requesting payment for the transaction. First ser 102 may also provide other information during checkout, such as a message or comment for the transaction, rules about payment for the transaction bysecond user 104, shipping information for the items/services purchased, and/or information about the transaction displayed tosecond user 104 when requesting payment for the transaction. Once first user 102 has completed entry of checkout information to havesecond user 104 pay for the transaction, a payment token may be transmitted topayer device 140 bypayment provider server 150, as will be explained in more detail herein. In certain embodiments, the identification information forsecond user 104 may not enable contact ofsecond user 104. Thus, first user 102 may be informed of the incorrect identification/contact information, and new information may be request or a notification cancellation of the transaction may be transmitted to first user 102. Ifsecond user 104 accepts or declines payment, first user 102 may view the decision using one or more ofbrowser application 120 and/orpayment provider application 112. Ifsecond user 104 accepts payment, first user 102 may view a transaction history, payment, rules regarding payment of the transaction, rules regarding use of items/services in the transaction, and/or shipping/pickup information for completion of the transaction. Ifsecond user 104 declines payment, first user 102 may view the decision and any comments made bysecond user 104. Additionally, ifsecond user 104 declines payment, first user 102 may utilizepayment provider application 112 to complete payment for the transaction, or may request a new payer to be sent the payment token for a request for payment for the transaction. - Thus,
payment provider application 112 may be used, for example, to provide a convenient interface to permit first user 102 to select payment options and provide payment for items and/or services. For example,payment provider application 112 may be implemented as an application having a user interface enabling the user to enter payment options for storage byrequester device 110, provide payment tomerchant server 130, and complete a transaction for the items and/or services using a payment instrument (e.g., a payment account with payment provider server 150). In certain embodiments,payment provider application 112 may correspond more generally to a web browser configured to view information available over the Internet or access a website corresponding to a payment provider. - In various embodiments, one or more features of
browser application 120 and/orpayment provider application 112 may be incorporated in the same application so as to provide their respective features in one application. -
Requester device 110 includesother applications 114 as may be desired in particular embodiments to provide features torequester device 110. For example,other applications 114 may include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) overnetwork 170, or other types of applications.Other applications 114 may also include email, texting, voice and IM applications that allow a user to send and receive emails, calls, texts, and other notifications throughnetwork 170. In various embodiments,other applications 114 may include financial applications, such as banking, online payments, money transfer, or other applications associated withpayment provider server 150.Other applications 114 may include browser, social networking, and/or mapping applications. Various applications, features, and/or processes ofother applications 114 may be used in conjunction withbrowser application 120 and/orpayment provider application 112.Other applications 114 may contain software programs, executable by a processor, including a graphical user interface (GUI) configured to provide an interface to the user. -
Requester device 110 may further includedatabase 116 which may include, for example, identifiers such as operating system registry entries, cookies associated withbrowser application 120,payment provider application 112, and/orother applications 114, identifiers associated with hardware ofrequester device 110, or other appropriate identifiers, such as identifiers used for payment/user/device authentication or identification. Identifiers indatabase 116 may be used by a payment/credit provider, such aspayment provider server 150, to associaterequester device 110 with a particular account maintained by the payment/credit provider. The identifiers may also be used by a merchant, such asmerchant server 130 to identify first user 102 and/or a merchant account with the merchant.Database 110 may include transaction information and/or payment decisions for transaction after receipt from one or more ofmerchant server 130 and/orpayment provider server 150. -
Requester device 110 includes at least onenetwork interface component 118 adapted to communicate withmerchant server 130,payer device 140, and/orpayment provider server 150. In various embodiments,network interface component 118 may include a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency, infrared, Bluetooth, and near field communication devices. -
Merchant server 130 may be maintained, for example, by an online merchant, which may offer one or more items and/or services for purchase through a merchant website and/or merchant application. In this regard,merchant server 130 includes one or more processing applications which may be configured to interact withrequester device 110 and/orpayer device 140 to facilitate generation of a transaction and payment for the transaction using a payment token. In one example,merchant server 130 may be provided by EBAY®, Inc. of San Jose, Calif., USA or STUBHUB®, Inc. of San Francisco, Calif. However, in other embodiments,merchant server 130 may be maintained by or include any merchant, including merchants that offer offline sales of items and/or services through merchant locations. Moreover, in various embodiments, one or more of the applications, processes, and/or features discussed below in reference tomerchant server 130 may be included inpayment provider server 150, and vice versa. -
Merchant server 130 ofFIG. 1 contains a merchant application 132,other applications 134, adatabase 136, and anetwork interface component 138. Merchant application 132 andother applications 134 may correspond to processes, procedures, and/or applications, for example, a software program, executable by a hardware processor. In other embodiments,merchant server 130 may include additional or different software as required. - Merchant application 132 may also be utilized to, for example, provide a merchant sales and/or marketplace interface permitting user 102 to browse items for sale from a merchant corresponding to
merchant server 130. In this regard, merchant application 132 includes one or more processes and/or features to transmit the interface over network 180 touser device 110 for display to first user 102, for example, usingbrowser application 120. The interface may enable first user 102 to view one or more items and/or services for sale from the merchant and select one or more of the items/services for purchase. After selecting items for purchase, merchant application 132 may generate a transaction for the selected item(s)/service(s), for example, by gathering the item(s)/service(s) into a shopping basket and providing a checkout interface for completion of the transaction. The checkout interface may include an option for first user 102 to provide payment for the transaction, for example, usingpayment provider application 112 andpayment provider server 150. In various embodiments, the checkout interface may further allow first user 102 to enter information to have another user (e.g., a payer, such as second user 104) to provide payment for the transaction. - If payment by another user is selected by first user 102, merchant application 132 may request information used to generate a payment token by
payment provider server 150 or merchant application 132 may redirect first user 102 topayment provider server 150 for collection of the information. In either embodiments, information requested for use in generating a payment token to be transmitted to the payer (e.g., first user 102) may include payer identification information (e.g., identification information forsecond user 104, such as contact information enabling transmission of the payment token), requester identification information (e.g., identification information for first user 102, such as sufficient information forsecond user 104 to identify first user 102 as transmitting the payment token), a message, note, or other comment by user 102 forsecond user 104, selected transaction information to be added to the payment token and/or removed/redacted from the payment token, and/or rules regarding payment for the transaction. Once the selected information is accrued bymerchant server 130 and/orpayment provider server 150,payment provider server 150 may generate a payment token, transmit the payment token topayer device 140, and receive a decision on the payment token, as will be explained in more detail herein. - During or after generation of the payment token by
payment provider server 150, merchant application 132 may suspend the transaction for first user 102. The transaction may be left suspended (e.g., the items/services may be held) for an amount of time determined by the merchant corresponding tomerchant server 130 and/or first user 102 when requesting payment for the transaction. Ifsecond user 104 is not contacted successfully (e.g., the identification information does not enablepayment provider server 150 to transmit the payment token) then merchant application 132 may alert first user 102, cancel the transaction, and/or request new identification/contact information forsecond user 104. If the payment token is successfully transmitted, merchant application 132 may alert first user 102 of the transmission and the amount of time the payment token is valid. Once a decision on payment for the transaction is made bysecond user 104, merchant application 132 may alert first user 102 of the decision. Wheresecond user 104 has selected to pay for the transaction, merchant application 132 may provide a transaction history (e.g., receipt) to first user 102 may begin the process of providing first user 102 with the selected item(s)/service(s) in the transaction. However, ifsecond user 104 declines payment or if the payment token expires, merchant application 132 may request payment by first user 102, allow first user 102 to identify another payer, or may cancel the transaction. - In various embodiments,
merchant server 130 includesother applications 134 as may be desired in particular embodiments to provide features tomerchant server 130. For example,other applications 134 may include security applications for implementing server-side security features, programmatic server applications for interfacing with appropriate application programming interfaces (APIs) overnetwork 170, or other types of applications.Other applications 134 may contain software programs, executable by a processor, including a graphical user interface (GUI), configured to provide an interface to a user. - Additionally,
merchant server 130 includesdatabase 136. First user 102 and/orsecond user 104 may establish one or more merchant accounts having user information withmerchant server 130. User accounts indatabase 136 may include a name, address, birthdate, payment/funding information, additional user financial information, and/or other desired user data. First user 102 and/orsecond user 104 may link to their respective accounts through a user and/or device identifier. In other embodiments, first user 102 and/orsecond user 104 may not have previously established an account and may provide other information tomerchant server 130 to generate and/or complete financial transactions, as previously discussed.Database 136 may further include information used by merchant application 132 to provide a merchant sales and/or marketplace interface, such as item inventory information and pricing, interface components, and/or seller information. - In various embodiments,
merchant server 130 includes at least onenetwork interface component 138 adapted to communicaterequester device 110,payer device 140, and/orpayment provider server 150 overnetwork 170. In various embodiments,network interface component 138 may comprise a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency (RF), and infrared (IR) communication devices. -
Payer device 140 may be implemented using any appropriate hardware and software configured for wired and/or wireless communication withrequester device 110,merchant server 130, and/orpayment provider server 150.Payer device 140 may correspond to a device utilized byuser 104 to receive a payment token for a transaction and make a decision on whether to pay for the transaction. Thus,payer device 140 may be implemented as a personal computer (PC), a smart phone, laptop computer, wristwatch with appropriate computer hardware resources, eyeglasses with appropriate computer hardware (e.g. GOOGLE GLASS ®), other type of wearable computing device, and/or other types of computing devices capable of transmitting and/or receiving data, such as an IPAD® from APPLE®. Although a payer device is shown, the payer device may be managed or controlled by any suitable processing device. Although only one payer device is shown, a plurality of payer devices may function similarly -
Payer device 140 ofFIG. 1 contains apayment application 142,other applications 144, adatabase 146, and anetwork interface component 148.Payment application 142 andother applications 144 may correspond to processes, procedures, and/or applications, for example, a software program, executable by a hardware processor. In other embodiments,payer device 140 may include additional or different software as required. -
Payment application 142 may be used, for example, to provide a convenient interface to permitsecond user 104 to select payment options and provide payment for received payment tokens. For example,payment application 142 may be implemented as an application having a user interface enabling the user to enter payment options for storage bypayer device 140, provide payment tomerchant server 130, and complete payment for a transaction in a payment token. In certain embodiments,payment application 142 may correspond more generally to a web browser configured to view information available over the Internet or access a website corresponding to a payment provider. - Thus,
payment application 142 may first receive a payment token generated bypayment provider server 150, as will be explained in more detail herein. In this regard,payment application 142 may correspond to an application that may provide an interface where first user 102 may view a received payment token. The interface may display tosecond user 104 the payment token information, including at least a payment amount and the submitted identification information forsecond user 104. The payment token may further include transaction details (e.g., items/services selected, cost of each selected item/service, tax costs, discounts or benefits applied to the transaction, merchant name for the transaction, etc.), identification information for first user 102, a message, comment or note by first user 102, a time until expiration of the payment token, and/or merchant information. Thus,payee device 140 may receive the payment token after the payment token is generated bypayment provider server 150 using the aforementioned information, as will be discussed in more detail herein.Second user 104 may then decide to accept responsibility to pay for the transaction through the payment token or may decline to pay for the transaction. Ifsecond user 104 does not view or accept by expiration of the payment token, the payment token may become invalid and it may be considered thatsecond user 104 has declined to pay for the transaction in the payment token, which may be transmitted topayment provider server 150. Additionally, ifsecond user 104 declines payment, the decision to decline may be similarly transmitted topayment provider server 150. - However, if
second user 104 accepts payment for the transaction/payment amount in the payment token, a payment request for the transaction may be communicated topayment provider server 150 bypayment application 142. The payment request may instructpayment provider server 150 to provide payment for the transaction. Additionally, the payment request may denote a payment instrument thatpayment provider server 150 may utilize to provide the payment for the transaction.Payment application 142 may utilize a credit/debit card, a bank account, payment account withpayment provider server 150, etc. When either accepting or declining payment,second user 104 may further enter a note, comment, or other free text for transmission to first user 102 and/or add rules regarding payment of the transaction for first user 102. - The payment request may correspond to a token including the selected payment instrument for first user 102 as well as identification of the payment token and/or transaction in the payment token. Once the payment request is generated,
second user 104 may authorize the payment request for transmission topayment provider server 150 in order to effectuate a payment tomerchant server 130 for the transaction. In other embodiments,payment application 142 may transmit the payment request as a token with a payment instrument, an identifier forsecond user 104, and/or an identifier for the transaction tomerchant server 130 for processing a payment for the transaction. Once a payment is processed for the transaction,payment application 142 may receive a transaction history documenting completion of the payment.Payment application 142 may correspond to a dedicated application for payment provider server 150 (e.g., a specific device application) or may correspond to a browser application. -
Payer device 140 includesother applications 144 as may be desired in particular embodiments to provide features topayer device 140. For example,other applications 144 may include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) overnetwork 170, or other types of applications. In various embodiments,other applications 144 may include financial applications, such as banking, online payments, money transfer, or other applications associated withpayment provider server 150.Other applications 144 may include browser, social networking, and/or mapping applications. Various applications, features, and/or processes ofother applications 144 may be used in conjunction withpayment application 142.Other applications 144 may contain other software programs, executable by a processor, including a graphical user interface (GUI) configured to provide an interface to the user. -
Payer device 140 may further includedatabase 146 which may include, for example, identifiers such as operating system registry entries, cookies associated withpayment application 142 and/orother applications 144, identifiers associated with hardware ofpayer device 140, or other appropriate identifiers, such as identifiers used for payment/user/device authentication or identification. In one embodiment, identifiers indatabase 146 may be used bymerchant server 130 and/orpayment provider server 150 toassociate payer device 140 with a particular account maintained bymerchant server 130 and/orpayment provider server 150.Database 146 may also store received payment tokens and associated information, such as decisions on payment tokens and/or transaction histories for paid transaction and their associated payment tokens.Database 146 may also store financial information used bypayment application 142 to process payments. -
Payer device 140 includes at least onenetwork interface component 148 adapted to communicate withrequester device 110,merchant server 130, and/orpayment provider server 150. In various embodiments,network interface component 148 may include a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency, infrared, Bluetooth, and near field communication devices. -
Payment provider server 150 may be maintained, for example, by an online payment service provider, which may provide payment services and/or processing for financial transactions on behalf of users, including generation of tokens for use in requesting and completing payments by two or more users. In this regard,payment provider server 150 includes one or more processing applications which may be configured to interact withrequester device 110,merchant server 130, and/orpayer device 140 to facilitate payment for a transaction. In one example,payment provider server 150 may be provided by PAYPAL®, Inc. of San Jose, Calif., USA. However, in other embodiments,payment provider server 150 may be maintained by or include a credit provider, financial services provider, financial data provider, and/or other service provider, which may provide payment services to user 102 and/or the merchant Moreover, in various embodiments, one or more of the applications, processes, and/or features discussed below in reference topayment provider server 150 may be included inmerchant server 130, and vice versa. -
Payment provider server 150 ofFIG. 1 includes apayment request application 160, atransaction processing application 152,other applications 154, adatabase 156, and anetwork interface component 158.Payment request application 160,transaction processing application 152 andother applications 154 may correspond to processes, procedures, and/or applications, for example, a software program, executable by a hardware processor. In other embodiments,payment provider server 150 may include additional or different software as required. -
Payment request application 160 may correspond to an application configured to receive information used to generate a payment token for a transaction, verify identification and/or contact information for the payer of the transaction (e.g., second user 104), transmit the payment token to the payer, and take additional steps necessary after a decision is made regarding payment corresponding to the payment token. In this regard,payment request application 160 may receive information from first user 102 (e.g., through user device 110) for a transaction and the associated payer for the transaction, or may receive such information frommerchant server 130 after collection bymerchant server 130. The information necessary to generate a payment token may include at least a payment amount for the transaction and a payer for the transaction (e.g. identification/contact information for second user 104). As previously discussed, the information may further include transaction details (e.g., items/services selected, cost of each selected item/service, tax costs, discounts or benefits applied to the transaction, merchant name for the transaction, etc.), identification information for first user 102, a message, comment or note by first user 102, a time until expiration of the payment token, and/or merchant information. Once the information has been receivedpayment request application 160 may generate a payment token. - After generation of the payment token,
payment request application 160 may attempt to transmit the payment token tosecond user 104, the designated payer for the transaction. If the contact information cannot be determined forsecond user 104 using the supplied identification information,payment request application 160 may alert first user 102 and/ormerchant server 130 of the failure to communicate the payment token tosecond user 104.Merchant server 130 may then cancel the transaction. However, new information identifyingsecond user 104 may also be supplied topayment request application 160, which may further attempt to communicate the payment token. Once the payment token is communicated topayer device 140 for viewing bysecond user 104,payment request application 160 may await a response fromsecond user 104. - If
second user 104 declines payment for the transaction or does not accept payment within the validity period of the payment token,payment request application 160 may alert user 102 and/ormerchant server 130 of the failure to receive payment. Thus, first user 102 and/ormerchant server 130 may take further actions, such as cancellation of the transaction, payment by first user 102, and/or payment by another payer. However, ifsecond user 104 accepts payment for the transaction designated in the payment token,payment request application 160 may receive the payment request for the transaction and begin processing the payment request usingtransaction processing application 152.Payment request application 160 may notify first user 102 and/ormerchant server 130 thatsecond user 104 has accepted responsibility to pay for the transaction. -
Transaction processing application 152 may be configured to receive information from and/or transmit information torequester device 110,merchant server 130, and/orpayer device 140 for processing and completion of transactions generated by user 102 and paid for byuser 104.Transaction processing application 152 may include one or more applications to process the transaction from first user 102 andmerchant server 130 by receiving a payment request to complete payment for the transaction of items and/or services offered by the merchant corresponding tomerchant server 130. The payment request may correspond to a payment fromsecond user 104 to the merchant. The payment may include a user account identifier or other payment information (e.g. a credit/debit card or checking account) forsecond user 104 and a receiving account for the merchant. Additionally, the payment request may include a payment amount and terms of payment (e.g., notes fromsecond user 104 and/or rules set forsecond user 104 for payment of the transaction).Transaction processing application 152 may complete the transaction by providing payment to the merchant through the receiving account/payment information. Additionally,transaction processing application 152 may provide transaction histories, including receipts, torequester device 110,merchant server 130, and/orpayer device 140 for completion and documentation of the transaction. For example, a transaction history may be provided torequester device 110,merchant server 130, and/orpayer device 140 to allow for the respective users and/or merchants to view the transaction and provide the items and/or services to first user 102. - In various embodiments,
payment provider server 150 includesother applications 154 as may be desired in particular embodiments to provide features topayment provider server 150. For example,other applications 154 may include security applications for implementing server-side security features, programmatic server applications for interfacing with appropriate application programming interfaces (APIs) overnetwork 170, or other types of applications.Other applications 154 may contain software programs, executable by a processor, including a graphical user interface (GUI), configured to provide an interface to a user. - Additionally,
payment provider server 150 includesdatabase 156. As previously discussed, first user 102,second user 104, and/or the merchant corresponding tomerchant server 130 may establish one or more payment accounts withpayment provider server 150. User accounts indatabase 156 may include user/merchant information, such as name, address, birthdate, payment/funding information, additional user financial information, and/or other desired user data. First user 102,second user 104, and/or the merchant may link to their respective payment accounts through a user, merchant, and/or device identifier. Thus, when an identifier is transmitted topayment provider server 150, e.g. fromrequester device 110,merchant server 130, and/orpayer device 140, a payment account belonging to first user 102,second user 104, and/or the merchant may be found. In other embodiments, first user 102 and/or the merchant may not have previously established a payment account and may provide other financial information topayment provider server 150 to complete financial transactions, as previously discussed.Database 156 may further include information received for use in generated payment tokens, generated payment tokens and their respective information, and/or decisions regarding payment tokens. Transaction histories used to document payment for transactions corresponding to payment tokens may also be stored bydatabase 156 for distribution to first user 102,second user 104, and/or the merchant. - In various embodiments,
payment provider server 150 includes at least onenetwork interface component 158 adapted to communicaterequester device 110,merchant server 130, and/orpayer device 140 overnetwork 170. In various embodiments,network interface component 158 may comprise a DSL (e.g., Digital Subscriber Line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency (RF), and infrared (IR) communication devices. -
Network 170 may be implemented as a single network or a combination of multiple networks. For example, in various embodiments,network 170 may include the Internet or one or more intranets, landline networks, wireless networks, and/or other appropriate types of networks. Thus,network 170 may correspond to small scale communication networks, such as a private or local area network, or a larger scale network, such as a wide area network or the Internet, accessible by the various components ofsystem 100. -
FIG. 2 is an exemplary system environment showing a requesters device creating a transaction with a merchant for use in generating a payment token to a payer, according to an embodiment.Environment 200 ofFIG. 2 includes arequester device 210, apayment provider server 250, and anetwork 270 corresponding generally torequester device 110,payment provider server 150, andnetwork 170, respectively, ofFIG. 1 . -
Requester device 210 displays abrowser application interface 220 corresponding generally to the processes and features described in reference tobrowser application 120 ofFIG. 1 . As previously discussed, a user device executing a browser application may display a merchant's sales website or marketplace where a user may select items and/or services for purchase in a transaction. In other embodiments, the browser application may instead correspond to a dedicated application for the merchant. Thus,browser application interface 220displays item 221, such as a selected item for purchase in a transaction, aprice 222, and acheckout 223 process.Item 221 may correspond to an item offered for sale from a merchant (not shown) via the merchant's server and/or a physical merchant location where the user may pick up the product and/or have delivered from.Price 222 corresponds to a price foritem 221, such as a transaction price, shown as $109.99. Once the user is satisfied with the transaction, the user may initiate a checkout process throughcheckout 223.Checkout 223 includes arequester field 224, apayer field 225, atext field 226, and a submitbutton 227.Requester field 224 may include a field to enter identification information for the requester of payment for atransaction including item 221 andprice 222.Payer field 225 may have similar identification information and/or contact information for the payer of the transaction, such as a person/user that requester 224 is requesting payment from for the transaction. The requester (e.g., the user of requester device 210) may enter a message, comment, or note to the transaction for transmission to the payer intotext field 226. Additional information may also be selected and/or entered undercheckout 223 in various embodiments. Once the requester is satisfied with their entries, the requester may select submitbutton 227 to transmit the request for payment topayment provider server 250 overnetwork 270. -
Payment provider server 250 executes apayment request application 260 corresponding generally to the processes and features described in reference topayment request application 160 ofFIG. 1 .Payment request application 260 may be configured to generate a payment token for the transaction and request to pay for the transaction generated and submitted topayment provider server 250 duringcheckout 223. Thus,payment request application 260 includes atransaction request 261 corresponding to the transaction and the request to pay the transaction by a payer.Transaction request 261 includesrequester information 262 and payer information 263 corresponding generally to the payment requester and the payment payer, respectively.Requester information 262 and payer information 263 may include contact information enablingpayment request application 260 to contact the requester and payer.Transaction request 261 further include transaction 264 having details of the transaction, such as the items/service (e.g., item 221), prices (e.g., 222), and other transaction information. Using this information, payment token 264 may be generated. Once generated,payment request application 260 may verify the contact information for the payer by determining contact information verification 266.Payment request application 260 may further include merchant information 267 used to communicate the result of contact information verification to and any decisions regarding payment token 264. -
FIG. 3 is an exemplary system environment showing a payer device displaying a receiving payment token for authorizing or declining the transaction in the payment token, according to an embodiment.Environment 300 includes apayer device 340, apayment provider server 350, and anetwork 370 corresponding generally topayer device 140,payment provider server 150, andnetwork 170, respectively, ofFIG. 1 . -
Payer device 340 displays apayment application interface 342 corresponding generally to the processes and features described in reference topayment application 142 ofFIG. 1 .Payment application interface 342 displays a payment application where the payer (e.g., the user ofpayer device 340, not shown) may view a payment token and make a decision on whether to pay for the purchase represented by the payment token. In this regard,payment application interface 342 displays apayment token 1000,payment instruments 1010, and account details 1012.Payment token 1000 includes a received payment token from a requester, and may include atransaction field 1002, acost field 1004, adescription field 1006, and an approve/denybutton 1008.Transaction field 1002 may display the selected items/service (e.g.,item 221 ofFIG. 2 ) and may have further information about the items/services, such as descriptions, per unit cost, discounts, etc.Cost field 1004 may include a total accrued cost that the payer will pay if the payer accepts the transaction.Description field 1006 include further information submitted by the requester, such as a note, comment, etc., a time limit for validity ofpayment token 1000, and/or any rules or other settings they have set for accepting or declining payment for the transaction. Approve/denybutton 1008 initiates processes to accept payment for the transaction and/or decline payment for the transaction, and may enable the payer to set rules, add notes, or perform other actions when initiating a further process. The payer may select one or more payment instruments used to process a payment for the transaction underpayment instrument 1010, and may view their account details (e.g., account balances) under account details 1012. Once the payer has made a decision regardingpayment token 1000, the decision may be transmitted topayment provider server 350 overnetwork 370. As shown inFIG. 3 , the payer has accepted payment for a transaction associated withtransaction field 1002 inpayment token 1000, thus a payment is being processed bypayment provider server 350. -
Payment provider server 350 executes atransaction processing application 352 corresponding generally to the processes and features described in reference totransaction processing application 152 ofFIG. 1 . As previously described, the payer has accepted payment fortransaction 1002. Thus,transaction processing application 352 is processing a payment forpayment token 1000, which includes payment status 1020 (e.g., information identifying that the payer has accepted payment for transaction 1002), requester information enablingtransaction processing application 352 to alert the requester that payment has been made fortransaction 1002, merchant information 1024 enablingtransaction processing application 352 to alert the merchant that payment has been made fortransaction 1002, and the transaction 1026 information enabling transaction processing application to process payment fortransaction 1002 usingpayment instrument 1010. -
FIG. 4 is a flowchart of an exemplary process for requesting payment for selected items or services using payment tokens, according to an embodiment. Note that one or more steps, processes, and methods described herein may be omitted, performed in a different sequence, or combined as desired or appropriate. - At
step 402, a transaction request for an item or service available with a merchant is accessed, wherein the transaction request identifies a request for the item or service, and wherein the transaction request identifies a payer for the item or service. The requester may utilize a payment provider website to submit the transaction request with the merchant or may use a merchant website and/or merchant application to submit the request. The merchant may hold the item or service for purchase for a period of time, which may be denoted in the transaction request. The transaction request may include transaction information, which may comprise at least one of a name for the payer, an email address for the payer, a phone number for the payer, an account of the payer, and a messaging identifier for the payer. - A payment token is generated using the transaction request, at
step 404, wherein the payment token comprises requester identification information for the requester and a payment amount of the item or service. The payment token may further comprise at least one of information for the item or service, merchant identification information for the merchant, and validity information for the payment token. The validity information may comprise at least one of a time limit for validity of the payment token, a rule associated with the payment of the payment amount, and a rule associated with receipt and use of the item or service. Additionally, contact information for the payer may be determined using the transaction request, wherein the contact information comprises one of a messaging account, an email address, a payment account with a payment provider, and a phone number, wherein the payment token to the payer using the contact information. A validity of the contact information may also be determined, and the requester alerted based on the validity of the contact information. The merchant for the transaction request may also be alerted of the validity of the contact information. Thus, the contact information may be verified and the merchant may be alerted to cancel the transaction if the contact information is not verified, in certain embodiments. A notification that the payment token was not successfully communicated to the payer may be received, and the notification may be communicated to at least one of the merchant and the requester. However, if the contact information is verified, the payment token may be transmitted to the payer using the contact information. - Thus, at
step 406, the payment token is communicated to the payer for payment of the payment amount. Once the payment token is communicated, the requester may be redirected to a merchant website for the merchant after the requester submits the transaction request. Authorization to pay for the transaction in the transaction request may be received from the payer, and a payment for the transaction may be processed. The authorization may comprise at least one rule for the requester based on the payment of the transaction. The authorization may be communicated to at least one of the merchant and the requester. In certain embodiments, a notification that the payer has viewed the token may be received and may be communicated to the merchant. If the payer decides to decline the transaction, a denial of the transaction may be received from the payer and may be communicated to the merchant and/or the requester. -
FIG. 5 is a block diagram of a computer system suitable for implementing one or more components inFIG. 1 , according to an embodiment. In various embodiments, the user device may comprise a personal computing device (e.g., smart phone, a computing tablet, a personal computer, laptop, a wearable computing device such as glasses or a watch, Bluetooth device, key FOB, badge, etc.) capable of communicating with the network. The service provider may utilize a network computing device (e.g., a network server) capable of communicating with the network. It should be appreciated that each of the devices utilized by users and service providers may be implemented ascomputer system 500 in a manner as follows. -
Computer system 500 includes a bus 502 or other communication mechanism for communicating information data, signals, and information between various components ofcomputer system 500. Components include an input/output (I/O)component 504 that processes a user action, such as selecting keys from a keypad/keyboard, selecting one or more buttons, image, or links, and/or moving one or more images, etc., and sends a corresponding signal to bus 502. I/O component 504 may also include an output component, such as adisplay 511 and a cursor control 513 (such as a keyboard, keypad, mouse, etc.). An optional audio input/output component 505 may also be included to allow a user to use voice for inputting information by converting audio signals. Audio I/O component 505 may allow the user to hear audio. A transceiver ornetwork interface 506 transmits and receives signals betweencomputer system 500 and other devices, such as another user device, service device, or a service provider server vianetwork 170. In one embodiment, the transmission is wireless, although other transmission mediums and methods may also be suitable. One ormore processors 512, which can be a micro-controller, digital signal processor (DSP), or other processing component, processes these various signals, such as for display oncomputer system 500 or transmission to other devices via acommunication link 518. Processor(s) 512 may also control transmission of information, such as cookies or IP addresses, to other devices. - Components of
computer system 500 also include a system memory component 514 (e.g., RAM), a static storage component 516 (e.g., ROM), and/or adisk drive 517.Computer system 500 performs specific operations by processor(s) 512 and other components by executing one or more sequences of instructions contained insystem memory component 514. Logic may be encoded in a computer readable medium, which may refer to any medium that participates in providing instructions to processor(s) 512 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. In various embodiments, non-volatile media includes optical or magnetic disks, volatile media includes dynamic memory, such assystem memory component 514, and transmission media includes coaxial cables, copper wire, and fiber optics, including wires that comprise bus 502. In one embodiment, the logic is encoded in non-transitory computer readable medium. In one example, transmission media may take the form of acoustic or light waves, such as those generated during radio wave, optical, and infrared data communications, - Some common forms of computer readable media includes, for example, floppy disk, flexible disk, hard disk, magnetic tape, any other magnetic medium, CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, RAM, PROM, EEPROM, FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer is adapted to read.
- In various embodiments of the present disclosure, execution of instruction sequences to practice the present disclosure may be performed by
computer system 500. In various other embodiments of the present disclosure, a plurality ofcomputer systems 500 coupled bycommunication link 518 to the network (e.g., such as a LAN, WLAN, PTSN, and/or various other wired or wireless networks, including telecommunications, mobile, and cellular phone networks) may perform instruction sequences to practice the present disclosure in coordination with one another. - Where applicable, various embodiments provided by the present disclosure may be implemented using hardware, software, or combinations of hardware and software. Also, where applicable, the various hardware components and/or software components set forth herein may be combined into composite components comprising software, hardware, and/or both without departing from the spirit of the present disclosure. Where applicable, the various hardware components and/or software components set forth herein may be separated into sub-components comprising software, hardware, or both without departing from the scope of the present disclosure. In addition, where applicable, it is contemplated that software components may be implemented as hardware components and vice-versa.
- Software, in accordance with the present disclosure, such as program code and/or data, may be stored on one or more computer readable mediums. It is also contemplated that software identified herein may be implemented using one or more general purpose or specific purpose computers and/or computer systems, networked and/or otherwise. Where applicable, the ordering of various steps described herein may be changed, combined into composite steps, and/or separated into sub-steps to provide features described herein.
- The foregoing disclosure is not intended to limit the present disclosure to the precise forms or particular fields of use disclosed. As such, it is contemplated that various alternate embodiments and/or modifications to the present disclosure, whether explicitly described or implied herein, are possible in light of the disclosure. Having thus described embodiments of the present disclosure, persons of ordinary skill in the art will recognize that changes may be made in form and detail without departing from the scope of the present disclosure. Thus, the present disclosure is limited only by the claims.
Claims (20)
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/483,095 US20160071095A1 (en) | 2014-09-10 | 2014-09-10 | Requesting payments for selected items or services using payment tokens |
US16/807,087 US11461767B2 (en) | 2014-09-10 | 2020-03-02 | Requesting payments for selected items or services using payment tokens |
US17/959,108 US20230095214A1 (en) | 2014-09-10 | 2022-10-03 | Requesting payments for selected items or services using payment tokens |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/483,095 US20160071095A1 (en) | 2014-09-10 | 2014-09-10 | Requesting payments for selected items or services using payment tokens |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/807,087 Continuation US11461767B2 (en) | 2014-09-10 | 2020-03-02 | Requesting payments for selected items or services using payment tokens |
Publications (1)
Publication Number | Publication Date |
---|---|
US20160071095A1 true US20160071095A1 (en) | 2016-03-10 |
Family
ID=55437857
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/483,095 Abandoned US20160071095A1 (en) | 2014-09-10 | 2014-09-10 | Requesting payments for selected items or services using payment tokens |
US16/807,087 Active 2035-06-20 US11461767B2 (en) | 2014-09-10 | 2020-03-02 | Requesting payments for selected items or services using payment tokens |
US17/959,108 Pending US20230095214A1 (en) | 2014-09-10 | 2022-10-03 | Requesting payments for selected items or services using payment tokens |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/807,087 Active 2035-06-20 US11461767B2 (en) | 2014-09-10 | 2020-03-02 | Requesting payments for selected items or services using payment tokens |
US17/959,108 Pending US20230095214A1 (en) | 2014-09-10 | 2022-10-03 | Requesting payments for selected items or services using payment tokens |
Country Status (1)
Country | Link |
---|---|
US (3) | US20160071095A1 (en) |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20180047089A1 (en) * | 2015-09-24 | 2018-02-15 | Tencent Technology (Shenzhen) Company Limited | Payment method, apparatus and system |
US20180121908A1 (en) * | 2016-11-01 | 2018-05-03 | Mastercard Asia/Pacific Pte Ltd | Cross device digital wallet payment system and process |
US20180174222A1 (en) * | 2016-12-16 | 2018-06-21 | Paypal, Inc. | Accessing chat sessions via chat bots for cart generation |
US20180276737A1 (en) * | 2017-03-21 | 2018-09-27 | Aparna Krishnan Girish | System and method for delayed transaction completion |
CN109064176A (en) * | 2018-06-11 | 2018-12-21 | 阿里巴巴集团控股有限公司 | A kind of transaction processing method, apparatus and system |
CN110135836A (en) * | 2018-09-29 | 2019-08-16 | 广东小天才科技有限公司 | A kind of payment control method and wearable device based on wearable device |
EP3545649A4 (en) * | 2016-11-24 | 2020-07-22 | Diversify Finance Limited | System and method for processing a request token |
US20210065185A1 (en) * | 2019-08-29 | 2021-03-04 | Amazon Technologies, Inc. | Delegated payment verification for shared payment instruments |
US11227252B1 (en) * | 2018-09-28 | 2022-01-18 | The Descartes Systems Group Inc. | Token-based transport rules |
US11276106B2 (en) * | 2018-12-11 | 2022-03-15 | Wells Fargo Bank, N.A. | System and method for claw back and price protection |
US20230237464A1 (en) * | 2022-01-20 | 2023-07-27 | Mastercard International Incorporated | System and Method for Providing Transaction Report Data Using A User Device |
US11803784B2 (en) * | 2015-08-17 | 2023-10-31 | Siemens Mobility, Inc. | Sensor fusion for transit applications |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10872370B2 (en) * | 2017-11-14 | 2020-12-22 | Tommy Run LLC | Systems and methods for on-demand delivery of construction materials and other items |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060031359A1 (en) * | 2004-05-29 | 2006-02-09 | Clegg Paul J | Managing connections, messages, and directory harvest attacks at a server |
US20080021885A1 (en) * | 2006-07-24 | 2008-01-24 | Chacha Search, Inc. | System for substantially immediate payment for search related tasks |
US20090043855A1 (en) * | 2007-08-08 | 2009-02-12 | Blake Bookstaff | System for providing information to originator of misdirected email |
US20100114733A1 (en) * | 2008-10-30 | 2010-05-06 | Socialwise, Inc. | Party Payment System |
US20120171990A1 (en) * | 2011-01-04 | 2012-07-05 | Boku, Inc. | Systems and Methods to Restrict Payment Transactions |
US20130060679A1 (en) * | 2011-09-06 | 2013-03-07 | Rawllin International Inc. | Third-party payments for electronic commerce |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130332337A1 (en) * | 2012-06-08 | 2013-12-12 | David Nghiem Tran | Systems and Methods for Enabling Trusted Borrowing and Lending Using Electronic Funds |
US9767265B2 (en) * | 2014-05-06 | 2017-09-19 | Anchor Id, Inc. | Authentication with parental control functionality |
-
2014
- 2014-09-10 US US14/483,095 patent/US20160071095A1/en not_active Abandoned
-
2020
- 2020-03-02 US US16/807,087 patent/US11461767B2/en active Active
-
2022
- 2022-10-03 US US17/959,108 patent/US20230095214A1/en active Pending
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060031359A1 (en) * | 2004-05-29 | 2006-02-09 | Clegg Paul J | Managing connections, messages, and directory harvest attacks at a server |
US20080021885A1 (en) * | 2006-07-24 | 2008-01-24 | Chacha Search, Inc. | System for substantially immediate payment for search related tasks |
US20090043855A1 (en) * | 2007-08-08 | 2009-02-12 | Blake Bookstaff | System for providing information to originator of misdirected email |
US20100114733A1 (en) * | 2008-10-30 | 2010-05-06 | Socialwise, Inc. | Party Payment System |
US20120171990A1 (en) * | 2011-01-04 | 2012-07-05 | Boku, Inc. | Systems and Methods to Restrict Payment Transactions |
US20130060679A1 (en) * | 2011-09-06 | 2013-03-07 | Rawllin International Inc. | Third-party payments for electronic commerce |
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11803784B2 (en) * | 2015-08-17 | 2023-10-31 | Siemens Mobility, Inc. | Sensor fusion for transit applications |
US20180047089A1 (en) * | 2015-09-24 | 2018-02-15 | Tencent Technology (Shenzhen) Company Limited | Payment method, apparatus and system |
US11120493B2 (en) * | 2015-09-24 | 2021-09-14 | Tencent Technology (Shenzhen) Company Limited | Payment method, apparatus and system |
US20180121908A1 (en) * | 2016-11-01 | 2018-05-03 | Mastercard Asia/Pacific Pte Ltd | Cross device digital wallet payment system and process |
EP3545649A4 (en) * | 2016-11-24 | 2020-07-22 | Diversify Finance Limited | System and method for processing a request token |
US10929917B2 (en) * | 2016-12-16 | 2021-02-23 | Paypal, Inc. | Accessing chat sessions via chat bots for cart generation |
US20180174222A1 (en) * | 2016-12-16 | 2018-06-21 | Paypal, Inc. | Accessing chat sessions via chat bots for cart generation |
US20180276737A1 (en) * | 2017-03-21 | 2018-09-27 | Aparna Krishnan Girish | System and method for delayed transaction completion |
CN109064176A (en) * | 2018-06-11 | 2018-12-21 | 阿里巴巴集团控股有限公司 | A kind of transaction processing method, apparatus and system |
US11227252B1 (en) * | 2018-09-28 | 2022-01-18 | The Descartes Systems Group Inc. | Token-based transport rules |
CN110135836A (en) * | 2018-09-29 | 2019-08-16 | 广东小天才科技有限公司 | A kind of payment control method and wearable device based on wearable device |
US11276106B2 (en) * | 2018-12-11 | 2022-03-15 | Wells Fargo Bank, N.A. | System and method for claw back and price protection |
US11900441B1 (en) | 2018-12-11 | 2024-02-13 | Wells Fargo Bank, N.A. | System, method, and medium for claw back and price protection |
US20210065185A1 (en) * | 2019-08-29 | 2021-03-04 | Amazon Technologies, Inc. | Delegated payment verification for shared payment instruments |
US20230237464A1 (en) * | 2022-01-20 | 2023-07-27 | Mastercard International Incorporated | System and Method for Providing Transaction Report Data Using A User Device |
Also Published As
Publication number | Publication date |
---|---|
US20230095214A1 (en) | 2023-03-30 |
US11461767B2 (en) | 2022-10-04 |
US20200273021A1 (en) | 2020-08-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11461767B2 (en) | Requesting payments for selected items or services using payment tokens | |
US11875352B2 (en) | Dynamic authentication through user information and intent | |
US10223677B2 (en) | Completion of online payment forms and recurring payments by a payment provider systems and methods | |
US11216791B2 (en) | Software development kits for point-of-sale device and mobile device interactive frameworks | |
US10152699B2 (en) | Recovery of declined transactions | |
US9454753B2 (en) | Friendly funding source | |
US20140379576A1 (en) | Transaction approval for shared payment account | |
US20120254025A1 (en) | Online payment for offline purchase | |
US11756019B2 (en) | SDK for dynamic workflow rendering on mobile devices | |
US9569760B2 (en) | Rapid checkout after payment | |
US20160071139A1 (en) | Preauthorize buyers to commit to a group purchase | |
US11461770B2 (en) | Active application of secondary transaction instrument tokens for transaction processing systems | |
US11790333B2 (en) | Tokenized data having split payment instructions for multiple accounts in a chain transaction | |
WO2015164012A1 (en) | Transaction conversion with payment card | |
US11055716B2 (en) | Risk analysis and fraud detection for electronic transaction processing flows | |
US20160180344A1 (en) | Communication device interfaces for transaction approval at a merchant location |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: EBAY INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FOERSTER, DAWID;LOHMAR, CLAUS CHRISTIAN;RECKER, THORSTEN;SIGNING DATES FROM 20140831 TO 20140901;REEL/FRAME:033723/0819 |
|
AS | Assignment |
Owner name: PAYPAL, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:EBAY INC.;REEL/FRAME:036171/0221 Effective date: 20150717 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |