WO2017181185A1 - Système et procédé pour paiements web sécurisés - Google Patents

Système et procédé pour paiements web sécurisés Download PDF

Info

Publication number
WO2017181185A1
WO2017181185A1 PCT/US2017/027957 US2017027957W WO2017181185A1 WO 2017181185 A1 WO2017181185 A1 WO 2017181185A1 US 2017027957 W US2017027957 W US 2017027957W WO 2017181185 A1 WO2017181185 A1 WO 2017181185A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
commerce
merchant
computer system
data
Prior art date
Application number
PCT/US2017/027957
Other languages
English (en)
Inventor
Parveen Bansal
Barbara Elizabeth Patterson
Aparna Krishnan GIRISH
Original Assignee
Visa International Service Association
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Visa International Service Association filed Critical Visa International Service Association
Priority to EP17783362.1A priority Critical patent/EP3443515A4/fr
Priority to RU2018136099A priority patent/RU2018136099A/ru
Priority to CA3019922A priority patent/CA3019922A1/fr
Priority to JP2018553362A priority patent/JP2019517055A/ja
Priority to SG11201808714WA priority patent/SG11201808714WA/en
Priority to CN201780023331.9A priority patent/CN109155026A/zh
Priority to AU2017250377A priority patent/AU2017250377A1/en
Publication of WO2017181185A1 publication Critical patent/WO2017181185A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • 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/405—Establishing or using transaction specific rules
    • 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/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • 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
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction

Definitions

  • the present disclosure relates to a system and associated methods for securely facilitating payment reconciliation for a transaction between a credit account holder and an e-commerce merchant.
  • Payment systems allow a user to enter several electronic payment devices into an application. Thereafter, the user may select and use one or more of the payment devices to pay for a transaction by just entering a user name and a password, rather than having to enter all the payment information for each payment device over and over.
  • each payment application may represent another opportunity for sales but also may represent a requirement to add more programming to their e-commerce site to handle the various payment systems as there is no consistent way for payment applications to interact with e-commerce web sites.
  • E- Commerce Enablers play an important role in forging a trusted relationship with consumers. For example, E-Commerce Enablers may facilitate checkout at merchant sites, collecting card information for payment purposes, and sharing required data with merchants and merchant payment service providers (PSPs).
  • PSPs merchant payment service providers
  • a common standard for web-based payment solutions may benefit cardholders, e-commerce enablers, merchants, payment service providers, acquirers, and card issuers.
  • Standardizing web-based payments may provide a consistent checkout experience, as well as deliver required transaction information for processing purposes from e-commerce enablers to other entities in the payment flow.
  • Cardholders may benefit from consistent payment experiences, and may be better informed in providing necessary information to complete the payment.
  • merchants may make better decisions about the payment and, thereby, alleviate the need to collecting data from consumers at every single checkout.
  • E-commerce enablers may convert more consumers by delivering a standard payment experience and effectively engage their merchants and PSPs by streamlining the payment flows, and facilitating an easier integration between them. Standardization may also streamline payment flows throughout the payment life-cycle, regardless of whether the E- Commerce Enabler returns payment data with PANs or enables tokenization, thereby returning PANs instead of tokens.
  • Systems and methods may facilitate payment transactions between user computer systems and merchant computer systems.
  • An e-commerce enabler system may generate a library of instructions for execution on the user computing device. On execution, the library of instructions may provide payment information for a payment transaction to a merchant e-commerce computer system via a website hosted by the merchant e-commerce computer system. The payment information may correspond to primary account holder data identifying a payment device.
  • the e- commerce enabler system may forward the payment information to a payment network system, create payment payload data from data returned by the payment network system, and forward the payload data to the merchant e-commerce computer system.
  • the merchant e-commerce computer system may then decrypt at least a portion of the payment payload data to complete the payment transaction between the computing device and the merchant e-commerce computer system.
  • FIG. 1 is an exemplary system for facilitating web payments
  • FIG. 2A and FIG. 2B are different views of an exemplary payment device
  • FIG. 3 and FIG. 4A illustrate exemplary process flows for securely facilitating payment reconciliation for a transaction between a credit account holder and an e-commerce merchant
  • FIG. 4B illustrates an exemplary checkout graphical user interface
  • FIG. 5 illustrates another exemplary process flow for securely facilitating payment reconciliation for a transaction between a credit account holder and an e- commerce merchant
  • FIG. 6 illustrates exemplary process flows for tokenizing payment data
  • FIG. 7A, FIG. 7B, and FIG. 7C illustrate still further exemplary process flows for securely facilitating payment reconciliation for a transaction between a credit account holder and an e-commerce merchant
  • FIG. 8 illustrates an exemplary computing device used within the systems and methods for securely facilitating payment reconciliation for a transaction between a credit account holder and an e-commerce merchant, as described herein.
  • 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.
  • Fig. 1 generally illustrates one embodiment of a system 100 for securely facilitating payment reconciliation between a credit account holder and a merchant.
  • the system 100 may include a computer network 102 that links one or more systems and computer components.
  • the system 100 includes an account holder computer system 103, a merchant e-commerce computer system 104, a payment network system 106, an e-commerce enabler system 108, and a token service provider 1 1 0.
  • the network 102 may be described variously as a communication link, computer network, internet connection, etc.
  • the system 100 may include various software or computer-executable instructions stored on tangible memories and specialized hardware components or modules that employ the software and instructions to securely facilitate payment reconciliation between a credit account holder and a merchant, as described herein.
  • the various modules may be implemented as computer-readable storage memories containing computer- readable instructions (i.e., software) for execution by one or more processors of the system 100 within a specialized or unique computing device.
  • the modules may perform the various tasks, methods, modules, etc., as described herein.
  • the system 100 may also include both hardware and software applications, as well as various data communications channels for communicating data between the various specialized and unique hardware and software components.
  • the payment network computer system 106 may include one or more instruction modules including a payment network module 1 12 that, generally, may include instructions to cause a processor 1 14 of a payment network computer system server 1 16 to functionally communicate with a plurality of other computer- executable steps or modules, e.g., modules 1 12, 124, 135, 152 and components of the system 100 via the network 102.
  • the module 1 12 includes instructions to accept, transmit, or process transactions made using a payment device 200 (FIGs. 2A and 2B).
  • the module may also include instructions to transfer information among various entities of the system 100 including payment device issuers, acquirers, merchants, and account holders.
  • modules 1 12, 124, 135, 1 52 may include instructions that, upon loading into the server memory 1 18 and execution by one or more computer processors 1 14, securely facilitate payment reconciliation between a credit account holder using a payment device 200 (FIGs. 2A and 2B) and a merchant.
  • a primary account holder data repository 1 20 may include primary account holder data 120A that each includes various pieces of data to describe an account of a primary account holder and user of the system 100.
  • primary account holder data 120A or a portion of the primary account holder data 1 20A (e.g., a personal account number or "PAN”) may be included with a payment device 200.
  • An e-commerce enabler system 1 08 may include an e-commerce enabler module 1 24 that, generally, may include instructions to provide checkout
  • the e-commerce enabler system 108 may include an e-commerce enabler server 1 26 including a processor 128 and memory 130.
  • the module 124 may be loaded onto the memory 130 and the module instructions may be executed by the processor 128.
  • the module 124 may also include instructions to collect payment information for future checkout and payments across multiple merchant e-commerce computer systems 104.
  • the module 1 24 may eliminate the need for a user to physically enter payment information for each merchant e-commerce computer system 104.
  • the module 124 may include instructions to provide either card- or token- based payment information to merchants.
  • Instructions of the e-commerce enabler module 1 24 may include instructions to collect payment information from consumers, provide payment information to various authorized merchant e-commerce computer systems 104, and support other functions (e.g., 3DS, international transactions, etc.).
  • Further instructions of the e-commerce enabler module 124 may include onboarding of the merchant e-commerce computer system 104 at the e-commerce enabler system 108.
  • Onboarding may include instructions to create an e-commerce merchant account profile 133A for each merchant e-commerce computer system 104, within an account repository 133, associate a profile with each e-commerce merchant account 133A, generate any required API credentials for the e-commerce merchant account profile 133A so that the merchant is authorized to perform transactions with the e-commerce enabler system 1 08, and generate libraries 131 A that are stored within a library repository 131 and communicated to each merchant e-commerce computer system 104 to facilitate payment by the consumer to the merchant via the system 104.
  • Each library 131 A may be a software development kit (e.g., JavaScript SDK) including processor executable instructions to implement the transaction process described herein within the various components of the merchant e- commerce computer system 104.
  • the libraries 131 A include various configurations that may be implemented within the browser of the account holder computing device 103.
  • the library 131 A may include
  • the library 1 31 A may also include instructions to communicate a list of allowable shipping countries as well as indicate whether shipping information can be changed during checkout or must be selected from an on-file address (e.g., account holder data 120A).
  • the library 131 A may also include instructions to implement additional security measures if the merchant e-commerce computer system 104 participates in those measures.
  • the merchant e-commerce computer system 104 may implement an additional security layer for online payment device transactions such as 3DS.
  • these extra security layers are implemented at the time of the transaction and a payload sent to the merchant e-commerce computer system 104 may include details of any results of the extra security check.
  • the payload may include one or more 3DS results such as ECI Raw, CAW, VERes Timestamp, PARes Status, PARes
  • Timestamp, XID, etc. The merchant e-commerce computer system 104 may then pass these results or other results related to an additional security layer to the payment network system 1 06 so that it may be used in authorizing a consumer.
  • each merchant e-commerce computer system 104 or an authorized entity may include API credentials to perform authorized transactions with the e- commerce enabler system 108.
  • the API credentials include an API key that includes both a key and a shared secret.
  • the merchant e-commerce computer system 104 uses the API key to identify itself to the e-commerce enabler system 108 when sending a transaction request.
  • the API key includes a combination of alphanumeric characters that are provided to the merchant e- commerce computer system 104 when, for example, the merchant e-commerce computer system 104 created an account profile 133A.
  • the e-commerce enabler system 108 uses the shared secret to confirm the identity of the requestor.
  • the e-commerce enabler system 108 may include a payload repository 132 for storing payment payload data 132A used in the transactions within the system 100.
  • the token service provider 1 10 may include a token service module 135 including instructions that are loaded onto a memory 134 of a token service server 136 and executed by a processor 138 of the server 136.
  • the module 135 includes instructions that are loaded onto a memory 134 of a token service server 136 and executed by a processor 138 of the server 136.
  • a token 140A is a replacement for the consumer's account number as it appears on a card or PAN.
  • the merchant e-commerce computer system 104 may receive a token-based payload that contains a token 140A in place of the full account number.
  • the module 135 may include further instructions as the authorized entity of the system 1 00 to issue tokens 140A to the various other entities (e.g., the merchant e-commerce computer system 104) of the system 100.
  • the module 1 35 may include instructions to maintain organization of a token vault repository 140, generate and issue the payment tokens 140A, apply security measures 135A to the transactions between system entities that include the payment tokens 140A, and create and maintain a token requestor registry 142 to track all history related to the payment tokens 140A. Additionally, the module 1 24 may include a token requestor API including all provisioning functions. In some embodiments, the module 1 35 includes an instruction to ensure that any token bank identification number (BIN) corresponding to a payment token 140A is distinct from a personal account number (PAN) corresponding to a primary account holder data 120A.
  • BIN token bank identification number
  • PAN personal account number
  • the merchant e-commerce computer system 104 may include any components that are used by a business to complete an internet-based, e-commerce transaction where a customer uses a payment device 200 to link a payment token 140A other payment data to transactions originating from the account holder computer system 103 or other entity of the system 1 00.
  • the system 104 may include an e-commerce server 144 having an e-commerce processor 146 and e-commerce memory 148.
  • the memory 148 may include processor- implemented instructions such as a checkout module 152 that is used by the system 104 to gather transaction data 154A, including an amount for a transaction between the account holder computer system 1 03 and the merchant-commerce computer system 104, customer account information (e.g., a Personal Account Number ("PAN”) 206A and a Card Verification number (“CVN”) 206B), payment token 140A, and primary account holder data 120A from the primary account holder data repository 120.
  • the checkout module 152 may also include instructions to integrate the merchant e-commerce computer system 104 with the e-commerce enabler 108, and render an e-commerce enabler graphic object 156 on a payment webpage 1 58.
  • selecting the e-commerce enabler graphic object 156 displayed within the payment webpage 158 will cause the merchant e-commerce computer system 104 to execute instructions of the checkout module 152 to initiate a checkout process, as described herein.
  • the checkout module 152 may also include instructions to request and receive payment information such as payload data 132A (e.g., primary account holder data 1 20A, token data 140A, etc.) from one or more of the payment network system 106, the ecommerce enabler 108, and the token service provider 1 1 0).
  • Other instructions of the checkout module 152 may include instructions to process payments using the payment network system 1 06.
  • a system that is authorized by the merchant e-commerce computer system 106 may receive payload data 132A.
  • the merchant e-commerce computer system may store the transaction data 154A within a transaction data repository 154.
  • the account holder computer system 1 03 may be a personal computer, mobile computing device (e.g., mobile phone, tablet, etc.) or other computing device that is capable of accessing at least the merchant e-commerce computer system 104 or other entities of the system 100 via the network 102.
  • the account holder computer system 103 may include a processor 160 and memory 162.
  • the memory 162 may include one or more modules (e.g., a payment application 164) including instructions that, when executed by the processor 160 cause the account holder computer system 103 to access the merchant e-commerce computer system 104 or other system entities.
  • the account holder computer system 103 may complete a purchase transaction by providing information to the e- commerce enabler 108 via the merchant e-commerce computer system 104 to complete a purchase transaction with a payment device 200.
  • the account holder computer system 103 may include one or more modules such as the payment application 164 that facilitate creating and linking a payment token 140A or other data representing the payment device 200 to transaction data 154A, as described herein.
  • an exemplary payment device 200 may take on a variety of shapes and forms. In some
  • the payment device 200 is a traditional card such as a debit card or credit card.
  • the payment device 200 may be a fob on a key chain, an NFC wearable, or other device.
  • the form of the payment device 200 may not be especially critical and may be a design choice for the embodiments described herein. For example, many legacy payment devices may have to be read by a magnetic stripe reader and thus, the payment device 200 may have to be sized to fit through a magnetic card reader.
  • the payment device 200 may
  • the form of the payment device 200 may be virtually any form. Of course, other forms may be possible based on the use of the card, the type of reader being used, etc.
  • the payment device 200 may be a card and the card may have a plurality of layers to contain the various elements that make up the payment device
  • the payment device 200 may have a substantially flat front surface 202 and a substantially flat back surface 204 opposite the front surface 202.
  • the surfaces 202, 204 may have some
  • the payment device 200 may include data corresponding to the primary account holder, such as a primary account holder data 1 26A for the primary account holder.
  • a memory 254 generally and a module 254A in particular may be encrypted such that all data related to payment is secure from unwanted third parties.
  • a communication interface 256 may include instructions to facilitate sending payload data 132A to the merchant e-commerce computer system 104, which then passes the payment data/token to the payment processing computer system 106 via the network 1 02.
  • FIG. 3 illustrates a method 300 for securely facilitating payment
  • the method 300 generally describes the life cycle of web-based payments between consumers and merchants. The life cycle includes three function blocks.
  • the method 300 may initialize payment by opening a communication link between the merchant e-commerce computer system 104 and the e-commerce enabler 108 to complete a payment request.
  • the method 300 may create and return payload data 1 32A to an authorized entity requesting the payment (e.g., the merchant e-commerce computer system or an entity authorized by the system).
  • the method 300 assumes that the merchant e-commerce computer system 104 or other authorized entity processes the payload received at block 304 and then confirms the status of the payment back to the e-commerce enabler system 108.
  • FIG. 4A illustrates a method 400 for securely facilitating payment initialization in a transaction between a credit account holder and an e-commerce merchant.
  • Each step of the method may be performed on a server or other computing device including instructions that, when executed by a processor, perform the action or block described herein.
  • the method may receive one or more enabler libraries 131 A from the e-commerce enabler system 108.
  • the method may receive one or more enabler libraries 131 A from the e-commerce enabler system 108.
  • the method 400 may receive an indication of a consumer selecting the e- commerce enabler graphic object 156 displayed within a payment webpage 158.
  • the enabler library 131 A received at block 402 may include instructions to render the enabler graphic object 156 within the payment webpage 158.
  • the account holder computer system 103 may display the payment webpage 158 and the enabler graphic object 156 within a browser executing on the system 103.
  • the enabler graphic object 156 may also include a list of payment devices 200 that are available to complete the transaction, allowed billing countries, and shipping properties to include allowable shipping countries and whether shipping information can be changed during checkout or must be selected from addresses on file with one or more of the payment network system 1 06, the e-commerce enabler system 108, and the merchant e-commerce computer system 104.
  • Receiving the selection of the enabler graphic object 156 within the webpage 1 58 for the item 450 may cause the method 400 to execute block 406.
  • the method 400 may load one or more enabler libraries 131 A received from the e-commerce enabler system 108.
  • the method 400 may initiate a checkout experience as defined by the one or more enabler libraries 131 A loaded at block 406.
  • the enabler libraries 131 A may cause the webpage 158 to initiate a checkout experience for the consumer viewing the webpage 1 58 at the account holder computer system 103 (e.g., including the look and feel of the checkout, what payment features must be enabled within the webpage 158, what aspects of the loaded library 1 31 A applies to the particular merchant e-commerce computer system 104, etc.).
  • the library 131 A includes an indication of what language will be used within the webpage 158, a secure logo URL to display, a name associated with the merchant e-commerce computer system 104, an a complete URL to the merchant website.
  • the library 131 A includes shipping settings for display on the webpage 1 58.
  • the shipping settings may include an indication of accepted countries and whether to obtain a shipping address from the consumer.
  • the library 131 A may also include payment settings within the webpage 158.
  • the library 131 A may include a merchant's ID associated with the request to the e-commerce enabler system 108, an indication of currency type to be used, an indication of shipping charges and taxes, a discount, gift wrapping availability, a total payment amount, an order ID, description, and promotional codes, and any custom data provided by the merchant e-commerce computer system 1 04 within the merchant account profile 133A.
  • event handlers implemented by one or more of the webpage 1 58 and the library 131 A may respond to submission of a payment indication by the consumer at the account holder computer system 103 and within the experience created by execution of the library 131 A loaded at block 406.
  • event handlers implemented by one or more of the webpage 158 and the library 131 A may respond to the payment indication by requesting payment payload data 132A from the e-commerce enabler system 108.
  • FIG. 5 illustrates a method 500 for securely creating and returning payload data 132A to facilitate payment in a transaction between a credit account holder and an e-commerce merchant.
  • the e-commerce enabler module 124 includes instructions to return payload data 132A in response to an authorized request from the merchant e-commerce computer system 104.
  • Each step of the method may be performed on a server or other computing device including instructions that, when executed by a processor, perform the action or block described herein.
  • the method 500 may request payload data 132A from the e- commerce enabler system 108 for a transaction initiated at the website 158 by the account holder computer system 103 via the network 102.
  • the request 166 may be communicated from the e-commerce server 144 to the e-commerce enabler server
  • the request may be communicated any time during or after the purchase transaction such that the merchant e- commerce computer system 104 is able to process transactions smoothly without requiring additional integration efforts.
  • the request 166 may include instructions to receive various types of data from other components of the system in response.
  • the request may include instructions to receive a public API key which is different than the shared secret, an e-commerce enabler system transaction ID associated with a payment request, and a data level that indicates what type of data from one or more of the payment network system 106 and the e-commerce enabler system 108 shall be included with the payload data 132A sent in response to the request 166.
  • the data level is set by the merchant e- commerce computer system 104 during an on-boarding process with the system
  • the data level may indicate that the e-commerce enabler system 108 may include an instruction to optionally reveal the full PAN only when asked.
  • the request 166 may also include instructions to receive a token signature that identifies the token contents and allows the e-commerce enabler system 108 to validate the caller of the request 166.
  • the request 166 may also include instructions to receive a currency type for the payment, a subtotal for the payment, shipping and handling charges, tax, discounts, gift wrap options, uncategorized or miscellaneous charges, a total, an order ID, a merchandise description, a promo code, and any other merchant-supplied data.
  • the enabler module 124 may execute instructions to create the payload data 132A at block 504.
  • the payload data 132A may include various information for the merchant e-commerce computer system 104 to complete the transaction initiated by the consumer at the account holder computer system 103.
  • the payload data 132A may include a creation time stamp and encrypted payment data.
  • the encrypted payment data may include account holder data 120A (e.g., name, email address, mobile number, URLs to consumer's image, age, gender, etc.), payment instrument information (e.g., cardholder name, PAN, expiration date, CVV2) or token information (token, token expiration
  • the instructions to create the payload data at block 504 may also include tokenizing the payload data 132A or portions of the payload data 132A.
  • a method 600 may convert the payload data 132A, portions of the payload data 132A, or other data used to complete a transaction with the system 100 into a token that represents a
  • Fig. 6 may illustrate at a high level how tokens may operate to store the primary account holder data 120A, the payload data 132A, or other data for use in transactions between the merchant e-commerce computer system 104 and the account holder computer system 103.
  • a component 604 of the system 100 such as the enabler module 124 of the e- commerce enabler system 108, the checkout module 1 52 of the merchant e- commerce computer system 104, or other component may execute instructions to issue a request 606 to a token service provider 1 10 to receive payment data for a consumer.
  • a token service provider 1 10 may generate a response that includes a token 140A.
  • the token 140A may take the place of a personal account number (PAN) or other primary account holder data 120A of the user.
  • PAN personal account number
  • the token 140A may be able to be converted by the token service 1 1 0 into the PAN, but no other entity could perform the same conversion.
  • the token 140A includes several fields of data including a token number, a token range including the first nine digits of the token number, a last four including the last four digits of the token number, a token expiration date including month, day, and year, a cryptogram, and an e-commerce indicator.
  • the merchant e-commerce computer system 104 may request via communication 610 authorization on behalf of the customer to an authorization server 612 (i.e., a module of the payment network system 106) using the received token 140A as the payload.
  • the authorization server 612 may request confirmation of the token 140A via communication with the token service 1 10 and provide an authorization response 614.
  • the token 140A alone may be useless, but the token service 1 1 0 may translate the token 140A into a PAN while the PAN may not be exposed over the network 102.
  • the method 500 may return the payload data 132A from the e-commerce enabler system 108 to the merchant e-commerce computer system 104.
  • One or more event handlers from the library 131 A received by the merchant e-commerce computer system 104 at block 402 may include instructions to determine success, error, or cancellation of the transaction.
  • the method 500 may execute an event handler to determine if the payload data 132A was successfully created based on the request of block 502.
  • Block 508 may include instructions to confirm various information within the payload data 132A including: a transaction ID associated with the payment request, an external client ID as received from the entity initializing the payment, a response status (e.g., a HTTPS status, a sub-code corresponding to the e-commerce enabler system 108, a severity indicator, a description of the status, etc.), an encrypted key to be used to decrypt encrypted payment data (i.e., the shared secret may decrypt this key), and the encrypted payment data. If, at block 508, the payload data 1 32A is not successful, the method may execute instructions to determine whether the payload data 132A included errors at block 510.
  • a response status e.g., a HTTPS status, a sub-code corresponding to the e-commerce enabler system 108, a severity indicator, a description of the status, etc.
  • an encrypted key to be used to decrypt encrypted payment data i.e., the shared secret may decrypt this key
  • the method may execute instructions to determine
  • payload data 132A that includes an error may fail an HTTPS response status, return an incorrect e-commerce enabler sub-code, of may indicate a severe error along with a description of that error. If the payload data 132A included an error, then the method 500 may return to execute instructions at block 502. If the data did not succeed, but also did not include errors, then at block 512, the method 500 may determine whether the payment transaction was cancelled. In some embodiments, a payment payload 132A for a cancelled transaction may include a transaction ID that indicates cancellation. If the transaction ID does not indicate cancellation, then the method 500 may return to execute instructions at block 502. If the transaction ID indicates cancellation, then the method 500 may end.
  • the method 500 may encrypt the payment data and payload data 132A according to standards that ensure security of the data.
  • the method 500 may process the payload data 132A and other data sent and received by elements of the system 1 00 to ensure secure encryption of transmission and secure storage of encrypted data.
  • the method 500 may also include instructions to ensure integrity and non- repudiation of sensitive data (if applicable, for data in transit).
  • the method 500 may employ symmetric (e.g., AES-GCM, CBS, CCM) or asymmetric (e.g., PKI) keys.
  • the encryption keys may also be securely protected.
  • the key sizes may be 1 28-bits or higher(sym), or in an RSA Modulus, 2048-bits or higher (asym).
  • ECC keysize may be 256-bits or higher, as per Industry best practices and protocols.
  • the method 500 may securely transmit the payload data 1 32A by, for example, two- way SSL to secure communication of personally identifiable information (e.g., cardholder address) as well as personal account identifiers (e.g., token).
  • personally identifiable information e.g., cardholder address
  • personal account identifiers e.g., token
  • this secure transmission may occur by SSL/TLS secure communication, as per Industry best practices and protocols.
  • the method 500 may also include instructions for controlling authentication and session management.
  • communications include appropriate authentication methods between applications (e.g., mobile app, web redirects) or between business entities (e.g., client-to-server, server-to-server).
  • the method 500 may control authentication and session management by user name/password, PIN, OAuth 2.0, SAML 2.0, etc., as per Industry best practices and protocols.
  • the method may also include instructions to employ access control measures that prevent identity attacks.
  • the method 500 may include instructions for role-based access control, as per Industry best practices.
  • block 306 includes instructions for the merchant e- commerce computer system 104 to send confirmation data 168 indicating the status of the payload data 132A back to the e-commerce enabler system 108.
  • an authorized entity of the merchant e-commerce computer system 104 may confirm the payload data 132A. Execution of instructions to confirm payment at block 305 may occur in real time, immediately after the checkout is submitted by the account holder computer system 103 to the merchant e-commerce computer system 104, or at a later time.
  • Confirmation may be made directly from the website 158 of the merchant e-commerce computer system 104 to the e-commerce enabler system 108 by passing parameters in a one-pixel image as provided by the e-commerce enabler system 108. Confirmation may also be made in a server-to- server request (e.g., the e-commerce server 144 to the e-commerce enabler server 126).
  • a server-to- server request e.g., the e-commerce server 144 to the e-commerce enabler server 126.
  • Both order and payment status may be communicated by the confirmation data 168 at block 306 and may also include updates that are sent periodically or as information is available to send to the e-commerce enabler system 108. Update data may also be sent for a specific order, as identified by a particular transaction ID.
  • An order status of the confirmation data 168 may include various data including indications that an order was placed, rejected, and/or cancelled, etc.
  • a payment status of the confirmation data 168 may also include various data including indications of success or failure for authorization, settlement, refunds, reversals, chargebacks, etc.
  • the confirmation data 168 may be sent to the e-commerce enabler system 108 in one or many updates based on the nature and type of transaction.
  • the confirmation data 1 68 may include any data that indicates the status of the transaction between the merchant e-commerce computer system 104 and the e- commerce enabler system 108.
  • the confirmation data includes an e-commerce enabler transaction ID associated with a payment request, a public API key that is different than the shared secret, an indication of the currency with which to process the transaction, a total of discounts related to the payment (e.g., a positive value representing the amount to be deducted from the total), an indication of the event associated with the update, a subtotal of the payment, a total of shipping and handling charges in the payment, a total tax-related charges in the payment, a total gift-wrapping charges in the payment, a total uncategorized charges in the payment, a total of the payment including all amounts, a merchant's order ID associated with the payment, a description associated with the payment, a promotion codes associated with the payment, a reason for the update, etc.
  • the confirmation data 168 may include a token signature identifying the transaction and its contents.
  • Block 306 may include instructions for the e-commerce enabler system to use this signature to validate the caller of a particular request 166.
  • a method 700 may complete an e-commerce transaction within the system 100 using a payment device 200.
  • This method 700 may generally describe a cardholder initiating a payment to an e-commerce site using the e-commerce enabler and a wallet application 170 executing at the account holder computer system 103 to transfer payment and other order information.
  • the 152 may include instructions to perform transaction processing described by the method 700.
  • the wallet application may execute instructions to pass the payment data (PAN and other information) to the merchant e-commerce computer system 104.
  • the checkout module 1 52 may execute instructions to initiate authorizations using the payload data 132A provided by the e-commerce enabler system 108.
  • a payment application 164 may access the website 158 to perform an e-commerce transaction.
  • the method 700 may execute instructions to pay for merchant's goods/services using the wallet application 1 70 that is linked to the e-commerce enabler system 108.
  • the method 700 may execute instructions to provide or receive payment data from the account holder computer system 103.
  • the payment data includes account holder data 120A including a PAN, expiration date, etc., billing and shipping address etc.
  • the method 700 may execute instructions to confirm the received payment data using the e-commerce enabler system and also create the payload data 132A.
  • the method 700 may execute instructions to receive the payload data 132A from the e-commerce enabler system 108 and, at block 712, decrypt at least a portion of the payload data 1 32A.
  • the method 700 may execute instructions to display a portion of one or more of the decrypted payload data 132A or the payment information for review at the account holder computer system 103.
  • the method 700 may then execute instructions to cause the merchant e-commerce computer system 104 to pass an authorization request to an acquirer of the payment network system 106.
  • the acquirer may perform processing checks on the payload data 132A, and, at block 718, the payment network system 1 06 may pass the authorization request to a bank that issued the payment device 200 used in the transaction.
  • the bank may complete an account-level validation and authorization check of the payload data and send an authorization response to the payment network system 106.
  • the payment network system 106 may pass at least a portion of the payload data 132A to the acquirer as part of the authorization response with standard data elements, and the acquirer may pass the authorization response to the merchant e- commerce computer system 104.
  • the method 700 may execute instructions to notify the account holder computer system of success or failure of the payment transaction.
  • a method 730 may complete an e-commerce transaction within the system 100 using a token 140A.
  • This method 730 may generally describe a cardholder initiating a payment to an e-commerce site using the e-commerce enabler and a wallet application 170 executing at the account holder computer system 103 to transfer payment and other order information.
  • this method 730 describes the merchant e-commerce computer system as requesting a token 140A rather than a PAN or other data that may directly correspond to the payment device 200.
  • the e-commerce enabler system 108 may assist in the tokenization process to free the merchant e- commerce computer system 104 from storing the PAN or other sensitive information.
  • the wallet application 170 may pass a token 140A in lieu of the PAN or other information to the merchant e-commerce computer system 104. The merchant e-commerce computer system 104 may then initiate authorizations using the token 140A.
  • a payment application 164 may access the website 158 to perform an e-commerce transaction.
  • the method 730 may execute instructions to pay for merchant's goods/services using the wallet application 1 70 that is linked to the e-commerce enabler system 108.
  • the method 730 may execute instructions to provide or receive payment data from the account holder computer system 103.
  • the payment data includes account holder data 120A including a PAN, expiration date, etc., billing and shipping address etc.
  • the method 730 may execute instructions to confirm the received payment data using the e-commerce enabler system and also create the payload data 132A including a token 140A.
  • Block 738 may also include instructions to generate a cryptogram for the token 140A.
  • the method 730 may execute instructions to receive the payload data 132A including the token 140A from the e-commerce enabler system 108 and, at block 742, decrypt at least a portion of the payload data 132A.
  • the method 730 may execute instructions to display a portion of one or more of the decrypted payload data 132A or the payment information for review at the account holder computer system 1 03.
  • the method 730 may then execute instructions to cause the merchant e-commerce computer system 104 to pass an authorization request to an acquirer of the payment network system 106.
  • the acquirer may perform processing checks on the payload data 132A, and, at block 748, pass the token 140A to the payment network system 106.
  • the payment network system 106 may interface with the token service provider 1 1 0 to retrieve the PAN, verify the state of a mapping between the token 140A and the PAN in the token vault repository 140, and other controls that may be defined for the token 140A.
  • the payment network system 106 may also validate the cryptogram for the token 140A and validate a token domain restriction controls for the token 140A. Alternatively, a card issuer may validate the cryptogram if it has the necessary keys. Where the token requestor ID is not included with the token 140A, it may also be retrieved at block 750.
  • the method 730 may pass the authorization request to a bank that issued the payment device 200 used in the transaction, the authorization request including the PAN, PAN expiration date, and an indicator that conveys to the issuer bank that an on-behalf-of validation has been completed by the Token Service Provider 1 10 of the token 140A.
  • the authorization request to the issuer bank may include the token 140A, a token expiry date, token assurance data, a token assurance level, a token requestor ID, a POS entry mode code, etc.
  • the payment network system 106 may replace the PAN with the token 140A based on the mapping, and pass further data to the acquirer as part of the authorization response.
  • the further data may include the payment token 140A, a token assurance level, a last four digits of the PAN, and a PAN product ID.
  • the acquirer may also pass the authorization response to the merchant e-commerce computer system 104.
  • the method 730 may execute instructions to notify the account holder computer system of success or failure of the payment transaction.
  • a method 760 may complete an e-commerce transaction within the system 100 where a merchant e-commerce computer system 104 is integrated with a partner to handle its payment processing or the partner hosts the website 158.
  • a cardholder may initiate payment to the merchant e-commerce computer system 104 via the website 158 using a wallet application 170 to transfer payment and other order information.
  • the merchant e-commerce computer system may be integrated to a partner.
  • the partner performs transaction processing and the merchant may provide their relationship with the partner to the e-Commerce enabler system 108.
  • the assigned partner receives corresponding credentials required to transact with the e- commerce enabler system 108.
  • the merchant e-commerce computer system 104 assigns the partner as an authorized entity to receive payment data from the e-commerce enabler system 108.
  • the e-commerce enabler system generates the authorized credentials needed for the partner to make transactions on behalf of the merchant.
  • the e-commerce enabler system may send an identifier of the payment in the payload data 140A to the merchant e-commerce commuter system 1 04.
  • the merchant e- commerce computer system 104 not having the infrastructure for business reasons and other rationale to process payments, may pass on this identifier to the partner. Partners can then request the e-commerce enabler system 1 08 for payload data 140A for the corresponding checkout transaction using the checkout transaction identifier.
  • the e-commerce enabler system 108 authorizes the partner and provides the partner with the payload data 140A. Partners may then initiate authorizations using the payload data 140A provided by the e-commerce enabler.
  • the partner hosts the website 158, the partner also renders the e- commerce enabler graphic object 156, and performs transaction processing.
  • the merchant e-commerce computer system provides data identifying the relationship to the partner with the e-commerce enabler system 108.
  • the assigned partner receives corresponding credentials required to transact with the e-commerce enabler system 108.
  • the partner then enables the merchant e- commerce computer system 104 for using the e-commerce enabler system 108 as a payment option.
  • Partners request payment data from the e-commerce enabler system 108 for the consumer's checkout transaction on behalf of the merchant, and initiate authorizations using the payload data 140A provided by the e-commerce enabler system 108.
  • a payment application 164 may access the website 158 to perform an e-commerce transaction.
  • the method 760 may execute instructions to pay for merchant's goods/services using the wallet application 1 70 that is linked to the e-commerce enabler system 108.
  • the method 760 may execute instructions to provide or receive payment data from the account holder computer system 103.
  • the payment data includes account holder data 120A including a PAN, expiration date, etc., billing and shipping address etc.
  • the method 760 may execute instructions to confirm the received payment data using the e-commerce enabler system.
  • the method 760 may execute instructions to pass a transaction identifier corresponding to the consumer checkout to the merchant e-commerce computer system 1 04 from the e- commerce enabler system 108.
  • the method 760 may execute instructions to display a portion of one or more of the decrypted payload data 132A or the payment information for review at the account holder computer system 103 for confirmation by the consumer.
  • the method 760 may pass the transaction identifier from the merchant e-commerce computer system to the partner.
  • the method 760 may then cause the partner to initiate a request for payload data 140A to the e-commerce enabler system 108 and, upon receipt by the partner, decrypt at least a portion of the payload data 140A.
  • the method 760 may cause the partner to send an authorization request and receive a response to the authorization request.
  • the partner may perform processing checks on the payload data 140A, and pass the PAN and other account holder data 1 20A to the payment network system 106.
  • the payment network system 106 may send the authorization request to the issuer bank, and the issuer bank may complete the account-level validation and the authorization checks.
  • the issuer bank may then send an authorization response to the payment network system 106.
  • the payment network system may then pass the required fields to the partner as part of the authorization response with standard data elements.
  • the partner may update the e-commerce enabler system 108 on the status of the payment and order.
  • Fig. 8 is a high-level block diagram of an example computing environment 800 for the system and associated methods for securely facilitating payment reconciliation for a transaction between a credit account holder and an e-commerce merchant, as described herein.
  • the computing device 801 may include a server (e.g., servers 1 16, 126, 136, 144, etc.), a mobile computing device (e.g., account holder computing device 103, a cellular phone, a tablet computer, a Wi-Fi-enabled device or other personal computing device capable of wireless or wired communication), a thin client, or other known type of computing device.
  • a server e.g., servers 1 16, 126, 136, 144, etc.
  • a mobile computing device e.g., account holder computing device 103, a cellular phone, a tablet computer, a Wi-Fi-enabled device or other personal computing device capable of wireless or wired communication
  • a thin client or other known type of computing device.
  • other types of computing devices can
  • Processor systems similar or identical to the example system and associated methods for securely facilitating payment reconciliation for a transaction between a credit account holder and an e-commerce merchant may be used to implement and execute the example systems of Fig. 1 .
  • the example system 800 is described below as including a plurality of peripherals, interfaces, chips, memories, etc., one or more of those elements may be omitted from other example processor systems used to implement and execute the example system described herein. Also, other components may be added.
  • the computing device 801 includes a processor 802 that is coupled to an interconnection bus.
  • the processor 802 includes a register set or register space 804, which is depicted in Fig. 8 as being entirely on-chip, but which could alternatively be located entirely or partially off-chip and directly coupled to the processor 802 via dedicated electrical connections and/or via the interconnection bus.
  • the processor 82 may be any suitable processor, processing unit or microprocessor.
  • the computing device 801 may be a multi-processor device and, thus, may include one or more additional processors that are identical or similar to the processor 802 and that are communicatively coupled to the interconnection bus.
  • the processor 802 of Fig. 8 is coupled to a chipset 806, which includes a memory controller 808 and a peripheral input/output (I/O) controller 810.
  • a chipset typically provides I/O and memory management functions as well as a plurality of general purpose and/or special purpose registers, timers, etc. that are accessible or used by one or more processors coupled to the chipset 806.
  • the memory controller 808 performs functions that enable the processor 802 (or processors if there are multiple processors) to access a system memory 812 and a mass storage memory 814, that may include either or both of an in-memory cache (e.g., a cache within the memory 812) or an on-disk cache (e.g., a cache within the mass storage memory 814).
  • the system memory 812 may include any desired type of volatile and/or non-volatile memory such as, for example, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, read-only memory (ROM), etc.
  • the mass storage memory 814 may include any desired type of mass storage device.
  • the mass storage memory 814 may include a hard disk drive, an optical drive, a tape storage device, a solid-state memory (e.g., a flash memory, a RAM memory, etc.), a magnetic memory (e.g., a hard drive), or any other memory suitable for mass storage.
  • a hard disk drive e.g., the various modules for securely facilitating payment reconciliation for a transaction between a credit account holder and an e-commerce merchant, as herein described.
  • the mass storage memory 814 may include a hard disk drive, an optical drive, a tape storage device, a solid-state memory (e.g., a flash memory, a RAM memory, etc.), a magnetic memory (e.g., a hard drive), or any other memory suitable for mass storage.
  • the terms module, block, function, operation, procedure, routine, step, and method refer to tangible computer program logic or tangible computer executable instructions that provide the specified functionality to the computing device 801 and the system 800.
  • a module, block, function, operation, procedure, routine, step, and method can be implemented in hardware, firmware, and/or software.
  • program modules and routines are stored in mass storage memory 814, loaded into system memory 812, and executed by a processor 802 or can be provided from computer program products that are stored in tangible computer-readable storage mediums (e.g. RAM, hard disk, optical/magnetic media, etc.).
  • the peripheral I/O controller 810 performs functions that enable the processor 802 to communicate with a peripheral input/output (I/O) device 824, a network interface 826, a local network transceiver 828, (via the network interface 1026) via a peripheral I/O bus.
  • the I/O device 824 may be any desired type of I/O device such as, for example, a keyboard, a display (e.g., a liquid crystal display (LCD), a cathode ray tube (CRT) display, etc.), a navigation device (e.g., a mouse, a trackball, a capacitive touch pad, a joystick, etc.), etc.
  • the I/O device 824 may be used with the module 816, etc., to receive data from the transceiver 828, send the data to the components of the system 1 00, and perform any operations related to the methods as described herein.
  • the local network transceiver 828 may include support for a Wi-Fi network, Bluetooth, Infrared, cellular, or other wireless data transmission protocols.
  • one element may simultaneously support each of the various wireless protocols employed by the computing device 801 .
  • a software-defined radio may be able to support multiple protocols via downloadable instructions.
  • the computing device 801 may be able to periodically poll for visible wireless network transmitters (both cellular and local network) on a periodic basis.
  • the network interface 826 may be, for example, an Ethernet device, an asynchronous transfer mode (ATM) device, an 802.1 1 wireless interface device, a DSL modem, a cable modem, a cellular modem, etc., that enables the system 1 00 to communicate with another computer system having at least the elements described in relation to the system 100.
  • ATM asynchronous transfer mode
  • 802.1 1 wireless interface device a DSL modem, a cable modem, a cellular modem, etc.
  • the computing environment 800 may also implement the module 816 on a remote computing device 830.
  • the remote computing device 830 may communicate with the computing device 801 over an Ethernet link 832.
  • the module 816 may be retrieved by the computing device 801 from a cloud computing server 834 via the Internet 836.
  • the retrieved module 81 6 may be programmatically linked with the computing device 801 .
  • the module 816 may be a collection of various software platforms including artificial intelligence software and document creation software or may also be a Java® applet executing within a Java® Virtual Machine (JVM) environment resident in the computing device 801 or the remote computing device 830.
  • the module 816 may also be a "plug-in" adapted to execute in a web-browser located on the computing devices 801 and 830.
  • the module 81 6 may communicate with back end components 838 such as the merchant e-commerce computer system 1 04, the e- commerce enabler system 108, the payment network system 106, and the token service provider 1 1 0 of FIG. 1 via the Internet 836.
  • the system 800 may include but is not limited to any combination of a
  • LAN local area network
  • MAN metropolitan area network
  • WAN wide area network
  • mobile a wired or wireless network
  • private network a private network
  • virtual private network a virtual private network.
  • remote computing device 830 is illustrated in Fig. 8 to simplify and clarify the description, it is understood that any number of client computers are supported and can be in communication within the system 800.
  • 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.
  • one or more computer systems e.g., a standalone, client or server computer system
  • one or more hardware modules of a computer system e.g., a processor or a group of processors
  • software e.g., an application or application portion
  • a hardware module may be implemented mechanically or electronically.
  • 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.
  • 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.
  • “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).
  • a resource e.g., a collection of information
  • processors may be 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.
  • 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.
  • 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).)
  • SaaS software as a service
  • 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.
  • the one or more processors or processor-implemented modules may be located in a single
  • the one or more processors or processor-implemented modules may be distributed across a number of geographic locations.
  • 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.
  • Coupled and “connected” along with their derivatives.
  • 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.

Landscapes

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

Abstract

Des systèmes et des procédés peuvent faciliter des transactions de paiement entre les systèmes informatiques d'un utilisateur et les systèmes informatiques d'un commerçant. Un système de validation de commerce électronique peut générer une bibliothèque d'instructions à exécuter sur le dispositif informatique utilisateur. Lors de l'exécution, la bibliothèque d'instructions peut fournir des informations de paiement pour une transaction de paiement effectuée avec un système informatique de commerce électronique d'un commerçant par le biais du site Web hébergé par le système informatique de commerce électronique du commerçant. Les informations de paiement peuvent correspondre aux données d'un titulaire de compte principal identifiant un dispositif de paiement. Le système de validation de commerce électronique peut transférer les informations de paiement à un système de réseau de paiement, créer des données de charge utile de paiement à partir des données renvoyées par le système de réseau de paiement, et transmettre les données de charge utile au système informatique de commerce électronique du commerçant. Ensuite, le système informatique de commerce électronique du commerçant peut déchiffrer au moins une partie des données de charge utile de paiement pour effectuer la transaction de paiement entre le dispositif informatique et le système informatique de commerce électronique du commerçant.
PCT/US2017/027957 2016-04-15 2017-04-17 Système et procédé pour paiements web sécurisés WO2017181185A1 (fr)

Priority Applications (7)

Application Number Priority Date Filing Date Title
EP17783362.1A EP3443515A4 (fr) 2016-04-15 2017-04-17 Système et procédé pour paiements web sécurisés
RU2018136099A RU2018136099A (ru) 2016-04-15 2017-04-17 Система и способ безопасных платежей через веб-сайт
CA3019922A CA3019922A1 (fr) 2016-04-15 2017-04-17 Systeme et procede pour paiements web securises
JP2018553362A JP2019517055A (ja) 2016-04-15 2017-04-17 セキュアなウェブ支払のためのシステムおよび方法
SG11201808714WA SG11201808714WA (en) 2016-04-15 2017-04-17 System and method for secure web payments
CN201780023331.9A CN109155026A (zh) 2016-04-15 2017-04-17 用于安全网络支付的系统和方法
AU2017250377A AU2017250377A1 (en) 2016-04-15 2017-04-17 System and method for secure web payments

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662323148P 2016-04-15 2016-04-15
US62/323,148 2016-04-15

Publications (1)

Publication Number Publication Date
WO2017181185A1 true WO2017181185A1 (fr) 2017-10-19

Family

ID=60039517

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/027957 WO2017181185A1 (fr) 2016-04-15 2017-04-17 Système et procédé pour paiements web sécurisés

Country Status (9)

Country Link
US (1) US20170300909A1 (fr)
EP (1) EP3443515A4 (fr)
JP (1) JP2019517055A (fr)
CN (1) CN109155026A (fr)
AU (1) AU2017250377A1 (fr)
CA (1) CA3019922A1 (fr)
RU (1) RU2018136099A (fr)
SG (1) SG11201808714WA (fr)
WO (1) WO2017181185A1 (fr)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019246539A1 (fr) 2018-06-22 2019-12-26 Visa International Service Association Environnement-cadre de transactions à distance sécurisées utilisant un élément de passage en caisse sécurisé dynamique
US10937025B1 (en) 2015-01-15 2021-03-02 Wells Fargo Bank, N.A. Payment services via application programming interface
CN112703523A (zh) * 2018-09-12 2021-04-23 维萨国际服务协会 点对点支付的系统和方法
US10990974B1 (en) 2015-01-15 2021-04-27 Wells Fargo Bank, N.A. Identity verification services and user information provision via application programming interface
US10997654B1 (en) 2015-01-15 2021-05-04 Wells Fargo Bank, N.A. Identity verification services through external entities via application programming interface
US11044092B1 (en) 2019-06-21 2021-06-22 Wells Fargo Bank, N.A. Secure communications via third-party systems through frames
US11093912B1 (en) 2018-12-10 2021-08-17 Wells Fargo Bank, N.A. Third-party payment interfaces
US11106515B1 (en) 2017-12-28 2021-08-31 Wells Fargo Bank, N.A. Systems and methods for multi-platform product integration
US11161245B2 (en) 2018-10-25 2021-11-02 Wells Fargo Bank, N.A. Systems and methods for secure locker feeders
US11468485B1 (en) 2015-01-09 2022-10-11 Wells Fargo Bank, N.A. Systems and methods for on demand and location-based offers
US11676126B1 (en) 2017-12-28 2023-06-13 Wells Fargo Bank, N.A. Account open interfaces
US11847690B1 (en) 2015-01-15 2023-12-19 Wells Fargo Bank, N.A. Identity verification services with identity score through external entities via application programming interface
US11995619B1 (en) 2017-12-28 2024-05-28 Wells Fargo Bank, N.A. Account open interfaces

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10706400B1 (en) 2015-11-19 2020-07-07 Wells Fargo Bank, N.A. Systems and methods for financial operations performed at a contactless ATM
US10535047B1 (en) 2015-11-19 2020-01-14 Wells Fargo Bank N.A. Systems and methods for financial operations performed at a contactless ATM
US11645697B2 (en) * 2016-10-06 2023-05-09 Bread Financial Payments, Inc. Simple checkout
US11164188B2 (en) * 2017-11-14 2021-11-02 Intel Corporation Methods and apparatus to securely handle chip cards
WO2019139595A1 (fr) * 2018-01-11 2019-07-18 Visa International Service Association Autorisation hors ligne d'interactions et de tâches contrôlées
US11605065B2 (en) * 2018-08-24 2023-03-14 Mastercard International Incorporated Systems and methods for secure remote commerce
WO2021007026A1 (fr) * 2019-07-08 2021-01-14 Mastercard International Incorporated Systèmes et procédés destinés à être utilisés pour faciliter des interactions de réseau

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090299820A1 (en) * 2006-03-31 2009-12-03 Lee Wang Contingent fee advertisement publishing service provider system and method
US20150019443A1 (en) * 2013-07-15 2015-01-15 John Sheets Secure remote payment transaction processing
EP2838060A1 (fr) 2013-08-14 2015-02-18 Facebook, Inc. Procédés et systèmes permettant de faciliter des paiements de commerce électronique
US20150248664A1 (en) * 2011-02-16 2015-09-03 Visa International Service Association Snap Mobile Payment Apparatuses, Methods and Systems

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001101271A (ja) * 1999-09-28 2001-04-13 Kazuhiro Shiina 認証・決済代行機関によるネットワーク上の決済システム
US20010047335A1 (en) * 2000-04-28 2001-11-29 Martin Arndt Secure payment method and apparatus
US7111168B2 (en) * 2000-05-01 2006-09-19 Digimarc Corporation Digital watermarking systems
JP2001344550A (ja) * 2000-06-02 2001-12-14 Nec Informatec Systems Ltd 電子決済方法及びシステム並びに電子決済用プログラムを記憶した記憶媒体
JP2002042015A (ja) * 2000-07-21 2002-02-08 Toshinori Kido クレジットカード決済システム
JP2002279195A (ja) * 2001-03-16 2002-09-27 Toshiba Corp 消費者システム及び暗証番号入力端末装置
US20130046679A1 (en) * 2005-05-06 2013-02-21 Caringfamily, Llc Joint payment
US8725644B2 (en) * 2011-01-28 2014-05-13 The Active Network, Inc. Secure online transaction processing
WO2012106655A2 (fr) * 2011-02-05 2012-08-09 Visa International Service Association Appareils, procédés et systèmes de plateforme de liaison marchand-consommateur
US9760871B1 (en) * 2011-04-01 2017-09-12 Visa International Service Association Event-triggered business-to-business electronic payment processing apparatuses, methods and systems
WO2012151590A2 (fr) * 2011-05-05 2012-11-08 Transaction Network Services, Inc. Systèmes et procédés permettant d'effectuer des paiements mobiles
EP2718886A4 (fr) * 2011-06-07 2015-01-14 Visa Int Service Ass Appareils, procédés et systèmes de segmentation en unités de confidentialité de paiement
US10438176B2 (en) * 2011-07-17 2019-10-08 Visa International Service Association Multiple merchant payment processor platform apparatuses, methods and systems
US9508072B2 (en) * 2011-08-26 2016-11-29 Paypal, Inc. Secure payment instruction system
EP2767110A4 (fr) * 2011-10-12 2015-01-28 C Sam Inc Plateforme mobile d'activation de transaction sécurisée à plusieurs étages
US9830596B2 (en) * 2011-11-01 2017-11-28 Stripe, Inc. Method for conducting a transaction between a merchant site and a customer's electronic device without exposing payment information to a server-side application of the merchant site
US20140032399A1 (en) * 2012-07-30 2014-01-30 Ewise Systems Usa Inc. Electronic transaction system
US20160019536A1 (en) * 2012-10-17 2016-01-21 Royal Bank Of Canada Secure processing of data
US11080700B2 (en) * 2015-01-19 2021-08-03 Royal Bank Of Canada Secure processing of electronic payments
US20140351080A1 (en) * 2013-05-24 2014-11-27 Retry Llc System and method for joint shopping cart
GB201312398D0 (en) * 2013-07-10 2013-08-21 Powa Technologies Ltd Electronic transaction validation
US10496964B2 (en) * 2014-04-02 2019-12-03 Facebook, Inc. Routing payments to payment aggregators
JP2016009375A (ja) * 2014-06-25 2016-01-18 Ｎｅｃエンジニアリング株式会社 決済システムおよび決済処理方法
US10783513B2 (en) * 2014-10-27 2020-09-22 Facebook, Inc. Facilitating sending and receiving of payments using message-based contextual prompts
US20170169420A1 (en) * 2015-12-14 2017-06-15 WIBMO Inc. One-step payments in a secure digital platform
US11216805B2 (en) * 2016-09-08 2022-01-04 Modopayments, Llc COIN operated digital payments hub
US20180096320A1 (en) * 2016-10-03 2018-04-05 Paypal, Inc. Account top-up feature to interface with a vendor application programming interface
SG10201701042TA (en) * 2017-02-09 2018-09-27 Mastercard Asia Pacific Pte Ltd System For Making An Electronic Payment Transaction

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090299820A1 (en) * 2006-03-31 2009-12-03 Lee Wang Contingent fee advertisement publishing service provider system and method
US20150248664A1 (en) * 2011-02-16 2015-09-03 Visa International Service Association Snap Mobile Payment Apparatuses, Methods and Systems
US20150019443A1 (en) * 2013-07-15 2015-01-15 John Sheets Secure remote payment transaction processing
EP2838060A1 (fr) 2013-08-14 2015-02-18 Facebook, Inc. Procédés et systèmes permettant de faciliter des paiements de commerce électronique

Non-Patent Citations (1)

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

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11468485B1 (en) 2015-01-09 2022-10-11 Wells Fargo Bank, N.A. Systems and methods for on demand and location-based offers
US11847690B1 (en) 2015-01-15 2023-12-19 Wells Fargo Bank, N.A. Identity verification services with identity score through external entities via application programming interface
US10937025B1 (en) 2015-01-15 2021-03-02 Wells Fargo Bank, N.A. Payment services via application programming interface
US10990974B1 (en) 2015-01-15 2021-04-27 Wells Fargo Bank, N.A. Identity verification services and user information provision via application programming interface
US10997654B1 (en) 2015-01-15 2021-05-04 Wells Fargo Bank, N.A. Identity verification services through external entities via application programming interface
US11238421B1 (en) 2015-01-15 2022-02-01 Wells Fargo Bank, N.A. Payment services via application programming interface
US11475514B1 (en) 2015-01-15 2022-10-18 Wells Fargo Bank, N.A. Identity verification services through external entities via application programming interface
US11868977B1 (en) 2015-01-15 2024-01-09 Wells Fargo Bank, N.A. Payment services via application programming interface
US11106515B1 (en) 2017-12-28 2021-08-31 Wells Fargo Bank, N.A. Systems and methods for multi-platform product integration
US11995619B1 (en) 2017-12-28 2024-05-28 Wells Fargo Bank, N.A. Account open interfaces
US11676126B1 (en) 2017-12-28 2023-06-13 Wells Fargo Bank, N.A. Account open interfaces
WO2019246539A1 (fr) 2018-06-22 2019-12-26 Visa International Service Association Environnement-cadre de transactions à distance sécurisées utilisant un élément de passage en caisse sécurisé dynamique
CN112703523A (zh) * 2018-09-12 2021-04-23 维萨国际服务协会 点对点支付的系统和方法
US11161245B2 (en) 2018-10-25 2021-11-02 Wells Fargo Bank, N.A. Systems and methods for secure locker feeders
US11093912B1 (en) 2018-12-10 2021-08-17 Wells Fargo Bank, N.A. Third-party payment interfaces
US11379850B1 (en) 2018-12-10 2022-07-05 Wells Fargo Bank, N.A. Third-party payment interfaces
US11756011B1 (en) 2018-12-10 2023-09-12 Wells Fargo Bank, N.A. Third-party payment interfaces
US11797956B1 (en) 2018-12-10 2023-10-24 Wells Fargo Bank, N.A. Third-party payment interfaces
US11044246B1 (en) 2019-06-21 2021-06-22 Wells Fargo Bank, N.A. Secure communications via third-party systems through frames
US11700122B1 (en) 2019-06-21 2023-07-11 Wells Fargo Bank, N.A. Secure communications via third-party systems through frames
US11700248B1 (en) 2019-06-21 2023-07-11 Wells Fargo Bank, N.A. Secure communications via third-party systems through frames
US11695560B1 (en) 2019-06-21 2023-07-04 Wells Fargo Bank, N.A. Secure communications via third-party systems through frames
US11050565B1 (en) 2019-06-21 2021-06-29 Wells Fargo Bank, N.A. Secure communications via third-party systems through frames
US11044092B1 (en) 2019-06-21 2021-06-22 Wells Fargo Bank, N.A. Secure communications via third-party systems through frames

Also Published As

Publication number Publication date
CN109155026A (zh) 2019-01-04
EP3443515A1 (fr) 2019-02-20
US20170300909A1 (en) 2017-10-19
RU2018136099A (ru) 2020-05-15
CA3019922A1 (fr) 2017-10-19
EP3443515A4 (fr) 2019-04-03
SG11201808714WA (en) 2018-11-29
RU2018136099A3 (fr) 2020-07-30
JP2019517055A (ja) 2019-06-20
AU2017250377A1 (en) 2018-10-25

Similar Documents

Publication Publication Date Title
US20170300909A1 (en) System and method for secure web payments
JP7189769B2 (ja) 位置照合を使用する認証システムおよび方法
CN109328445B (zh) 唯一令牌认证验证值
CN108885747B (zh) 适应性认证处理
CN110869961A (zh) 用于使用交易标识符来保护敏感凭据的系统和方法
US20230237457A1 (en) Systems and methods for payment processing on platforms
US20140101055A1 (en) Systems, methods, and computer program products for managing remote transactions
US20230019012A1 (en) Secure remote transaction system using mobile devices
CA3010055A1 (fr) Systemes et methode de retraits de fonds sans carte actives par un dispositif mobile
EP3400567B1 (fr) Accès universel à un portefeuille électronique
US11645697B2 (en) Simple checkout
WO2020023500A1 (fr) Paiement avec des points au niveau d'un point de service
US10121147B2 (en) Methods of processing transactions and related systems and computer program products
US11640592B2 (en) System, method, and apparatus for integrating multiple payment options on a merchant webpage
US20180114201A1 (en) Universal payment and transaction system
EP3933735A1 (fr) Service d'observation de réseau de paiement
US11507936B2 (en) Payment transaction systems and methods by dynamically pushing data to payment service provider
US20210142317A1 (en) Systems and methods for global financial transaction routing

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 3019922

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 2018553362

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017250377

Country of ref document: AU

Date of ref document: 20170417

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2017783362

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2017783362

Country of ref document: EP

Effective date: 20181115

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

Ref document number: 17783362

Country of ref document: EP

Kind code of ref document: A1