PROVIDING SHIPPING DETAILS ON A PAY TRANSACTION VIA THE INTERNET
E-commerce personal account numbers, shipping addresses, and other data may be tokenized to facilitate transaction completion by establishing e-commerce browser standards. Tag data may be received from a website associated with an e-commerce transaction. The tag data may include an indication that a merchant payment webpage is configured to receive a payment transaction via a token. Tokens may then be created from a personal account number and a shipping address corresponding to the personal account number in response to a request for token data.
This application claims the benefit of U.S. Provisional Application No. 62/321,094, entitled “EXPEDITED E-COMMERCE TOKENIZATION” filed Apr. 11, 2016 and priority to Indian patent application IN 6294/CHE/2015, entitled “A SYSTEM AND METHOD FOR CONDUCTING A TRANSACTION” filed Nov. 23, 2015. The disclosures of both applications are incorporated herein by reference.
BACKGROUNDThe background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.
When cards are used for payment purposes during checkout, E-Commerce merchants as well as payment service providers (PSPs) may traditionally allow browser auto-form fills during checkout to expedite the consumer's payment process. Merchants and PSPs then use the card information stored on file during this process. However, when a card on file has expired, the merchant/PSP has to nudge the consumer to either provide the refreshed expiry date or select another card. This practice often leads to consumer drop-offs.
When these merchants/PSPs tokenize the cards using a token service token requestor such as Browser Partners or E-Commerce Enablers, while the benefits of tokenization are reaped, these token numbers cannot be auto-filled or key entered in the consumer browser.
Likewise, the use of communication devices such as mobile phones in conducting financial transactions is becoming widespread. In some cases, mobile phones enable consumers to scan graphical codes, such as quick response barcodes, to initiate payments in favor of a merchant displaying the graphical code.
While these techniques enable consumers to quickly initiate a payment in favor of a merchant, in many transaction types, additional information will be required by the merchant. For example, in the case of an electronic commerce (e-commerce) transaction, the merchant will typically require a shipping address and possibly contact information of the consumer to enable the merchant to ship the purchased product to the consumer.
Requiring the user to provide such further information may slow down the process of transacting and may in turn increase the difficulty experienced by consumers in transacting.
It may further be troublesome for merchants to receive a consumer's shipping address from one source and confirmation of payment from another source. Receiving information from disparate sources may increase back-end processing which the merchant needs to perform, for example, in tying the shipping address of the consumer received from one source with the payment confirmation received from another source such as the merchant's financial institution.
SUMMARYFeatures and advantages described in this summary and the following detailed description are not all-inclusive. Many additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims hereof. Additionally, other embodiments may omit one or more or all of the features and advantages described in this summary.
Systems and methods described herein may expedite e-commerce tokenization and transaction completion by establishing e-commerce browser standards around tokenization for merchants and PSPs, reducing friction during checkout thereby increasing conversion rates, and circumventing the expired cards problem with tokenization by requesting a valid and unique cryptogram. Another aspect may include tokenization of the card used in checkout.
A method for conducting a transaction in which funds are transferred from a payer to a payee, may be conducted at an issuer server computer associated with the payer. The method may include receiving, from a communication device of the payer, a transaction message including an amount associated with the transfer of funds, an account identifier of the payee, and a permission indication that presents the payer's approval or denial in respect of sharing with the payee personal information requested by the payee. If the permission indication indicates that the requested personal information may be shared with the payee, the method may generate a transaction request message including the amount, the account identifier of the payee and the requested personal information. The method may then transmit the transaction request message for receipt by an acquirer server computer associated with the payee for processing the transaction and conditional forwarding of the requested personal information to the payee.
A further feature provides for the method to include, if the permission indication indicates that the requested personal information may not be shared with the payee, generating a transaction request message including the amount and the account identifier of the payee.
Still further features provide for the transaction to be a push transaction; and for the transaction request message to an original credit transaction request message.
A yet further feature provides for the personal information to include one or more of the group of: a shipping address, an email address, and a phone number.
An even further feature provides for the permission indication to include the requested personal information.
A further feature provides for the method to include retrieving the personal information from a data record associated with the payer.
A still further feature provides for the method to include receiving a transaction response message confirming or denying the transaction.
Yet further features provide for transmitting the transaction request message for receipt by the acquirer server computer to include transmitting the transaction request message to the acquirer server computer via a payment processing network, and for the account identifier of the payee to include routing information usable by the payment processing network in routing the transaction request message to the acquirer server computer. The payment processing network may be an interoperable payment processing network.
A method may also conduct a transaction in which funds are transferred from a payer to a payee. The method may be conducted at a communication device of the payer comprising: obtaining, from a tag, an account identifier of the payee and a personal information flag indicating that personal information of the payer is requested by the payee; prompting the payer for permission to share the requested personal information with the payee; receiving the payer's approval or denial in respect of sharing the requested personal information with the payee; generating a transaction message including an amount associated with the transfer of funds, the account identifier of the payee and a permission indication indicating the payer's approval or denial in respect of sharing the requested personal information with the payee; and, transmitting the transaction message to an issuer server computer associated with the payer for processing the transaction and conditional forwarding of the requested personal information to the payee.
A further feature provides for the tag to be one of: a radio frequency beacon, a near sound communication beacon, or graphical code.
Still further features provide for the personal information to include one or more of the group of: a shipping address, an email address, and a phone number, and for the personal information flag to indicate that one or more of a shipping address, an email address, and a phone number of the payer is requested by the payee.
A yet further feature provides for prompting the payer for permission to share the requested personal information with the payee to include displaying the personal information which will be shared with the payee.
A still further feature provides for prompting the payer for permission to share the requested personal information with the payee to include providing the payer with an option to edit the personal information which will be shared with the payee.
A yet further feature provides for prompting the payer for permission to share the requested personal information with the payee to include providing the payer with an option to select personal information of a contact of the payer which will be shared with the payee.
A system may conduct a transaction in which funds are transferred from a payer to a payee, the system including an issuer server computer associated with the payer, comprising: a payer messaging component for receiving, from a communication device of the payer, a transaction message including an amount associated with the transfer of funds, an account identifier of the payee, and a permission indication indicating the payer's approval or denial in respect of sharing with the payee personal information requested by the payee; a generating component for, if the permission indication indicates that the requested personal information may be shared with the payee, generating a transaction request message including the amount, the account identifier of the payee and the requested personal information; and, a payment network messaging component for transmitting the transaction request message for receipt by an acquirer server computer associated with the payee for processing the transaction and conditional forwarding of the requested personal information to the payee.
A further feature provides for the generating component to be for, if the permission indication indicates that the requested personal information may not be shared with the payee, generating a transaction request message including the amount and the account identifier of the payee.
Still further features provide for the transaction to be a push transaction and for the transaction request message to be an original credit transaction request message.
A yet further feature provides for the personal information to include one or more of the group of: a shipping address, an email address, and a phone number.
An even further feature provides for the permission indication to include the requested personal information.
A still further feature provides for the system to include a retrieving component for retrieving the personal information from a data record associated with the payer.
A further feature provides for the payment network messaging component further to be for receiving a transaction response message confirming or denying the transaction.
A still further feature provides for the payment network messaging component to transmit the transaction request message to the acquirer server computer via a payment processing network, and for the account identifier of the payee to include routing information usable by the payment processing network in routing the transaction request message to the acquirer server computer. The payment processing network may be an interoperable payment processing network.
A system may also conduct a transaction in which funds are transferred from a payer to a payee, the system including a communication device of the payer, comprising: an obtaining component for obtaining, from a tag, an account identifier of the payee and a personal information flag indicating that personal information of the payer is requested by the payee; a prompting component for prompting the payer for permission to share the requested personal information with the payee; an input component for receiving the payer's approval or denial in respect of sharing the requested personal information with the payee; a generating component for generating a transaction message including an amount associated with the transfer of funds, the account identifier of the payee and a permission indication indicating the payer's approval or denial in respect of sharing the requested personal information with the payee; and, a transmitting component for transmitting the transaction message to an issuer server computer associated with the payer for processing the transaction and conditional forwarding of the requested personal information to the payee.
A further feature provides for the tag to be one of: a radio frequency beacon, a near sound communication beacon, or graphical code.
A still further feature provides for the personal information to include one or more of the group of: a shipping address, an email address, and a phone number, and for the personal information flag to indicate that one or more of a shipping address, an email address, and a phone number of the payer is requested by the payee.
A yet further feature provides for the prompting component to display the personal information which will be shared with the payee.
A further feature provides for the prompting component to provide the payer with an option to edit the personal information which will be shared with the payee.
A still further feature provides for the prompting component to provide the payer with an option to select personal information of a contact of the payer which will be shared with the payee.
A computer program product may conduct a transaction in which funds are transferred from a payer to a payee, the computer program product comprising a computer-readable medium having stored computer-readable program code for performing the steps of: receiving, from a communication device of the payer, a transaction message including an amount associated with the transfer of funds, an account identifier of the payee, and a permission indication indicating the payer's approval or denial in respect of sharing with the payee personal information requested by the payee; if the permission indication indicates that the requested personal information may be shared with the payee, generating a transaction request message including the amount, the account identifier of the payee and the requested personal information; and, transmitting the transaction request message for receipt by an acquirer server computer associated with the payee for processing the transaction and conditional forwarding of the requested personal information to the payee.
Another computer program product may conduct a transaction in which funds are transferred from a payer to a payee, the computer program product comprising a computer-readable medium having stored computer-readable program code for performing the steps of: obtaining, from a tag, an account identifier of the payee and a personal information flag indicating that personal information of the payer is requested by the payee; prompting the payer for permission to share the requested personal information with the payee; receiving the payer's approval or denial in respect of sharing the requested personal information with the payee; generating a transaction message including an amount associated with the transfer of funds, the account identifier of the payee and a permission indication indicating the payer's approval or denial in respect of sharing the requested personal information with the payee; and, transmitting the transaction message to an issuer server computer associated with the payer for processing the transaction and conditional forwarding of the requested personal information to the payee.
Further features provide for the computer-readable medium to be a non-transitory computer-readable medium and for the computer-readable program code to be executable by a processing circuit.
Persons of ordinary skill in the art will appreciate that elements in the figures are illustrated for simplicity and clarity so not all connections and options have been shown to avoid obscuring the inventive aspects. For example, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are not often depicted in order to facilitate a less obstructed view of these various embodiments of the present disclosure. It will be further appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. It will also be understood that the terms and expressions used herein are to be defined with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein.
DETAILED DESCRIPTIONThe present invention now will be described more fully with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific exemplary embodiments by which the invention may be practiced. These illustrations and exemplary embodiments are presented with the understanding that the present disclosure is an exemplification of the principles of one or more inventions and is not intended to limit any one of the inventions to the embodiments illustrated. The invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Among other things, the present invention may be embodied as methods, systems, computer readable media, apparatuses, or devices. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. The following detailed description is, therefore, not to be taken in a limiting sense.
Payment services may be designed to make payments easier and smoother. In one aspect, payment services may receive one or more payment devices such as credit cards or payment accounts. The account data such as account number, account name, billing address, shipping address, etc., may only need to be entered once and the payment service will securely store the account data using an account name. In use, a user may only need to have a payment system log-on and password to make a payment using any of the various accounts that the user has added to the payment system. In operation, the payment system may not communicate an actual account number to a merchant but may communicate a short term account number in a token for that specific transaction with the payment service may translate into the actual account number on the backend.
As illustrated in
Token Data 110, 204 may include one or more of unencrypted and encrypted data. In some embodiments, unencrypted data of the token data 110, 204 may include non-sensitive information for display purposes to the consumer without requiring decryption. For example, the unencrypted token data may include a last four digits of a credit card number, or PAN, a customer ZIP code, country, or other data. In further embodiments, encrypted data of the token data 110, 204 may include sensitive information for transaction purposes. For example, encrypted token data 110, 204 may include payment fields as obtained from the token server which may include a token number, a token expiration date, a token cryptogram TAVV, a card or PAN number, or an ECI indicator. Consumer profile fields may also be unencrypted or encrypted, as available by the Token Requestor and depending on a customer's data sensitivity. For example, a billing address, a shipping address, an email address, or phone numbers may be tokenized as encrypted or unencrypted data. Of course, any or all of the data may be tokenized as needed by the systems and method described herein. For example, the shipping information for a purchase may be tokenized and inserted into a transaction so that a customer does not have to enter the details once a payment method is selected.
A token requestor 104 may be integrated with the token server 102. One or more APIs executing on the server 102 may also enroll and provision Personal Account Numbers PANs as well as receive cryptograms for provisioned tokens. Table 1 below may provide an overview of the basic APIs corresponding to the server 102 used to explain some of the use cases.
At 302, a consumer browser 302 may be directed to a website interface 304. In some embodiments, the interface 304 may include a merchant payment webpage 304a of the interface 304 that is configured to initiate the checkout process such as when a consumer has selected items and is preparing to pay for the items. A local or remote shopping server (e.g., a server 203 hosting the partner interface 202) may host the merchant interface 304.
At 306, one or more tags 304b at the merchant's payment page 304a may be sent to a token requestor module 312. In some embodiments, the tags 304b may include a “Token Ready” tag and/or a “Token Client ID” tag. The tags 304b may be visible to the consumer or may only be available to backend servers such as the payment service 308.
At 310, in response to receiving the “Token Ready” tag and/or a “Token Client ID” tag, the token requestor module 312 may identify the page to be “Token Ready,” validate the Token Client ID tag via the one or more tags 304b, and, via the consumer browser module 302, present the Consumer the option to select a payment device such as an existing credit card or a new card using the payment system. Logically, if the page is not token ready and/or the token client ID is not validated, the customer may not be able to use a token-based payment service as represented by the flow of data 300. The token requestor 312 may be part of the shopping server 203 or may be a separate server which is physically configured to request tokens.
At block 314, the consumer browser 302 may receive an input indicating selection of a payment device such as a card on file or add a new card to the payment application. The selection may be as simple as clicking on a visual representation of one of the accounts that have been added to the payment system via the browser 304. The selection may then be sent to the token requestor module 312.
At block 316, a token requestor 312 may receive token data from a token server 308 at the token service 308a for the payment device or card and other information. In some embodiments, if the payment device is an existing card with a provisioned token, the token requestor 312 may request the token server 308 for a cryptogram and receive the cryptogram using a Get Payment Data API call to the checkout module 308b. In further embodiments, if the payment device is an existing card with a provisioned token, the token requestor 312 may request the token server 308 for a further cryptogram and receive the further cryptogram using a Get Shipping Details API call to the checkout module 308b corresponding to a token that includes the shipping details of the customer. The token server 308 may be a server physically configured to handle the request, creation or provisioning, and communication of tokens. If the payment device is a new card, the token requestor 312 may enroll the card and provision the PAN first (i.e., execute both an Enroll PAN API call and a Provisioned Token API call to the checkout module 308b), and then may request a cryptogram from the token service 308a for the token using Get Payment Data API. A user interface may be presented to the user via the browser 304 to assist in adding the new payment device.
At block 318, the token requestor 312 may use a Token Client ID API to encrypt the token data 110, 204 as well as other data elements provided in token data 110, 204, as described herein. The encryption may be any known encryption that is appropriate and widely accepted in the payment system.
At block 320, the token requestor 102 may push token details to the browser 304 in the “Token Data” tag structure 320a, described below, via the merchant interface 304. As the tag structure is known and standard, the merchant interface 304 may be configured to auto fill data 320b from the payment system which may make payments easier for consumers and may mean more sales for merchants. For example, consumers have become accustomed to shipping addresses being auto-filled and the described system enables such auto-filling to continue using a payment service.
Further, assuming the standard is followed by other payments systems, receiving auto fill data 320b from a variety of systems may be simplified. For example, currently Payment System A may have a name field as the first element in a communication while Payment System B may have a name field as the fifth element in a communication. By following a standard, the Merchant will not have to have separate procedures for Payment System A and Payment System B but will simply have to follow the standard for payment system data exchange.
At block 322, the Merchant Interface 304 or PSP may obtain the token details in the “Token Data” tag, and may display appropriate card details, shipping data, and other information from the token data 110, 204 to the consumer. In some embodiments, the interface 304 may be configured to use a cryptogram created by the token service 308a to decipher and display the token data within the merchant payment webpage 304a. From the displayed information, a user may be able to accept or reject the displayed card and account details.
At block 324, the consumer may review the payment device card information and may submit the order. For example, if the payment details are not as expected, the order may be canceled but if the payment details are as expected, the order may proceed. In some embodiments, the Merchant Interface 304 or PSP may select to display one or more of the following from the token data 320a to the consumer: a) Payment data; b) Last 4 of card; and/or c) Value added data elements as decided by the Merchant/PSP (e.g. Shipping & Billing Details).
At block 326, the merchant interface 304 or PSP may map the token details to an e-commerce authorization request 326a, and may submit the request 326a to the issuer server 328 through its acquiring channel for approval. The approval may be made by an approval module 328a which may be local or remote to the issuer server 328 and may be physically configured to make and communicate authorization decisions.
At block 330, the e-commerce authorization request may be approved or declined, and the corresponding authorization response 330a may be sent back to the merchant. If the authorization is declined, a user may be permitted to submit the authorization data again. In some embodiments, the flow 300 may execute a Get Shipping Details API call to the checkout module 308b and insert shipping details into the transaction upon receiving an indication that the transaction was approved.
To aid implementation of the method 300, the various requirements as well as recommendations to Token Requestors 312, the Merchant Interface 304 as well as Payment Service Providers PSPs in the payment experience, the following system elements and tags 304b may be communicated among the various modules, entities, etc., of the flow 300 as follows:
“Token Ready” Tag
1. Merchant or PSP Interface 304 receiving the token details may need to enable an HTML tag on the payment page to mark it “Token Ready.”
2. Token Requestor 312 may need to be able to identify the payment page as being “Token Ready,” and subsequently trigger the corresponding E-Commerce payment experience in executing the steps of the flow 300 described herein.
“Token Client ID” tag
1. Merchant or PSP Interface 304 receiving the token details may need to enable an HTML tag “Token Client ID” tag to specify its relationship with Token Requestor 312.
a. Merchant Interface 304 may have a direct relationship with Token Requestor 312, or
b. Merchant Interface 304 may be connected to the Token Requestor 312 via a PSP or partner Acquirer/Gateway/E-Commerce Payment Service Provider.
2. Token Requestor 312 may be able to validate the “Token Client ID” tag 304b as well as use it to encrypt token data.
“Token Data” Tag 320a
1. Token Requestor 312 may need to be able to return token details obtained from token server 308 required for the consumer's order confirmation, receipt as well as payment authorization in “Token Data” tag 320a.
2. Merchant or PSP Interface 304 receiving token elements may need to be able to receive token data in the “Token Data” tag 320a.
3. The value added data elements (e.g., customer shipping information as retrieved and tokenized using the Get Shipping Details API call to the checkout module 308b) may contain more elements than the ones specified in the list below, and may be dependent on their availability and data sensitivity.
Table 2, below, shows some procedures which may make the e-commerce tokenization procedures described herein more expedited and efficient.
Data Encryption
The token data 110, 204, tag data 304b and other data to implement the embodiments described herein may be encrypted. As shown in Table 3, the encryption may apply to personal account identifiers or other information that may be traced to an account that is sent by the token requestor 312 to the merchant or PSP interface 304.
Finally, the Merchant or PSP interface 304 may decrypt the encrypted information in token data 304b to assist in auto-filing fields and presenting data to users to speed transactions and make transactions more trustworthy from a user's perspective.
As a result of the system and the unified format described herein, a merchant may be able to make a single request for a certain type of data without regard to the payment service receiving the request. Currently, each payment service has a different way to name each data field, a different API to call for certain data, a different manner of delivering the data, etc. As a result, a merchant has to add programming for each payment service that is supported along with the appropriate APIs for each payment service. By having a consistent manner of naming data, calling for data, receiving data, etc., the amount of programming may significantly drop. Further, the exchange with payment applications may be more reliable as the data exchange should follow a standard.
A more recent complexity is the use of tokens. Tokens are not actual PANs but may be used as a proxy for a PAN wherein an authority can translate the token data 304b into a PAN but the token data is the only data disclosed on a network. By following the blocks of the embodiments described herein, account data which may be stored by the token server 308 may still be accessed and used for autofill purposes to assist users in filling out forms which can be filled with autofill data. Such data was often previously unavailable to merchants when tokens were used. By addressing this technical problem of user data being hidden behind tokens, the user data may now be available to merchants in an encrypted manner.
Another benefit may be that expired cards may not limit a user from using a payment application to make a purchase. The merchant may request a valid and unique cryptogram which may be provided even if the underlying card has expired in certain circumstances. Instead of having to bother users to enter data on new cards with updated expiration dates, the old card may be leveraged to allow a user to continue to use the payment application to make payments. In other embodiments, the user may only have to update an expiration data and all the other card data may be auto-filled.
With reference to
In the embodiments described herein, the payee may provide its account identifier to the payer in a tag e.g., tags 304b, etc. which includes a personal information flag indicating that certain personal information of the payer is requested by the payee. Embodiments described herein may also include personal information in the tags which may be requested by the payee including one or more of the group of: a shipping address, an address of a contact other than the payer, contact information of the payer such as an email address and/or a phone number, know-your-customer KYC information, an identity number, a social security number and the like. Accordingly, and depending on whether the payer grants permission for the personal information requested by the payee to be shared with the payee, the transaction request message may include the requested personal information of the payer 412 which will be shared with the payee.
The issuer and acquirer server computers 410, 420 respectively may be any appropriate server computers, server computer clusters, distributed server computers, cloud-based server computers and the like. Each of the server computers 410, 420 may include a processor and a non-transitory computer readable medium comprising code executable by the processor to perform functions, such as generating messages, electronically receiving and transmitting messages or data, parsing messages or data, and the like. The server computers 410, 420 may be configured to transmit and receive financial system transaction messages such as ISO 8583 messages, debit and credit financial accounts, transmit messages to and receive messages from the communication devices 414, 424 respectively and the like.
The issuer server computer 410 may be maintained or operated by financial institution 416 controlling a financial account 418 of the payer. The financial account of the payer may be associated with an account identifier. Similarly, the acquirer server computer 420 may be maintained or operated by another financial institution 426 controlling a financial account 428 of the payee 412. The financial account 428 of the payee 422 may be associated with an account identifier.
The account identifiers of the payer and the payee may include routing information usable by the payment processing network 430 in routing financial system transaction response messages between the server computers 410, 420. The routing information may be a bank identification number BIN associated with the respective financial institution 416, 426 and which is usable by the payment processing network 430 in identifying the appropriate financial institution 416, 426 to which the financial system response messages should be transmitted.
The payment processing network 430 may include data processing subsystems, networks, server computers and operations used to support and deliver authorization services, exception file services, and clearing and settlement services. The payment processing network 430 may be any suitable network able to transmit and receive financial system transaction messages e.g., ISO 8583 messages, and process original credit and debit card transactions. Payment processing systems are able to process credit card transactions, debit card transactions, and other types of commercial transactions, including virtual card and mobile wallet transactions. The payment processing network 430 may be an interoperable payment processing network.
The payer's communication device 414 may be any appropriate electronic device capable of communicating over a communication network 450. The communication device 414 may be one or more of: a mobile phone, a smart phone, a wearable computing device, tablet computing device, a personal digital assistant, a laptop or desktop computer or the like. The communication device 414 may have a software application resident therein and installed thereon which may enable the communication device 414 to transmit data messages to and receive data messages from the issuer server computer 410. In other embodiments, the communication device 414 may exchange data messages with the issuer server computer 410 using Unstructured Supplementary Service Data USSD sessions or Short Messaging Service SMS messages via the communication network 450.
The payee's communication device 424 may be any appropriate electronic device capable of communicating over the communication network 450. Depending on the application, the payee communication device 424 may be a mobile phone, a point of sales device, an electronic transaction server or the like. The payee's communication device 424 may also have an appropriate software application resident therein and installed thereon which may enable the communication device 424 to transmit data messages to and receive data messages from the acquirer server computer 420.
By enabling the payer's communication device 414 to exchange messages with the issuer server computer 410, the payer 412 may be able to use the communication device 414 to transact against the financial account 418 of the payer controlled by the payer's financial institution 416. The payer may be able to initiate transactions in favor of the payee's financial account 428 by using the payer's communication device 414 to generate and transmit a transaction message, including the account identifier of the payee and an amount associated with the transfer of funds, to the issuer server computer 410. When initiating a transaction in favor of the payee, the payer may be able to indicate whether he or she permits personal information, such as a shipping address or contact information, to be shared with the payee.
In response to receiving the transaction message requesting the issuer server computer 410 to initiate a transfer of funds in favor of the payee's financial account 428, the issuer server computer 410 debits the financial account of the payer and transmits a transaction request message, including the account identifier of the payee and the amount, to the acquirer server computer 420. If the payer has indicated that personal information may be shared with the payee, the issuer server computer 410 may include this personal information in the transaction request message.
A transaction request message may be any suitable financial system transaction message transmitted from the issuer server computer 410 to the acquirer server computer 420 through the payment processing network 430. A transaction request message may be in the standard ISO 8583 messaging format, or in any other suitable financial system transaction messaging format. Suitable messages may also be in an “0200” message format. The transaction request message may be an Original Credit Transaction OCT type message.
An OCT is typically a clearing and settlement credit transaction designed for use in business applications such as a business money transfer or business-to-consumer repayments. A special indicator identifies an OCT to the recipient of the message. OCT messages may also include an Electronic Commerce Indicator ECI to indicate an Internet OCTs if appropriate. Representational State Transfer Extensible Markup Language REST-XML, REST-JavaScript Object Notation REST-JSON, and REST-Name-Value-Pairs REST-NVP templates may be used for the OCT request messages. OCT request messages described herein may include an amount associated with the transfer of funds, an account identifier of the payee, an account identifier of a payer, personal information of the payer, a message type indicator, a transaction identifier, currency information and any other appropriate information.
The transaction request message may thus be routed from the payment processing network 430 to the acquirer server computer 420. The acquirer server computer 420 credits the payee's financial account 128 and transmits a transaction response message, either confirming or denying the transaction, to the issuer server computer 410 via the payment processing network 430. A transaction response message may be any suitable message transmitted from the acquirer server computer 420 to the issuer server computer 410 through the payment processing network 430, in response to the transaction request message. A transaction response message may be in the standard ISO 8583 messaging format, or in any other suitable financial system transaction messaging format. The transaction response message may include an indication that the transfer of funds was approved or not approved.
The acquirer server computer 420 may transmit a payment confirmation message to the payee indicating the amount paid by the payer and including the personal information of the payer requested by the payee. The payee may then be able to use the personal information to communicate with the payer, for example by shipping a product purchased by the payer to the address included in the transaction request message or by acknowledging a donation received from the payer.
Turning now to
The communication device 414 of the payer may include a communication network interface 502 arranged to enable the communication device 414 to communicate with the issuer server computer 410 over the communication network 450. Further details of an embodiment of a communication device are provided with reference to
The communication device 414 may include a processor for executing the functions of the described components which may be software units executing on the communication device 414 either being resident thereon or provided remotely. Instructions may be provided to the processor to carry out the functionality of the described components.
The communication device 414 may host a banking or payment functionality provided by a payment application 503 which may include secure transaction capabilities. A payment application 503 may be provided by a financial institution or payment processing network and may be resident on the communication device 414 or may be provided as a remotely based service application.
The payment application 503 may include an obtaining component 504 which is configured to obtain information from a tag provided by the payee. The obtaining component 504 may include access to hardware components of the communication device 414 including one or more of the group of: a camera 504A for capturing information from a tag in the form of a graphical code such as a barcode, two-dimensional barcode or the like; an antenna and transceiver 504B for receiving information from a tag in the form of a radio frequency beacon such as a Near Field Communication NFC, Radio Frequency Identification RFID, Bluetooth™ Low Energy BLE beacon or the like; and a microphone 504C for receiving information from a tag in the form of a near sound communication beacon. The information obtained from the tag may include one or more of the group of: an account identifier of the payee; a personal information flag indicating that personal information of the payer is requested by the payee; an amount e.g. $200; information about the payee such as a name of the payee, an address of the payee, a merchant category code where applicable of the payee and the like.
The payment application 503 may also include a prompting component 506 arranged to prompt the payer operating the communication device 414 for permission to share the requested personal information with the payee. The prompting component 506 may prompt the payer via a message displayed on a display screen 508 of the communication device 414. The prompting component 506 may also display the personal information which will be shared with the payee together with the prompt. In some embodiments, the prompting component 506 may be configured to provide the payer with an option to edit the personal information which will be shared with the payee. It is also anticipated that the prompting component 506 may be arranged to provide the payer with an option to select personal information of a contact of the payer which will be shared with the payee, for example, where the payer is purchasing a gift for one of the payer's contacts.
The payment application 503 may further include an input component 510 which is arranged to receive the payer's approval or denial in respect of sharing the requested personal information with the payee. The input component 510 may further be configured to receive input by the payer editing the personal information to be shared with the payer or alternatively the payer's input as to a contact whose personal information should be shared with the payee. In some embodiments, the input component 510 is further configured to receive an amount input by the payer in respect of the transfer of funds e.g. where this is not included in the information received from the tag.
The payment application 503 may include a generating component 512 configured to generate a transaction message. The generating component 512 may be arranged to include one or more of: the amount associated with the transfer of funds; the account identifier of the payee obtained from the tag; the account identifier of the payer; and a permission indication indicating the payer's approval or denial in respect of sharing the requested personal information with the payee in the transaction message. In some embodiments, the generating component 512 includes a retrieving component 512A for retrieving the requested personal information from a digital memory of the communication device and including the retrieved personal information with the permission indication in the transaction message. In other embodiments, the personal information may be stored at the issuer server computer 410 for retrieval thereat.
The payment application 503 may also include a transmitting component 514 configured to transmit the generated transaction message to the issuer server computer 410 associated with the payer for processing the transaction and conditional forwarding of the requested personal information to the payee. The communication device 414 may further include a receiving component 516 for receiving a transaction confirmation or denial message confirming or denying the transaction. The transmitting component 514 and receiving component 516 may use the communication network interface 502 to transmit the transaction message to and receive the transaction confirmation or denial message from the issuer server computer 410 via the communication network 450. The issuer server computer 410 may include at least one processor, a hardware module, or a circuit for executing the functions of the described components which may be software units executing on the at least one processor.
The issuer server computer 410 may include a communication network interface 520A arranged to enable the issuer server computer 410 to communicate with the communication device 414 of the payer over the communication network 450. The issuer server computer 410 may include a payment processing network interface 520B configured to enable the issuer server computer 410 to communicate with the payment processing network 430 and in turn the acquirer server computer 420. The payment processing network interface 520B may, for example be configured to parse messages into ISO 8583 formatted messages for transmission over the payment processing network 430 as well as performing handshaking and other networking operations.
The issuer server computer 410 may also include a payer messaging bcomponent 522 which is configured to receive the transaction message from the communication device 414 of the payer. The payer messaging component 522 may receive the transaction message via the communication network interface 520A of the issuer server computer 410.
The issuer server computer 410 may also include an identifying component 524 arranged to identify a financial account and/or a data record associated with the payer. The identifying component 524 may use the account identifier of the payer included in the transaction message to identify the financial account and/or the data record. The identifying component 524 may also include a debiting component 524A for debiting the financial account with the amount associated with the transfer of funds.
The issuer server computer 410 may include an evaluating component 526 which is arranged to evaluate the permission indication included in the transaction message to determine whether the payer has granted or denied permission to the issuer server computer 410 to share personal information requested by the payee with the payee.
In some embodiments, the issuer server computer 410 includes a retrieving component 528 configured to retrieve the requested personal information, in respect of which the payer has granted permission for sharing with the payee, from the data record associated with the payer. In other embodiments, the personal information is included with the permission indication in the transaction message.
The issuer server computer 410 may include a generating component 530 arranged to, if the permission indication indicates that the requested personal information may be shared with the payee, generate a transaction request message. The generating component 530 may include one or more of the amount; the account identifier of the payee; the account identifier of the payer; the requested personal information in respect of which the payer has granted permission for sharing with the payee; and optionally additional information in the transaction request message. The transaction request message generated by the generating component 530 may be an OCT request message.
If the permission indication indicates that the requested personal information may not be shared with the payee, the generating component 530 may be configured to generate a transaction request message including the amount and the account identifier of the payee and optionally other information. In other embodiments, the transaction may fail if the permission indication indicates that the requested personal information may not be shared with the payee.
The issuer server computer 410 may also include a payment network messaging component 532 which is arranged to transmit the transaction request message for receipt by the acquirer server computer 420 associated with the payee. The payment network messaging component 532 may also be arranged to receive a transaction response message from the acquirer server computer either confirming or denying the transaction. The payment network messaging component 532 may send and receive transaction request and response messages to and from the payment processing network using the payment processing network interface 520B.
The acquirer server computer 420 may include at least one processor, a hardware module, or a circuit for executing the functions of the described components which may be software units executing on the at least one processor.
The acquirer server computer 420 may include a communication network interface 540A arranged to enable the acquirer server computer 420 to communicate with the communication device 424 of the payee over the communication network 450. The acquirer server computer 420 may include a payment processing network interface 540B configured to enable the acquirer server computer 420 to communicate with the payment processing network 430 and in turn the issuer server computer 410.
The acquirer server computer 420 may include a payment network messaging component 542 for receiving transaction request messages from the issuer server computer 410 via the payment processing network 430. The payment network messaging component 542 may also be arranged to transmit transaction response messages to the issuing server computer via the payment processing network either confirming or denying the transaction. The payment network messaging component 542 may send and receive transaction response and request messages to and from the payment processing network using the payment processing network interface 5408.
The acquirer server computer 420 may also include an extracting component 544 configured to extract the amount associated with the transfer of funds, the account identifier of the payee and the personal information from the transaction request message.
The acquirer server computer 420 may also include an identifying component 546 for identifying the financial account of the payee associated with the payee account identifier and a crediting component 546A for crediting the financial account of the payee with the amount.
The acquirer server computer 420 may further include a payee messaging component 548 arranged to transmit a confirmation or denial message to the communication device 424 of the payee either confirming or denying the transaction. The payment confirmation message may include the amount in respect of the transfer of funds as well as the personal information which was requested by the payee.
It should be appreciated that the issuer server computer 410 may be configured to act as and perform the operations of an acquirer server computer and vice versa. Thus embodiments of the described system anticipate an issuer server computer including the components of and being able to perform the functions and operations of an acquirer server computer and similarly an acquirer server computer including the components of and being able to perform the functions and operations of an issuer server computer. For example, a server computer may be an acquirer server computer to one entity and an issuer server computer to another entity. In some cases, depending on whether the entity is a payer or a payee in a particular transaction, the server computer may act as and perform the operations and functions of an acquirer server computer or an issuer server computer as may be required.
An exemplary method 600 for conducting a transaction using the system described above is illustrated in
The method may be implemented in a number of transaction scenarios. For example, in one scenario, a payer may be a consumer who notices an advertisement which advertises a product which the payee a merchant is selling. The advertisement may be a digital display and may include a tag in which the account identifier of the payer, an amount which must be paid for the product, as well as a personal information flag indicating that certain personal information of the payer will be required by the payee. The personal information flag may, for example, indicate that the payee will require a shipping address of the payer so that the product can be shipped to the payer.
In another exemplary scenario, the payee may be a charity appealing to donors to make donations. The payee may place advertisements including a tag in public spaces. The tag may include the account identifier of the payer, a suggested donation amount, as well as a personal information flag indicating that certain personal information such as an email address of the payer will be required by the payee.
Upon noticing the advertisement and wishing to act on it, the payer may use his or her communication device 414 to obtain information from the tag. At a first stage 602, the communication device 414 of the payer obtains information from the tag. The information obtained from the tag may include an account identifier of the payee, a personal information flag indicating that personal information of the payer is requested by the payee, optionally an amount, and optionally additional information. Obtaining the information from the tag may include scanning a graphical code or receiving the information from a radio frequency or near sound communication beacon.
The communication device 414 may then, at a following stage 604, detect that the information includes a personal information flag indicating that personal information of the payer is requested by the payee. The personal information flag may indicate that one or more of a shipping address, an email address, and a phone number of the payer is requested by the payee.
At a next stage 606, the communication device 414 prompts the payer for permission to share the requested personal information with the payee. This stage 606 may include displaying the personal information which will be shared with the payee to the payer. In some embodiments, the stage 606 of prompting the payer for permission to share personal information includes providing the payer with an option to edit the personal information which will be shared with the payee and/or with an option to select personal information of a contact of the payer which will be shared with the payee. The prompt may, for example, allow the payer to select a contact from an address book stored in the communication device 414, where the payer is purchasing a gift for the contact.
The payer may decide that the requested personal information may be shared with the payee or alternatively that he or she does not wish for the requested personal information to be shared with the payee. The communication device 414 may then receive the payer's approval or denial in respect of sharing the requested personal information with the payee in a following stage 608. This stage 608 may include receiving edits to the personal information made by the payer and/or personal information of a contact other than the payer. In some embodiments, the payer may also input an amount for example where the payer is making a donation to the payee while in other embodiments the amount is included in the information obtained from the tag.
At a next stage 610, the communication device 414 generates a transaction message including the amount associated with the transfer of funds, the account identifier of the payee, a permission indication indicating the payer's approval or denial in respect of sharing the requested personal information with the payee and optionally additional information. In some embodiments, the step 610 of generating the transaction message may include a step of retrieving the requested personal information for inclusion with the permission indication in the transaction message. In other embodiments this step is performed by the issuer server computer.
At a following stage 612, the communication device 414 transmits the transaction message to the issuer server computer 410 associated with the payer for processing the transaction and conditional forwarding depending on the permission indication included in the message of the requested personal information to the payee.
The issuer server computer 410 then receives the transaction message at a following stage 614. The transaction message may include the amount associated with the transfer of funds, the account identifier of the payee, a permission indication indicating the payer's approval or denial in respect of sharing with the payee personal information requested by the payee, and optionally additional information.
At a following stage 616, the issuer server computer 410 identifies a financial account and/or a data record associated with the payer, for example using the account identifier of the payer included in the transaction message. This stage 616 may include debiting the financial account of the payer with the amount associated with the transfer of funds.
The issuer server computer 410 may then, at a following stage 618, evaluate the permission indication included in the transaction message to determine whether the payer has granted or denied permission to the issuer server computer 410 to share the requested personal information with the payee.
If 620 the permission indication indicates that the requested personal information may be shared with the payee, the issuer server computer 410 may retrieve the requested personal information from the data record associated with the payer at a next stage 622. In other embodiments, the permission indication may include the requested personal information. At a next stage 624, the issuer server computer 410 may then generate a transaction request message including the amount, the account identifier of the payee, the requested personal information and optionally additional information. The transaction request message generated by the issuer server computer may be an OCT request message.
Alternatively, if 620 the permission indication indicates that the requested personal information may not be shared with the payee, the issuer server computer 410 may generate a transaction request message including the amount, the account identifier of the payee and optionally additional information at an alternative stage 626. In other cases, where the requested personal information may not be shared with the payee, the transaction may fail and messages to that effect may be transmitted.
At a following stage 628, the issuer server computer 410 transmits the transaction request message for receipt by the acquirer server computer 420 associated with the payee. Transmitting the transaction request message may transmit the message via the payment processing network.
The acquirer server computer 420 may then receive the transaction request message at a following stage 630.
The acquirer server computer 420 may then, at a further stage 632, extract the amount associated with the transfer of funds, the account identifier of the payee and the personal information if any from the transaction request message.
At a next stage 634, the acquirer server computer 420 may identify the financial account of the payee associated with the payee account identifier and credit the financial account with the amount.
The acquirer server computer 420 may then generate and transmit a transaction response message to the issuer server computer 410 either confirming or denying the transaction at a following stage 636. The transaction response message may be an OCT response message.
The acquirer server computer 420 may also transmit a confirmation or denial message to the communication device of the payee either confirming or denying the transaction at a next stage 638. The payment confirmation message may include the amount in respect of the transfer of funds as well as the personal information which was requested by the payee.
Having received the payment confirmation message together with the personal information of the payer, the payee may cause the product purchased by the payee to be shipped; may send an email to the payer thanking the payer for his or her donation or the like.
The issuer server computer 410 may receive the transaction response message at a following stage 640 and may then transmit a payment confirmation or denial message to the communication device of the payer either confirming or denying the transaction.
The embodiments described herein thus enable personal information of a payer to be transmitted together with payment information e.g. an account identifier of a payee and an amount in respect of the transfer of funds to be sent together in a single message. The personal information and payment information may thus be received from a single source as opposed to disparate sources as may previously have been the case. Furthermore, embodiments described herein provide for payment information and personal information of the payer to be transmitted over an interoperable payment processing network. Embodiments described herein provide a system and method in which push payment transaction messages are transmitted over an interoperable payment processing network and include both payment information and personal information of the payer which may be used by the payee.
The system and method described herein may be advantageous in that receiving information by payees such as merchants from disparate sources is obviated. This may reduce the time and processing required at the payee to tie related pieces of information together e.g. a payment confirmation received from a bank and address information received directly from the payer.
The computing device 800 may include subsystems or components interconnected via a communication infrastructure 805 for example, a communications bus, a cross-over bar device, or a network. The computing device 800 may include at least one central processor 810 and at least one memory component in the form of computer-readable media.
The memory components may include system memory 815, which may include read only memory ROM and random access memory RAM. A basic input/output system BIOS may be stored in ROM. System software may be stored in the system memory 815 including operating system software.
The memory components may also include secondary memory 820. The secondary memory 820 may include a fixed disk 821, such as a hard disk drive, and, optionally, one or more removable-storage interfaces 822 for removable-storage components 823.
The removable-storage interfaces 822 may be in the form of removable-storage drives for example, magnetic tape drives, optical disk drives, floppy disk drives, etc. for corresponding removable storage-components for example, a magnetic tape, an optical disk, a floppy disk, etc., which may be written to and read by the removable-storage drive.
The removable-storage interfaces 822 may also be in the form of ports or sockets for interfacing with other forms of removable-storage components 823 such as a flash memory drive, external hard drive, or removable memory chip, etc.
The computing device 800 may include an external communications interface 830 for operation of the computing device 800 in a networked environment enabling transfer of data between multiple computing devices 800. Data transferred via the external communications interface 830 may be in the form of signals, which may be electronic, electromagnetic, optical, radio, or other types of signal.
The external communications interface 830 may enable communication of data between the computing device 800 and other computing devices including servers and external storage facilities. Web services may be accessible by the computing device 800 via the communications interface 830. The external communications interface 830 may also enable other forms of communication to and from the computing device 800 including, voice communication, near field communication, Bluetooth™, etc.
The computer-readable media in the form of the various memory components may provide storage of computer-executable instructions, data structures, program modules, and other data. A computer program product may be provided by a computer-readable medium having stored computer-readable program code executable by the central processor 810. A computer program product may be provided by a non-transient computer-readable medium, or may be provided via a signal or other transient means via the communications interface 830.
Interconnection via the communication infrastructure 805 allows a central processor 810 to communicate with each subsystem or component and to control the execution of instructions from the memory components, as well as the exchange of information between subsystems or components.
Peripherals such as printers, scanners, cameras, or the like and input/output I/O devices such as a mouse, touchpad, keyboard, microphone, joystick, or the like may couple to the computing device 500 either directly or via an I/O controller 535. These components may be connected to the computing device 500 by any number of means known in the art, such as a serial port. One or more monitors 545 may be coupled via a display or video adapter 540 to the computing device 500.
The communication device 900 may include a processor 905 e.g., a microprocessor for processing the functions of the communication device 900 and a display 920 to allow a user to see the phone numbers and other information and messages. The communication device 900 may further include an input element 925 to allow a user to input information into the device e.g., input buttons, touch screen, etc., a speaker 930 to allow the user to hear voice communication, music, etc., and a microphone 935 to allow the user to transmit his or her voice through the communication device 900.
The processor 905 of the communication device 900 may connect to a memory 915. The memory 915 may be in the form of a computer-readable medium that stores data and, optionally, computer-executable instructions.
The communication device 900 may also include a communication element 940 for connection to communication channels e.g., a cellular telephone network, data transmission network, Wi-Fi™ network, satellite-phone network, Internet network, Satellite Internet Network, etc. The communication element 940 may include an associated wireless transfer element, such as an antenna.
The communication element 940 may include a subscriber identity module SIM in the form of an integrated circuit that stores an international mobile subscriber identity and the related key used to identify and authenticate a subscriber using the communication device 900. One or more subscriber identity modules may be removable from the communication device 900 or embedded in the communication device 900.
The communication device 900 may further include a contactless element 950, which is typically implemented in the form of a semiconductor chip or other data storage element with an associated wireless transfer element, such as an antenna. The contactless element 950 may be associated with e.g., embedded within the communication device 900 and data or control instructions transmitted via a cellular network may be applied to the contactless element 950 by means of a contactless element interface not shown. The contactless element interface may function to permit the exchange of data and/or control instructions between mobile device circuitry and hence the cellular network and the contactless element 950.
The contactless element 950 may be capable of transferring and receiving data using a near field communications NFC capability or near field communications medium typically in accordance with a standardized protocol or data transfer mechanism e.g., ISO 14443/NFC. Near field communications capability is a short-range communications capability, such as radio-frequency identification RFID, Bluetooth™′ infra-red, or other data transfer capability that can be used to exchange data between the communication device 900 and an interrogation device. Thus, the communication device 900 may be capable of communicating and transferring data and/or control instructions via both a cellular network and near field communications capability.
The data stored in the memory 915 may include: operation data relating to the operation of the communication device 900, personal data e.g., name, date of birth, identification number, etc., financial data e.g., bank account information, a bank identification number BIN, credit or debit card number information, account balance information, expiration date, loyalty provider account numbers, etc., transit information e.g., as in a subway or train pass, access information e.g., as in access badges, etc. A user may transmit this data from the communication device 900 to selected receivers.
The communication device 900 may be, amongst other things, a notification device that can receive alert messages and access reports, a portable merchant device that can be used to transmit control data identifying a discount to be applied, as well as a portable consumer device that can be used to make payments.
The foregoing description of the embodiments of the invention has been presented for the purpose of illustration; it is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Persons skilled in the relevant art can appreciate that many modifications and variations are possible in light of the above disclosure.
The user devices, computers and servers described herein may have, among other elements, a microprocessor such as from the Intel Corporation, AMD or Motorola; volatile and non-volatile memory; one or more mass storage devices i.e., a hard drive; various user input devices, such as a mouse, a keyboard, or a microphone; and a video display system. The user devices, computers and servers described herein may be running on any one of many operating systems including, but not limited to WINDOWS, UNIX, LINUX, MAC OS, or Windows XP, VISTA, etc. It is contemplated, however, that any suitable operating system may be used for the present invention. The servers may be a cluster of web servers, which may each be LINUX based and supported by a load balancer that decides which of the cluster of web servers should process a request based upon the current request-load of the available servers.
The user devices, computers and servers described herein may communicate via networks, including the Internet, WAN, LAN, Wi-Fi, other computer networks now known or invented in the future, and/or any combination of the foregoing. It should be understood by those of ordinary skill in the art having the present specification, drawings, and claims before them that networks may connect the various components over any combination of wired and wireless conduits, including copper, fiber optic, microwaves, and other forms of radio frequency, electrical and/or optical communication techniques. It should also be understood that any network may be connected to any other network in a different manner. The interconnections between computers and servers in system are examples. Any device described herein may communicate with any other device via one or more networks.
The example embodiments may include additional devices and networks beyond those shown. Further, the functionality described as being performed by one device may be distributed and performed by two or more devices. Multiple devices may also be combined into a single device, which may perform the functionality of the combined devices.
The various participants and elements described herein may operate one or more computer apparatuses to facilitate the functions described herein. Any of the elements in the above-described Figures, including any servers, user devices, or databases, may use any suitable number of subsystems to facilitate the functions described herein.
Any of the software components or functions described in this application, may be implemented as software code or computer readable instructions that may be executed by at least one processor using any suitable computer language such as, for example, Java, C++, or Perl using, for example, conventional or object-oriented techniques.
The software code may be stored as a series of instructions or commands on a non-transitory computer readable medium, such as a random access memory RAM, a read only memory ROM, a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer readable medium may reside on or within a single computational apparatus and may be present on or within different computational apparatuses within a system or network.
It may be understood that the present invention as described above can be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art may know and appreciate other ways and/or methods to implement the present invention using hardware, software, or a combination of hardware and software.
The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention. A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary. Recitation of “and/or” is intended to represent the most inclusive sense of the term unless specifically indicated to the contrary.
One or more of the elements of the present system may be claimed as means for accomplishing a particular function. Where such means-plus-function elements are used to describe certain elements of a claimed system it will be understood by those of ordinary skill in the art having the present specification, figures and claims before them, that the corresponding structure is a general purpose computer, processor, or microprocessor as the case may be programmed to perform the particularly recited function using functionality found in any general purpose computer without special programming and/or by implementing one or more algorithms to achieve the recited functionality. As would be understood by those of ordinary skill in the art that algorithm may be expressed within this disclosure as a mathematical formula, a flow chart, a narrative, and/or in any other manner that provides sufficient structure for those of ordinary skill in the art to implement the recited process and its equivalents.
While the present disclosure may be embodied in many different forms, the drawings and discussion are presented with the understanding that the present disclosure is an exemplification of the principles of one or more inventions and is not intended to limit any one of the inventions to the embodiments illustrated.
The present disclosure provides a solution to the long-felt need described above. In particular, the systems and methods described herein may be configured for improving payment systems. Further advantages and modifications of the above described system and method will readily occur to those skilled in the art. The disclosure, in its broader aspects, is therefore not limited to the specific details, representative system and methods, and illustrative examples shown and described above. Various modifications and variations can be made to the above specification without departing from the scope or spirit of the present disclosure, and it is intended that the present disclosure covers all such modifications and variations provided they come within the scope of the following claims and their equivalents.
Additionally, certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules e.g., code or instructions embodied on a machine-readable medium or in a transmission signal, wherein the code is executed by a processor or hardware modules. A hardware module is tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems e.g., a standalone, client or server computer system or one or more hardware modules of a computer system e.g., a processor or a group of processors may be configured by software e.g., an application or application portion as a hardware module that operates to perform certain operations as described herein.
In various embodiments, a hardware module may be implemented mechanically or electronically. For example, a hardware module may comprise dedicated circuitry or logic that is permanently configured e.g., as a special-purpose processor, such as a field programmable gate array FPGA or an application-specific integrated circuit ASIC to perform certain operations. A hardware module may also comprise programmable logic or circuitry e.g., as encompassed within a general-purpose processor or other programmable processor that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry e.g., configured by software may be driven by cost and time considerations.
Accordingly, the term “hardware module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured e.g., hardwired, or temporarily configured e.g., programmed to operate in a certain manner or to perform certain operations described herein. As used herein, “hardware-implemented module” refers to a hardware module. Considering embodiments in which hardware modules are temporarily configured e.g., programmed, each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where the hardware modules comprise a general-purpose processor configured using software, the general-purpose processor may be configured as respective different hardware modules at different times. Software may accordingly configure a processor, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.
Hardware modules can provide information to, and receive information from, other hardware modules. Accordingly, the described hardware modules may be regarded as being communicatively coupled. Where multiple of such hardware modules exist contemporaneously, communications may be achieved through signal transmission e.g., over appropriate circuits and buses that connect the hardware modules. In embodiments in which multiple hardware modules are configured or instantiated at different times, communications between such hardware modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple hardware modules have access. For example, one hardware module may perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further hardware module may then, at a later time, access the memory device to retrieve and process the stored output. Hardware modules may also initiate communications with input or output devices, and can operate on a resource e.g., a collection of information.
The various operations of example methods described herein may be performed, at least partially, by one or more processors that are temporarily configured e.g., by software or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, comprise processor-implemented modules.
Similarly, the methods or routines described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or processors or processor-implemented hardware modules. The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the processor or processors may be located in a single location e.g., within a home environment, an office environment or as a server farm, while in other embodiments the processors may be distributed across a number of locations.
The one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” SaaS. For example, at least some of the operations may be performed by a group of computers as examples of machines including processors, these operations being accessible via a network e.g., the Internet and via one or more appropriate interfaces e.g., application program interfaces APIs.
The performance of certain of the operations may be distributed among the one or more processors, not only residing within a single machine, but deployed across a number of machines. In some example embodiments, the one or more processors or processor-implemented modules may be located in a single geographic location e.g., within a home environment, an office environment, or a server farm. In other example embodiments, the one or more processors or processor-implemented modules may be distributed across a number of geographic locations.
Some portions of this specification are presented in terms of algorithms or symbolic representations of operations on data stored as bits or binary digital signals within a machine memory e.g., a computer memory. These algorithms or symbolic representations are examples of techniques used by those of ordinary skill in the data processing arts to convey the substance of their work to others skilled in the art. As used herein, an “algorithm” is a self-consistent sequence of operations or similar processing leading to a desired result. In this context, algorithms and operations involve physical manipulation of physical quantities. Typically, but not necessarily, such quantities may take the form of electrical, magnetic, or optical signals capable of being stored, accessed, transferred, combined, compared, or otherwise manipulated by a machine. It is convenient at times, principally for reasons of common usage, to refer to such signals using words such as “data,” “content,” “bits,” “values,” “elements,” “symbols,” “characters,” “terms,” “numbers,” “numerals,” or the like. These words, however, are merely convenient labels and are to be associated with appropriate physical quantities.
Unless specifically stated otherwise, discussions herein using words such as “processing,” “computing,” “calculating,” “determining,” “presenting,” “displaying,” or the like may refer to actions or processes of a machine e.g., a computer that manipulates or transforms data represented as physical e.g., electronic, magnetic, or optical quantities within one or more memories e.g., volatile memory, non-volatile memory, or a combination thereof, registers, or other machine components that receive, store, transmit, or display information.
As used herein any reference to “some embodiments” or “an embodiment” or “teaching” means that a particular element, feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. The appearances of the phrase “in some embodiments” or “teachings” in various places in the specification are not necessarily all referring to the same embodiment.
Some embodiments may be described using the expression “coupled” and “connected” along with their derivatives. For example, some embodiments may be described using the term “coupled” to indicate that two or more elements are in direct physical or electrical contact. The term “coupled,” however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other. The embodiments are not limited in this context.
Further, the figures depict preferred embodiments for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein
Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for the systems and methods described herein through the disclosed principles herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those skilled in the art, may be made in the arrangement, operation and details of the systems and methods disclosed herein without departing from the spirit and scope defined in any appended claims.
Claims
1. A payment transaction system comprising:
- a token requestor module for receiving tag data associated with an e-commerce transaction for goods or services, the tag data including an indication that a merchant payment webpage is configured to receive a payment transaction via a token; and
- a token service for creating one or more tokens from a personal account number and a shipping address corresponding to the personal account number in response to a request for token data from the token requestor module;
- wherein the token requestor module includes an instruction to push the one or more tokens to the merchant payment webpage.
2. The system of claim 1, wherein the token requestor is further for validating the tag data.
3. The system of claim 1, wherein the token requestor is further for receiving an input indicating selection of a payment device.
4. The system of claim 1, wherein the cryptogram includes payment device data and shipping data.
5. The system of claim 1, wherein the token requestor module includes a further instruction to encrypt the token before pushing the token to the merchant payment webpage.
6. The system of claim 1, wherein the token service is further for creating one or more cryptogams that each correspond to a token of the one or more tokens.
7. The system of claim 6, wherein the merchant payment webpage is configured to send the token and a cryptogram corresponding to the token to an issuer server.
8. The system of claim 7, wherein the token service is further for receiving the personal account number corresponding to the token and an approval decision from the issuer server.
9. The system of claim 8, wherein the token service is further for exchanging the personal account number for the token.
10. The system of claim 9, wherein the merchant payment website is configured to map the token to an e-commerce authorization request and to send the request and token to the issuer server.
11. A method for completing an e-commerce payment transaction comprising:
- receiving tag data associated with an e-commerce transaction for goods or services, the tag data including an indication that a merchant payment webpage is configured to receive a payment transaction via a token;
- creating one or more tokens from a personal account number and a shipping address corresponding to the personal account number in response to a request for token data from the token requestor module; and
- pushing the one or more tokens to the merchant payment webpage.
12. The method of claim 11, further comprising validating the tag data.
13. The method of claim 11, further comprising receiving an input indicating selection of a payment device.
14. The method of claim 11, wherein the cryptogram includes payment device data and shipping data.
15. The method of claim 11, further comprising encrypting the token before pushing the token to the merchant payment webpage.
16. The method of claim 11, further comprising creating one or more cryptogams that each correspond to a token of the one or more tokens.
17. The method of claim 16, further comprising sending the token and a cryptogram corresponding to the token to an issuer server.
18. The method of claim 17, further comprising receiving the personal account number corresponding to the token and an approval decision from the issuer server.
19. The method of claim 18, further comprising exchanging the personal account number for the token.
20. The method of claim 19, further comprising mapping the token to an e-commerce authorization request and sending the request and token to the issuer server.
Type: Application
Filed: Nov 23, 2016
Publication Date: May 25, 2017
Inventors: PANKAJ RAJURKAR (Singapore), Ashish Kulpati (Singapore), Koni Uttam Nayak (Mumbai), Gurumoorthy Hariharan (Mumbai), Aparna Krishnan Girish (Foster City, CA), Parveen Bansal (Foster City, CA), Michelle Scurrah (Victoria)
Application Number: 15/360,357
