Method, system, and computer program product for dynamically ensuring SDK integrity

Abstract

A system, method, and computer program product for dynamically ensuring SDK integrity: loading a software development kit (SDK) wrapper from a payment gateway system on a merchant system through a merchant webpage associated with the merchant system; executing the SDK wrapper, which loads an SDK core when executed; determining the integrity of the SDK core; performing a handshake between the SDK wrapper and the SDK core in response to determining the integrity of the SDK core, and overloading real functions exported by the SDK wrapper; and providing a secure payment container request from the merchant system to a payment gateway system through the SDK core.

Description

Technical Field

[0001] The present disclosure relates generally to systems, apparatuses, products, devices, and methods for software development kits (SDKs), and in some embodiments or aspects, to methods, systems, and products for dynamically ensuring SDK integrity. Background Art

[0002] Accept.js is a JavaScript library for sending secure payment data directly to a payment gateway system (e.g., Authorize.Net, etc.). Accept.js captures payment data and submits it directly to the payment gateway system in exchange for a one-time use token or payment nonce. This payment nonce can be used in place of payment data in subsequent createTransactionRequest API calls. AcceptCore.js verifies the information passed from the merchant web page to the payment gateway system and calls a secure payment container request in response to the information being verified. The Accept.js and AcceptCore.js libraries are described by the Authorize.Net API reference published at https: / / developer.authorize.net / api / reference / , the entire contents of which are incorporated herein by reference in their entirety.

[0003] When a merchant webpage loads a client-side software development kit (SDK), such as the client-side SDK provided by Authorize.Net, by adding the Accept.js and AcceptCore.js libraries as script tags to the merchant webpage, a man-in-the-middle attack may change the SDK. Therefore, the integrity of the SDK needs to be verified. The merchant website may include a W3C subresource integrity check, which is defined by the W3C Recommendation published on June 23, 2016 at https: / / www.w3.org / TR / SRI / , the entire contents of which are incorporated herein by reference in their entirety, and the W3C Recommendation is a mechanism by which a user agent can verify that the acquired resources were delivered without unexpected manipulation. For example, an integrity check hash from the W3C subresource integrity mechanism can be added to the merchant webpage as a script tag with the AcceptCore.js library to verify the integrity of the AcceptCore.js library. However, if a new version of the AcceptCore.js library is released and / or the AcceptCore.js library is changed, the hash will also change, and the merchant webpage must be updated to reflect the changes so that the AcceptCore.js library passes or satisfies the integrity check. Therefore, the merchant can completely remove the integrity check hash from the merchant webpage to avoid having to repeatedly update the merchant webpage, which may expose transactions conducted on the merchant webpage to man-in-the-middle attacks and / or the like. Therefore, there is a need in the art for improved SDK integrity checking. Summary of the invention

[0004] Thus, improved systems, apparatus, products, devices and / or methods for dynamically ensuring SDK integrity are provided.

[0005] According to some non-limiting embodiments or aspects, a computer-implemented method is provided, comprising: loading a software development kit (SDK) wrapper from a payment gateway system via a merchant webpage associated with the merchant system with at least one processor on a merchant system; executing the SDK wrapper with at least one processor, wherein the SDK wrapper loads an SDK core when executed; determining the integrity of the SDK core with at least one processor; performing a handshake between the SDK wrapper and the SDK core with at least one processor in response to determining the integrity of the SDK core, and overloading real functions exported by the SDK wrapper; and providing a secure payment container request from the merchant system to a payment gateway system via the SDK core with at least one processor.

[0006] In some non-limiting embodiments or aspects, the method further includes: receiving, with at least one processor, account data associated with an account of a user on the merchant system through the merchant webpage, wherein the SDK wrapper is loaded in response to receiving the account data through the merchant webpage, and wherein the secure payment container request includes the account data.

[0007] In some non-limiting embodiments or aspects, the method further includes receiving, with at least one processor, a token associated with the account data from the payment gateway system in response to providing the secure payment container request.

[0008] In some non-limiting embodiments or aspects, determining the integrity of the SDK core includes performing a W3C subresource integrity check hash on the SDK core.

[0009] In some non-limiting embodiments or aspects, the secure payment container request is provided in response to a successful handshake between the SDK wrapper and the SDK core.

[0010] In some non-limiting embodiments or aspects, executing the SDK wrapper exposes the real function as a public method, and wherein the real function throws an error in response to being called by the merchant system.

[0011] In some non-limiting embodiments or aspects, the SDK wrapper includes an Accept.js library, and the SDK core includes an AcceptCore.js library.

[0012] According to some non-limiting embodiments or aspects, a computing system is provided, comprising: one or more processors, which are programmed and / or configured to: load a software development kit (SDK) wrapper from a payment gateway system through a merchant webpage associated with the merchant system on a merchant system; execute the SDK wrapper, wherein the SDK wrapper loads an SDK core when executed; determine the integrity of the SDK core; perform a handshake between the SDK wrapper and the SDK core in response to determining the integrity of the SDK core, and overload real functions exported by the SDK wrapper; and provide a secure payment container request from the merchant system to a payment gateway system through the SDK core.

[0013] In some non-limiting embodiments or aspects, the one or more processors are further programmed and / or configured to: receive account data associated with a user's account on the merchant system via the merchant webpage, wherein the SDK wrapper is loaded in response to receiving the account data via the merchant webpage, and wherein the secure payment container request includes the account data.

[0014] In some non-limiting embodiments or aspects, the one or more processors are further programmed and / or configured to: receive a token associated with the account data from the payment gateway system in response to providing the secure payment container request.

[0015] In some non-limiting embodiments or aspects, determining the integrity of the SDK core includes performing a W3C subresource integrity check hash on the SDK core.

[0016] In some non-limiting embodiments or aspects, the secure payment container request is provided in response to a successful handshake between the SDK wrapper and the SDK core.

[0017] In some non-limiting embodiments or aspects, executing the SDK wrapper exposes the real function as a public method, and wherein the real function throws an error in response to being called by the merchant system.

[0018] In some non-limiting embodiments or aspects, the SDK wrapper includes an Accept.js library, and the SDK core includes an AcceptCore.js library.

[0019] According to some non-limiting embodiments or aspects, there is provided a computer program product comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium comprising program instructions, which, when executed by at least one processor, cause the at least one processor to: load a software development kit (SDK) wrapper from a payment gateway system through a merchant webpage associated with the merchant system on a merchant system; execute the SDK wrapper, wherein the SDK wrapper loads an SDK core when executed; determine the integrity of the SDK core; perform a handshake between the SDK wrapper and the SDK core in response to determining the integrity of the SDK core, and overload real functions exported by the SDK wrapper; and provide a secure payment container request from the merchant system to the payment gateway system through the SDK core.

[0020] In some non-limiting embodiments or aspects, the instructions further cause the at least one processor to: receive account data associated with an account of a user on the merchant system through the merchant webpage, wherein the SDK wrapper is loaded in response to receiving the account data through the merchant webpage, and wherein the secure payment container request includes the account data.

[0021] In some non-limiting embodiments or aspects, the instructions further cause the at least one processor to: receive a token associated with the account data from the payment gateway system in response to providing the secure payment container request.

[0022] In some non-limiting embodiments or aspects, determining the integrity of the SDK core includes performing a W3C subresource integrity check hash on the SDK core.

[0023] In some non-limiting embodiments or aspects, the secure payment container request is provided in response to a successful handshake between the SDK wrapper and the SDK core.

[0024] In some non-limiting embodiments or aspects, executing the SDK wrapper exposes the real function as a public method, and wherein the real function throws an error in response to being called by the merchant system.

[0025] In some non-limiting embodiments or aspects, the SDK wrapper includes an Accept.js library, and the SDK core includes an AcceptCore.js library.

[0026] Other embodiments or aspects are set forth in the following numbered clauses.

[0027] Clause 1. A computer-implemented method comprising: loading a software development kit (SDK) wrapper from a payment gateway system on a merchant system via a merchant webpage associated with the merchant system using at least one processor; executing the SDK wrapper using at least one processor, wherein the SDK wrapper loads an SDK core when executed; determining the integrity of the SDK core using at least one processor; performing a handshake between the SDK wrapper and the SDK core using at least one processor in response to determining the integrity of the SDK core, and overloading real functions exported by the SDK wrapper; and providing a secure payment container request from the merchant system to a payment gateway system via the SDK core using at least one processor.

[0028] Clause 2. The computer-implemented method of Clause 1 further comprises: receiving, using at least one processor, account data associated with an account of a user on the merchant system through the merchant webpage, wherein the SDK wrapper is loaded in response to receiving the account data through the merchant webpage, and wherein the secure payment container request includes the account data.

[0029] Clause 3. The computer-implemented method of clause 1 or 2, further comprising: receiving, with at least one processor, a token associated with the account data from the payment gateway system in response to providing the secure payment container request.

[0030] Clause 4. The computer-implemented method of any one of Clauses 1 to 3, wherein determining the integrity of the SDK core comprises performing a W3C subresource integrity check hash on the SDK core.

[0031] Clause 5. The computer-implemented method of any one of Clauses 1 to 4, wherein the secure payment container request is provided in response to a successful handshake between the SDK wrapper and the SDK core.

[0032] Clause 6. The computer-implemented method of any one of Clauses 1 to 5, wherein executing the SDK wrapper exposes the real function as a public method, and wherein the real function throws an error in response to being called by the merchant system.

[0033] Clause 7. The computer-implemented method of any one of Clauses 1 to 6, wherein the SDK wrapper comprises an Accept.js library, and wherein the SDK core comprises an AcceptCore.js library.

[0034] Clause 8. A computing system comprising: one or more processors programmed and / or configured to: load a software development kit (SDK) wrapper from a payment gateway system on a merchant system via a merchant webpage associated with the merchant system; execute the SDK wrapper, wherein the SDK wrapper loads an SDK core when executed; determine the integrity of the SDK core; perform a handshake between the SDK wrapper and the SDK core in response to determining the integrity of the SDK core, and overload real functions exported by the SDK wrapper; and provide a secure payment container request from the merchant system to a payment gateway system via the SDK core.

[0035] Clause 9. A computing system according to Clause 8, wherein the one or more processors are further programmed and / or configured to: receive account data associated with a user's account on the merchant system through the merchant webpage, wherein the SDK wrapper is loaded in response to receiving the account data through the merchant webpage, and wherein the secure payment container request includes the account data.

[0036] Clause 10. The computing system of clause 8 or 9, wherein the one or more processors are further programmed and / or configured to: receive a token associated with the account data from the payment gateway system in response to providing the secure payment container request.

[0037] Clause 11. The computing system of any of Clauses 8 to 10, wherein determining the integrity of the SDK core comprises performing a W3C subresource integrity check hash on the SDK core.

[0038] Clause 12. The computing system of any of Clauses 8 to 11, wherein the secure payment container request is provided in response to a successful handshake between the SDK wrapper and the SDK core.

[0039] Clause 13. The computing system of any one of clauses 8 to 12, wherein executing the SDK wrapper exposes the real function as a public method, and wherein the real function throws an error in response to being called by the merchant system.

[0040] Clause 14. The computing system of any of Clauses 8 to 13, wherein the SDK wrapper comprises an Accept.js library, and wherein the SDK core comprises an AcceptCore.js library.

[0041] Clause 15. A computer program product comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium comprising program instructions that, when executed by at least one processor, cause the at least one processor to: load a software development kit (SDK) wrapper from a payment gateway system on a merchant system through a merchant web page associated with the merchant system; execute the SDK wrapper, wherein the SDK wrapper loads an SDK core when executed; determine the integrity of the SDK core; perform a handshake between the SDK wrapper and the SDK core in response to determining the integrity of the SDK core, and overload real functions exported by the SDK wrapper; and provide a secure payment container request from the merchant system to the payment gateway system through the SDK core.

[0042] Clause 16. A computer program product according to Clause 15, wherein the instructions further cause the at least one processor to: receive account data associated with an account of a user on the merchant system through the merchant webpage, wherein the SDK wrapper is loaded in response to receiving the account data through the merchant webpage, and wherein the secure payment container request includes the account data.

[0043] Clause 17. The computer program product of Clause 15 or 16, wherein the instructions further cause the at least one processor to: receive a token associated with the account data from the payment gateway system in response to providing the secure payment container request.

[0044] Clause 18. The computer program product of any of Clauses 15 to 17, wherein determining the integrity of the SDK core comprises performing a W3C subresource integrity check hash on the SDK core.

[0045] Clause 19. The computer program product of any of Clauses 15 to 18, wherein the secure payment container request is provided in response to a successful handshake between the SDK wrapper and the SDK core.

[0046] Clause 20. The computer program product of any one of Clauses 15 to 19, wherein executing the SDK wrapper exposes the real function as a public method, and wherein the real function throws an error in response to being called by the merchant system.

[0047] Clause 21. The computer program product of any one of Clauses 15 to 20, wherein the SDK wrapper comprises an Accept.js library, and wherein the SDK core comprises an AcceptCore.js library.

[0048] These and other features and characteristics of the present disclosure, as well as methods of operation and functions of combinations of related structural elements and parts and economies of manufacturing will become more apparent after considering the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals indicate corresponding parts in the various figures. However, it is to be expressly understood that the figures are for illustration and description purposes only and are not intended as definitions of limitations. Unless the context clearly dictates otherwise, when used in this specification and claims, the singular forms "a", "an", and "the" include plural referents. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] Additional advantages and details are explained in more detail below with reference to exemplary embodiments or aspects shown in the schematic drawings, in which:

[0050] Figure 1 are diagrams of non-limiting embodiments or aspects of environments in which the systems, apparatus, products, devices, and / or methods described herein may be implemented;

[0051] Figure 2 yes Figure 1 diagrams of non-limiting embodiments or aspects of one or more devices and / or components of one or more systems;

[0052] Figure 3 is a flow chart of a non-limiting embodiment or aspect of a process for dynamically ensuring integrity of a software development kit (SDK); and

[0053] Figure 4 is a signal flow diagram of an implementation of a non-limiting example or aspect of a process for dynamically ensuring SDK integrity. DETAILED DESCRIPTION

[0054] It should be understood that, except where expressly specified to the contrary, the present disclosure may employ various alternative variations and step sequences. It should also be understood that the specific devices and processes shown in the accompanying drawings and described in the following specification are merely exemplary and non-limiting embodiments or aspects. Therefore, specific dimensions and other physical characteristics associated with the embodiments or aspects disclosed herein should not be considered limiting.

[0055] Aspects, components, elements, structures, actions, steps, functions, instructions, etc. used herein should not be understood as critical or necessary unless explicitly described as such. Also, as used herein, the article "one" is intended to include one or more items, and can be used interchangeably with "one or more" and "at least one". In addition, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, a combination of related items and unrelated items, etc.), and can be used interchangeably with "one or more" or "at least one". In the case of wishing only one item, the term "one" or similar language is used. Also, as used herein, the term "having" etc. is intended to be an open term. In addition, unless otherwise explicitly stated, the phrase "based on" is intended to mean "based at least in part on".

[0056] As used herein, the term "communication" refers to receiving or conveying one or more signals, messages, commands or other types of data. For a unit (e.g., any device, system or component thereof) to be communicated with another unit, it means that the unit can directly or indirectly receive data from another unit and / or transmit data to another unit. This may refer to a direct or indirect connection that is wired and / or wireless in nature. In addition, although the transmitted data can be modified, processed, relayed and / or routed between the first unit and the second unit, the two units may also communicate with each other. For example, although the first unit passively receives data and does not actively transmit data to the second unit, the first unit may also communicate with the second unit. As another example, if the intermediate unit processes data from a unit and transmits the processed data to the second unit, the first unit may communicate with the second unit. It should be understood that there may be many other arrangements.

[0057] Obviously, the systems and / or methods described herein can be implemented in different forms of hardware, software, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods does not limit the implementation. Therefore, the operation and behavior of the systems and / or methods are described herein without reference to specific software codes, and it should be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

[0058] Some non-limiting embodiments or aspects are described herein in conjunction with threshold values. As used herein, satisfying a threshold value may refer to a value greater than a threshold value, more than a threshold value, above a threshold value, greater than or equal to a threshold value, less than a threshold value, less than a threshold value, below a threshold value, less than or equal to a threshold value, equal to a threshold value, etc.

[0059] As used herein, the term "transaction service provider" may refer to an entity that receives transaction authorization requests from merchants or other entities and, in some cases, provides payment assurance through an agreement between the transaction service provider and an issuer organization. The terms "transaction service provider" and "transaction service provider system" may also refer to one or more computer systems operated by or on behalf of the transaction service provider, such as a transaction processing system that executes one or more software applications. The transaction processing system may include a server computer having one or more processors and, in some non-limiting embodiments or aspects, may be operated by or on behalf of the transaction service provider.

[0060] As used herein, the term "account identifier" may include one or more primary account numbers (PANs), tokens, or other identifiers (e.g., globally unique identifiers (GUIDs), universally unique identifiers (UUIDs), etc.) associated with a customer account of a user (e.g., a client, a customer, etc.). The term "token" may refer to an identifier used as a replacement or substitute identifier for an original account identifier such as a PAN. An account identifier may be alphanumeric, or any combination of characters and / or symbols. A token may be associated with a PAN or other original account identifier in one or more databases so that a transaction may be conducted using the token without directly using the original account identifier. In some instances, an original account identifier such as a PAN may be associated with multiple tokens for different individuals or purposes.

[0061] As used herein, the terms "issuer institution", "portable financial device issuer", "issuer" or "issuer bank" may refer to one or more entities that provide one or more accounts to a user (e.g., a customer, consumer, organization, etc.) to conduct a transaction (e.g., a payment transaction), such as initiating a credit card payment transaction and / or a debit card payment transaction. For example, an issuer institution may provide an account identifier such as a personal account number (PAN) to a user, which uniquely identifies one or more accounts associated with the user. The account identifier may be implemented on a portable financial device such as a physical financial instrument (e.g., a payment card), and / or may be electronic and used for electronic payments. In some non-limiting embodiments or aspects, the issuer institution may be associated with a bank identification number (BIN) that uniquely identifies the issuer institution. As used herein, an "issuer institution system" may refer to one or more computer systems operated by or on behalf of an issuer institution, such as a server computer that executes one or more software applications. For example, an issuer institution system may include one or more authorization servers for authorizing payment transactions.

[0062] As used herein, the term "merchant" may refer to a person or entity that provides products and / or services, or the right to use products and / or services, to a customer based on a transaction, such as a payment transaction. The term "merchant" or "merchant system" may also refer to one or more computer systems operated by or on behalf of a merchant, such as a server computer that executes one or more software applications. As used herein, a "point of sale (POS) system" may refer to one or more computers and / or peripheral devices used by a merchant to conduct payment transactions with customers, including one or more card readers, near field communication (NFC) receivers, radio frequency identification (RFID) receivers and / or other contactless transceivers or receivers, contact-based receivers, payment terminals, computers, servers, input devices, and / or other similar devices that can be used to initiate payment transactions.

[0063] As used herein, the term "mobile device" may refer to one or more portable electronic devices configured to communicate with one or more networks. For example, a mobile device may include a cellular phone (e.g., a smart phone or a standard cellular phone), a portable computer (e.g., a tablet computer, a laptop computer, etc.), a wearable device (e.g., a watch, glasses, lenses, clothing, etc.), a personal digital assistant (PDA), and / or other similar devices. As used herein, the terms "client device" and "user device" refer to any electronic device configured to communicate with one or more servers or remote devices and / or systems. Client devices or user devices may include mobile devices, network-enabled devices (e.g., network-enabled TVs, refrigerators, thermostats, etc.), computers, POS systems, and / or any other devices or systems capable of communicating with a network.

[0064] As used herein, the term "computing device" or "computer device" may refer to one or more electronic devices configured to communicate directly or indirectly with one or more networks or to communicate on one or more networks. The computing device may be a mobile device, a desktop computer, etc. In addition, the term "computer" may refer to any computing device including necessary components for receiving, processing and outputting data and typically including a display, a processor, a memory, an input device, and a network interface. An "application" or "application programming interface" (API) refers to computer code or other data sorted on a computer-readable medium, which can be executed by a processor to facilitate interaction between software components, such as interaction of a client-side front end and / or a server-side back end for receiving data from a client. An "interface" refers to a generated display, such as one or more graphical user interfaces (GUIs) with which a user can interact directly or indirectly (e.g., via a keyboard, a mouse, a touch screen, etc.).

[0065] As used herein, the terms "electronic wallet" and "electronic wallet application" refer to one or more electronic devices and / or software applications configured to initiate and / or conduct payment transactions. For example, an electronic wallet may include a mobile device executing an electronic wallet application, and may also include server-side software and / or databases for maintaining and providing transaction data to the mobile device. An "electronic wallet provider" may include an entity that provides and / or maintains electronic wallets for customers, such as Google Wallet. TM 、Android Apple Samsung And / or other similar electronic payment systems. In some non-limiting examples, the issuing bank may be an electronic wallet provider.

[0066] As used herein, the term "portable financial device" or "payment device" may refer to, for example, a payment card (e.g., a credit or debit card), a gift card, a smart card, smart media, a payroll card, a health care card, a wristband, a machine-readable medium containing account information, a key chain device or pendant, an RFID transponder, a retailer discount or membership card, a mobile device executing an electronic wallet application, a personal digital assistant (PDA), a security card, an access card, a wireless terminal, and / or a transponder. A portable financial device may include volatile or non-volatile memory for storing information such as an account identifier and / or an account holder's name.

[0067] As used herein, the term "server" may refer to or include one or more processors or computers, storage devices, or similar computer arrangements operated by or facilitating communication and processing by multiple parties in a network environment such as the Internet, but it should be understood that communications may be facilitated through one or more public or private network environments, and a variety of other arrangements are possible. In addition, multiple computers, such as servers, or other computerized devices, such as POS devices, communicating directly or indirectly in a network environment may constitute a "system" such as a merchant's POS system.

[0068] As used herein, the term "acquirer" may refer to an entity that is licensed by a transaction service provider and / or approved by a transaction service provider to initiate a transaction using a portable financial device of a transaction service provider. An acquirer may also refer to one or more computer systems operated by or on behalf of an acquirer, such as a server computer (e.g., "acquirer server") that executes one or more software applications. An "acquirer" may be a merchant bank, or in some cases, a merchant system may be an acquirer. The transaction may include an original credit transaction (OCT) and an account funds transaction (AFT). The transaction service provider may authorize an acquirer to sign a merchant of the service provider to initiate a transaction using a portable financial device of a transaction service provider. The acquirer may sign a contract with a payment facilitator to enable the facilitator to sponsor a merchant. The acquirer may monitor the compliance of the payment service provider according to the transaction service provider regulations. The acquirer may conduct due diligence on the payment facilitator and ensure that appropriate due diligence is conducted before signing a sponsoring merchant. The acquirer may be responsible for all transaction service provider programs that they operate or sponsor. The acquirer may be responsible for the behavior of its payment service provider and the merchant sponsored by it or its payment service provider.

[0069] As used herein, the term "payment gateway" may refer to an entity and / or a payment processing system operated by or on behalf of such an entity that provides payment services (e.g., transaction service provider payment services, payment processing services, etc.) to one or more merchants (e.g., merchant service provider, payment service provider, payment facilitator, payment facilitator with a contract with an acquirer, payment aggregator, etc.). The payment service may be associated with the use of a portable financial device managed by a transaction service provider. As used herein, the term "payment gateway system" may refer to one or more computer systems, computer devices, servers, server groups, etc. operated by or on behalf of a payment gateway.

[0070] Improved systems, apparatus, products, devices and / or methods are provided for dynamically ensuring the integrity of a software development kit (SDK).

[0071] Non-limiting embodiments or aspects of the present disclosure relate to systems, methods, and computer program products for dynamically ensuring SDK integrity: loading a software development kit (SDK) wrapper from a payment gateway system through a merchant webpage associated with the merchant system on a merchant system; executing the SDK wrapper, which loads an SDK core when executed; determining the integrity of the SDK core; performing a handshake between the SDK wrapper and the SDK core in response to determining the integrity of the SDK core, and overloading real functions exported by the SDK wrapper; and providing a secure payment container request from the merchant system to the payment gateway system through the SDK core.

[0072] In this way, non-limiting embodiments or aspects of the present disclosure may provide an SDK wrapper that dynamically ensures a new or updated integrity check hash each time the SDK core is updated or changed, and ensures that the merchant system is able to use the required SDK wrapper from the payment gateway system, which eliminates the need for merchants to update merchant web pages and / or integrity check hashes each time the SDK core is updated or changed, and improves the merchant system's implementation of required security measures.

[0073] Reference now Figure 1 , Figure 1 1 is a diagram of an example environment 100 in which the apparatus, systems, methods, and / or products described herein may be implemented. Figure 1 As shown, environment 100 includes a transaction processing network 101, which may include a merchant system 102, a payment gateway system 104, an acquirer system 106, a transaction service provider system 108 and / or an issuer system 110, a user device 112 and / or a communication network 114. Transaction processing network 101, merchant system 102, payment gateway system 104, acquirer system 106, transaction service provider system 108, issuer system 110 and / or user device 112 may be interconnected (e.g., establish connections for communication, etc.) via wired connections, wireless connections, or a combination of wired and wireless connections.

[0074] The merchant system 102 may include one or more devices that are capable of receiving information and / or data from the payment gateway system 104, the acquirer system 106, the transaction service provider system 108, the issuer system 110, and / or the user device 112 (e.g., via a communication network 114, etc.) and / or transmitting information and / or data to the payment gateway system 104, the acquirer system 106, the transaction service provider system 108, the issuer system 110, and / or the user device 112 (e.g., via a communication network 114, etc.). The merchant system 102 may include a communication connection (e.g., an NFC communication connection, an RFID communication connection, a The merchant system 102 may include a device that receives information and / or data from the user device 112 (e.g., a communication connection, etc.) and / or transmits information and / or data to the user device 112 through the communication connection. For example, the merchant system 102 may include a computing device, such as a server, a server group, a client device, a client device group, and / or other similar devices. In some non-limiting embodiments or aspects, the merchant system 102 may be associated with a merchant described herein. In some non-limiting embodiments or aspects, the merchant system 102 may include one or more devices that can be used by merchants to conduct payment transactions with users, such as computers, computer systems, and / or peripheral devices. For example, the merchant system 102 may include a POS device and / or a POS system.

[0075] The payment gateway system 104 may include one or more devices capable of receiving information and / or data from the merchant system 102, the acquirer system 106, the transaction service provider system 108, the issuer system 110, and / or the user device 112 (e.g., via a communication network 114, etc.), and / or transmitting information and / or data to the merchant system 102, the acquirer system 106, the transaction service provider system 108, the issuer system 110, and / or the user device 112 (e.g., via a communication network 114, etc.). For example, the payment gateway system 104 may include a computing device, such as a server, a server group, and / or other similar devices. In some non-limiting embodiments or aspects, the payment gateway system 104 is associated with the payment gateway described herein.

[0076] The acquirer system 106 may include one or more devices capable of receiving information and / or data from the merchant system 102, the payment gateway system 104, the transaction service provider system 108, the issuer system 110, and / or the user device 112 (e.g., via a communication network 114, etc.), and / or transmitting information and / or data to the merchant system 102, the payment gateway system 104, the transaction service provider system 108, the issuer system 110, and / or the user device 112 (e.g., via a communication network 114, etc.). For example, the acquirer system 106 may include a computing device, such as a server, a server group, and / or other similar devices. In some non-limiting embodiments or aspects, the acquirer system 106 may be associated with an acquirer as described herein.

[0077] The transaction service provider system 108 may include one or more devices that are capable of receiving information and / or data from the merchant system 102, the payment gateway system 104, the acquirer system 106, the issuer system 110, and / or the user device 112 (e.g., via a communication network 114, etc.), and / or transmitting information and / or data to the merchant system 102, the payment gateway system 104, the acquirer system 106, the issuer system 110, and / or the user device 112 (e.g., via a communication network 114, etc.). For example, the transaction service provider system 108 may include a computing device, such as a server (e.g., a transaction processing server, etc.), a server group, and / or other similar devices. In some non-limiting embodiments or aspects, the transaction service provider system 108 may be associated with a transaction service provider described herein. In some non-limiting embodiments or aspects, the transaction service provider 108 may include and / or access one or more internal and / or external databases that include account data, transaction data, merchant data, demographic data, etc.

[0078] The issuer system 110 may include one or more devices that are capable of receiving information and / or data from the merchant system 102, the payment gateway system 104, the acquirer system 106, the transaction service provider system 108, and / or the user device 112 (e.g., via a communication network 114, etc.), and / or transmitting information and / or data to the merchant system 102, the payment gateway system 104, the acquirer system 106, the transaction service provider system 108, and / or the user device 112 (e.g., via a communication network 114, etc.). For example, the issuer system 110 may include a computing device, such as a server, a server group, and / or other similar devices. In some non-limiting embodiments or aspects, the issuer system 110 may be associated with an issuer organization described herein. For example, the issuer system 110 may be associated with an issuer organization that issues payment accounts or instruments (e.g., credit accounts, debit accounts, credit cards, debit cards, etc.) to users (e.g., users associated with the user device 112, etc.).

[0079] In some non-limiting embodiments or aspects, the transaction processing network 101 includes multiple systems in a communication path for processing transactions. For example, the transaction processing network 101 may include a merchant system 102, a payment gateway system 104, an acquirer system 106, a transaction service provider system 108, and / or an issuer system 110 in a communication path (e.g., a communication path, a communication channel, a communication network, etc.) for processing electronic payment transactions. For example, the transaction processing network 101 can process (e.g., receive, initiate, conduct, authorize, etc.) electronic payment transactions through the communication path between the merchant system 102, the payment gateway system 104, the acquirer system 106, the transaction service provider system 108, and / or the issuer system 110.

[0080] The user device 112 may include one or more devices that are capable of receiving information and / or data from the merchant system 102, the payment gateway system 104, the acquirer system 106, the transaction service provider system 108, and / or the issuer system 110 (e.g., via the communication network 114, etc.), and / or transmitting information and / or data to the merchant system 102, the payment gateway system 104, the acquirer system 106, the transaction service provider system 108, and / or the issuer system 110 (e.g., via the communication network 114, etc.). For example, the user device 112 may include a client device, etc. In some non-limiting embodiments or aspects, the user device 112 is capable of communicating with the merchant system 102, the payment gateway system 104, the acquirer system 106, the transaction service provider system 108, and / or the issuer system 110 via a short-range wireless communication connection (e.g., an NFC communication connection, an RFID communication connection, The user device 112 may receive information via a short-range wireless communication connection (e.g., from the merchant system 102, etc.), and / or transmit information via a short-range wireless communication connection (e.g., to the merchant system 102). In some non-limiting embodiments or aspects, the user device 112 may include an application associated with the user device 112, such as an application stored on the user device 112, a mobile application stored and / or executed on the user device 112 (e.g., a mobile device application, a native application of the mobile device, a mobile cloud application of the mobile device, an electronic wallet application, etc.).

[0081] The communication network 114 may include one or more wired and / or wireless networks. For example, the communication network 114 may include a cellular network (e.g., a long term evolution (LTE) network, a third generation (3G) network, a fourth generation (4G) network, a fifth generation (5F) network, a code division multiple access (CDMA) network, etc.), a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., a public switched telephone network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, a fiber-based network, a cloud computing network, etc., and / or a combination of these or other types of networks.

[0082] supply Figure 1 The number and arrangement of devices and systems shown are examples. Additional devices and / or systems, fewer devices and / or systems, different devices and / or systems, and / or devices and / or systems may be present. Figure 1 The devices and / or systems shown in the drawings may be arranged in different ways. In addition, the invention may be implemented in a single device and / or system. Figure 1 Two or more devices and / or systems shown, or Figure 1The single device and / or system shown may be implemented as multiple distributed devices and / or systems. Additionally or alternatively, a set of devices and / or systems (e.g., one or more devices or systems) of environment 100 may perform one or more functions described as being performed by another set of devices and / or systems of environment 100.

[0083] Reference now Figure 2 , Figure 2 is a diagram of example components of device 200. Device 200 may correspond to one or more devices of transaction processing network 101, one or more devices of merchant system 102, one or more devices of payment gateway system 104, one or more devices of acquirer system 106, one or more devices of transaction service provider system 108, one or more devices of issuer system 110, and / or user device 112 (e.g., one or more devices of user device 112's system, etc.). In some non-limiting embodiments or aspects, one or more devices of transaction processing network 101, one or more devices of merchant system 102, one or more devices of payment gateway system 104, one or more devices of acquirer system 106, one or more devices of transaction service provider system 108, one or more devices of issuer system 110, user device 112 (e.g., one or more devices of user device 112's system, etc.), and / or one or more devices of communication network 114 may include at least one device 200 and / or at least one component of device 200. Figure 2 As shown, apparatus 200 may include a bus 202 , a processor 204 , a memory 206 , a storage component 208 , an input component 210 , an output component 212 , and a communication interface 214 .

[0084] The bus 202 may include components that permit communication between components of the device 200. In some non-limiting embodiments or aspects, the processor 204 may be implemented in hardware, hardware, or a combination of hardware and software. For example, the processor 204 may include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), etc.), a microprocessor, a digital signal processor (DSP), and / or any processing component that can be programmed to perform a function (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.). The memory 206 may include a random access memory (RAM), a read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, optical memory, etc.) that stores information and / or instructions for use by the processor 204.

[0085] The storage component 208 may store information and / or software related to the operation and use of the device 200. For example, the storage component 208 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, a solid-state disk, etc.), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cassette, a magnetic tape, and / or another type of computer-readable medium, and a corresponding drive.

[0086] Input components 210 may include components that permit device 200 to receive information, such as through user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, buttons, switches, a microphone, etc.). Additionally or alternatively, input components 210 may include sensors for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.). Output components 212 may include components that provide output information from device 200 (e.g., a display, a speaker, one or more light emitting diodes (LEDs), etc.).

[0087] The communication interface 214 may include a transceiver-type component (e.g., a transceiver, a separate receiver and transmitter, etc.) that enables the device 200 to communicate with other devices, such as through a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface 214 may permit the device 200 to receive information from another device and / or provide information to another device. For example, the communication interface 214 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, Interface, cellular network interface, etc.

[0088] The device 200 may perform one or more processes described herein. The device 200 may perform these processes based on the processor 204 executing software instructions stored by a computer-readable medium such as the memory 206 and / or the storage component 208. A computer-readable medium (e.g., a non-transitory computer-readable medium) is defined herein as a non-transitory memory device. A non-transitory memory device includes a memory space located within a single physical memory device or a memory space spread across multiple physical memory devices.

[0089] The software instructions may be read into the memory 206 and / or storage component 208 from another computer-readable medium or from another device via the communication interface 214. When executed, the software instructions stored in the memory 206 and / or storage component 208 may cause the processor 204 to perform one or more processes described herein. Additionally or alternatively, hard-wired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, the embodiments or aspects described herein are not limited to any specific combination of hardware circuitry and software.

[0090] The memory 206 and / or the storage component 208 may include a data storage device or one or more data structures (e.g., a database, etc.). The device 200 is capable of receiving information from, storing information in, transmitting information to, or searching for information stored in the data storage device or one or more data structures in the memory 206 and / or the storage component 208. For example, the transaction service provider system 108 may include and / or access one or more internal and / or external databases that store transaction data, account data, input data, output data, update data, classification data, etc. associated with transactions that have been processed and / or are being processed in the transaction processing network 101 (e.g., previous or historical transactions processed by the transaction service provider system 108).

[0091] supply Figure 2 The number and arrangement of components shown are provided as examples. In some non-limiting embodiments or aspects, the device 200 may include additional components, fewer components, different components, or components in a manner similar to that of the device 200. Figure 2 Additionally or alternatively, one set of components (eg, one or more components) of the device 200 may perform one or more functions described as being performed by another set of components of the device 200.

[0092] Reference now Figure 3 , Figure 3 300 for dynamically ensuring SDK integrity. In some non-limiting embodiments or aspects, one or more of the steps of the process 300 may be performed (e.g., in full, in part, etc.) by the merchant system 102 (e.g., one or more devices of the merchant system 102, etc.). In some non-limiting embodiments or aspects, one or more of the steps of the process 300 may be performed (e.g., in full, in part, etc.) by another device or group of devices that is independent of or includes the merchant system 102, such as the payment gateway system 104 (e.g., one or more devices of the payment gateway system 104), the acquirer system 106 (e.g., one or more devices of the acquirer system 106), the transaction service provider system 108 (e.g., one or more devices of the transaction service provider system 108), the issuer system 110 (e.g., one or more devices of the issuer system 110), and / or the user device 112 (e.g., one or more devices of the system of the user device 112).

[0093] like Figure 3As shown, at step 302, process 300 includes receiving account data. For example, merchant system 102 can receive account data. For example, merchant system 102 can receive account data (e.g., PAN, transaction data, etc.) associated with a user's account via a merchant webpage associated with merchant system 102. In this example, the merchant webpage can include an HTML form tag that uses the Accept.js library to create a submit button on the merchant webpage. For example, the operation parameters of the form can be set to point to a response handler script, and the submit button can be configured to interact with the AcceptUI portion of the Accept.js library. For example, and also with reference to Figure 4 , which is a signal flow diagram of an implementation scheme 400 of a non-limiting example or aspect of a process for dynamically ensuring SDK integrity. In step S402, the user can click a submit button in the user's client browser on the user device 112 to open a payment information form, fill in the user's payment information (e.g., account data) in the form, and submit the form to the merchant system 102 using the submit button, and the merchant system 102 may send the payment information to the payment gateway system 104 (e.g., Authorize.net, etc.), as described in more detail herein.

[0094] like Figure 3 As shown, at step 304, process 300 includes loading the SDK wrapper. For example, merchant system 102 can load the SDK wrapper. For example, merchant system 102 can load the SDK wrapper (e.g., Accept.js library, etc.) from payment gateway system 104 via a merchant webpage associated with merchant system 102. In this example, and again referring to Figure 4 , in step S404, the SDK wrapper may be loaded from the payment gateway system 104 in response to receiving the account data through the merchant webpage.

[0095] In some non-limiting embodiments or aspects, in response to loading the Accept.js library, the Accept.js library exports real functions (e.g., tokenization functions, secure payment container request functions, etc.) as public methods, and the public methods throw errors if called by the merchant system 102. Thus, the merchant system 102 may be forced to implement the AcceptCore.js library, which is automatically loaded by the Accept.js library, as described in more detail herein.

[0096] like Figure 3As shown, at step 306, process 300 includes executing the SDK wrapper to load the SDK core. For example, merchant system 102 can execute the SDK wrapper to load the SDK core. For example, merchant system 102 can execute the SDK wrapper, wherein the SDK wrapper loads the SDK core (e.g., AcceptCore.js library, etc.). In this example, and again referring to Figure 4 In step S406, the AcceptCore.js library may be automatically loaded from the payment gateway system 104 (eg, loaded from a content delivery network (CDN) of Authorize.net, etc.) in response to the merchant system 102 loading and / or executing the Accept.js library.

[0097] like Figure 3 As shown, at step 308, process 300 includes determining the integrity of the SDK core. For example, merchant system 102 can determine the integrity of the SDK core. For example, merchant system 102 can determine the integrity of the SDK core. In this example, and again referring to Figure 4 In step S408, the Accept.js library automatically verifies whether the integrity of the AcceptCore.js library matches the sub-resource integrity in response to loading the AcceptCore.js library from the payment gateway system 104. In some non-limiting embodiments or aspects, determining the integrity of the SDK core includes performing a W3C sub-resource integrity check hash on the SDK core. For example, the Accept.js library may perform a W3C sub-resource integrity check hash on the AcceptCore.js library.

[0098] like Figure 3 As shown, at step 310, process 300 includes performing a handshake between the SDK wrapper and the SDK core. For example, the merchant system 102 can perform a handshake between the SDK wrapper and the SDK core. For example, in response to determining the integrity of the SDK core, the merchant system 102 can perform a handshake between the SDK wrapper and the SDK core, and overload the real functions exported by the SDK wrapper with the real functions of the SDK core (e.g., overloading the tokenization function, the secure payment container request, etc.) with the tokenization function of the SDK core, the secure payment container request function of the SDK core, etc. In this example, and again referring to Figure 4, in step S410 , in response to the sub-resource integrity check hash matching the hash on the AcceptCore.js library, the AcceptCore.js library can automatically overload the real function exported by the Accept.js library, and in step S410 , automatically perform a handshake (e.g., a 3-way handshake including synchronization, confirmation, and initialization, etc.) between the Accept.js library and the AcceptCore.js library, which ensures that the two libraries are always together (e.g., the merchant system 102 cannot implement only the Accept.js library without performing integrity checks, nor can the AcceptCore.js library be directly added to the merchant webpage itself, etc.)

[0099] like Figure 3 As shown, at step 312, process 300 includes providing a secure payment container request. For example, the merchant system 102 may provide a secure payment container request. For example, the merchant system 102 may provide the secure payment container request to the payment gateway system 104 through the SDK core. In this example, the secure payment container request may include account data. In this example, the secure payment container request may be automatically provided in response to a successful handshake between the SDK wrapper and the SDK core. For example, the SDK wrapper may throw an error in response to an unsuccessful handshake between the SDK wrapper and the SDK core, which may prevent the merchant system 102 from providing the secure payment container request to the payment gateway system 104 through the SDK core. For example, and again referring to Figure 4 In step S412, the AcceptCore.js library may automatically provide a secure payment container request to the payment gateway system 104 (e.g., to the API CDN of Authorize.net, etc.) (e.g., using the tokenization function or API of the SDK core, using the secure payment container request function or API of the SDK core, etc.) in response to a successful handshake between the AcceptCore.js library and the AcceptCore.js library. In this example, the secure payment container request may include account data associated with the user of the user device 112.

[0100] like Figure 3 As shown, at step 314, process 300 includes receiving a token. For example, merchant system 102 may receive the token. For example, merchant system 102 may receive a token associated with account data from payment gateway system 104 in response to providing a secure payment container request. In this example, and again referring to Figure 4 In step S414 , the AcceptCore.js library may receive, in response to providing the secure payment container request, from the payment gateway system 104 a token associated with the account data included in the secure payment container request.

[0101] Although embodiments or aspects have been described in detail for purposes of illustration and description, it will be understood that such details are used for that purpose only and that the embodiments or aspects are not limited to the disclosed embodiments or aspects, but, on the contrary, are intended to cover modifications and equivalent arrangements within the spirit and scope of the appended claims. For example, it will be understood that the present disclosure contemplates that, to the extent possible, one or more features of any embodiment or aspect may be combined with one or more features of any other embodiment or aspect. In fact, any of these features may be combined in a manner not specifically recited in the claims and / or disclosed in the specification. Although each dependent claim listed below may be directly dependent on only one claim, the disclosure of possible implementation schemes includes each dependent claim in combination with each other claim in the claim set.

Claims

1. A method for dynamically ensuring integrity of a software development kit, comprising: loading, with at least one processor, a software development kit (SDK) wrapper from a payment gateway system via a merchant webpage associated with the merchant system on a merchant system; executing the SDK wrapper with at least one processor, wherein the SDK wrapper loads the SDK core when executed; Determining, with at least one processor, the integrity of the SDK core; performing, with at least one processor, a handshake between the SDK wrapper and the SDK core and overloading a real function exported by the SDK wrapper in response to determining the integrity of the SDK core; and providing, with at least one processor, a secure payment container request from the merchant system to a payment gateway system via the SDK core, wherein the method further comprises: receiving, with at least one processor, account data associated with an account of a user at the merchant system via the merchant webpage, wherein the SDK wrapper is loaded in response to receiving the account data via the merchant webpage, and wherein the secure payment container request includes the account data; and receiving, with at least one processor, from the payment gateway system a token associated with the account data in response to providing the secure payment container request, Wherein determining the integrity of the SDK core comprises performing a W3C subresource integrity check hash on the SDK core, wherein executing the SDK wrapper exposes the real function as a public method, and wherein the real function throws an error in response to being called by the merchant system, and Wherein the SDK wrapper comprises an Accept.js library, and wherein the SDK core comprises an AcceptCore.js library. 2 . The method of claim 1 , wherein the secure payment container request is provided in response to a successful handshake between the SDK wrapper and the SDK core.

3. A computing system for dynamically ensuring the integrity of a software development kit, comprising: One or more processors programmed and / or configured to: loading a software development kit (SDK) wrapper from a payment gateway system on a merchant system via a merchant webpage associated with the merchant system; executing the SDK wrapper, wherein the SDK wrapper loads the SDK core when executed; Determining the integrity of the SDK core; performing a handshake between the SDK wrapper and the SDK core in response to determining the integrity of the SDK core, and overloading a real function exported by the SDK wrapper; and Providing a secure payment container request from the merchant system to the payment gateway system through the SDK core; wherein the one or more processors are further programmed and / or configured to: receiving, at the merchant system via the merchant webpage, account data associated with an account of a user, wherein the SDK wrapper is loaded in response to receiving the account data via the merchant webpage, and wherein the secure payment container request includes the account data; and receiving, from the payment gateway system, a token associated with the account data in response to providing the secure payment container request, Wherein determining the integrity of the SDK core comprises performing a W3C subresource integrity check hash on the SDK core; wherein executing the SDK wrapper exposes the real function as a public method, and wherein the real function throws an error in response to being called by the merchant system, and Wherein the SDK wrapper comprises an Accept.js library, and wherein the SDK core comprises an AcceptCore.js library. 4 . The system of claim 3 , wherein the secure payment container request is provided in response to a successful handshake between the SDK wrapper and the SDK core.

5. A computer program product for dynamically ensuring integrity of a software development kit comprising at least one non-transitory computer readable medium, the at least one non-transitory computer readable medium comprising program instructions that, when executed by at least one processor, cause the at least one processor to: loading a software development kit (SDK) wrapper from a payment gateway system on a merchant system via a merchant webpage associated with the merchant system; executing the SDK wrapper, wherein the SDK wrapper loads the SDK core when executed; Determining the integrity of the SDK core; performing a handshake between the SDK wrapper and the SDK core in response to determining the integrity of the SDK core, and overloading a real function exported by the SDK wrapper; and Providing a secure payment container request from the merchant system to the payment gateway system through the SDK core; The instructions further cause the at least one processor to: receiving, at the merchant system via the merchant webpage, account data associated with an account of a user, wherein the SDK wrapper is loaded in response to receiving the account data via the merchant webpage, and wherein the secure payment container request includes the account data; and Receiving a token associated with the account data from the payment gateway system in response to providing the secure payment container request Wherein determining the integrity of the SDK core comprises performing a W3C subresource integrity check hash on the SDK core, wherein executing the SDK wrapper exposes the real function as a public method, and wherein the real function throws an error in response to being called by the merchant system, And wherein the SDK wrapper includes an Accept.js library, and wherein the SDK core includes an AcceptCore.js library.

6. The computer program product of claim 5, wherein the secure payment container request is provided in response to a successful handshake between the SDK wrapper and the SDK core.

Images