US20150348010A1 - Switch server system interoperable with mobile devices providing secure communications - Google Patents
Switch server system interoperable with mobile devices providing secure communications Download PDFInfo
- Publication number
- US20150348010A1 US20150348010A1 US14/723,316 US201514723316A US2015348010A1 US 20150348010 A1 US20150348010 A1 US 20150348010A1 US 201514723316 A US201514723316 A US 201514723316A US 2015348010 A1 US2015348010 A1 US 2015348010A1
- Authority
- US
- United States
- Prior art keywords
- merchant
- encrypted
- payment
- consumer
- communicating
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/401—Transaction verification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
- G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
-
- 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
- G06Q20/027—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
- G06Q20/202—Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/327—Short range or proximity payments by means of M-devices
- G06Q20/3278—RFID or NFC payments by means of M-devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
- G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/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
- G06Q2220/00—Business processing using cryptography
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
Definitions
- the present invention relates to payments.
- the present technology provides a switch server system interoperable with mobile devices for providing secure communications.
- Some embodiments of the present technology include a computer-implemented method for conducting a secure transaction over a network using one or more gateway servers.
- Embodiments of the method include receiving a request from a consumer, sending the request to a merchant, and receiving, from the merchant, a payment order associated with the request. The payment order is received via a merchant programmable user interface.
- Embodiments of the method also include confirming the payment order to transform the payment order to a confirmed payment order, sending the confirmed payment order to a user, and receiving, from the user, a payment authorization associated with the confirmed payment order, and the payment authorization is received via a consumer programmable user interface.
- the payment authorization from the user includes a secure, encrypted, Internet Protocol (IP) message using encryption hashed with public and private key management.
- IP Internet Protocol
- Embodiments of the method also include performing a transaction in accordance with the payment authorization.
- Various embodiments of the method include sending a registration message to the merchant, receiving, from the merchant, identifying information associated with the merchant in response to the registration message, and validating the identifying information.
- Embodiments of the method also include sending a validation message associated with the validating of the identifying information to a payment service provider (PSP).
- PSP payment service provider
- Some embodiments of the present technology include performing of the transaction in accordance with the payment authorization being associated the PSP, the PSP being at least one of: an internal consumer wallet account, a direct bank transfer account, and a third-party PSP.
- Various embodiments of the present technology include the PSP being an internal consumer wallet account.
- Some embodiments of the present technology include performing of the transaction being in accordance with the payment authorization, using a secure internal switch, and being associated with the internal consumer wallet account.
- the internal consumer wallet account being associated with an account of the user.
- the account of the user being at least one of: a credit account, a debit account, a savings account, a loyalty account, and a virtual currency account.
- Various embodiments of the present technology include sending, to the consumer, the merchant, and the user one or more payment confirmations associated with the performing of the transaction in accordance with the payment authorization.
- Some embodiments of the present technology include the merchant programmable user interface being coupled with a mobile Points Of Sale (mPOS) terminal, the merchant programmable user interface configured to perform at least one of: registering the terminal, managing the terminal, and authorizing a payment from the PSP to the merchant.
- Embodiments of the method include the merchant programmable user interface also configured to perform at least one of: preauthorizing the payment from the PSP, voiding the payment from the PSP, refunding the payment from the PSP, and settling the payment from the PSP.
- Various embodiments of the present technology include the merchant programmable user interface being configured to perform at least one of: managing a profile of the merchant, managing a definition of a product, managing an inventory of the product, managing a location of the product, managing agents of the merchant; and contacting a support system about the merchant.
- Some embodiments of the present technology include the merchant programmable user interface being configured to perform at least one of: communicating with a product catalog of the merchant, communicating with an inventory system of the merchant, communicating with a product information management system of the merchant, and updating inventory of the merchant based on the request.
- Various embodiments of the present technology include the merchant programmable user interface being configured to perform at least one of: communicating with a third-party product catalog, communicating with a third-party inventory system, and communicating with a third-party product information management system.
- FIG. 1 is a simplified block diagram of a system according to exemplary embodiments of the present technology
- FIG. 2 is a simplified block diagram of a system according to exemplary embodiments of the present technology
- FIG. 3A is a flow diagram illustrating an example method according to exemplary embodiments of the present technology
- FIG. 3B is a flow diagram illustrating an exemplary method according embodiments of the present technology
- FIG. 4 is a flow diagram showing a further example according to exemplary embodiments of the present technology.
- FIG. 5 illustrates a computer system according to exemplary embodiments of the present technology.
- Embodiments of the present technology provide a convenient, secure, cost-effective, and unified payment solution.
- the solution is designed to reduce the cost traditionally incurred by merchants, facilitate easier and faster consumer acquisition by dynamically extending the payment options to consumers and merchants.
- Payit Orders work for both card-present and card-not-present scenarios.
- the solution allows to extend the payment options available to the consumer and to dynamically transform the payment scenario from a card-present to a card-not-present scenario and vise-versa.
- a Payit Order is a signed and encrypted cryptographic payment order payload that is typically sent securely from the merchant mobile application to the Consumer mobile application through the Payit Cloud Platform (namely, Payit Gateway).
- Merchants' identities are initially verified through a Know-your-customer (KYC) process, which consequently allows their orders to be signed with (their private keys) and encrypted.
- KYC Know-your-customer
- a Consumer goes through a verification process, after which his/her e-Wallet becomes associated with the mobile device (e.g. EMEI and Phone Number). This allows consumer requests (e.g. order acceptance request) to be signed and sent securely.
- Payit Orders supports multiple use cases, including electronic payments for m-commerce transactions, money transfers, and electronic payments from 3rd-party e-commerce applications (via Payit Checkout). In this manner, the system provides a unique alternative to in-store card-present payments.
- the following points describe the sale process.
- the merchant keys in the required amount and the account Id of the consumer (e.g. phone number) into the Payit merchant app, which in turn, creates a Payit order cryptogram using the merchants private key.
- the cryptogram is then submitted to Payit Gateway (the Payit Cloud Platform).
- Payit Gateway decrypts the cryptogram and validates the merchant.
- Payit Gateway pushes a signed order to the consumer's mobile application, which decrypts the order, and prompts the consumer to accept it.
- the consumer selects the payment method he/she wants to use for payment (by default, Payit Coins (Wallet)).
- a signed request is sent from the consumer application to the Payit Gateway, which in turn, validates the request and forwards it to Payit Switch for processing.
- the payment order is processed by Payit switch; i.e. the consumer wallet is debited, and the merchant wallet is credited in one atomic transaction.
- the result is returned to Payit Gateway.
- Payit Gateway sends a “successful payment” confirmation to the consumer, and sends a “successful payment” confirmation to the merchant.
- the merchant can then submit an invoice to Payit at any later stage.
- Payit Orders can be passed through different merchant channels, be accessed through different consumer channels, and eventually be routed to different payment channels. In other words, it extends the number of payment methods available to the consumer, and transforms the payment scenario from card-present to card-not-present and vise versa.
- the following illustrates the various channels. Payit orders may be submitted to Payit Gateway from a Payit Merchant mobile application, from a 3rd-party e-Commerce Site through Payit Checkout, or from a 3rd-party service provider app through APIs.
- Merchants go through an acquiring and KYC process, and consumers go through a verification process after which their unique identifications (mobiles number, email or ID) are associated to their accounts.
- Both parties become known to Payit, which allows the Payit Gateway to facilitate the entire payment process in a closed loop manner, without depending on other parties (banks, schemes, etc).
- the solution enables a relatively fast and easy consumer acquisition.
- the payment order flow is different from other solutions.
- the Payit order cryptogram is initiated by merchant and flows to the consumer, who in turn, decides to pay using the payment methods available to him. In other words, the consumer is in control of the payment process, and the consumer doesn't need to share any payment choice with merchant.
- the solution does not require sophisticated consumer devices (e.g.
- Payit Orders can be initiated and submitted through different channels; e.g. merchant mobile app, 3rd-party e-Commerce sites (via Payit Checkout), and through other API-integrated systems. Payit Orders can be processed in different ways; using smart phones, basic phones, and through Payit dealers (in which case, they can pay for an item or service, even if they don't have their mobile device with them).
- the present technology extends a payment solution to cover whole consumer segment levels, from banked to unbanked, from smartphones to feature phones and even to non-mobile subscribers. All parties can buy and shop within Payment Order cryptography-IP.
- the present technology specializes in a number of diverse business domains, including Value Added Services (VAS), Mobile Money, Mobile payment, Money Transfer, Mobile banking, Mobile health care, retail, VOIP, m-Commerce; and works with different stakeholders, including banks, payment service providers, telcos, service providers, retailer, etc.
- VAS Value Added Services
- Mobile Money Mobile payment
- Money Transfer Mobile banking
- Mobile health care retail
- VOIP VOIP
- m-Commerce m-Commerce
- a computer-implemented method for conducting a secure transaction over a network using one or more gateway servers includes generating, with a processor, the payment order by encoding changes to the values of the request from the consumer, storing the payment order in a first memory location, receiving the payment authorization and storing the payment authorization in a second memory location, comparing, with a processor, the payment authorization with the payment order, and converting the payment authorization into a secure transaction authorization.
- the present technology provides a mobile application that may be downloaded to a mobile device.
- a user e.g. consumer or merchant registers with a central system to activate an account.
- the user may then fund the account from one or more sources, for instance a credit account, a debit account (also referred to as a checking account), a savings account, loyalty accounts, a virtual currency or any other appropriate currency account.
- the user may link the one or more accounts and may institute an automatic replenishment (also referred to as a top-off) order.
- the authentication process may include associating a mobile number, user name, email, account information, and any other identifying information.
- a password may be provided or selected, and an activation code may be sent via Short Message System (SMS) text message to the mobile device to ensure correct association.
- SMS Short Message System
- the user e.g. consumer or merchant then chooses to pay a bill using the mobile application.
- a user may indicate to a merchant a desire to pay a bill with the present application (also referred to as “Payit” or the “Payit application”), and may identify themselves to the merchant using their mobile phone number.
- the merchant may have the Payit application downloaded to a mobile device, at a cash register, on a tablet, or may quickly download the Payit application to any of these devices, or any other appropriate device.
- the merchant may send a secure, encrypted Internet Protocol (IP) message to the user based on the Payit identifier of the user.
- IP Internet Protocol
- the secure, encrypted IP message may be hashed using a public and private key management system to ensure utmost security and privacy.
- the encrypted IP message includes a payment order.
- the user then opens the Payit application, sees the payment order in a list of payment orders, and authorizes the payment.
- the authorization may be a secure, encrypted IP message sent to the merchant and indicates payment.
- the merchant and consumer have records in their respective accounts in the Payit application of all payment orders, both received and unpaid, and paid. Alternatively, the user may choose to reject or not pay any payment order, thus ensuring user confidence in the Payit application.
- the user chooses to pay monthly or other periodic bills using the Payit application.
- the user may consolidate all billing in a central location and may reduce transaction costs and bookkeeping obligations.
- the user may also choose to share certain information from the Payit application to other contacts, either from the Payit application or from another address book application, or via a social media application.
- the user uses the Payit application to shop for goods and services by searching for an item or a merchant in the Payit application, and selecting goods or services for purchase.
- the merchant may receive the order from the user in the Payit application, and then may send a secure, encrypted IP message to the user via the Payit application including a payment order.
- the user may receive the payment order and authorize it, causing the Payit application to send a secure, encrypted IP message to the merchant.
- the merchant then fulfills the order.
- merchants use the Payit application to receive payments from a consumer, make payments to suppliers, and maintain inventory.
- Merchants may link inventory and orders from suppliers so that when inventory drops below a predetermined, selectable threshold, a new order to a supplier is made, and payment may be made.
- the system may operate in a cloud-based computer environment or, alternatively, may operate as a secure server. All communications to and from mobile devices and other mobile applications may be encrypted and decrypted for security purposes.
- the Payit application may be a mobile application, and/or may be used on a laptop, smartphone or PDA, wearable device, and may be downloadable or web-based.
- the system may be implemented in software and/or hardware.
- a mobile application may be provided that enables a user to access a web-based version of the system from a mobile device.
- FIG. 1 is a simplified block diagram of a system 100 according to exemplary embodiments of the present technology.
- the architecture comprises a server system that is configured to provide various functionalities, which are described in greater detail throughout this document.
- the system 100 is configured to communicate with client devices.
- Client devices may include, for example, a Smartphone, a laptop, a computer, or other similar computing device.
- An example of a computing device that can be utilized in accordance with the present technology is described in greater detail with respect to FIG. 5 .
- the system 100 may communicatively couple with clients via a public or private network.
- Suitable networks may include or interface with any one or more of, for instance, a local intranet, a PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network), a MAN (Metropolitan Area Network), a virtual private network (VPN), a storage area network (SAN), a frame relay connection, an Advanced Intelligent Network (AIN) connection, a synchronous optical network (SONET) connection, a digital T1, T3, E1 or E3 line, Digital Data Service (DDS) connection, DSL (Digital Subscriber Line) connection, an Ethernet connection, an ISDN (Integrated Services Digital Network) line, a dial-up port such as a V.90, V.34 or V.34bis analog modem connection, a cable modem, an ATM (Asynchronous Transfer Mode) connection, or an FDDI (Fiber Distributed Data Interface) or CDDI (Copper Distributed Data Interface) connection, and the like.
- communications may also include links to any of a variety of wireless networks, including WAP (Wireless Application Protocol), GPRS (General Packet Radio Service), GSM (Global System for Mobile Communication), CDMA (Code Division Multiple Access) or TDMA (Time Division Multiple Access), cellular phone networks, GPS (Global Positioning System), CDPD (cellular digital packet data), RIM (Research in Motion, Limited) duplex paging network, Bluetooth radio, or an IEEE 802.11-based radio frequency network, and the like.
- WAP Wireless Application Protocol
- GPRS General Packet Radio Service
- GSM Global System for Mobile Communication
- CDMA Code Division Multiple Access
- TDMA Time Division Multiple Access
- cellular phone networks GPS (Global Positioning System)
- CDPD cellular digital packet data
- RIM Research in Motion, Limited
- Bluetooth radio or an IEEE 802.11-based radio frequency network, and the like.
- a network can further include or interface with any one or more of an RS-232 serial connection, an IEEE-1394 (Firewire) connection, a Fiber Channel connection, an IrDA (infrared) port, a SCSI (Small Computer Systems Interface) connection, a USB (Universal Serial Bus) connection or other wired or wireless, digital or analog interface or connection, mesh or Digi® networking, and the like.
- an RS-232 serial connection an IEEE-1394 (Firewire) connection, a Fiber Channel connection, an IrDA (infrared) port, a SCSI (Small Computer Systems Interface) connection, a USB (Universal Serial Bus) connection or other wired or wireless, digital or analog interface or connection, mesh or Digi® networking, and the like.
- the system 100 in FIG. 1 generally comprises consumer application 110 , merchant application 120 , dealer application 130 and checkout application 140 .
- the system 100 further includes application programming interface(s) 150 , public application programming interface(s) 160 , gateway server(s) 170 , and switch 180 .
- Application programming interface(s) 150 , gateway server(s) 170 , and switch 180 form sub-system 105 , which may also be referred to as the internal Payit system.
- Consumer application 110 , merchant application 120 , dealer application 130 and checkout application 140 may communicate bilaterally with gateway server(s) 170 via application programming interface(s) 150 .
- System 100 also includes payment service providers (PSPs) 192 1 - 192 x and consumer service providers (CSPs) 194 1 - 194 y .
- PSPs payment service providers
- CSPs consumer service providers
- Payment service providers (PSPs) 192 1 - 192 x may communicate bilaterally with gateway server(s) 170 via switch 180 .
- Consumer service providers (CSPs) 194 1 - 194 y may bilaterally communicate directly with gateway server(s) 170 .
- Consumer service providers (CSPs) 194 1 - 194 y may include the merchant, service providers operating on behalf of the merchant, and/or third party retailers working in partnership with, or appearing in a catalog of, the merchant.
- FIG. 2 is a simplified block diagram of a system 200 according to exemplary embodiments of the present technology.
- the system 200 in FIG. 2 includes the consumer application 110 , the merchant application 120 , mobile Point of Sale (mPOS) terminal 210 , the checkout application 140 , and third-party merchant application(s) 220 .
- the system 200 further includes the gateway server(s) 170 with global server 230 and point of sale server 240 .
- the system 200 also includes the consumer service providers (CSPs) 194 1 - 194 y , the switch 180 , the payment service providers (PSPs) 192 1 - 192 x , and internal consumer wallet account 250 .
- the internal consumer wallet account 250 may be an account of the consumer or an account of the user (e.g. a third-party).
- the switch 180 adds additional security to messages sent within the system 100 and system 200 by signing, authenticating, and applying business rules to the messages during the routing process. For example, a MyOrders cryptographic message is signed with a public and a private key. In addition to hashing, Secure Socket Layer (SSL) encryption and key store exchange occurs between systems within a merchant and consumer data flow.
- SSL Secure Socket Layer
- the switch 180 maintains extra signing and login/handshake authentication that may involve account parameters for achieving a purchase transaction. For instance, when a merchant pushes an order through the gateway server(s) 170 , the switch 180 routes the order to a consumer system by applying business rules linked to the order itself.
- the switch 180 routes the order to a consumer system by applying business rules linked to the order itself, whether the order is within a Payit Network, to a third-party system, and/or issued by a third-party party merchant.
- the switch 180 applies signing, authentication, and business rules to orders during the routing process, which is managed via a fraud control policy, risk management, and end-to-end business rules.
- a normal switch has known standards and authentication that can be compromised when an IP packet data is transported from one system to another.
- a closed loop transaction operates within a Payit network with a set of cryptography parameters that are shared between modules, making every purchase and payment operate seamlessly within the data flow.
- IP packets receive extra parameters to ensure that the outside system is authorized to communicate with the Payit network through the switch 180 . For example, signing with keys, authentication, and application of business rules, are all maintained and enforced by the switch for each IP cryptography packet to ensure that a transaction is genuine before processing it with the Payit network (e.g. system 100 or system 200 ).
- FIG. 3A is a flow diagram illustrating an example method according to exemplary embodiments of the present technology. Optional steps are shown with dashed lines.
- FIG. 3A illustrates a method 300 for conducting a secure transaction over a network.
- method 300 is performed by a computing system, as described in relation to FIG. 5 .
- a request from a consumer is received.
- the request to a merchant is sent.
- a payment order associated with the request is received from the merchant.
- the payment is confirmed in order to transform the payment order to a confirmed payment order.
- the confirmed payment order to the consumer is sent to a user.
- the user may be the consumer or a third-party user.
- a payment authorization associated with the confirmed payment order is received from the user.
- a financial transaction in accordance with the payment authorization is performed.
- a confirmation is sent to the merchant.
- the confirmation is a confirmation of payment and once the merchant receives the confirmation of payment from the consumer, the merchant delivers the item and/or performs the requested service. Then the merchant issues a receipt to the consumer.
- the method 300 illustrated in FIG. 3A may also be adapted to the case of sending money securely.
- a user can initiate the transaction by inputting a merchant identifier into the consumer application, and sending a payment request to the system. In this manner, a user may send a payment to a friend or relative via the merchant.
- a shopping cart may enable direct shopping by the consumer, and also enable a merchant to maintain stock inventory.
- FIG. 3B is a flow diagram illustrating an exemplary method according embodiments of the present technology.
- FIG. 3B illustrates a method 305 that comprises additional steps that may be performed for conducting a secure transaction over a network.
- method 305 is performed by a computing system, as described in relation to FIG. 5 .
- a registration message is sent to the merchant.
- identifying information associated with the merchant in response to the registration message is received from the merchant.
- the identifying information is validated.
- a validation message associated with the validating of the identifying information is sent to a payment service provider (PSP).
- PSP payment service provider
- FIG. 4 is a flow diagram showing a further example method according to exemplary embodiments of the present technology, and in particular shows greater detail related to steps 360 and 370 shown in FIG. 3B .
- FIG. 4 illustrates a method 400 for performing a transaction in accordance with the payment authorization.
- FIG. 4 illustrates an algorithm of a means for performing a transaction in accordance with the payment authorization.
- method 400 is performed by a computing system, as described in relation to FIG. 5 .
- a payment authorization associated with the confirmed payment order is received from the consumer.
- a decision is made whether a validation message associated with the validating of the identifying information has been sent to a PSP.
- a registration message is sent to the merchant. If yes, at step 430 , a decision is made whether a payment authorization associated with the confirmed payment order has been received from the consumer. If no, at step 440 , the confirmed payment order is sent to the consumer. If yes, at step 450 , a decision is made whether an internal consumer wallet account is activated. If no, at step 460 , an alternative PSP is activated. If yes, at step 370 , a financial transaction in accordance with the payment authorization is performed. Step 370 , a financial transaction in accordance with the payment authorization is performed may also be performed after step 460 .
- the functionalities described herein, which are attributed to the system 100 may also be executed within a client. That is, a client may be programmed to execute the functionalities described herein. In other instances, the system 100 , and a client may cooperate to provide the functionalities described herein, such that a client is provided with a client-side application that interacts with the system 100 such that the system 100 and a client operate in a client/server relationship.
- Complex computational features may be executed by the gateway server(s) 170 , while simple operations that require fewer computational resources may be executed by a client, such as data gathering and data display.
- a user interface module may be executed by the system 100 to provide various programmable user interfaces such as a graphical user interfaces (GUIs) that allow users (e.g. merchants and consumers) to interact with the system 100 .
- GUIs graphical user interfaces
- GUIs are generated by execution of an application itself. Users may interact with the system 100 using, for example, a client.
- the system 100 may generate web-based interfaces for a client.
- the system 100 is generally referred to herein as “Payit system” and/or “Payit services”
- the present technology is a system delivery specification.
- Exemplary mobile payment systems and applications for consumers and merchants are described below.
- Exemplary GUIs include the Payit Home Screen comprising the following main icons: MyPayit, Services, Loyalty Cards, Merchants, We Listen, Language Switcher, Quick Help Tour, and countries.
- the MyPayit icon includes MyOrders.
- MyOrders is part of MyPayit that allows users (e.g. merchants and consumers) to: activate their account, view their account balance, add funds from different sources to their account, and instantly make transactions with Payit services rather than filling out debit/credit card details for every transaction.
- a consumer may make a request for product or a service from a merchant.
- the merchant sends the consumer a purchase order for each request.
- the purchase order may be an invoice, bill of sale, account statement, and the like.
- MyOrders is incoming purchase orders from different merchants in response to requests for products or services by the consumer. The consumer may accept the purchase order and process payment for the purchase order.
- MyOrders is a solution for parents to approve payments for purchases made by their children at school. For instance, a child can make a purchase at school using the Payit system and a parent can remotely approve the purchase using the Payit system.
- MyOrders may be associated with a single user (e.g. consumer) with a master account and that oversees multiple payments for multiple accounts using a single payment processing point.
- MyOrders is an inbox holding all the details of all pending purchase orders.
- the pending purchase orders are categorized with the order status, such as order pending or order already paid.
- the details of the purchase orders include: merchant name, order number, representation of the product or service, price or the product or service, quantity, and the like.
- a consumer may select a particular pending purchase order to view the details of that particular pending purchase order.
- consumers can share the details of their purchase order with other users using social media, messaging, and the like.
- the scope within the Payit system includes the following on the merchant interface side (e.g. merchant application 120 ) and the consumer interface side (e.g. consumer application 110 ).
- the merchant interface side includes a Payit interface and/or a third-party interface. Both the Payit interface and the third-party interface include: a regular Point of Sale (POS), a Payit merchant, and/or any additional applications from any source operator.
- the consumer interface side includes an internal consumer wallet and/or a third-party wallet, and/or a direct bank account interface.
- the merchant interface and the consumer interface communicate with high security through the cloud.
- communications are hashed with public and private keys management.
- the purchase orders are sent to account specific numbers.
- payment orders are sent via a Mobile Station International Subscriber Directory Number (MSISDN), email Identification, a verification code, and the like.
- MSISDN Mobile Station International Subscriber Directory Number
- Bilateral communication between the merchant interface and the consumer interface may be through a network as described herein.
- the processing of purchase orders follows the following flow depending on whether the consumer and/or the merchant have a PSP activated. If the consumer and/or the merchant do not have a PSP activated, an activation message is sent to the consumer and/or to the merchant. If the consumer and merchant have a PSP activated, the flow depends on which payment system the consumer and merchant have activated, such as: an internal consumer wallet account (e.g. “Payit Wallet”), a third-party wallet, and/or a direct bank account access. If the consumer and the merchant both have a Payit Wallet, transaction flow results in credit value moving from the consumer wallet account to the merchant wallet account instantly.
- an internal consumer wallet account e.g. “Payit Wallet”
- the transaction will be completed using an alternative PSP (e.g. the third-party wallet or the direct bank account access).
- PSP e.g. the third-party wallet or the direct bank account access
- the merchant account must be activated.
- Transaction flow results in credit value added to the merchant wallet account as soon as the issuer of the third-party wallet responds to a payment request.
- the consumer account and/or the merchant account include a direct bank account access
- a merchant wallet account must be activated.
- Transaction flow results in credit value added to the merchant wallet as soon as the issuer of the user bank account responds to a payment processing request.
- “one-in” activation enables consumers to have one-time activation of accounts. For example, consumers activate the MyPayit system with their mobile number. Payit consumers are sent email verification, and the email will be used for future communications between the Payit system and consumers. Additionally, a consumer password is established with secondary authentication by the consumer email and or mobile number. For instance, authentication by mobile number is completed by an activation code delivered via a text message. In some instances, if the consumer does not respond to the activation within five minutes the activation code expires and must be resent.
- the MyPayit home page that includes account balances and recent transactions of the consumer.
- the account balance may be a single account balance that can be used to pay any merchant for any product or service. Additionally, recent transactions of the consumer are displayed below the account balance.
- MyPayit alerts consumers when their account balance falls below a threshold.
- the MyPayit Homepage sends a push notification to a consumer when the account balance falls below the threshold. For instance, when the account balance of a consumer reaches or is below a consumer selected threshold, MyPayit sends the consumer an alert.
- a consumer may add funds to their account balance from multiple sources such as a credit/debit card, voucher, gift card, or loyalty card by clicking on an “Add Funds” button on the MyPayit Homepage.
- the merchant catalog includes the following. From the consumer perspective (e.g. GUIs coupled with consumer application 110 ), a consumer selects the merchant icon to display merchants with available items. A consumer can select to display the merchants by name and/or by category of goods.
- the category of goods may include: Automotive, Business Supplies, Electronics, Education, Entertainment, Food and Dining, and Health/Medicine. The consumer can select their desired category of goods and view all the merchants that sell goods classified in that category. Each merchant displays the number of in-stock items in the selected category.
- the merchant side e.g. GUIs coupled with merchant application 120 ) allows the merchant to update the status of the goods in real-time.
- the consumer and the merchant are interact by the consumer “virtual shopping” in the merchant store.
- the merchant adds items using the Payit system to their merchant store.
- the consumer requests an item by selecting a “Request button” for the item of interest in the merchant store.
- the merchant receives the request in the merchant side that enables the merchant to accept or to reject the consumer request for the item.
- the consumer instantaneously receives a notification if the merchant accepts the consumer request.
- the Payit system sends a payment request to the consumer.
- the consumer can reject or pay the payment request from the merchant.
- the merchant receives a payment confirmation.
- the merchant delivers the item and issues a receipt to the consumer.
- the Payit system includes the following parties: Payit platform, consumers, financial institutions, merchant retailers, billers and service providers, and governments.
- the Payit platform features include: an administrative panel for managing Payit services, account access privileges for the affiliated team and dealers, multiple delivery options across multiple channels, centralized back-to-back services integration, automated processing for different methods of payment, Payit compatibility for all transactions with all devices and operating systems, and real-time payment.
- Payit includes the following functionalities for consumers: choice of multiple funding sources, secure access to trusted funding-sources, a single screen for quick access to selection buttons, real-time access to services, multiple language options with localized language use, and overall system that is intuitive, easy-to-use, and always available.
- Payit functionalities for financial institutions include: new revenue streams, an efficient payment process, decreased/controlled risk, user protection with a verified Know Your Consumer (KYC) policies.
- KYC Know Your Consumer
- a bank account of a user remains the center for funding.
- Payit functionality for merchant retailers include: a mobilized inventory system, scalability to match products of a merchant, decreased cost to complete business, and secure instant invoicing that results in reliable payment.
- Payit functionality for billers and service providers include: decreased costs, minimal service charges, invoice collection in real-time before product delivery, strong consumer relationships, and ability to reach new consumers.
- Payit features for governments include: a simple payment process, increased consumer choice, decreased risk for regulation and money pools, and improving the daily life of individuals.
- the following are the transaction flows of functionality enabled by the Payit system for consumers requesting items from a merchant catalog (consumer purchasing), merchants sending orders to consumers (merchant pushing), consumer transacting with another consumer (peer-to-peer transactions), and integration of third-parties (non-Payit merchant or consumer) with the Payit system (third-party merchant requests).
- Closed loop transaction flows are between Payit wallet users. For example, consumer purchasing and merchant pushing are closed loop transactions when both the merchant and the Payit user utilize the Payit wallet for the transaction.
- Open loop transaction flows include a third-party wallet. For example, an open-loop transaction between a user with a Payit Wallet and a user with a third-party wallet, or between two users that both have third-party wallets.
- the Payit system acts as the processor of the transaction between the two users (e.g. consumer and merchant).
- FIG. 5 illustrates an exemplary computer system 500 that may be used to implement some embodiments of the present invention.
- the computer system 500 in FIG. 5 may be implemented in the contexts of the likes of computing systems, networks, servers, or combinations thereof.
- the computer system 500 in FIG. 5 includes one or more processor unit(s) 510 and main memory 520 .
- Main memory 520 stores, in part, instructions and data for execution by processor unit(s) 510 .
- Main memory 520 stores the executable code when in operation, in this example.
- the computer system 500 in FIG. 5 further includes a mass data storage 530 , portable storage device 540 , output devices 550 , user input devices 560 , a graphics display system 570 , and peripheral device(s) 580 .
- FIG. 5 The components shown in FIG. 5 are depicted as being connected via a single bus 590 .
- the components may be connected through one or more data transport means.
- Processor unit(s) 510 and main memory 520 are connected via a local microprocessor bus, and the mass data storage 530 , peripheral device(s) 580 , portable storage device 540 , and graphics display system 570 are connected via one or more input/output (I/O) buses.
- I/O input/output
- Mass data storage 530 which can be implemented with a magnetic disk drive, solid state drive, or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by processor unit(s) 510 . Mass data storage 530 stores the system software for implementing embodiments of the present disclosure for purposes of loading that software into main memory 520 .
- Portable storage device 540 operates in conjunction with a portable non-volatile storage medium, such as a flash drive, floppy disk, compact disk, digital video disc, or Universal Serial Bus (USB) storage device, to input and output data and code to and from the computer system 500 in FIG. 5 .
- a portable non-volatile storage medium such as a flash drive, floppy disk, compact disk, digital video disc, or Universal Serial Bus (USB) storage device
- USB Universal Serial Bus
- User input devices 560 can provide a portion of a user interface.
- User input devices 560 may include one or more microphones, an alphanumeric keypad, such as a keyboard, for inputting alphanumeric and other information, or a pointing device, such as a mouse, a trackball, stylus, or cursor direction keys.
- User input devices 560 can also include a touchscreen.
- the computer system 500 as shown in FIG. 5 includes output devices 550 . Suitable output devices 550 include speakers, printers, network interfaces, and monitors.
- Graphics display system 570 include a liquid crystal display (LCD) or other suitable display device. Graphics display system 570 is configurable to receive textual and graphical information and processes the information for output to the display device.
- LCD liquid crystal display
- Peripheral device(s) 580 may include any type of computer support device to add additional functionality to the computer system 500 .
- the components provided in the computer system 500 in FIG. 5 are those typically found in computer systems that may be suitable for use with embodiments of the present disclosure and are intended to represent a broad category of such computer components that are well known in the art.
- the computer system 500 in FIG. 5 can be a personal computer (PC), hand held computer system, telephone, mobile computer system, workstation, tablet, phablet, mobile phone, server, minicomputer, mainframe computer, wearable, or any other computer system.
- the computer may also include different bus configurations, networked platforms, multi-processor platforms, and the like.
- Various operating systems may be used including UNIX, LINUX, WINDOWS, MAC OS, PALM OS, QNX ANDROID, IOS, CHROME, and other suitable operating systems.
- Some of the above-described functions may be composed of instructions that are stored on storage media (e.g., computer-readable medium).
- the instructions may be retrieved and executed by the processor.
- Some examples of storage media are memory devices, tapes, disks, and the like.
- the instructions are operational when executed by the processor to direct the processor to operate in accord with the technology. Those skilled in the art are familiar with instructions, processor(s), and storage media.
- the computer system 500 may be implemented as a cloud-based computing environment, such as a virtual machine operating within a computing cloud.
- the computer system 500 may itself include a cloud-based computing environment, where the functionalities of the computer system 500 are executed in a distributed fashion.
- the computer system 500 when configured as a computing cloud, may include pluralities of computing devices in various forms, as will be described in greater detail below.
- a cloud-based computing environment is a resource that typically combines the computational power of a large grouping of processors (such as within web servers) and/or that combines the storage capacity of a large grouping of computer memories or storage devices.
- Systems that provide cloud-based resources may be utilized exclusively by their owners or such systems may be accessible to outside users who deploy applications within the computing infrastructure to obtain the benefit of large computational or storage resources.
- the cloud is formed, for example, by a network of web servers that comprise a plurality of computing devices, such as the computer system 500 , with each server (or at least a plurality thereof) providing processor and/or storage resources.
- These servers manage workloads provided by multiple users (e.g., cloud resource consumers or other users).
- users e.g., cloud resource consumers or other users.
- each user places workload demands upon the cloud that vary in real-time, sometimes dramatically. The nature and extent of these variations typically depends on the type of business associated with the user.
- Non-volatile media include, for example, optical, magnetic, and solid-state disks, such as a fixed disk.
- Volatile media include dynamic memory, such as system RAM.
- Transmission media include coaxial cables, copper wire and fiber optics, among others, including the wires that comprise one embodiment of a bus.
- Transmission media can also take the form of acoustic or light waves, such as those generated during radio frequency (RF) and infrared (IR) data communications.
- RF radio frequency
- IR infrared
- Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, a hard disk, magnetic tape, any other magnetic medium, a CD-ROM disk, digital video disk (DVD), any other optical medium, any other physical medium with patterns of marks or holes, a RAM, a PROM, an EPROM, an EEPROM, a FLASH memory, any other memory chip or data exchange adapter, a carrier wave, or any other medium from which a computer can read.
- a bus carries the data to system RAM, from which a CPU retrieves and executes the instructions.
- the instructions received by system RAM can optionally be stored on a fixed disk either before or after execution by a CPU.
- Computer program code for carrying out operations for aspects of the present technology may be written in any combination of one or more programming languages, including an object oriented programming language such as JAVA, SMALLTALK, C++ and the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages.
- the program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.
- the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
- LAN local area network
- WAN wide area network
- Internet Service Provider for example, AT&T, MCI, Sprint, EarthLink, MSN, GTE, etc.
- These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
- the computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
- each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s).
- the functions noted in the block may occur out of the order noted in the figures. For example, 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 involved.
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Finance (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Cash Registers Or Receiving Machines (AREA)
Abstract
Description
- This application claims priority to co-pending U.S. Provisional Patent Application Ser. No. 62/004,091, filed May 28, 2014, which is entirely incorporated herein by reference for all purposes.
- The present invention relates to payments. In particular, the present technology provides a switch server system interoperable with mobile devices for providing secure communications.
- The use of currency (cash) has been rapidly decreasing, as consumers and merchants rely increasingly on credit and debit accounts. Further, mobile phones, tablets, and/or laptops are increasingly prevalent. Mobile phones have been used for payments, though typically they require special chips, for instance Near Field Communication (NFC) chips. Merchants are using mobile devices to accept payments, though likewise these systems require special hardware, for instance card readers.
- Some embodiments of the present technology include a computer-implemented method for conducting a secure transaction over a network using one or more gateway servers. Embodiments of the method include receiving a request from a consumer, sending the request to a merchant, and receiving, from the merchant, a payment order associated with the request. The payment order is received via a merchant programmable user interface. Embodiments of the method also include confirming the payment order to transform the payment order to a confirmed payment order, sending the confirmed payment order to a user, and receiving, from the user, a payment authorization associated with the confirmed payment order, and the payment authorization is received via a consumer programmable user interface. The payment authorization from the user includes a secure, encrypted, Internet Protocol (IP) message using encryption hashed with public and private key management. Embodiments of the method also include performing a transaction in accordance with the payment authorization.
- Various embodiments of the method include sending a registration message to the merchant, receiving, from the merchant, identifying information associated with the merchant in response to the registration message, and validating the identifying information. Embodiments of the method also include sending a validation message associated with the validating of the identifying information to a payment service provider (PSP).
- Some embodiments of the present technology include performing of the transaction in accordance with the payment authorization being associated the PSP, the PSP being at least one of: an internal consumer wallet account, a direct bank transfer account, and a third-party PSP.
- Various embodiments of the present technology include the PSP being an internal consumer wallet account.
- Some embodiments of the present technology include performing of the transaction being in accordance with the payment authorization, using a secure internal switch, and being associated with the internal consumer wallet account. The internal consumer wallet account being associated with an account of the user. The account of the user being at least one of: a credit account, a debit account, a savings account, a loyalty account, and a virtual currency account.
- Various embodiments of the present technology include sending, to the consumer, the merchant, and the user one or more payment confirmations associated with the performing of the transaction in accordance with the payment authorization.
- Some embodiments of the present technology include the merchant programmable user interface being coupled with a mobile Points Of Sale (mPOS) terminal, the merchant programmable user interface configured to perform at least one of: registering the terminal, managing the terminal, and authorizing a payment from the PSP to the merchant. Embodiments of the method include the merchant programmable user interface also configured to perform at least one of: preauthorizing the payment from the PSP, voiding the payment from the PSP, refunding the payment from the PSP, and settling the payment from the PSP.
- Various embodiments of the present technology include the merchant programmable user interface being configured to perform at least one of: managing a profile of the merchant, managing a definition of a product, managing an inventory of the product, managing a location of the product, managing agents of the merchant; and contacting a support system about the merchant.
- Some embodiments of the present technology include the merchant programmable user interface being configured to perform at least one of: communicating with a product catalog of the merchant, communicating with an inventory system of the merchant, communicating with a product information management system of the merchant, and updating inventory of the merchant based on the request.
- Various embodiments of the present technology include the merchant programmable user interface being configured to perform at least one of: communicating with a third-party product catalog, communicating with a third-party inventory system, and communicating with a third-party product information management system.
-
FIG. 1 is a simplified block diagram of a system according to exemplary embodiments of the present technology; -
FIG. 2 is a simplified block diagram of a system according to exemplary embodiments of the present technology; -
FIG. 3A is a flow diagram illustrating an example method according to exemplary embodiments of the present technology; -
FIG. 3B is a flow diagram illustrating an exemplary method according embodiments of the present technology; -
FIG. 4 is a flow diagram showing a further example according to exemplary embodiments of the present technology; -
FIG. 5 illustrates a computer system according to exemplary embodiments of the present technology. - While this technology is susceptible of embodiment in many different forms, there is shown in the drawings and will herein be described in detail several specific embodiments with the understanding that the present disclosure is to be considered as an exemplification of the principles of the technology and is not intended to limit the technology to the embodiments illustrated. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the technology. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and/or “including,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. It will be understood that like or analogous elements and/or components, referred to herein, may be identified throughout the drawings with like reference characters. It will be further understood that several of the figures are merely schematic representations of the present technology. As such, some of the components may have been distorted from their actual scale for pictorial clarity.
- Embodiments of the present technology provide a convenient, secure, cost-effective, and unified payment solution. The solution is designed to reduce the cost traditionally incurred by merchants, facilitate easier and faster consumer acquisition by dynamically extending the payment options to consumers and merchants. The channels by which consumers and merchants can interact with Payment Orders (Payit Coins (Wallet)) and provide an IP cryptography-based secure payment method works seamlessly for both card-present and card-not-present scenarios.
- In the past, there have been numerous alternative solutions to card-not-present payment methods (e.g. using e-Wallets, and physical agents). However there have been no major alternatives to traditional card-present methods. Recently, several NFC- and QR-based alternatives have emerged (e.g. Apple Pay, VISA Paywave, MasterCard PayPass, AMEX ExpressPay). Yet, these alternatives have restrictions including that they are targeted with limited set of devices (e.g. NFC-enabled), still rely on traditional infrastructure (e.g. costly brands network), and follow the same traditional flow between payment card/payment application and Point of Sale Terminal/NFC-enabled Point of Sale Terminal.
- Recently-emerging solutions only work with a limited set of consumer devices (e.g. phones with NFC support), require sophisticated setup at the merchant side (e.g. NFC Paywave certified POS terminals), and still rely on the existing payment network infrastructure (e.g. costly brands network). Furthermore, they do not provide any unified approach for card-present and card-not-present scenarios.
- In various embodiments, Payit Orders work for both card-present and card-not-present scenarios. The solution allows to extend the payment options available to the consumer and to dynamically transform the payment scenario from a card-present to a card-not-present scenario and vise-versa.
- According to various embodiments of the present technology, a solution is provided by Payit Orders and the Payit Cloud Platform. A Payit Order is a signed and encrypted cryptographic payment order payload that is typically sent securely from the merchant mobile application to the Consumer mobile application through the Payit Cloud Platform (namely, Payit Gateway). Merchants' identities are initially verified through a Know-your-customer (KYC) process, which consequently allows their orders to be signed with (their private keys) and encrypted. A Consumer goes through a verification process, after which his/her e-Wallet becomes associated with the mobile device (e.g. EMEI and Phone Number). This allows consumer requests (e.g. order acceptance request) to be signed and sent securely. In various embodiments, Payit Orders supports multiple use cases, including electronic payments for m-commerce transactions, money transfers, and electronic payments from 3rd-party e-commerce applications (via Payit Checkout). In this manner, the system provides a unique alternative to in-store card-present payments.
- According to various embodiments of the present technology, the following points describe the sale process. The merchant keys in the required amount and the account Id of the consumer (e.g. phone number) into the Payit merchant app, which in turn, creates a Payit order cryptogram using the merchants private key. The cryptogram is then submitted to Payit Gateway (the Payit Cloud Platform). Payit Gateway decrypts the cryptogram and validates the merchant. Payit Gateway pushes a signed order to the consumer's mobile application, which decrypts the order, and prompts the consumer to accept it. The consumer selects the payment method he/she wants to use for payment (by default, Payit Coins (Wallet)). A signed request is sent from the consumer application to the Payit Gateway, which in turn, validates the request and forwards it to Payit Switch for processing. The payment order is processed by Payit switch; i.e. the consumer wallet is debited, and the merchant wallet is credited in one atomic transaction. The result is returned to Payit Gateway. Payit Gateway sends a “successful payment” confirmation to the consumer, and sends a “successful payment” confirmation to the merchant. The merchant can then submit an invoice to Payit at any later stage.
- In various embodiments, Payit Orders can be passed through different merchant channels, be accessed through different consumer channels, and eventually be routed to different payment channels. In other words, it extends the number of payment methods available to the consumer, and transforms the payment scenario from card-present to card-not-present and vise versa. The following illustrates the various channels. Payit orders may be submitted to Payit Gateway from a Payit Merchant mobile application, from a 3rd-party e-Commerce Site through Payit Checkout, or from a 3rd-party service provider app through APIs.
- According to various embodiments of the present technology, Merchants go through an acquiring and KYC process, and consumers go through a verification process after which their unique identifications (mobiles number, email or ID) are associated to their accounts. Both parties become known to Payit, which allows the Payit Gateway to facilitate the entire payment process in a closed loop manner, without depending on other parties (banks, schemes, etc). The solution enables a relatively fast and easy consumer acquisition. The payment order flow is different from other solutions. The Payit order cryptogram is initiated by merchant and flows to the consumer, who in turn, decides to pay using the payment methods available to him. In other words, the consumer is in control of the payment process, and the consumer doesn't need to share any payment choice with merchant. The solution does not require sophisticated consumer devices (e.g. smart phone with NFC support). It can work with basic phones using SMS. Payit Orders can be initiated and submitted through different channels; e.g. merchant mobile app, 3rd-party e-Commerce sites (via Payit Checkout), and through other API-integrated systems. Payit Orders can be processed in different ways; using smart phones, basic phones, and through Payit dealers (in which case, they can pay for an item or service, even if they don't have their mobile device with them). The present technology extends a payment solution to cover whole consumer segment levels, from banked to unbanked, from smartphones to feature phones and even to non-mobile subscribers. All parties can buy and shop within Payment Order cryptography-IP.
- In various embodiments, the present technology specializes in a number of diverse business domains, including Value Added Services (VAS), Mobile Money, Mobile payment, Money Transfer, Mobile banking, Mobile health care, retail, VOIP, m-Commerce; and works with different stakeholders, including banks, payment service providers, telcos, service providers, retailer, etc.
- In various embodiments of the present technology, a computer-implemented method for conducting a secure transaction over a network using one or more gateway servers, the method includes generating, with a processor, the payment order by encoding changes to the values of the request from the consumer, storing the payment order in a first memory location, receiving the payment authorization and storing the payment authorization in a second memory location, comparing, with a processor, the payment authorization with the payment order, and converting the payment authorization into a secure transaction authorization.
- In some embodiments, the present technology provides a mobile application that may be downloaded to a mobile device. A user (e.g. consumer or merchant) registers with a central system to activate an account. The user may then fund the account from one or more sources, for instance a credit account, a debit account (also referred to as a checking account), a savings account, loyalty accounts, a virtual currency or any other appropriate currency account. The user may link the one or more accounts and may institute an automatic replenishment (also referred to as a top-off) order. The authentication process may include associating a mobile number, user name, email, account information, and any other identifying information. A password may be provided or selected, and an activation code may be sent via Short Message System (SMS) text message to the mobile device to ensure correct association.
- In various embodiments, the user (e.g. consumer or merchant) then chooses to pay a bill using the mobile application. For example, a user may indicate to a merchant a desire to pay a bill with the present application (also referred to as “Payit” or the “Payit application”), and may identify themselves to the merchant using their mobile phone number. The merchant may have the Payit application downloaded to a mobile device, at a cash register, on a tablet, or may quickly download the Payit application to any of these devices, or any other appropriate device. Using the Payit application, the merchant may send a secure, encrypted Internet Protocol (IP) message to the user based on the Payit identifier of the user. The secure, encrypted IP message may be hashed using a public and private key management system to ensure utmost security and privacy. The encrypted IP message includes a payment order. The user then opens the Payit application, sees the payment order in a list of payment orders, and authorizes the payment. The authorization may be a secure, encrypted IP message sent to the merchant and indicates payment. The merchant and consumer have records in their respective accounts in the Payit application of all payment orders, both received and unpaid, and paid. Alternatively, the user may choose to reject or not pay any payment order, thus ensuring user confidence in the Payit application.
- According to some embodiments, the user (e.g. consumer or merchant) chooses to pay monthly or other periodic bills using the Payit application. By linking certain service providers, for example, phone, internet, utility or other monthly (or other periodic, or non-periodic) bills, with the Payit application, the user may consolidate all billing in a central location and may reduce transaction costs and bookkeeping obligations. The user may also choose to share certain information from the Payit application to other contacts, either from the Payit application or from another address book application, or via a social media application.
- According to various embodiments, the user (e.g. consumer or merchant) uses the Payit application to shop for goods and services by searching for an item or a merchant in the Payit application, and selecting goods or services for purchase. The merchant may receive the order from the user in the Payit application, and then may send a secure, encrypted IP message to the user via the Payit application including a payment order. The user may receive the payment order and authorize it, causing the Payit application to send a secure, encrypted IP message to the merchant. The merchant then fulfills the order.
- In exemplary embodiments, merchants use the Payit application to receive payments from a consumer, make payments to suppliers, and maintain inventory. Merchants may link inventory and orders from suppliers so that when inventory drops below a predetermined, selectable threshold, a new order to a supplier is made, and payment may be made.
- According to some embodiments, the system may operate in a cloud-based computer environment or, alternatively, may operate as a secure server. All communications to and from mobile devices and other mobile applications may be encrypted and decrypted for security purposes.
- According to various embodiments, the Payit application may be a mobile application, and/or may be used on a laptop, smartphone or PDA, wearable device, and may be downloadable or web-based. Alternatively, the system may be implemented in software and/or hardware. A mobile application may be provided that enables a user to access a web-based version of the system from a mobile device.
-
FIG. 1 is a simplified block diagram of asystem 100 according to exemplary embodiments of the present technology. The architecture comprises a server system that is configured to provide various functionalities, which are described in greater detail throughout this document. Generally thesystem 100 is configured to communicate with client devices. Client devices may include, for example, a Smartphone, a laptop, a computer, or other similar computing device. An example of a computing device that can be utilized in accordance with the present technology is described in greater detail with respect toFIG. 5 . - The
system 100 may communicatively couple with clients via a public or private network. Suitable networks may include or interface with any one or more of, for instance, a local intranet, a PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network), a MAN (Metropolitan Area Network), a virtual private network (VPN), a storage area network (SAN), a frame relay connection, an Advanced Intelligent Network (AIN) connection, a synchronous optical network (SONET) connection, a digital T1, T3, E1 or E3 line, Digital Data Service (DDS) connection, DSL (Digital Subscriber Line) connection, an Ethernet connection, an ISDN (Integrated Services Digital Network) line, a dial-up port such as a V.90, V.34 or V.34bis analog modem connection, a cable modem, an ATM (Asynchronous Transfer Mode) connection, or an FDDI (Fiber Distributed Data Interface) or CDDI (Copper Distributed Data Interface) connection, and the like. Furthermore, communications may also include links to any of a variety of wireless networks, including WAP (Wireless Application Protocol), GPRS (General Packet Radio Service), GSM (Global System for Mobile Communication), CDMA (Code Division Multiple Access) or TDMA (Time Division Multiple Access), cellular phone networks, GPS (Global Positioning System), CDPD (cellular digital packet data), RIM (Research in Motion, Limited) duplex paging network, Bluetooth radio, or an IEEE 802.11-based radio frequency network, and the like. A network can further include or interface with any one or more of an RS-232 serial connection, an IEEE-1394 (Firewire) connection, a Fiber Channel connection, an IrDA (infrared) port, a SCSI (Small Computer Systems Interface) connection, a USB (Universal Serial Bus) connection or other wired or wireless, digital or analog interface or connection, mesh or Digi® networking, and the like. - The
system 100 inFIG. 1 generally comprisesconsumer application 110,merchant application 120,dealer application 130 andcheckout application 140. Thesystem 100 further includes application programming interface(s) 150, public application programming interface(s) 160, gateway server(s) 170, andswitch 180. Application programming interface(s) 150, gateway server(s) 170, and switch 180form sub-system 105, which may also be referred to as the internal Payit system.Consumer application 110,merchant application 120,dealer application 130 andcheckout application 140 may communicate bilaterally with gateway server(s) 170 via application programming interface(s) 150.System 100 also includes payment service providers (PSPs) 192 1-192 x and consumer service providers (CSPs) 194 1-194 y. Payment service providers (PSPs) 192 1-192 x may communicate bilaterally with gateway server(s) 170 viaswitch 180. Consumer service providers (CSPs) 194 1-194 y may bilaterally communicate directly with gateway server(s) 170. Consumer service providers (CSPs) 194 1-194 y may include the merchant, service providers operating on behalf of the merchant, and/or third party retailers working in partnership with, or appearing in a catalog of, the merchant. -
FIG. 2 is a simplified block diagram of asystem 200 according to exemplary embodiments of the present technology. Thesystem 200 inFIG. 2 includes theconsumer application 110, themerchant application 120, mobile Point of Sale (mPOS) terminal 210, thecheckout application 140, and third-party merchant application(s) 220. Thesystem 200 further includes the gateway server(s) 170 withglobal server 230 and point ofsale server 240. Thesystem 200 also includes the consumer service providers (CSPs) 194 1-194 y, theswitch 180, the payment service providers (PSPs) 192 1-192 x, and internalconsumer wallet account 250. In various embodiments, the internalconsumer wallet account 250 may be an account of the consumer or an account of the user (e.g. a third-party). - In various embodiments, the
switch 180 adds additional security to messages sent within thesystem 100 andsystem 200 by signing, authenticating, and applying business rules to the messages during the routing process. For example, a MyOrders cryptographic message is signed with a public and a private key. In addition to hashing, Secure Socket Layer (SSL) encryption and key store exchange occurs between systems within a merchant and consumer data flow. Theswitch 180 maintains extra signing and login/handshake authentication that may involve account parameters for achieving a purchase transaction. For instance, when a merchant pushes an order through the gateway server(s) 170, theswitch 180 routes the order to a consumer system by applying business rules linked to the order itself. Theswitch 180 routes the order to a consumer system by applying business rules linked to the order itself, whether the order is within a Payit Network, to a third-party system, and/or issued by a third-party party merchant. Thus, theswitch 180 applies signing, authentication, and business rules to orders during the routing process, which is managed via a fraud control policy, risk management, and end-to-end business rules. In contrast, a normal switch has known standards and authentication that can be compromised when an IP packet data is transported from one system to another. - According to various embodiments, a closed loop transaction operates within a Payit network with a set of cryptography parameters that are shared between modules, making every purchase and payment operate seamlessly within the data flow. When an open loop transaction is initiated for routing an order, or a third-party system requests to submit orders, then IP packets receive extra parameters to ensure that the outside system is authorized to communicate with the Payit network through the
switch 180. For example, signing with keys, authentication, and application of business rules, are all maintained and enforced by the switch for each IP cryptography packet to ensure that a transaction is genuine before processing it with the Payit network (e.g. system 100 or system 200). -
FIG. 3A is a flow diagram illustrating an example method according to exemplary embodiments of the present technology. Optional steps are shown with dashed lines.FIG. 3A illustrates amethod 300 for conducting a secure transaction over a network. In various embodiments,method 300 is performed by a computing system, as described in relation toFIG. 5 . Atstep 310, a request from a consumer is received. Atstep 320, the request to a merchant is sent. Atstep 330, a payment order associated with the request is received from the merchant. Atstep 340, the payment is confirmed in order to transform the payment order to a confirmed payment order. Atstep 350, the confirmed payment order to the consumer is sent to a user. In various embodiments the user may be the consumer or a third-party user. Atstep 360, a payment authorization associated with the confirmed payment order is received from the user. Atstep 370, a financial transaction in accordance with the payment authorization is performed. Atstep 380, a confirmation is sent to the merchant. In various embodiments, the confirmation is a confirmation of payment and once the merchant receives the confirmation of payment from the consumer, the merchant delivers the item and/or performs the requested service. Then the merchant issues a receipt to the consumer. - The
method 300 illustrated inFIG. 3A may also be adapted to the case of sending money securely. In the money transfer use case, a user can initiate the transaction by inputting a merchant identifier into the consumer application, and sending a payment request to the system. In this manner, a user may send a payment to a friend or relative via the merchant. In still further alternatives, a shopping cart may enable direct shopping by the consumer, and also enable a merchant to maintain stock inventory. -
FIG. 3B is a flow diagram illustrating an exemplary method according embodiments of the present technology.FIG. 3B illustrates amethod 305 that comprises additional steps that may be performed for conducting a secure transaction over a network. In various embodiments,method 305 is performed by a computing system, as described in relation toFIG. 5 . Atstep 315, a registration message is sent to the merchant. Atstep 325, identifying information associated with the merchant in response to the registration message is received from the merchant. Atstep 335, the identifying information is validated. Atstep 345, a validation message associated with the validating of the identifying information is sent to a payment service provider (PSP). -
FIG. 4 is a flow diagram showing a further example method according to exemplary embodiments of the present technology, and in particular shows greater detail related tosteps FIG. 3B . According to some embodiments,FIG. 4 illustrates amethod 400 for performing a transaction in accordance with the payment authorization. In some embodiments,FIG. 4 illustrates an algorithm of a means for performing a transaction in accordance with the payment authorization. In various embodiments,method 400 is performed by a computing system, as described in relation toFIG. 5 . Atstep 360, a payment authorization associated with the confirmed payment order is received from the consumer. Atstep 410, a decision is made whether a validation message associated with the validating of the identifying information has been sent to a PSP. If no, atstep 420, a registration message is sent to the merchant. If yes, atstep 430, a decision is made whether a payment authorization associated with the confirmed payment order has been received from the consumer. If no, at step 440, the confirmed payment order is sent to the consumer. If yes, atstep 450, a decision is made whether an internal consumer wallet account is activated. If no, atstep 460, an alternative PSP is activated. If yes, atstep 370, a financial transaction in accordance with the payment authorization is performed.Step 370, a financial transaction in accordance with the payment authorization is performed may also be performed afterstep 460. - It will be understood that the functionalities described herein, which are attributed to the
system 100 may also be executed within a client. That is, a client may be programmed to execute the functionalities described herein. In other instances, thesystem 100, and a client may cooperate to provide the functionalities described herein, such that a client is provided with a client-side application that interacts with thesystem 100 such that thesystem 100 and a client operate in a client/server relationship. Complex computational features may be executed by the gateway server(s) 170, while simple operations that require fewer computational resources may be executed by a client, such as data gathering and data display. - In general, a user interface module may be executed by the
system 100 to provide various programmable user interfaces such as a graphical user interfaces (GUIs) that allow users (e.g. merchants and consumers) to interact with thesystem 100. In some instances, GUIs are generated by execution of an application itself. Users may interact with thesystem 100 using, for example, a client. Thesystem 100 may generate web-based interfaces for a client. Thesystem 100 is generally referred to herein as “Payit system” and/or “Payit services” - In various embodiments, the present technology is a system delivery specification. Exemplary mobile payment systems and applications for consumers and merchants are described below. Exemplary GUIs include the Payit Home Screen comprising the following main icons: MyPayit, Services, Loyalty Cards, Merchants, We Listen, Language Switcher, Quick Help Tour, and Countries.
- In some embodiments, the MyPayit icon includes MyOrders. MyOrders is part of MyPayit that allows users (e.g. merchants and consumers) to: activate their account, view their account balance, add funds from different sources to their account, and instantly make transactions with Payit services rather than filling out debit/credit card details for every transaction. For instance, a consumer may make a request for product or a service from a merchant. In response to the request for the product or the service, the merchant sends the consumer a purchase order for each request. The purchase order may be an invoice, bill of sale, account statement, and the like. MyOrders is incoming purchase orders from different merchants in response to requests for products or services by the consumer. The consumer may accept the purchase order and process payment for the purchase order. Alternatively, the consumer may reject the purchase order. For example, MyOrders is a solution for parents to approve payments for purchases made by their children at school. For instance, a child can make a purchase at school using the Payit system and a parent can remotely approve the purchase using the Payit system. MyOrders may be associated with a single user (e.g. consumer) with a master account and that oversees multiple payments for multiple accounts using a single payment processing point.
- According to various embodiments, MyOrders is an inbox holding all the details of all pending purchase orders. The pending purchase orders are categorized with the order status, such as order pending or order already paid. For example, the details of the purchase orders include: merchant name, order number, representation of the product or service, price or the product or service, quantity, and the like. A consumer may select a particular pending purchase order to view the details of that particular pending purchase order. Additionally, consumers can share the details of their purchase order with other users using social media, messaging, and the like.
- In some embodiments, the scope within the Payit system includes the following on the merchant interface side (e.g. merchant application 120) and the consumer interface side (e.g. consumer application 110). The merchant interface side includes a Payit interface and/or a third-party interface. Both the Payit interface and the third-party interface include: a regular Point of Sale (POS), a Payit merchant, and/or any additional applications from any source operator. The consumer interface side includes an internal consumer wallet and/or a third-party wallet, and/or a direct bank account interface.
- In various embodiments, the merchant interface and the consumer interface communicate with high security through the cloud. For example, communications are hashed with public and private keys management. The purchase orders are sent to account specific numbers. For example, payment orders are sent via a Mobile Station International Subscriber Directory Number (MSISDN), email Identification, a verification code, and the like. Bilateral communication between the merchant interface and the consumer interface may be through a network as described herein.
- In some embodiments, the processing of purchase orders follows the following flow depending on whether the consumer and/or the merchant have a PSP activated. If the consumer and/or the merchant do not have a PSP activated, an activation message is sent to the consumer and/or to the merchant. If the consumer and merchant have a PSP activated, the flow depends on which payment system the consumer and merchant have activated, such as: an internal consumer wallet account (e.g. “Payit Wallet”), a third-party wallet, and/or a direct bank account access. If the consumer and the merchant both have a Payit Wallet, transaction flow results in credit value moving from the consumer wallet account to the merchant wallet account instantly. If consumer and/or merchant wallet do not have a Payit Wallet then the transaction will be completed using an alternative PSP (e.g. the third-party wallet or the direct bank account access). For instance, if the consumer and/or the merchant do not both have a Payit Wallet, the merchant account must be activated. Transaction flow results in credit value added to the merchant wallet account as soon as the issuer of the third-party wallet responds to a payment request. For example, if the consumer account and/or the merchant account include a direct bank account access, a merchant wallet account must be activated. Transaction flow results in credit value added to the merchant wallet as soon as the issuer of the user bank account responds to a payment processing request.
- In various embodiments, “one-in” activation enables consumers to have one-time activation of accounts. For example, consumers activate the MyPayit system with their mobile number. Payit consumers are sent email verification, and the email will be used for future communications between the Payit system and consumers. Additionally, a consumer password is established with secondary authentication by the consumer email and or mobile number. For instance, authentication by mobile number is completed by an activation code delivered via a text message. In some instances, if the consumer does not respond to the activation within five minutes the activation code expires and must be resent.
- In some embodiments, after “one-in” is activated, consumers can view the MyPayit home page that includes account balances and recent transactions of the consumer. The account balance may be a single account balance that can be used to pay any merchant for any product or service. Additionally, recent transactions of the consumer are displayed below the account balance. MyPayit alerts consumers when their account balance falls below a threshold. For example, the MyPayit Homepage sends a push notification to a consumer when the account balance falls below the threshold. For instance, when the account balance of a consumer reaches or is below a consumer selected threshold, MyPayit sends the consumer an alert. A consumer may add funds to their account balance from multiple sources such as a credit/debit card, voucher, gift card, or loyalty card by clicking on an “Add Funds” button on the MyPayit Homepage.
- In various embodiments, the merchant catalog includes the following. From the consumer perspective (e.g. GUIs coupled with consumer application 110), a consumer selects the merchant icon to display merchants with available items. A consumer can select to display the merchants by name and/or by category of goods. For example, the category of goods may include: Automotive, Business Supplies, Electronics, Education, Entertainment, Food and Dining, and Health/Medicine. The consumer can select their desired category of goods and view all the merchants that sell goods classified in that category. Each merchant displays the number of in-stock items in the selected category. The merchant side (e.g. GUIs coupled with merchant application 120) allows the merchant to update the status of the goods in real-time.
- According to various embodiments, the consumer and the merchant are interact by the consumer “virtual shopping” in the merchant store. For example, the merchant adds items using the Payit system to their merchant store. The consumer requests an item by selecting a “Request button” for the item of interest in the merchant store. The merchant receives the request in the merchant side that enables the merchant to accept or to reject the consumer request for the item. The consumer instantaneously receives a notification if the merchant accepts the consumer request. Upon acceptance of the consumer request, the Payit system sends a payment request to the consumer. The consumer can reject or pay the payment request from the merchant. If the consumer accepts the payment request the merchant receives a payment confirmation. Once the merchant receives confirmation of payment from the consumer, the merchant delivers the item and issues a receipt to the consumer.
- In some embodiments, the Payit system includes the following parties: Payit platform, consumers, financial institutions, merchant retailers, billers and service providers, and governments. The Payit platform features include: an administrative panel for managing Payit services, account access privileges for the affiliated team and dealers, multiple delivery options across multiple channels, centralized back-to-back services integration, automated processing for different methods of payment, Payit compatibility for all transactions with all devices and operating systems, and real-time payment. Payit includes the following functionalities for consumers: choice of multiple funding sources, secure access to trusted funding-sources, a single screen for quick access to selection buttons, real-time access to services, multiple language options with localized language use, and overall system that is intuitive, easy-to-use, and always available. Payit functionalities for financial institutions include: new revenue streams, an efficient payment process, decreased/controlled risk, user protection with a verified Know Your Consumer (KYC) policies. A bank account of a user remains the center for funding. Payit functionality for merchant retailers include: a mobilized inventory system, scalability to match products of a merchant, decreased cost to complete business, and secure instant invoicing that results in reliable payment. Payit functionality for billers and service providers include: decreased costs, minimal service charges, invoice collection in real-time before product delivery, strong consumer relationships, and ability to reach new consumers. Payit features for governments include: a simple payment process, increased consumer choice, decreased risk for regulation and money pools, and improving the daily life of individuals.
- According to various embodiments, the following are the transaction flows of functionality enabled by the Payit system for consumers requesting items from a merchant catalog (consumer purchasing), merchants sending orders to consumers (merchant pushing), consumer transacting with another consumer (peer-to-peer transactions), and integration of third-parties (non-Payit merchant or consumer) with the Payit system (third-party merchant requests). Closed loop transaction flows are between Payit wallet users. For example, consumer purchasing and merchant pushing are closed loop transactions when both the merchant and the Payit user utilize the Payit wallet for the transaction. Open loop transaction flows include a third-party wallet. For example, an open-loop transaction between a user with a Payit Wallet and a user with a third-party wallet, or between two users that both have third-party wallets. The Payit system acts as the processor of the transaction between the two users (e.g. consumer and merchant).
-
FIG. 5 illustrates anexemplary computer system 500 that may be used to implement some embodiments of the present invention. Thecomputer system 500 inFIG. 5 may be implemented in the contexts of the likes of computing systems, networks, servers, or combinations thereof. Thecomputer system 500 inFIG. 5 includes one or more processor unit(s) 510 andmain memory 520.Main memory 520 stores, in part, instructions and data for execution by processor unit(s) 510.Main memory 520 stores the executable code when in operation, in this example. Thecomputer system 500 inFIG. 5 further includes amass data storage 530,portable storage device 540,output devices 550,user input devices 560, agraphics display system 570, and peripheral device(s) 580. - The components shown in
FIG. 5 are depicted as being connected via asingle bus 590. The components may be connected through one or more data transport means. Processor unit(s) 510 andmain memory 520 are connected via a local microprocessor bus, and themass data storage 530, peripheral device(s) 580,portable storage device 540, andgraphics display system 570 are connected via one or more input/output (I/O) buses. -
Mass data storage 530, which can be implemented with a magnetic disk drive, solid state drive, or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by processor unit(s) 510.Mass data storage 530 stores the system software for implementing embodiments of the present disclosure for purposes of loading that software intomain memory 520. -
Portable storage device 540 operates in conjunction with a portable non-volatile storage medium, such as a flash drive, floppy disk, compact disk, digital video disc, or Universal Serial Bus (USB) storage device, to input and output data and code to and from thecomputer system 500 inFIG. 5 . The system software for implementing embodiments of the present disclosure is stored on such a portable medium and input to thecomputer system 500 via theportable storage device 540. -
User input devices 560 can provide a portion of a user interface.User input devices 560 may include one or more microphones, an alphanumeric keypad, such as a keyboard, for inputting alphanumeric and other information, or a pointing device, such as a mouse, a trackball, stylus, or cursor direction keys.User input devices 560 can also include a touchscreen. Additionally, thecomputer system 500 as shown inFIG. 5 includesoutput devices 550.Suitable output devices 550 include speakers, printers, network interfaces, and monitors. - Graphics display
system 570 include a liquid crystal display (LCD) or other suitable display device. Graphics displaysystem 570 is configurable to receive textual and graphical information and processes the information for output to the display device. - Peripheral device(s) 580 may include any type of computer support device to add additional functionality to the
computer system 500. - The components provided in the
computer system 500 inFIG. 5 are those typically found in computer systems that may be suitable for use with embodiments of the present disclosure and are intended to represent a broad category of such computer components that are well known in the art. Thus, thecomputer system 500 inFIG. 5 can be a personal computer (PC), hand held computer system, telephone, mobile computer system, workstation, tablet, phablet, mobile phone, server, minicomputer, mainframe computer, wearable, or any other computer system. The computer may also include different bus configurations, networked platforms, multi-processor platforms, and the like. Various operating systems may be used including UNIX, LINUX, WINDOWS, MAC OS, PALM OS, QNX ANDROID, IOS, CHROME, and other suitable operating systems. - Some of the above-described functions may be composed of instructions that are stored on storage media (e.g., computer-readable medium). The instructions may be retrieved and executed by the processor. Some examples of storage media are memory devices, tapes, disks, and the like. The instructions are operational when executed by the processor to direct the processor to operate in accord with the technology. Those skilled in the art are familiar with instructions, processor(s), and storage media.
- In some embodiments, the
computer system 500 may be implemented as a cloud-based computing environment, such as a virtual machine operating within a computing cloud. In other embodiments, thecomputer system 500 may itself include a cloud-based computing environment, where the functionalities of thecomputer system 500 are executed in a distributed fashion. Thus, thecomputer system 500, when configured as a computing cloud, may include pluralities of computing devices in various forms, as will be described in greater detail below. - In general, a cloud-based computing environment is a resource that typically combines the computational power of a large grouping of processors (such as within web servers) and/or that combines the storage capacity of a large grouping of computer memories or storage devices. Systems that provide cloud-based resources may be utilized exclusively by their owners or such systems may be accessible to outside users who deploy applications within the computing infrastructure to obtain the benefit of large computational or storage resources.
- The cloud is formed, for example, by a network of web servers that comprise a plurality of computing devices, such as the
computer system 500, with each server (or at least a plurality thereof) providing processor and/or storage resources. These servers manage workloads provided by multiple users (e.g., cloud resource consumers or other users). Typically, each user places workload demands upon the cloud that vary in real-time, sometimes dramatically. The nature and extent of these variations typically depends on the type of business associated with the user. - It is noteworthy that any hardware platform suitable for performing the processing described herein is suitable for use with the technology. The terms “computer-readable storage medium” and “computer-readable storage media” as used herein refer to any medium or media that participate in providing instructions to a CPU for execution. Such media can take many forms, including, but not limited to, non-volatile media, volatile media and transmission media. Non-volatile media include, for example, optical, magnetic, and solid-state disks, such as a fixed disk. Volatile media include dynamic memory, such as system RAM. Transmission media include coaxial cables, copper wire and fiber optics, among others, including the wires that comprise one embodiment of a bus. Transmission media can also take the form of acoustic or light waves, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, a hard disk, magnetic tape, any other magnetic medium, a CD-ROM disk, digital video disk (DVD), any other optical medium, any other physical medium with patterns of marks or holes, a RAM, a PROM, an EPROM, an EEPROM, a FLASH memory, any other memory chip or data exchange adapter, a carrier wave, or any other medium from which a computer can read.
- Various forms of computer-readable media may be involved in carrying one or more sequences of one or more instructions to a CPU for execution. A bus carries the data to system RAM, from which a CPU retrieves and executes the instructions. The instructions received by system RAM can optionally be stored on a fixed disk either before or after execution by a CPU.
- Computer program code for carrying out operations for aspects of the present technology may be written in any combination of one or more programming languages, including an object oriented programming language such as JAVA, SMALLTALK, C++ and the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
- The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present technology has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. Exemplary embodiments were chosen and described in order to best explain the principles of the present technology and its practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
- Aspects of the present technology are described above with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
- These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
- The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
- The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present technology. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, 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 involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
- The description of the present technology has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. Exemplary embodiments were chosen and described in order to best explain the principles of the present technology and its practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
Claims (21)
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/723,316 US9189778B1 (en) | 2014-05-28 | 2015-05-27 | Switch server system interoperable with mobile devices providing secure communications |
US14/822,734 US10810573B2 (en) | 2014-05-28 | 2015-08-10 | Switch server system interoperable with mobile devices providing secure communications |
US17/070,860 US20210027272A1 (en) | 2014-05-28 | 2020-10-14 | Switch Server System Interoperable with Mobile Devices Providing Secure Communications |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201462004091P | 2014-05-28 | 2014-05-28 | |
US14/723,316 US9189778B1 (en) | 2014-05-28 | 2015-05-27 | Switch server system interoperable with mobile devices providing secure communications |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/822,734 Continuation US10810573B2 (en) | 2014-05-28 | 2015-08-10 | Switch server system interoperable with mobile devices providing secure communications |
Publications (2)
Publication Number | Publication Date |
---|---|
US9189778B1 US9189778B1 (en) | 2015-11-17 |
US20150348010A1 true US20150348010A1 (en) | 2015-12-03 |
Family
ID=54434629
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/723,316 Active US9189778B1 (en) | 2014-05-28 | 2015-05-27 | Switch server system interoperable with mobile devices providing secure communications |
US14/822,734 Active 2039-05-02 US10810573B2 (en) | 2014-05-28 | 2015-08-10 | Switch server system interoperable with mobile devices providing secure communications |
US17/070,860 Pending US20210027272A1 (en) | 2014-05-28 | 2020-10-14 | Switch Server System Interoperable with Mobile Devices Providing Secure Communications |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/822,734 Active 2039-05-02 US10810573B2 (en) | 2014-05-28 | 2015-08-10 | Switch server system interoperable with mobile devices providing secure communications |
US17/070,860 Pending US20210027272A1 (en) | 2014-05-28 | 2020-10-14 | Switch Server System Interoperable with Mobile Devices Providing Secure Communications |
Country Status (2)
Country | Link |
---|---|
US (3) | US9189778B1 (en) |
WO (1) | WO2015183999A1 (en) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107507037A (en) * | 2017-08-29 | 2017-12-22 | 北纬通信科技南京有限责任公司 | Server, the present method for pushing on present column and storage medium |
US10810573B2 (en) | 2014-05-28 | 2020-10-20 | One Global Service For General Trading Llc | Switch server system interoperable with mobile devices providing secure communications |
Families Citing this family (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN106878236A (en) * | 2015-12-11 | 2017-06-20 | 阿里巴巴集团控股有限公司 | A kind of user's request processing method and equipment |
CN107180346A (en) * | 2016-05-16 | 2017-09-19 | 上海阿意梯医疗器械有限公司 | A kind of cosmetics payment system |
CN109313759B (en) | 2016-06-11 | 2022-04-26 | 苹果公司 | User interface for transactions |
US10621581B2 (en) | 2016-06-11 | 2020-04-14 | Apple Inc. | User interface for transactions |
US20180068313A1 (en) | 2016-09-06 | 2018-03-08 | Apple Inc. | User interfaces for stored-value accounts |
CN106485571A (en) * | 2016-09-30 | 2017-03-08 | 乐视控股(北京)有限公司 | A kind of method of servicing of Multifunctional integration and device |
JP6711734B2 (en) * | 2016-10-31 | 2020-06-17 | 株式会社日立製作所 | Trading system, trading system control method, and program therefor |
CN106651298A (en) * | 2016-11-18 | 2017-05-10 | 山东浪潮商用***有限公司 | Self-service method for examining, approving, verifying and issuing pre-application information |
CN112150133B (en) | 2017-05-16 | 2022-05-03 | 苹果公司 | User interface for peer-to-peer transmission |
US11221744B2 (en) | 2017-05-16 | 2022-01-11 | Apple Inc. | User interfaces for peer-to-peer transfers |
US20190114598A1 (en) * | 2017-10-18 | 2019-04-18 | Mastercard International Incorporated | Payment network as a platform |
CN107818457A (en) * | 2017-10-30 | 2018-03-20 | 江西博瑞彤芸科技有限公司 | Payment processing method |
EP3803649A1 (en) | 2018-06-03 | 2021-04-14 | Apple Inc. | User interfaces for transfer accounts |
US11100498B2 (en) | 2018-06-03 | 2021-08-24 | Apple Inc. | User interfaces for transfer accounts |
US10853115B2 (en) | 2018-06-25 | 2020-12-01 | Amazon Technologies, Inc. | Execution of auxiliary functions in an on-demand network code execution system |
US11099870B1 (en) | 2018-07-25 | 2021-08-24 | Amazon Technologies, Inc. | Reducing execution times in an on-demand network code execution system using saved machine states |
US11943093B1 (en) | 2018-11-20 | 2024-03-26 | Amazon Technologies, Inc. | Network connection recovery after virtual machine transition in an on-demand network code execution system |
US11861386B1 (en) * | 2019-03-22 | 2024-01-02 | Amazon Technologies, Inc. | Application gateways in an on-demand network code execution system |
US11328352B2 (en) | 2019-03-24 | 2022-05-10 | Apple Inc. | User interfaces for managing an account |
US11119809B1 (en) | 2019-06-20 | 2021-09-14 | Amazon Technologies, Inc. | Virtualization-based transaction handling in an on-demand network code execution system |
US11714682B1 (en) | 2020-03-03 | 2023-08-01 | Amazon Technologies, Inc. | Reclaiming computing resources in an on-demand code execution system |
US11632367B2 (en) | 2020-05-28 | 2023-04-18 | Capital One Services, Llc | System and method for agnostic authentication of a client device |
US11550713B1 (en) | 2020-11-25 | 2023-01-10 | Amazon Technologies, Inc. | Garbage collection in distributed systems using life cycled storage roots |
US11593270B1 (en) | 2020-11-25 | 2023-02-28 | Amazon Technologies, Inc. | Fast distributed caching using erasure coded object parts |
US11983702B2 (en) | 2021-02-01 | 2024-05-14 | Apple Inc. | Displaying a representation of a card with a layered structure |
US11921992B2 (en) | 2021-05-14 | 2024-03-05 | Apple Inc. | User interfaces related to time |
CN113570360B (en) * | 2021-06-30 | 2024-03-19 | ***股份有限公司 | Payment method, device, equipment and medium |
EP4123536A1 (en) * | 2021-07-22 | 2023-01-25 | Deutsche Telekom AG | Method and system for configuring a mobile point-of-sales application |
US11784956B2 (en) | 2021-09-20 | 2023-10-10 | Apple Inc. | Requests to add assets to an asset account |
US11968280B1 (en) | 2021-11-24 | 2024-04-23 | Amazon Technologies, Inc. | Controlling ingestion of streaming data to serverless function executions |
US12015603B2 (en) | 2021-12-10 | 2024-06-18 | Amazon Technologies, Inc. | Multi-tenant mode for serverless code execution |
CN114513364B (en) * | 2022-02-25 | 2024-03-15 | 杭州涂鸦信息技术有限公司 | Service authorization method and related components |
Family Cites Families (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7784684B2 (en) * | 2002-08-08 | 2010-08-31 | Fujitsu Limited | Wireless computer wallet for physical point of sale (POS) transactions |
US7822688B2 (en) * | 2002-08-08 | 2010-10-26 | Fujitsu Limited | Wireless wallet |
US20070022047A1 (en) * | 2005-07-25 | 2007-01-25 | Blackhawk Marketing Services, Inc. | Payment program for use in point-of-sale transactions |
WO2009136404A2 (en) * | 2008-04-17 | 2009-11-12 | Atom Technologies Limited | A system and method for implementing a secure transaction through mobile communicating device |
US8346628B2 (en) * | 2009-11-16 | 2013-01-01 | Sosbuzz, Inc. | Searcher call back request system and method |
US8635157B2 (en) * | 2010-07-19 | 2014-01-21 | Payme, Inc. | Mobile system and method for payments and non-financial transactions |
WO2012073014A1 (en) * | 2010-11-29 | 2012-06-07 | Mobay Technologies Limited | A system for verifying electronic transactions |
TWI588761B (en) * | 2010-12-28 | 2017-06-21 | li-he Yao | Wireless secure transaction payment system and its method |
US10102591B2 (en) * | 2011-01-21 | 2018-10-16 | Livingsocial, Inc. | Systems and methods to implement point of sale (POS) terminals, process orders and manage order fulfillment |
EP2705479A4 (en) | 2011-05-03 | 2014-12-24 | Panther Payments Llc | Method and system for facilitating person-to person payments |
SE1200088A1 (en) * | 2012-02-10 | 2013-08-11 | Seamless Distrib Ab | Procedure and systems |
US9129276B1 (en) * | 2011-11-02 | 2015-09-08 | Intuit Inc. | Inventory management |
CA3107007A1 (en) * | 2012-03-23 | 2013-09-26 | Digital Retail Apps., Inc. | System and method for facilitating secure self payment transactions of retail goods |
US20230196328A1 (en) * | 2013-02-14 | 2023-06-22 | Advanced New Technologies Co., Ltd. | Data interaction method and device, and offline credit payment method and device |
GB201302993D0 (en) * | 2013-02-20 | 2013-04-03 | Barclays Bank Plc | Application, method and system for purchasing a product |
US9189778B1 (en) * | 2014-05-28 | 2015-11-17 | Isys US, Inc. | Switch server system interoperable with mobile devices providing secure communications |
-
2015
- 2015-05-27 US US14/723,316 patent/US9189778B1/en active Active
- 2015-05-27 WO PCT/US2015/032735 patent/WO2015183999A1/en active Application Filing
- 2015-08-10 US US14/822,734 patent/US10810573B2/en active Active
-
2020
- 2020-10-14 US US17/070,860 patent/US20210027272A1/en active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10810573B2 (en) | 2014-05-28 | 2020-10-20 | One Global Service For General Trading Llc | Switch server system interoperable with mobile devices providing secure communications |
CN107507037A (en) * | 2017-08-29 | 2017-12-22 | 北纬通信科技南京有限责任公司 | Server, the present method for pushing on present column and storage medium |
Also Published As
Publication number | Publication date |
---|---|
US10810573B2 (en) | 2020-10-20 |
US20210027272A1 (en) | 2021-01-28 |
US9189778B1 (en) | 2015-11-17 |
US20150348031A1 (en) | 2015-12-03 |
WO2015183999A1 (en) | 2015-12-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20210027272A1 (en) | Switch Server System Interoperable with Mobile Devices Providing Secure Communications | |
US11676129B2 (en) | Offline bill splitting system | |
US11783343B2 (en) | Token aggregation for multi-party transactions | |
CN113379401B (en) | Secure processing of electronic payments | |
US10002353B2 (en) | Methods and systems for conducting transactions | |
EP3848874B1 (en) | Systems and methods for facilitating a transaction using a virtual card on a mobile device | |
US20170200155A1 (en) | Generating and sending encrypted payment data messages between computing devices to effect a transfer of funds | |
US8856043B2 (en) | Method and system for managing data and enabling payment transactions between multiple entities | |
US20140129422A1 (en) | Systems and methods for issuing mobile payment cards via a mobile communication network and internet-connected devices | |
WO2017160877A1 (en) | Technical architecture supporting tokenized payments | |
US20070125840A1 (en) | Extended electronic wallet management | |
US11803832B2 (en) | Smart card NFC secure money transfer | |
JP6775590B2 (en) | Systems and methods to promote secure electronic commerce | |
US20170068937A1 (en) | Mobile payment method and system | |
US20230004974A1 (en) | Plan interaction utilizing cryptogram | |
US20170169425A1 (en) | Selective encryption of transactional information for different participants of an electronic transaction | |
US11985241B2 (en) | Method and system for token transfer | |
US11636466B2 (en) | Offline coin protocol | |
US20230289792A1 (en) | System and Method for Authorizing Temporary Use of Accounts | |
WO2014019026A1 (en) | Electronic transction system and method | |
CA3146619A1 (en) | System and method for authorizing temporary use of accounts | |
KR20120029203A (en) | Electronic settlement method using storage medium of mobile smart device | |
WO2014113847A1 (en) | Payment system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: ISYS GENERAL TRADING GROUP, KUWAIT Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SH. AL-RASHIDI, MOHAMMED;REEL/FRAME:035906/0309 Effective date: 20140601 Owner name: ISYS US, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ISYS GENERAL TRADING GROUP;REEL/FRAME:035906/0423 Effective date: 20150527 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YR, SMALL ENTITY (ORIGINAL EVENT CODE: M2551); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY Year of fee payment: 4 |
|
AS | Assignment |
Owner name: ONE GLOBAL SERVICE FOR GENERAL TRADING LLC, KUWAIT Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ISYS US, INC.;REEL/FRAME:053720/0854 Effective date: 20200909 |
|
MAFP | Maintenance fee payment |
Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YR, SMALL ENTITY (ORIGINAL EVENT CODE: M2552); ENTITY STATUS OF PATENT OWNER: SMALL ENTITY Year of fee payment: 8 |