WO2017027533A1 - Plateforme d'approbation de paiement - Google Patents

Plateforme d'approbation de paiement Download PDF

Info

Publication number
WO2017027533A1
WO2017027533A1 PCT/US2016/046233 US2016046233W WO2017027533A1 WO 2017027533 A1 WO2017027533 A1 WO 2017027533A1 US 2016046233 W US2016046233 W US 2016046233W WO 2017027533 A1 WO2017027533 A1 WO 2017027533A1
Authority
WO
WIPO (PCT)
Prior art keywords
requestor
purchase
decision maker
request
transaction
Prior art date
Application number
PCT/US2016/046233
Other languages
English (en)
Inventor
Timothy Sheehan
Melissa MURPHY
Original Assignee
GreenLight Me, Inc.
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Priority claimed from US14/822,567 external-priority patent/US20170046697A1/en
Priority claimed from US14/822,548 external-priority patent/US20170046716A1/en
Priority claimed from US14/822,593 external-priority patent/US20170046758A1/en
Priority claimed from US14/822,526 external-priority patent/US10803428B2/en
Application filed by GreenLight Me, Inc. filed Critical GreenLight Me, Inc.
Priority to CA2995415A priority Critical patent/CA2995415A1/fr
Priority to EP16835797.8A priority patent/EP3335171A4/fr
Publication of WO2017027533A1 publication Critical patent/WO2017027533A1/fr
Priority to HK18116338.7A priority patent/HK1257090A1/zh

Links

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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0641—Shopping interfaces
    • G06Q30/0643—Graphical representation of items or shoppers
    • 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/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0641—Shopping interfaces

Definitions

  • the present disclosure generally relates to approval of commercial transactions.
  • EFT Electronic funds transfer
  • EFT includes, for example, cardholder-initiated transactions (e.g. using a payment card such as a credit or debit card).
  • a payment card such as a credit or debit card.
  • Credit cards, debit cards, charge cards and smart cards are popular tools for electronic payment transactions.
  • new technology is emerging including such as for example, smart phone payments (e.g., Apple Pay).
  • EFTs may be made in person, for example, at a point of sale, or online, for example, via an e-commerce platform.
  • a first individual ('decision maker') lends his/her payment card to a second individual ('requestor')
  • the first individual has no direct control over how the second individual uses the payment card.
  • a father may lend his son a credit card to purchase school supplies.
  • the father may be able to use a spending limit to restrict the amount that the son spends.
  • the father will not have direct control over whether the son buys school supplies or instead makes other purchases.
  • Embodiments of the present disclosure may receive, from a requestor, a purchase request comprising request details.
  • the purchase request may then be provided to the decision maker.
  • the decision maker may be enabled to approve or decline approval of the purchase request from the decision maker.
  • the platform may receive checkout details associated with the purchase request.
  • the platform may compare the checkout details to the request details. If the checkout details match the request details, the platform may enable a completion of a transaction associated with the purchase request.
  • Embodiments of the present disclosure may generate a purchase request from purchase details provided by a requestor.
  • the purchase request may be generated via a user interface enabling the input of a plurality of purchase details.
  • Embodiments of the present disclosure may then communicate the purchase request to a decision maker, and enable the decision maker to select a decision to approve or decline the request.
  • the platform may enable a communication interface between the requestor and the decision maker.
  • the platform may receive the decision, and notify the requestor of the decision.
  • a platform for providing a three-tier authorization may be provided.
  • the platform may receive a requestor login from a requestor including requestor access credentials, as well as a purchase request.
  • the platform may provide a first level of authentication upon authenticating the requestor access credentials.
  • the platform may further receive decision maker access credentials and provide a second authentication by receiving approval of the purchase request and authenticating the decision maker access credentials.
  • the platform may further receive payment details and authenticate the payment details to authorize the payment, providing a third authorization.
  • the platform may enable a transaction.
  • a platform for approving purchases in an e-commerce platform may be provided.
  • Embodiments of the present disclosure may first receive, from a requestor, a request for a purchase.
  • the request may be received while, for example, the requester is navigating an e-commerce platform.
  • the request for the purchase may comprise request details associated with the purchase and a link associated with an online merchant.
  • the request details may be retrieved by, for example, accessing the link and retrieving product information associated with the purchase.
  • the request and details may be provided to a decision maker associated with the requestor. The decision maker may then accept or decline the purchase.
  • the platform may enable a processing of a transaction associated with the purchase request.
  • drawings may contain text or captions that may explain certain embodiments of the present disclosure. This text is included for illustrative, non-limiting, explanatory purposes of certain embodiments detailed in the present disclosure.
  • drawings may contain text or captions that may explain certain embodiments of the present disclosure. This text is included for illustrative, non-limiting, explanatory purposes of certain embodiments detailed in the present disclosure.
  • FIG. 1 A illustrates a block diagram of an operating environment consistent with the present disclosure
  • FIG. IB illustrates a block diagram of an operating environment consistent with the present disclosure
  • FIG. 1C illustrates a block diagram of an operating environment consistent with the present disclosure
  • FIG. ID illustrates a block diagram of an operating environment consistent with the present disclosure
  • FIG. 2A is a flow chart of a method for providing a payment approval platform
  • FIG. 2B is a flow chart of a method for providing an e-commerce payment approval platform
  • FIG. 2C is a flow chart of a method for providing a single-user payment approval platform
  • FIG. 3 A illustrates an interface for receiving purchase request information from a requestor
  • FIG. 3B illustrates another interface for receiving purchase request information from a requestor
  • FIG. 3C illustrates yet another interface for receiving purchase request information from a requestor
  • FIG. 3D illustrates still another interface for receiving purchase request information from a requestor
  • FIG. 3E illustrates another interface for receiving purchase request information from a requestor
  • FIG. 4 illustrates an interface showing recurring purchase requests, as well as relevant information pertaining to such recurring requests
  • FIG. 5 illustrates an interface showing pending requests
  • FIG. 6 illustrates an interface showing the notification of a purchase pending approval
  • FIG. 7 illustrates an interface showing a rejection of a purchase request
  • FIG. 8 illustrates an interface showing an approval of a purchase request
  • FIG. 9 illustrates an interface showing a successful transaction
  • FIG. 10 is a flow chart setting forth the general stages involved in a method 1000 consistent with an embodiment of the disclosure for providing a three-tier payment approval method with platform 100;
  • FIG. 11 is a block diagram of a system including a computing device for performing the method of FIG. 2.
  • any embodiment may incorporate only one or a plurality of the above-disclosed aspects of the disclosure and may further incorporate only one or a plurality of the above- disclosed features.
  • any embodiment discussed and identified as being "preferred” is considered to be part of a best mode contemplated for carrying out the embodiments of the present disclosure.
  • Other embodiments also may be discussed for additional illustrative purposes in providing a full and enabling disclosure.
  • any embodiment may incorporate only one or a plurality of the above-disclosed aspects of the display and may further incorporate only one or a plurality of the above-disclosed features.
  • many embodiments, such as adaptations, variations, modifications, and equivalent arrangements will be implicitly disclosed by the embodiments described herein and fall within the scope of the present disclosure.
  • any sequence(s) and/or temporal order of steps of various processes or methods that are described herein are illustrative and not restrictive. Accordingly, it should be understood that, although steps of various processes or methods may be shown and described as being in a sequence or temporal order, the steps of any such processes or methods are not limited to being carried out in any particular sequence or order, absent an indication otherwise. Indeed, the steps in such processes or methods generally may be carried out in various different sequences and orders while still falling within the scope of the present invention. Accordingly, it is intended that the scope of patent protection is to be defined by the issued claim(s) rather than the description set forth herein.
  • the present disclosure includes many aspects and features. Moreover, while many aspects and features relate to, and are described in, the context of parents controlling their children's spending, embodiments of the present disclosure are not limited to use only in this context. For example, companies may employ embodiments of the present disclosure for controlling travel budgeting and expenses. Additionally, while many aspects, features, and examples relate to, and are described in, the context of purchasing merchandise at a point of sale, embodiments of the present disclosure are not limited to this context. For example, embodiments of the present disclosure may be used for approving any transaction, including, for example, purchases of services and e-commerce purchases. Further, while the term 'card' is used to reference a payment method used, any other payment method may be used. For example, electronic checking, and other types of electronic fund transfers and associated institutions may be implemented in embodiments of the present disclosure.
  • a payment approval platform may be provided.
  • This overview is provided to introduce a selection of concepts in a simplified form that are further described below. This overview is not intended to identify key features or essential features of the claimed subject matter. Nor is this overview intended to be used to limit the claimed subject matter's scope.
  • the payment approval platform may be used by individuals or companies to approve or decline purchases in real time.
  • Embodiments of the present disclosure may enable a "purchasing party" to remotely request and receive approval for, for example, a card transaction from a "decision maker party". Once approval is received from the decision maker party, a card processor associated with the card may enable the transaction to occur.
  • the request and approval process between the purchasing party and the deciding party may enable the setting of certain parameters and conditions on the transaction (e.g., amount, location, time, and the like).
  • the approved transaction in turn, would be limited, by the processor, to the parameters and conditions set for the transaction.
  • Embodiments of the present disclosure may first enable users to create accounts.
  • Accounts may be attached to requestors and/or decision makers (or collectively, 'users').
  • the parent may be a decision maker and a teenager may be a requestor.
  • the requestor and the decision maker may be the same person.
  • Accounts may be associated with user information including, for example, user name, address, email, date of birth, gender, and password, and one or more accounts (e.g., bank and/or card) associated with the user.
  • Decision maker accounts may then be connected to requestor accounts.
  • a requestor may be associated with one or more decision makers.
  • the decision maker must be at least 18 years of age.
  • the platform may require age confirmation.
  • the decision maker may be the provider of funds.
  • the decision maker may be the provider of funds. For example, the decision maker
  • the decision maker may register and associate one or more payment methods (e.g., credit card, debit card, prepaid card, bank account, etc.) with his or her account.
  • the decision maker may further register and associate one or more requestors (e.g., children and teens) with his or her account and associate one or more payment methods with each requestor.
  • the decision maker may control a master account, while each requestor may use a sub-account associated with the master account.
  • platform consistent embodiments of the present disclosure may enable the requestor to provide details of the desired purchase.
  • the teenager e.g., purchasing party
  • purchase details for an item she wants to purchase such as, for example, a description, price, store, photo, and date and time of purchase.
  • the platform may further require requestor account authentication, for example, by requiring the requestor to log in.
  • a login may be performed, for example, by requiring a username, password, biometric indicator (e.g., fingerprint scan), confirmation via a mobile phone or device associated with the requestor, or various other methods for authenticating requestor identity.
  • biometric indicator e.g., fingerprint scan
  • the platform may then notify the parent (e.g., decision maker party associated with the purchasing party) of the desired purchase pending approval including the details of the desired purchase. Notification may be received by the parent through, for example, but not limited to, a similar mobile phone based application associated with the platform.
  • the platform may then enable the parent to, for example, approve, reject approval, or modify the purchase request (e.g., reduce the amount available for spending) and then approve the desired purchase.
  • the platform may further require decision maker account authentication, for example, by requiring the decision maker to log in.
  • a login may be performed, for example, by requiring a username, password, biometric indicator (e.g., fingerprint scan), confirmation via a mobile phone or device associated with the decision maker, or various other methods for authenticating decision maker identity.
  • a transaction may be executed by the requestor.
  • the platform may be in operative communication with merchant banks, card processors, and other financial transaction institutions associated with the transaction (hereinafter referred to as "payment processor").
  • a card may be associated with the requestor's and decision makers' platform accounts. In this way, and as will be detailed below, the platform may verify that the parameters of the actual transaction may match the approved transaction details.
  • the platform may then enable, for example, a purchase in an amount up to the approved amount at the approved store, on the approved date and time. Accordingly, embodiments of the present disclosure may cause the card to be activated or deactivated for purchasing within the scope of the purchase details or applying a restriction thereto.
  • the platform may provide the requestor and decision maker with a notification.
  • the notification may include a reminder to take a picture of a receipt associated with the purchase.
  • approved purchases may be made recurring, such as, for example, a weekly grocery budget.
  • Embodiments of the present disclosure may display to users the past purchases, purchases pending approval, approved purchases, recurring purchases, and rejected purchases. Further information, such as, for example, comments, may additionally be provided to users.
  • FIG. 1A illustrates one possible operating environment through which a platform 100A consistent with embodiments of the present disclosure may be provided.
  • a payment approval platform 100 may be hosted on a centralized server 110, such as, for example, a cloud computing service.
  • a requestor 105 may access platform 100 through a software application.
  • a decision maker 108 may access platform 1100 through the same or an associated software application. In some embodiments, the requestor 105 and the decision maker 108 may be one and the same user.
  • the software applications may be embodied as, for example, but not be limited to, a website, a web application, a desktop application, and a mobile application compatible with a computing device 1100.
  • One possible embodiment of the software application may be provided by the GreenLightTM suite of products and services provided by GreenLight Me, Inc.
  • the platform 100 may further be accessed by financial networks, such as, for example, a merchant bank, a merchant, a card network, and a card processor.
  • financial networks such as, for example, a merchant bank, a merchant, a card network, and a card processor.
  • the card processor may be provided by, or associated with, for example, the platform provider.
  • the merchant bank may be an entity that provides merchant products and services needed to process payment cards. It may act as an intermediary between merchants, issuing banks, and card networks throughout the process. Further, the merchant bank may be responsible for depositing the transaction proceeds into merchant's designated bank account.
  • the computing device(s) through which the platform may be accessed may comprise, but not be limited to, for example, a desktop computer, laptop, a tablet, or mobile telecommunications device. Though the present disclosure is written with reference to a mobile telecommunications device, it should be understood that any computing device may be employed to provide the various embodiments disclosed herein.
  • a first user 105 may utilize a software or web application (e.g., a component of platform 100) on his or her respective a first computing device (e.g., configured as computing device 1100) to identify a desired transaction.
  • the desired transaction details and the first user's credentials e.g., login information, device ID, location information, Internet Protocol (IP) information, and the like
  • IP Internet Protocol
  • the desired transaction and the first user's credentials may be sent to a central database which may be located in, for example, but not limited to, a cloud environment or at a central location (e.g., server 110).
  • the central database may route the request to the authorized grantor ('decision maker'), second user 108.
  • the grantor may be an individual utilizing the software or web application (e.g., a component of platform 100) on a second computing device (e.g., configured as computing device 1100) and may authorize or deny the request.
  • the grantor's access to the information may provide a second authentication factor.
  • the requestor may be notified via the central database and effect the transaction using a payment device.
  • the payment device may comprise, for example, but not limited to, a credit, debit, or prepaid card, or virtual money account such as, for example, but not limited to, Apple Pay.
  • the central database may upload transactional related information to a payment device issuing bank and may modify a respective payment device transactional record to include the parameters related to the desired transaction.
  • the updated payment device transactional record may be compared to the actual transactional record. And if certain updated parameters match, such as, for example, amount, geo code (e.g., GPS coordinates), time, category or the like, then the transaction may be approved. If the information does not match, the transaction may be denied. This may provide a third factor of authentication.
  • FIG. IB illustrates an operating environment for a typical retail purchase 100B made by a requestor 105 using the software application 120 and a platform card.
  • the requestor 105 e.g., a teenager
  • the requestor may use the software application to request a purchase for a specific item with specific item parameters (e.g., pants, $75, J Crew, at Lenox Mall, on September 30, 2014).
  • the requestor may select a specific decision maker 108 for approving the request.
  • the decision maker 108 e.g., a parent
  • the software application 120 may update the card processor's database 130 to reflect specific purchase parameters (e.g., card status, transaction categories, geo-fence coordinates, time frame for purchase, and individual transaction maximum amount).
  • Merchant 140 may process the platform card and transaction information and request an authentication from a merchant bank 150.
  • the merchant bank 150 may submit authentication to a card network 160.
  • the card network 160 may send a request to the card processor's database 130.
  • the card processor's database 130 may compare the transaction information with the parameters approved by the decision maker 108 and approve or decline the transaction as an authentication response.
  • Card network 160 may forward the authentication response to the merchant bank 150.
  • Merchant bank 150 may forward the response to the merchant 140.
  • the merchant 140 may receive the authentication response and complete the transaction according to the authentication response. If approved, the requestor 105 may successfully complete the purchase.
  • Software application 120 may set a card status to suspended/inactive with the card processor's database 130.
  • FIG. 1C illustrates an operating environment for a typical e-commerce purchase lOOC made by a requestor 105 using the software application 120 and a platform card.
  • the requestor 105 e.g., a teenager
  • the item parameters may be submitted, for example, by sending a link to an online merchant's platform (e.g., a uniform resource locator (URL)) corresponding to the desired items into the software application 120. This may be done, for example, when the requestor clicks a link within an internet browser while shopping on an online merchant's e-commerce site.
  • the requestor may select a specific decision maker 108 (e.g., a parent) for approving the request.
  • the decision maker 108 may receive the request for example, the link.
  • the platform may retrieve product details from the e-commerce site and send the product details to the decision maker. The decision maker may then approve or decline the request via the software application.
  • the software application 120 may update the card processor's database 130 to reflect specific purchase parameters (e.g., card status, transaction categories, geo-fence coordinates, time frame for purchase, and individual transaction maximum amount).
  • specific purchase parameters e.g., card status, transaction categories, geo-fence coordinates, time frame for purchase, and individual transaction maximum amount.
  • the 140 may process the platform card and transaction information and request an authentication from a merchant bank 150.
  • the platform may provide an automated checkout method as further described herein.
  • the merchant bank 150 may submit authentication to a card network 160.
  • the card network 160 may send a request to the card processor's database 130.
  • the card processor's database 130 may compare the transaction information with the parameters approved by the decision maker 108 and approve or decline the transaction as an authentication response.
  • Card network 160 may forward the authentication response to the merchant bank 150.
  • Merchant bank 150 may forward the response to the merchant 140.
  • the merchant (Online merchant') 140 may receive the authentication response and complete the transaction according to the authentication response. If approved, the requestor 105 may successfully complete the purchase.
  • Software application 120 may set a card status to suspended/inactive with the card processor's database 130.
  • Software application may further update the card processor's database 130.
  • the platform may receive, from a requestor, a request for a purchase, where the request comprises request details associated with the purchase and a link associated with an online merchant. Next, the platform may provide the request to a decision maker associated with the requestor. In some embodiments, the request provided to the decision maker may comprise the link. Then, the platform may receive an approval of the request from the decision maker. Subsequently, the platform may enable a processing of a transaction.
  • the platform may receive the request while the requestor is navigating an online merchant's website.
  • the platform may access the link associated with the online merchant to retrieve product details.
  • the retrieved product details may be included and sent to the decision maker in the purchase request.
  • the requestor may request permission for purchasing a product associated with a website the requestor is currently navigating.
  • the platform may enable processing of the transaction via an automated application that navigates checkout in the browser of the decision maker or the requestor.
  • the platform may utilize an application programming interface (API) for interfacing with the browser.
  • API application programming interface
  • FIG. ID illustrates an operating environment for a single-user purchase 100D.
  • Decision maker 108 may use the software application 120 to turn on/enable the card for purchases. Furthermore, decision maker 108 may choose to set other purchase parameters like item, price, store, and timeframe.
  • the software application 120 may update the card processor's database 130 to reflect specific purchase parameters.
  • Merchant 140 may process the platform card and transaction information and request an authentication from a merchant bank 150.
  • the merchant bank 150 may submit authentication to a card network 160.
  • the card network 160 may send a request to the card processor's database 130.
  • the card processor's database 130 may compare the transaction information with the parameters approved by the decision maker 108 and approve or decline the transaction as an authentication response.
  • Card network 160 may forward the authentication response to the merchant bank 150.
  • Merchant bank 150 may forward the response to the merchant 140.
  • the merchant 140 may receive the authentication response and complete the transaction according to the authentication response. If approved, the decision maker 18 may successfully complete the purchase.
  • Software application 120 may set a card status to suspended/inactive with the card processor's database 130.
  • FIG. 2A is a flow chart setting forth the general stages involved in a method 200A consistent with an embodiment of the disclosure for providing a payment approval platform 100.
  • Method 200A may be implemented using a computing device 1100 as described in more detail below with respect to FIG. 11.
  • computing device 1100 may be used to perform the various stages of the methods.
  • different operations may be performed by different networked elements in operative communication with computing device 1100.
  • server 110 may be employed in the performance of some or all of the stages in the methods.
  • server 110 may be configured much like computing device 1100.
  • stages illustrated by the flow charts are disclosed in a particular order, it should be understood that the order is disclosed for illustrative purposes only. Stages may be combined, separated, reordered, and various intermediary stages may exist. Accordingly, it should be understood that the various stages illustrated within the flow chart may be, in various embodiments, performed in arrangements that differ from the ones illustrated. Moreover, various stages may be added or removed from the flow charts without altering or deterring from the fundamental scope of the depicted methods and systems disclosed herein. Ways to implement the stages of the methods will be described in greater detail below.
  • Method 200A may begin starting block 205 where the platform may receive user account information.
  • the platform may receive user account information for a decision maker and a requestor.
  • User account information may include, for example, but not be limited to, first and last name, address, phone number, email, date of birth, gender, and account password.
  • the platform may enable the decision maker to provide approval via a link to an e-commerce platform as an alternative to approving an in-store point of sale approval.
  • the platform may then assign the requestor and decision maker each with a unique identifier (e.g., GL-XXXX).
  • Account information may further include a role (e.g., decision maker or requestor).
  • the decision maker may then be associated with one or more requestors ('relationships').
  • Each user's account may further be associated with a financial institution.
  • the decision maker's account may be linked to a bank account, credit card account, etc.
  • the requestor's account may be associated with a financial institution through the decision maker's account.
  • method 200 A may proceed to proceed to stage 210 where platform 100 may receive a purchase request.
  • a requestor may request to purchase a pair of pants with the software application.
  • FIGs. 3A, 3B, 3C, 3D and 3E illustrate interfaces 300A, 300B, 300C, 300D, and 300E, respectively, for receiving purchase request information.
  • the platform may provide the requestor with a plurality of input prompts 310, to input purchase request information ('transactional information') such as, for example, but not limited to, price, merchant/store, geo-fence coordinates, transaction category, date/time limitations of purchase, a photo of the item(s) for purchase, to whom approval should be sent, and comments.
  • purchase request information e.g., but not limited to, price, merchant/store, geo-fence coordinates, transaction category, date/time limitations of purchase, a photo of the item(s) for purchase, to whom approval should be sent, and comments.
  • the platform may enable the user to make the purchase request recurring, such as, for example, if the requestor desires to request a weekly grocery budget.
  • FIG. 4 illustrates an interface 400 showing recurring purchase requests 405, as well as relevant information pertaining to such recurring requests (e.g., percent of budget spent 410).
  • the platform may receive a finalization of the purchase request, for example by receiving a selection of the submit request button 315. Platform 100 may then display to the user any pending purchase requests.
  • FIG. 5 illustrates an interface 500 showing pending requests 505.
  • stage 210 where platform 100 receives purchase request information, method 200 A may advance to stage 220 where platform 100 may send a notification to the decision maker and receive a decision.
  • the decision maker may receive a notification, for example, via the software application. In some cases, the decision maker may be the requestor.
  • FIG. 6 illustrates an interface 600 showing the notification.
  • the decision maker may receive purchase request information 605 corresponding to information received from the requestor's input prompts 310.
  • the decision maker may receive a selection of response options 610, such as, for example, accept, reject, call requestor, and message requestor.
  • the platform may further enable the user to edit the desired purchase request information, or provide further purchase limits (e.g., a spending limit, credit limit, account balance, day, time and location). In addition, the platform may enable the user to request to be notified at a later time.
  • platform 100 sends a notification to the decision maker and receives a decision in stage 220, if the platform receives a rejection of the purchase request, method 200A may notify the user.
  • FIG. 7 illustrates an interface 700 showing a rejection of a purchase request.
  • method 200A may notify the user and proceed to stage 230, where the platform may convert the purchase request details into approved parameters a card processing database can use.
  • FIG. 8 illustrates an interface 800 showing an approval of a purchase request.
  • platform 100 converts the purchase request details into parameters a card processing database can use, method 200 A may proceed to stage 240, where platform 100 may update a card processing database to reflect the transaction parameters.
  • method 200A may proceed to stage 250, where platform may attempt to systematically purchase the approved transaction via a payment device authentication system.
  • the payment device authentication system may include all facets of a standard electronic fund transfer ('EFT') authentication system such as a merchant bank, issuing bank, and any additional clearinghouse entities typically involved in the approval or disapproval of an EFT transaction.
  • 'EFT' electronic fund transfer
  • FIG. 1 the payment device authentication system is identified as Card Network and Merchant Bank.
  • the platform may send a push alert to approve the request.
  • the push alert may be sent, for example, via API, to the card processor.
  • a token may be passed from the merchant to the merchant bank in stage 260.
  • the merchant bank may then pass the token to the card network in stage 270.
  • the card network may pass the token to the card processor in stage 280 for additional approval.
  • platform 100 passes the token to the card processor in stage 280, method
  • platform 200 A may proceed to stage 280, where platform 100 compares the transaction parameters to the purchase details approved by the decision maker.
  • the platform may receive transaction parameters (e.g., geo-location, price, store, and date and time of purchase) received from an e-commerce platform or at a point of sale when the requestor attempts to make the purchase. Platform 100 may then compare the transaction parameters to the approved parameters.
  • transaction parameters e.g., geo-location, price, store, and date and time of purchase
  • the platform may complete the transaction and notify the merchant in stage 293a. Otherwise, the platform may reject the purchase in stage 293b.
  • method 200 A may proceed to 296, where platform 100 may display the completed purchase details to the users.
  • FIG. 9 illustrates an interface showing a successful transaction 900.
  • the platform may further prompt the requestor to take a photo of a receipt for the successful transaction, for example, by providing a photo button 905.
  • platform 100 displays the completed purchasing details to the users and prompts the requestor to take a picture of the receipt in stage 296, method 200A may then end.
  • FIG. 2B is a flow chart setting forth the general stages involved in a method 200B consistent with an embodiment of the disclosure for providing a payment approval platform 100.
  • Method 200B may be implemented using a computing device 1100 as described in more detail below with respect to FIG. 11.
  • computing device 1100 may be used to perform the various stages of the methods.
  • different operations may be performed by different networked elements in operative communication with computing device 1100.
  • server 110 may be employed in the performance of some or all of the stages in the methods.
  • server 110 may be configured much like computing device 1100.
  • stages illustrated by the flow charts are disclosed in a particular order, it should be understood that the order is disclosed for illustrative purposes only. Stages may be combined, separated, reordered, and various intermediary stages may exist. Accordingly, it should be understood that the various stages illustrated within the flow chart may be, in various embodiments, performed in arrangements that differ from the ones illustrated. Moreover, various stages may be added or removed from the flow charts without altering or deterring from the fundamental scope of the depicted methods and systems disclosed herein. Ways to implement the stages of the methods will be described in greater detail below.
  • Method 200A may begin starting block 205 where the platform may receive user account information.
  • the platform may receive user account information for a decision maker and a requestor.
  • User account information may include, for example, but not be limited to, first and last name, address, phone number, email, date of birth, gender, and account password. Further information may be associated with requestor and decision maker accounts, such as, for example, registered devices and biometric indicators (e.g., fingerprints), to provide additional security and authentication methods.
  • the platform may then assign the requestor and decision maker each with a unique identifier (e.g., GL-XXXX). Account information may further include a role (e.g., decision maker or requestor).
  • the decision maker may then be associated with one or more requestors ('relationships').
  • Each user's account may further be associated with a financial institution.
  • the decision maker's account may be linked to a bank account, credit card account, funding account, etc.
  • the requestor's account may be associated with a financial institution through the decision maker's account.
  • the platform may receive log-in information from a user for a specific account, such as, for example, an Amazon account.
  • method 200B may proceed to proceed to stage 210 where platform 100 may receive a purchase request.
  • a requestor may request to purchase a pair of pants with the software application.
  • FIGs. 3A, 3B, 3C, 3D and 3E illustrate interfaces 300A, 300B, 300C, 300D, and
  • the platform may provide the requestor with a plurality of input prompts 310, to input purchase request information ('transactional information') such as, for example, but not limited to, price, merchant/store, geo-fence coordinates, transaction category, date/time limitations of purchase, a photo of the item(s) for purchase, to whom approval should be sent, and comments.
  • purchase request information e.g., price, merchant/store, geo-fence coordinates, transaction category, date/time limitations of purchase, a photo of the item(s) for purchase, to whom approval should be sent, and comments.
  • platform 100 may receive purchase request information by receiving a URL associated with the item(s)/online shopping cart for purchase and subsequently receiving information attached to the URL.
  • platform 100 may be integrated into an e-commerce website.
  • a requestor may submit a request for an item via a uniform resource locator (URL) linking to that item.
  • the URL may be copy-pasted by the requestor or automatically retrieved by a plug-in module that may be installed on the web-browser being used by the requestor.
  • a plug-in module may be installed on the web-browser being used by the requestor.
  • such URL may be associated with the e-commerce website integrated with platform 100.
  • the decision making party may access the URL to review the item.
  • platform 100 may cause a transaction to occur on the e-commerce website - either by integration on a back-end system or by front-end automated-form filing (e.g., via the web-browser plug-in).
  • the platform may enable the decision maker to provide approval via a link to an e-commerce platform as an alternative to approving an in-store point of sale approval.
  • embodiments of the present disclosure may enable requests for purchases to be sent from a physical location (e.g., in-store) while the approval from the decision maker may be limited to an e-commerce purchase.
  • the inverse may be possible in other embodiments of the present disclosure.
  • embodiments of the present disclosure are described from the context of a purchase made at a point of sale, it should be understood that embodiments may further be utilized in a similar fashion as a payment method for, for example, an e-commerce merchant.
  • the platform may enable the user to make the purchase request recurring, such as, for example, if the requestor desires to request a weekly grocery budget.
  • FIG. 4 illustrates an interface 400 showing recurring purchase requests 405, as well as relevant information pertaining to such recurring requests (e.g., percent of budget spent 410).
  • the platform may receive a finalization of the purchase request, for example by receiving a selection of the submit request button 315. Platform 100 may then display to the user any pending purchase requests.
  • FIG. 5 illustrates an interface 500 showing pending requests 505.
  • the platform may further receive, from the account associated with the requestor which was provided during initial account creation, requestor information, such as, for example, but not limited to, requestor name, address, email, date of birth, gender, and password.
  • requestor information such as, for example, but not limited to, requestor name, address, email, date of birth, gender, and password.
  • the platform may receive information associated with a decision maker, such as, for example, but not limited to, name, address, email, date of birth, gender, and password.
  • the platform may receive further information associated with the users, such as bank information and account information.
  • stage 210 where platform 100 receives purchase request information
  • method 200B may advance to stage 220 where platform 100 may send a notification to the decision maker and receive a decision.
  • the decision maker may receive a notification, for example, via the software application.
  • the decision maker may be the requestor.
  • FIG. 6 illustrates an interface 600 showing the notification.
  • the decision maker may receive purchase request information 605 corresponding to information received from the requestor's input prompts 310.
  • the decision maker may receive a selection of response options 610, such as, for example, accept, reject, call requestor, and message requestor.
  • the platform may further enable the user to edit the desired purchase request information.
  • the platform may enable the user to request to be notified at a later time.
  • FIG. 7 illustrates an interface 700 showing a rejection of a purchase request.
  • method 200B may notify the user and proceed to stage 230, where the platform may convert the purchase request details into approved parameters a card processing database can use.
  • FIG. 8 illustrates an interface 800 showing an approval of a purchase request.
  • method 200B may proceed to stage 240, where platform 100 may update a card processing database to reflect the transaction parameters.
  • method 200B may proceed to stage 250, where platform may attempt to systematically purchase the approved transaction via a payment device authentication system.
  • the payment device authentication system may include all facets of a standard electronic fund transfer ('EFT') authentication system such as a merchant bank, issuing bank, and any additional clearinghouse entities typically involved in the approval or disapproval of an EFT transaction.
  • 'EFT' electronic fund transfer
  • FIG. 1 the payment device authentication system is identified as Card Network and Merchant Bank.
  • the platform may send a push alert to approve the request.
  • the push alert may be sent, for example, via API, to the card processor.
  • a token may be passed from the merchant to the merchant bank in stage 260.
  • the merchant bank may then pass the token to the card network in stage 270.
  • the card network may pass the token to the card processor in stage 280 for additional approval.
  • platform 100 may proceed to stage 280, where platform 100 compares the transaction parameters to the purchase details approved by the decision maker. For example, the platform may receive transaction parameters (e.g., geo-location, price, store, and date and time of purchase) received from an e-commerce platform. Platform 100 may then compare the transaction parameters to the approved parameters. If the transaction parameters match the approved parameters, the platform may reject the purchase in stage 293b. Alternatively, if the transaction parameters match the approved parameters, the platform may systematically perform check out in stage 295. For example, the platform may log into the online merchant's webpage with the account information of the decision maker. Then, the platform may automatically fill in the necessary information (e.g., shipping location, payment information, etc.) The platform may then complete the checkout and submit the order.
  • transaction parameters e.g., geo-location, price, store, and date and time of purchase
  • the platform may then compare the transaction parameters to the approved parameters. If the transaction parameters match the approved parameters, the platform may reject the purchase in stage 293b. Alternatively, if the transaction
  • method 200B may proceed to 296, where platform 100 may display the completed purchase details to the users.
  • FIG. 9 illustrates an interface showing a successful transaction 900.
  • method 200B may then end.
  • FIG. 2C is a flow chart setting forth the general stages involved in a method 200C consistent with an embodiment of the disclosure for providing a payment approval platform 100.
  • Method 200 may be implemented using a computing device 1100 as described in more detail below with respect to FIG. 11.
  • computing device 1100 may be used to perform the various stages of the methods.
  • different operations may be performed by different networked elements in operative communication with computing device 1100.
  • server 110 may be employed in the performance of some or all of the stages in the methods.
  • server 110 may be configured much like computing device 1100.
  • stages illustrated by the flow charts are disclosed in a particular order, it should be understood that the order is disclosed for illustrative purposes only. Stages may be combined, separated, reordered, and various intermediary stages may exist. Accordingly, it should be understood that the various stages illustrated within the flow chart may be, in various embodiments, performed in arrangements that differ from the ones illustrated. Moreover, various stages may be added or removed from the flow charts without altering or deterring from the fundamental scope of the depicted methods and systems disclosed herein. Ways to implement the stages of the methods will be described in greater detail below.
  • Method 200C may begin starting block 205 where the platform may receive user account information.
  • the platform may receive user account information for a decision maker.
  • User account information may include, for example, but not be limited to, first and last name, address, phone number, email, date of birth, gender, and account password. Further information may be associated with the decision maker account, such as, for example, registered devices and biometric indicators (e.g., fingerprints), to provide additional security and authentication methods.
  • the platform may then assign the user account with a unique identifier (e.g., GL-XXXX). Account information may further include a role (e.g., decision maker or requestor).
  • the user's account may further be associated with a financial institution.
  • the user's account may be linked to a bank account, credit card account, funding account, etc.
  • the requestor's account may be associated with a financial institution through the decision maker's account.
  • the platform may receive log-in information from a user for a specific account, such as, for example, an Amazon account.
  • method 200C may proceed to stage 210, where platform 100 may receive a purchase request.
  • a purchase request For example, a single user may request to purchase a pair of pants with the software application.
  • FIGs. 3A, 3B, 3C, 3D and 3E illustrate interfaces 300A, 300B, 300C, 300D, and 300E, respectively, for receiving purchase request information.
  • the platform may provide the user with a plurality of input prompts 310, to input purchase request information ('transactional information') such as, for example, but not limited to, price, merchant/store, geo-fence coordinates, transaction category, date/time limitations of purchase, a photo of the item(s) for purchase.
  • purchase request information e.g., but not limited to, price, merchant/store, geo-fence coordinates, transaction category, date/time limitations of purchase, a photo of the item(s) for purchase.
  • the platform may enable the user to make the purchase request recurring, such as, for example, if the requestor desires to request a weekly grocery budget.
  • FIG. 4 illustrates an interface 400 showing recurring purchase requests 405, as well as relevant information pertaining to such recurring requests (e.g., percent of budget spent 410).
  • the platform may receive a finalization of the purchase request, for example by receiving a selection of the submit request button 315.
  • FIG. 8 illustrates an interface 800 showing an approval of a purchase request.
  • method 200C may proceed to stage 240, where platform 100 may update a card processing database to reflect the transaction parameters.
  • method 200C may proceed to stage 245, where platform 100 may notify the user of an approval to make the purchase. For example, the platform may send a pop-up notification to the user and/or provide a display of approved purchases.
  • method 200C may proceed to stage 250, where platform may attempt to systematically purchase the approved transaction via a payment device authentication system.
  • the payment device authentication system may include all facets of a standard electronic fund transfer ('EFT') authentication system such as a merchant bank, issuing bank, and any additional clearinghouse entities typically involved in the approval or disapproval of an EFT transaction.
  • the payment device authentication system is identified as Card Network and Merchant Network.
  • the platform may send a push alert to approve the request.
  • the push alert may be sent, for example, via API, to the card processor.
  • a token may be passed from the merchant to the merchant bank in stage 260.
  • the merchant bank may then pass the token to the card network in stage 270.
  • the card network may pass the token to the card processor in stage 280 for further approval.
  • platform 100 may proceed to stage 280, where platform 100 compares the transaction parameters to the purchase details approved by the decision maker. For example, the platform may receive transaction parameters (e.g., geo-location, price, store, and date and time of purchase) received from an e-commerce platform or at a point of sale when the requestor attempts to make the purchase. Platform 100 may then compare the transaction parameters to the approved parameters. If the transaction parameters match the approved parameters, the platform may complete the transaction and notify the merchant in stage 293a. Otherwise, the platform may reject the purchase in stage 293b.
  • transaction parameters e.g., geo-location, price, store, and date and time of purchase
  • method 200C may proceed to 296, where platform 100 may display the completed purchase details to the users.
  • FIG. 9 illustrates an interface showing a successful transaction 900.
  • the platform may further prompt the requestor to take a photo of a receipt for the successful transaction, for example, by providing a photo button 905.
  • platform 100 displays the completed purchasing details to the users and reminds the requestor to take a picture of the receipt in stage 296, method 200C may then end.
  • Embodiments of the present disclosure may enable a requestor to request permission to purchase an item via platform 100.
  • the request may include various parameters associated with the item. Such parameters may include card status, geo-fence coordinates, time frame for purchase, individual transaction amount, product code, etc.
  • This request for permission may be sent to a decision maker and the decision maker may approve or decline the request.
  • platform 100 may convert the request into parameters relating to the transaction and transmit this information to a card processor's database.
  • the card processor's database may be specific to the payment device such as, for example, a card issued by the provider of platform 100 (e.g. GreenLight credit card, GreenLight database), while in other embodiments other payment processors may be used. Accordingly, platform 100 may provide the card processor's database with specific transactional information. The requester may be notified that the transaction has been approved and that the payment device (e.g., an approved card or, for example, the platform provider's card) may be capable of being utilized for finalizing the transaction.
  • the payment device e.g., an approved card or, for example, the platform provider's card
  • the requester may then attempt to make the purchase in the store or online per the methods disclosed above.
  • the merchant may processes the payment device and the information may be submitted to the merchant bank for authentication.
  • processing may occur as follows.
  • the merchant bank may subsequently send the request for authentication to the card network.
  • the financial processing network may send the request to the card processor's database.
  • the card processor's database may compare the transaction parameters received from card network with the information previously authorized by the decision maker. If the parameters as compared match, the transaction may be approved. If the parameters as compared do not match, the transaction may be declined and the respective decision may be processed back to the merchant.
  • a payment device specific to the EFT approval interface may be utilized. When the payment device is utilized, a card processor's database may interface with an EFT approval interface for storing approval information.
  • a requestor such as, for example, a teenager, may utilize platform 100 to request to purchase a specific item such as a pair of skinny jeans which cost a certain amount as seventy five dollars, at a specific store as J Crew, at a specific location such as a certain mall as Lenox Mall in Atlanta Georgia, on a specific date as September 30, 2014, at a certain time as 2 P.M.
  • a specific item such as a pair of skinny jeans which cost a certain amount as seventy five dollars, at a specific store as J Crew, at a specific location such as a certain mall as Lenox Mall in Atlanta Georgia, on a specific date as September 30, 2014, at a certain time as 2 P.M.
  • a decision maker such as, for example, a parent, may receive the request via t platform 100 and approve or decline the request utilizing platform 100.
  • platform 100 may update the associated card processor's database associated with t platform 100 to reflect the specific approved parameters.
  • the parameters may include, for example, the dollar amount, the item being purchased, the store location, the time, and any combination of these data points related to the transaction.
  • the merchant may process the payment device and request authentication from the merchant bank.
  • the merchant bank may submit the authentication request to the payment device authentication system.
  • the payment device authentication system may submit the request to the associated card processor's database associated with platform 100.
  • the approval information contained in the database may be compared with the transactional information submitted by the payment device authentication system. If the information meets the approved criteria by matching certain parameters, the associated card processor's database may send an approval to the payment device authentication system. If the parameters do not match, then the transaction may not be approved. The decision may subsequently be returned to the merchant bank and merchant for further completion or declining the transaction.
  • the payment device used to complete a transaction may be turned “off, meaning that the card is deactivated and utilization of the card would automatically result in the payment device not processing, as it would be identified as inactive.
  • the payment device In order to turn the payment device "on” meaning that the payment device could be utilized for a sales transaction, the card must first be authorized for a particular transaction.
  • the payment device such as a platform card may be utilized for payment of a transaction.
  • a first person who is the approver or decision maker of the payment device, and who is typically the owner of the payment device, may submit approval information.
  • the approval information which contains information specifically related to the transaction t which subsequently submits the approval information to the payment device authentication system.
  • sale transactional information which includes information specifically related to the transaction, may be submitted to the merchant bank and the payment device authentication system for approval.
  • the transactional information may be compared to the approval information.
  • the information specifically related to the transaction of transactional information may be compared to the information specifically related to the approval information. If the comparison determines that the information components are matched, then the transaction may be approved.
  • the merchant may be on site or virtual (e-commerce).
  • the payment device may be turned “off such that the utilization of the payment device when "off will result in the transaction may be denied. Furthermore, when the device is turned “on” meaning that the payment device may be utilized for a fulfillment of tendering payment for completion of a transaction, the payment device may not successfully be utilized for tendering of payment unless the specific transaction associated with turning the payment device on is conducted. This may be ensured by associating specific transactional information with the turning "on" of the payment device and comparing this specific transactional information with the actual transaction conducted. Only then will the transaction be approved.
  • a unique payment device may be identified.
  • the payment device may be an EFT suitable device which has a first and second status.
  • the first status may be "off," wherein the card may be unable to be utilized for any transaction and may be denied authentication to be utilized as a medium for completing a sales transaction.
  • the card may have a second status wherein the card is "on" meaning that the card may be utilized as a medium for completing a sales transaction.
  • the card may be turned “on” by identifying associated parameters relating to a particular transaction. These associated parameters may be provided to an intermediary database associated with the issuer of the card. Subsequently, when the sales transaction is conducted, the associated parameters may be compared with the actual transaction and only then may the transaction be allowed. If the payment device is utilized for an unauthorized transaction, the payment device may have a third status wherein the card is "on" but unauthorized.
  • Embodiments of the present disclosure may be utilized in a virtual merchant environment wherein the merchant is utilized for completing an e-commerce transaction.
  • the requestor may accesses a virtual merchant for purchasing an item.
  • additional information may be provided to the decision maker via the online merchant. For instance, the requestor may forward a particular web address to the decision maker that may have a specific product and related URL such that a specific product may be purchased. The decision maker, in seeing the specific item, may approve the specific item by utilizing the URL information or product information.
  • the virtual merchant environment may present two distinctive purchasing scenarios.
  • the grantor may approve the transaction, and the requestor may communicate directly with the virtual merchant for purchasing the desired item. Alternatively, the grantor may access the website via the URL and directly purchase the item on behalf of the requestor.
  • the transaction may include the usage of a prepaid card.
  • the prepaid card may include a set amount that has previously been allocated for this card.
  • the respective available funds may be accessed for payment for the transaction.
  • the unique payment device may have a second or third factor authentication security system.
  • a first person identified as the requestor may access an application software program, which may be, for example, on a mobile device or computer. Access by the first person may be accomplished utilizing a first user identification parameter and a first user password.
  • the first user identification parameter and first user password may be unique to the first user defining a first factor of authentication. This first factor of authentication may be required to access the application software for defining a user request.
  • the second factor of authentication which may be required may include the "approver".
  • the approver may receive the request via the application software associated with his or her respective interface device which may be, for example, a computer, smartphone, tablet, iPad, or the like. Accessing the application software application via the respective interface device may require a second user identification parameter and a second user password. The second user identification parameter and the second user password singularly or combined may constitute the second factor of authentication.
  • the approver may receive a request for a purchase by the requestor via the application software, which may require the first and second factors of authentication.
  • the approver approves the requested purchase, the parameters related to the transaction may be uploaded via the application software to the card network.
  • the transactional parameters may be integrated into the card information stored in the card network. When the transaction is initiated at the merchant, the same transactional parameters may be forwarded to the card network for comparison with the transactional parameters previously submitted via the system upon the approval by the approver. This transactional parameter may present a third factor of authentication.
  • the electronic fund transfer system may utilize the standard for exchanging information relating to electronic transactions made by cardholders using payment cards.
  • ISO 8583 International Organization for Standardization for such systems may utilize ISO 8583 standards for electronic financial transactions utilizing payment cards.
  • an EFT system utilizing a card-based transaction may utilize a series of networks to a card issuing system for authentication against a card holder's account.
  • the transaction data may contain information derived from the card, such as, for example, the account number, the terminal, (e.g., the merchant number), the transaction (e.g., the amount), together with other data which may be typically generated throughout intervening systems in the network.
  • elements may be utilized for carrying out the financial transactions.
  • the data elements may be individual fields which carry the transactional information throughout the transaction and also with the issuing bank. There may be up to 128 data elements specified in the original 1987 ISO 8583 standard. Some modifications to the standard have been made, but a unified standard of the data elements may exist.
  • the application software may generate transactional information, which may be uploaded to the issuing bank database, which may contain the specific customer information relating to a card based transaction device.
  • the issuing bank database utilizing ISO 8583 may have standard information such as, for example, the primary account number, the transaction amount, the settlement amount, transmission date and time, merchant type, and other information as defined by the standard.
  • certain data fields of the issuing bank customer record may be updated to reflect transactional parameters unique to the desired transaction, which has been approved by the grantor and assumed to be carried out by the requestor.
  • Such transactional parameters which may be transmitted by the application software and related database to the issuing bank database may include, for example, a status field (e.g. turning the card On' or Off), a set dollar amount for the desired transaction, a max transaction amount, a geo fence approval which would identify a general location for the transaction to occur, a timeframe for the desired transaction, and a specific category for the transaction such as apparel, gas, food, etc.
  • FIG. 10 is a flow chart setting forth the general stages involved in a method 1000 consistent with an embodiment of the disclosure for providing a three-tier payment authorization method with platform 100.
  • Method 1000 may be implemented using a computing device 1100 as described in more detail below with respect to FIG. 11.
  • Method 1000 may begin at starting block 1005 and proceed to stage 1010, where platform 100 may receive a first authorization from a first user.
  • the first user may provide the first authorization by providing purchase request parameters.
  • the purchase request parameters may comprise, for example, but not limited to, a purchase description, an amount of funds, a store (or geo-fence location), a date of purchase, and a second user for a second authorization.
  • the first authorization parameters may be received, for example, from a requestor in stage 210 above.
  • the first user may additionally provide a payment method, such as, for example a payment card.
  • the payment card may be associated with card parameters (e.g., card number, expiration date, and card verification value (CVV)).
  • the first authorization may additionally include, the first user's access credentials, such as, for example, a first username and password, which may, in turn, be authenticated by the platform.
  • stage 1010 where platform 100 receives a first authorization from a first user
  • method 1000 may proceed to stage 1020 where platform 100 may receive a second authorization from a second user, such as, for example, a decision maker in stage 220 above.
  • the second user may provide authorization by approving the request, as well as providing additions or modifications to the purchase request.
  • the second authorization may further include, the second user's access credentials such as, for example a second username and password as provided by the second user, which may, in turn, be authenticated by the platform.
  • platform 100 may receive a third authorization, for example from a card processor, bank, or other financial institution.
  • platform 100 may receive approval if the card processor finds the card parameters to match (e.g., card number, expiration date, and card verification value (CVV)).
  • the card processor may further verify that sufficient funds are available in the user's account.
  • the platform may receive purchase parameters from a check out and compare the purchase parameters to the purchase request parameters.
  • the platform may provide authorization upon authentication of the card parameters, verification of fund sufficiency, and matching of purchase parameters and purchase request parameters (collectively, "payment details").
  • platform 100 may receive declined approval if the card processor finds inconsistent card parameters, insufficient funds available in the user's account, or the purchase parameters do not match the purchase request parameters.
  • method 1000 may proceed to stage 1040, where platform 100 may cause with the transaction. Upon causing the transaction in stage 1040, method 1000 may end at stage 1050.
  • the purchase approval platform 100 may be embodied as, for example, but not be limited to, a website, a web application, a desktop application, and a mobile application compatible with a computing device.
  • the computing device may comprise, but not be limited to, a desktop computer, laptop, a tablet, or mobile telecommunications device.
  • platform 100 may be hosted on a centralized server, such as, for example, a cloud computing service.
  • method 200 has been described to be performed by a computing device 1100, it should be understood that, in some embodiments, different operations may be performed by different networked elements in operative communication with computing device 1100.
  • Embodiments of the present disclosure may comprise a system having a memory storage and a processing unit.
  • the processing unit may be coupled to the memory storage, wherein the processing unit is configured to perform the stages of method 200.
  • FIG. 11 is a block diagram of a system including computing device 1100.
  • the aforementioned memory storage and processing unit may be implemented in a computing device, such as computing device 1100 of FIG. 11. Any suitable combination of hardware, software, or firmware may be used to implement the memory storage and processing unit.
  • the memory storage and processing unit may be implemented with computing device 1100 or any of other computing devices 1118, in combination with computing device 1100.
  • the aforementioned system, device, and processors are examples and other systems, devices, and processors may comprise the aforementioned memory storage and processing unit, consistent with embodiments of the disclosure.
  • a system consistent with an embodiment of the disclosure may include a computing device, such as computing device 1100.
  • computing device 1100 may include at least one processing unit 1102 and a system memory 1104.
  • system memory 1104 may comprise, but is not limited to, volatile (e.g. random access memory (RAM)), non-volatile (e.g. read-only memory (ROM)), flash memory, or any combination.
  • System memory 1104 may include operating system 1105, one or more programming modules 1106, and may include a program data 1107. Operating system 1105, for example, may be suitable for controlling computing device 1100's operation.
  • programming modules 1106 may include authentication modules, such as, for example software application 1120 referenced throughout the present disclosure as part of platform 100.
  • authentication modules such as, for example software application 1120 referenced throughout the present disclosure as part of platform 100.
  • embodiments of the disclosure may be practiced in conjunction with a graphics library, other operating systems, or any other application program and is not limited to any particular application or system. This basic configuration is illustrated in FIG. 11 by those components within a dashed line 1108.
  • Computing device 1100 may have additional features or functionality.
  • computing device 1 100 may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape.
  • additional storage is illustrated in FIG. 11 by a removable storage 1109 and a non-removable storage 1110.
  • Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data.
  • System memory 1104, removable storage 1109, and non- removable storage 1110 are all computer storage media examples (i.e., memory storage.)
  • Computer storage media may include, but is not limited to, RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store information and which can be accessed by computing device 1100. Any such computer storage media may be part of device 1100.
  • Computing device 1100 may also have input device(s) 1112 such as a keyboard, a mouse, a pen, a sound input device, a touch input device, etc.
  • Output device(s) 1114 such as a display, speakers, a printer, etc. may also be included. The aforementioned devices are examples and others may be used.
  • Computing device 1100 may also contain a communication connection 1116 that may allow device 1100 to communicate with other computing devices 1118, such as over a network in a distributed computing environment, for example, an intranet or the Internet.
  • a communication connection 1116 may allow device 1100 to communicate with other computing devices 1118, such as over a network in a distributed computing environment, for example, an intranet or the Internet.
  • Communication connection 1116 is one example of communication media.
  • Communication media may typically be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media.
  • modulated data signal may describe a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal.
  • communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.
  • RF radio frequency
  • computer readable media as used herein may include both storage media and communication media.
  • program modules 1106 may perform processes including, for example, one or more of the methods' stages as described above.
  • processing unit 1102 may perform other processes.
  • Other programming modules that may be used in accordance with embodiments of the present disclosure may include electronic mail and contacts applications, word processing applications, spreadsheet applications, database applications, slide presentation applications, drawing or computer-aided application programs, etc.
  • program modules may include routines, programs, components, data structures, and other types of structures that may perform particular tasks or that may implement particular abstract data types.
  • embodiments of the disclosure may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like.
  • Embodiments of the disclosure may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
  • program modules may be located in both local and remote memory storage devices.
  • embodiments of the disclosure may be practiced in an electrical circuit comprising discrete electronic elements, packaged or integrated electronic chips containing logic gates, a circuit utilizing a microprocessor, or on a single chip containing electronic elements or microprocessors.
  • Embodiments of the disclosure may also be practiced using other technologies capable of performing logical operations such as, for example, AND, OR, and NOT, including but not limited to mechanical, optical, fluidic, and quantum technologies.
  • embodiments of the disclosure may be practiced within a general purpose computer or in any other circuits or systems.
  • Embodiments of the disclosure for example, may be implemented as a computer process (method), a computing system, or as an article of manufacture, such as a computer program product or computer readable media.
  • the computer program product may be a computer storage media readable by a computer system and encoding a computer program of instructions for executing a computer process.
  • the computer program product may also be a propagated signal on a carrier readable by a computing system and encoding a computer program of instructions for executing a computer process.
  • the present disclosure may be embodied in hardware and/or in software (including firmware, resident software, micro-code, etc.).
  • embodiments of the present disclosure may take the form of a computer program product on a computer-usable or computer-readable storage medium having computer-usable or computer-readable program code embodied in the medium for use by or in connection with an instruction execution system.
  • a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
  • the computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific computer-readable medium examples (a non-exhaustive list), the computer-readable medium may include the following: an electrical connection having one or more wires, a portable computer diskette, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, and a portable compact disc read-only memory (CD-ROM).
  • RAM random access memory
  • ROM read-only memory
  • EPROM or Flash memory erasable programmable read-only memory
  • CD-ROM portable compact disc read-only memory
  • the computer-usable or computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.
  • Embodiments of the present disclosure are described above with reference to block diagrams and/or operational illustrations of methods, systems, and computer program products according to embodiments of the disclosure.
  • the functions/acts noted in the blocks may occur out of the order as shown in any flowchart.
  • two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne une plateforme d'approbation d'achat. Des modes de réalisation de l'invention peuvent consister à recevoir, d'un demandeur, une demande d'achat comprenant des détails de demande. La demande d'achat peut ensuite être fournie au preneur de décision. Le preneur de décision peut être autorisé à approuver ou refuser une approbation de la demande d'achat du preneur de décision. Lors de la réception d'une approbation, la plateforme peut recevoir des détails d'encaissement associés à la demande d'achat. La plateforme peut comparer les détails d'encaissement aux détails de la demande. Si les détails d'encaissement correspondent aux détails de la demande, la plateforme peut autoriser une exécution d'une transaction associée à la demande d'achat. D'autres modes de réalisation de l'invention peuvent générer une demande d'achat à partir des détails d'achat fournis par un demandeur et peuvent communiquer ensuite la demande d'achat à un preneur de décision et permettre au preneur de décision de sélectionner une décision d'approuver ou de refuser la demande. Des modes de réalisation optionnels peuvent concerner une plateforme permettant de fournir une autorisation à trois niveaux, la plateforme pouvant fournir un premier niveau d'authentification, recevoir les justificatifs d'accès d'un preneur de décision et fournir une seconde authentification en recevant une approbation de la demande d'achat et en authentifiant les justificatifs d'accès du preneur de décision. La plateforme peut également recevoir des détails de paiement et authentifier les détails de paiement afin d'autoriser le paiement, ce qui permet de fournir une troisième autorisation. De plus, l'invention peut concerner une plateforme permettant d'approuver des achats dans une plateforme de commerce électronique.
PCT/US2016/046233 2015-08-10 2016-08-10 Plateforme d'approbation de paiement WO2017027533A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CA2995415A CA2995415A1 (fr) 2015-08-10 2016-08-10 Plateforme d'approbation de paiement
EP16835797.8A EP3335171A4 (fr) 2015-08-10 2016-08-10 Plateforme d'approbation de paiement
HK18116338.7A HK1257090A1 (zh) 2015-08-10 2018-12-20 支付批准平台

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US14/822,567 US20170046697A1 (en) 2015-08-10 2015-08-10 Payment Approval Platform
US14/822,548 2015-08-10
US14/822,548 US20170046716A1 (en) 2015-08-10 2015-08-10 Payment Approval Platform
US14/822,593 US20170046758A1 (en) 2015-08-10 2015-08-10 Payment Approval Platform
US14/822,526 2015-08-10
US14/822,593 2015-08-10
US14/822,526 US10803428B2 (en) 2015-08-10 2015-08-10 Method, non-transitory computer-readable medium, and system for payment approval
US14/822,567 2015-08-10

Publications (1)

Publication Number Publication Date
WO2017027533A1 true WO2017027533A1 (fr) 2017-02-16

Family

ID=57983838

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2016/046233 WO2017027533A1 (fr) 2015-08-10 2016-08-10 Plateforme d'approbation de paiement

Country Status (4)

Country Link
EP (1) EP3335171A4 (fr)
CA (1) CA2995415A1 (fr)
HK (1) HK1257090A1 (fr)
WO (1) WO2017027533A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020208262A1 (fr) 2019-04-11 2020-10-15 Xaalys Sas Contrôle parental mis en œuvre dans un systeme de traitement d'une transaction associee a une carte de paiement detenue par un utilisateur assujetti a un decideur

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060116957A1 (en) * 2000-03-17 2006-06-01 Jason May Method and apparatus for facilitating online payment transactions in a network-based transaction facility
US20060167756A1 (en) * 2005-01-21 2006-07-27 Ebay Inc. Network-based commerce facility offer management methods and systems
US20090119241A1 (en) * 2007-11-02 2009-05-07 Axel Fano Methods and systems for a decision client
US20100017302A1 (en) * 2008-07-21 2010-01-21 German Scipioni Systems and methods for making payments from selected funding sources
US20120150736A1 (en) * 2010-12-14 2012-06-14 Fiserv, Inc. Personal budget tool
US20140188715A1 (en) * 2012-12-31 2014-07-03 Fiserv, Inc. Systems and methods for bill payment with image capture of bill information and funding account
US20140244493A1 (en) * 2013-02-27 2014-08-28 Fiserv, Inc. Systems and methods for electronic payment instrument repository
US20140279459A1 (en) * 2013-03-15 2014-09-18 Fiserv, Inc. Electronic bill payment processing based on payor scheduled debits
US20150100500A1 (en) * 2013-10-08 2015-04-09 Srinivasa Pasupulati Best offer immediate pay feature

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8014756B1 (en) * 2007-02-28 2011-09-06 Intuit Inc. Mobile authorization service
US20090125440A1 (en) * 2007-11-13 2009-05-14 Mr. Joon Maeng Method and system for approving credit card transactions
US8700524B2 (en) * 2011-01-04 2014-04-15 Boku, Inc. Systems and methods to restrict payment transactions
US20120278202A1 (en) * 2011-04-26 2012-11-01 Virtual Piggy, Inc. Virtual piggybank having quick connect

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060116957A1 (en) * 2000-03-17 2006-06-01 Jason May Method and apparatus for facilitating online payment transactions in a network-based transaction facility
US20060167756A1 (en) * 2005-01-21 2006-07-27 Ebay Inc. Network-based commerce facility offer management methods and systems
US20090119241A1 (en) * 2007-11-02 2009-05-07 Axel Fano Methods and systems for a decision client
US20100017302A1 (en) * 2008-07-21 2010-01-21 German Scipioni Systems and methods for making payments from selected funding sources
US20120150736A1 (en) * 2010-12-14 2012-06-14 Fiserv, Inc. Personal budget tool
US20140188715A1 (en) * 2012-12-31 2014-07-03 Fiserv, Inc. Systems and methods for bill payment with image capture of bill information and funding account
US20140244493A1 (en) * 2013-02-27 2014-08-28 Fiserv, Inc. Systems and methods for electronic payment instrument repository
US20140279459A1 (en) * 2013-03-15 2014-09-18 Fiserv, Inc. Electronic bill payment processing based on payor scheduled debits
US20150100500A1 (en) * 2013-10-08 2015-04-09 Srinivasa Pasupulati Best offer immediate pay feature

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3335171A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020208262A1 (fr) 2019-04-11 2020-10-15 Xaalys Sas Contrôle parental mis en œuvre dans un systeme de traitement d'une transaction associee a une carte de paiement detenue par un utilisateur assujetti a un decideur
FR3095066A1 (fr) 2019-04-11 2020-10-16 Xaalys Contrôle parental mis en œuvre dans un système de traitement d’une transaction associée à une carte de paiement détenue par un utilisateur assujetti à un décideur

Also Published As

Publication number Publication date
HK1257090A1 (zh) 2019-10-11
EP3335171A1 (fr) 2018-06-20
CA2995415A1 (fr) 2017-02-16
EP3335171A4 (fr) 2019-04-10

Similar Documents

Publication Publication Date Title
US11379818B2 (en) Systems and methods for payment management for supporting mobile payments
US20170046758A1 (en) Payment Approval Platform
US10748147B2 (en) Adaptive authentication options
US10803428B2 (en) Method, non-transitory computer-readable medium, and system for payment approval
US20190197527A1 (en) Method and system for facilitating digital wallet based payment card transactions
US11080678B2 (en) Payment processing platform
US20120166334A1 (en) Methods and systems for identity based transactions
US20110006113A1 (en) Authorization verification system
US20240296450A1 (en) Systems and methods for intelligent step-up for access control systems
US20170300894A1 (en) System and method for providing reports on usage of payment token
US11853441B2 (en) Untethered resource distribution and management
US20210248600A1 (en) System and method to secure payment transactions
CN108292376B (zh) 利用钱包交易认证历史来进行交叉卡认证的方法和装置
US20170300907A1 (en) System and method for providing token based employee corporate cards
US20180130060A1 (en) Providing payment credentials securely for telephone order transactions
US20170046697A1 (en) Payment Approval Platform
US10762522B2 (en) Loyalty program enrollment facilitation
US20160140557A1 (en) E-commerce based payment system with authentication of electronic invoices
US20170046716A1 (en) Payment Approval Platform
EP3182360A1 (fr) Système et procédé d'ajout d'un code de sécurité dynamique d'achats à distance
US11580543B2 (en) Methods, systems and computer program products for implementing pre-authorized payment transactions
US20190197555A1 (en) Method and system for facilitating payments for items delivered at delivery locations
US20200258078A1 (en) Systems, methods and computer program products for wallet payment transactions
US20200265414A1 (en) Methods, systems and computer program products for split payment card account transactions
EP3335171A1 (fr) Plateforme d'approbation de paiement

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16835797

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2995415

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2016835797

Country of ref document: EP