Establishing digital account usage in digital wallet during cross-platform data processing

Abstract

Systems and methods are provided for establishing digital account usage in a digital wallet during cross-platform data processing. A user may transact with another user using a digital wallet, such as through a software application, such as purchasing goods, services, or other items from a merchant. The online transaction processor may provide a digital account for payment processing, which may provide financing and installment loan payment services. Where the payment account may be incompatible with the protocols and processes used by the digital wallet, a particular identifier may be pre-provisioned, and proxy data may be generated through exchanged calls and data between the system of the transaction processor and the system of the digital wallet. The identifier may mimic data used by the digital wallet and may also allow tokenization and processing by a token service provider on the payment network.

Description

Technical Field

[0001] This application generally relates to the use of digital wallets across platforms using a separate account, and more specifically to the creation and use of digital accounts in digital wallets provided by a separate online platform. Background Technology

[0002] Users can utilize online transaction processors to process payments between different entities via device applications and digital accounts. Furthermore, these online transaction processors can offer payment options, loans, and / or deferrals for face-to-face transaction processing and use at merchant locations. When offering deferred payment options and installment loan offers or plans, users may receive credit and / or purchase limits, and / or may be able to utilize credit balances, real funds, or virtual funds linked to their digital accounts. Such balances can be used through the digital accounts provided to users by the online transaction processor. Other merchants can utilize face-to-face payment terminals, such as point-of-sale (POS) devices, which may include components and modules for local wireless data exchange and transaction processing. However, digital wallets and mobile software applications may have specific requirements, configurations, and / or specifications for data transmission and interaction with mobile devices to utilize these terminals, which may be incompatible with certain data processing schemes. This may be the case when specific transactions and other data processing requests require real-time analysis when the merchant's device requests processing. Furthermore, due to threats such as cyberattacks, phishing scams, and malware that could compromise user accounts, users and online trading processors may wish to enhance preemptive and / or real-time restrictions on account usage through a separate platform. This may require specific integration of data processing operations, API calls and responses, and data formats for proper data manipulation and processing. Therefore, online trading processors are expected to provide cross-platform account integration and usage operations with external digital wallet providers. Attached Figure Description

[0003] Figure 1 This is a block diagram of a networking system suitable for implementing the processes described herein, according to an embodiment; Figure 2A-2B This is an example illustration of an embodiment for establishing a digital account through a digital wallet provided by a separate platform and using that digital account to perform short-range wireless data processing with merchant devices; Figures 3A-3B This is an exemplary illustration of data processing calls and operations between an online transaction processor system and a digital wallet provider system when creating and logging into a digital account using a digital wallet, according to an embodiment. Figure 4 This is a set of exemplary user interfaces for a mobile device application according to an embodiment when registering a digital account with an online transaction processor for use with a digital wallet via a separate digital wallet platform; Figure 5A This is a flowchart of an exemplary process for establishing a digital account in a digital wallet during cross-platform data processing, according to an embodiment of the present invention. Figure 5B This is a flowchart of an exemplary process according to an embodiment for using a digital account in a separate digital wallet across platforms during short-range data processing; and Figure 6 It is adapted to implement according to the embodiments. Figure 1 A block diagram of a computer system containing one or more components.

[0004] The embodiments and advantages of this disclosure can be best understood by referring to the following detailed description. It should be understood that the same reference numerals are used to identify the same elements shown in one or more figures, which are for illustrative purposes of embodiments of this disclosure and not for limiting the scope of the disclosure. Detailed Implementation

[0005] Methods are provided for establishing digital account usage in a digital wallet during cross-platform data processing and for using digital accounts across platforms in a separate digital wallet during data processing. Systems suitable for implementing the methods disclosed herein are also provided.

[0006] Users can use digital accounts, payment cards, and / or other sources of funds to process payments through electronic payment and / or transaction networks associated with back-end payment processors or other entities on the network. Identifiers may be linked to a user's digital account with an online transaction processor, such as a payment service provider (e.g., PayPal® and / or Paidy®), which provides electronic transaction processing services to the user through the account and one or more websites and / or applications of the online transaction processor or merchant. The digital account may be established using a credit line and / or may have a balance or value available for use in the digital account. The online transaction processor may include integration with an electronic payment network (e.g., for payment cards, tokens, etc.) that allows data exchange and communication between the two networks. Furthermore, the payment network may provide data communication and back-end processing equipment that enables interaction with front-end merchants, POS terminals, and / or payment terminal processing equipment that uses data transmission to process transactions, such as via digital payments, online payments, and / or contactless payments, including Near Field Communication (NFC), Radio Frequency Identification (RFID) field and communication, Bluetooth or WiFi communication, infrared scanners and / or communication, EMV chip readers, magnetic stripe and / or emulation readers, and other face-to-face and / or local data transmissions.

[0007] However, utilizing such payment mechanisms and networks may require specific data transmission and / or digital wallet protocols, systems, and communications. Traditionally, Buy Now Pay Later (BNPL) and / or installment loan balances and accounts may require real-time and / or on-the-spot approval and / or decision-making (e.g., risk and / or fraud analysis) during transaction processing. This may be incompatible with standard digital wallet protocols, which may not generate and pre-configure appropriate digital tokens, identifiers, and other data for transaction processing with merchant devices via short-range wireless communication. Therefore, online transaction processors can provide the ability to register and log in to digital wallet providers and digital wallets offering short-range wireless transaction processing services to offer BNPL, installment loan, and / or other payment services (e.g., for established balances, budgets, and / or loans, which may have recurring or refreshed payments due at each time period or time interval, and / or may offer deferred or financed payments). This can be achieved by generating and / or pre-configuring specific identifiers, such as bank identification numbers (BINs), that conform to the corresponding identifier usage standards of payment networks, token service providers (TSPs), and / or wireless payment terminals and devices (e.g., International Organization for Standardization (ISO) and / or International Electrotechnical Commission (IEC) standards, including ISO / IEC 7812). Such identifiers can be pre-configured for contactless payment providers (such as QUICPay™ and / or iD™), which provide components and operations for contactless payments via short-range wireless communication. These identifiers can then be registered and stored for an account in a digital wallet and used during wireless and / or contactless payment processing. These identifiers for contactless payments can be provided via cardless pre-configuration, where no physical payment card or other item is required to pre-configure the identifiers. Instead, cardless pre-configuration of identifiers can be built upon the BIN and / or other data required for payment processing on a wireless payment terminal, without the need for registration and / or use of a payment card through a mobile application and digital wallet.

[0008] In this regard, users may wish to purchase items via a software application and / or digital account on a mobile device, which provides value, credit, or other funds to the user through an online transaction processor and / or electronic payment network. Selecting one or more items in a face-to-face transaction at a physical merchant location may require the user to provide payment tools for electronic transaction processing, which can be provided via tokens, identifiers, data packets, etc., sent to the merchant's device at the location via short-range wireless communication (e.g., contactless payments via NFC, RFID, etc.). Users can pay for one or more transactions using a digital wallet set up and configured to utilize contactless payment terminals and devices through a payment network, where the digital wallet includes an account with an online service provider or other transaction processor. Account creation details can be provided, such as login, password (or other authentication credentials such as biometric fingerprints, retinal scans, etc.), and other account creation details. Account creation details may include identifying information used to create the account, such as the user's personal information, the entity's business or merchant information, or other types of identifying information including name, address, and / or other information.

[0009] When processing transactions with merchants and / or other users or entities, users may also be required to provide financial information, including digital account information (such as credit / debit card information), bank account information, gift card information, benefits / rewards, and / or financial investment information. Account creation can also be used to establish account funds and / or value, such as by transferring funds to the account and / or establishing available credit lines and corresponding credit values ​​for the account and / or card. Service providers may provide computing services to send, store, and receive funds, process financial instruments, and / or provide transaction history, including generating identifiers (e.g., for Funds Payment / Master Account (FPAN) and / or Device Payment / Master Account (DPAN) fields and processing BINs, etc.). Service providers may also provide tokenization of data used for transaction processing. Service provider applications or websites (such as PayPal® or other online payment providers) may provide payment and other transaction processing services. Furthermore, digital accounts can be utilized through one or more mobile applications or other software applications on mobile devices.

[0010] To make payments for a transaction (e.g., transferring or paying funds to another user, merchant, or other entity), a user can provide a digital account or source of funds information, and / or log in to an account with a service provider via authentication information in a software application. When face-to-face payments are provided through contactless payment terminals and mobile devices, an external wallet or a service provider's digital wallet can be used along with the account to wirelessly provide data to the terminal or device. In this regard, identifiers and / or digital tokens or other data can authorize and / or authenticate the user's use of the digital wallet and / or payment tools within the digital wallet (e.g., an account with an online transaction processor), and this data can be wirelessly transmitted to another for payment processing. This data can be stored and / or transmitted using one or more storage media and / or wireless transceivers (such as NFC / RFID components, smart keys, passive or active antennas, magnetic stripes or EMV chips, displayable codes or data, etc.). For example, POS devices and / or card readers can be used to read pre-configured data of an identifier using merchant equipment at the merchant's location, which can mimic or emulate card data from a wireless card. This allows users to make payments via short-range wireless communication and contactless processing through payment accounts and / or digital wallets. Then, payment can be sent to the other party in the transaction.

[0011] To log a user's digital account into a digital wallet and wallet provider platform for use with BNPL or other payment processing mechanisms (which, traditionally, are not established or associated with certain identifiers and protocols used for contactless payments), an online transaction processor can provide the ability to first receive and process requests to log in and / or create an account to a separate digital wallet (e.g., Apple® Wallet for Apple Pay®). Login and / or creation requests can be received, for example, through the software application (e.g., a mobile or other dedicated application) or website of the online transaction processor that provides the digital account, or via the digital wallet platform and the digital wallet's application / website. Once received (e.g., at the front end, such as the transaction processor's application / website for the account), the account's master account identifier can be requested and received from the transaction processor's host system or back-end system or server. The digital wallet and digital wallet provider can also perform eligibility checks on the account, which may include: querying and / or determining whether the digital account's application can perform payment account addition and / or security element addition via the digital wallet.

[0012] If an account is eligible to be added to and used via a digital wallet (e.g., for contactless payments), the account's front-end application or website can then provide the user with options and / or an interface for adding the account to the wallet and / or facilitate the process of adding the account to the wallet. The application can then request the wallet provider to add the account to the digital wallet. The wallet provider can retrieve certificates from its back-end servers or systems, which may include public certificates providing trust mechanisms, digital signatures, and secure connection establishment. These public certificates can be returned to the digital wallet platform and / or front-end application or wallet during the account registration and setup process for the digital wallet, whereby the digital wallet platform and / or front-end application or wallet provides the certificate back to the account's application, website, or other front-end. A random number (e.g., a non-repeating random value) can be returned from the back-end server or system along with the public certificate, and a random number signature using the random number can be provided to the account's front-end along with the certificate.

[0013] Online transaction processors can receive these certificates, random numbers, and / or random number signatures via a front-end application or website. They can then encrypt this data using the account's master account and provide it to the transaction processor's back-end (e.g., a server, processor, device, or other system). This can be provided via an application programming interface (API) call or request, and the back-end can correspond to a host, etc. The host can then provide an API response with an encrypted master account (PAN), which may correspond to a BIN or other identifier. The identifier provided in the encrypted PAN may correspond to an identifier specifically generated and / or pre-configured for the account by a contactless provider that provides contactless payment processing on a payment network used by merchant devices and digital wallets for contactless payment processing. Furthermore, the host can provide the transaction processor with an encrypted one-time password (OTP) and / or a temporary public key. Once received by the transaction processor's front-end for the account, the front-end can then interact with the digital wallet to set and establish identifiers (e.g., as an encrypted PAN), an encrypted OTP, and / or a temporary public key for use during contactless payment processing. Specifically, during account registration with a digital wallet, an identifier can be used and / or entered in the FPAN or DPAN fields via tokenization and TSP to enable payment processing. This identifier can be a BIN, which allows payment processing to be resolved on the payment network via a transaction processor. For example, the identifier can identify the account and the transaction processor on the network used for payment processing, and can be compatible with and used by tokenization operations and TSPs for contactless payments.

[0014] Subsequently, the digital wallet can complete registration with the account holder or user, transaction processor, digital wallet, and / or other servers, systems, and / or backends of the payment network. For example, data established using the digital wallet can be transmitted to the digital wallet's server, and verification can be performed on the data. A TSP compatible with a BIN or other identifier can be identified, and a network check card with an encrypted PAN or other identifier and a temporary public key can be provided to the TSP (e.g., FeliCa® TSP). The TSP can send an API request for card eligibility to the transaction processor's host, which can provide an API response for the product identifier and the issuing bank's card identifier. The TSP can then provide the digital wallet with terms and conditions, which can be requested by the user via the transaction processor's application or website. Once agreed, the digital wallet can provide activation data to the TSP, which can then request and receive the card digit from the transaction processor's host. The TSP can issue a token of the identifier as a DPAN to the digital wallet, which can be de-tokenized to identify the identifier and allow transaction processing during contactless payments. Then, the digital wallet can be successfully activated and an account created in response to the user via the front end of the transaction processor.

[0015] Once a digital account is opened and registered in a digital wallet for contactless payments, the user can access, offer, and / or receive available balances that the user can utilize. This can correspond to real or virtual assets or value and can be a revolving credit line offered to the user. Users may receive fixed balances and / or installment loans or other loan extensions, as well as authorizations and restrictions on individual transaction processing (e.g., for BNPL-type accounts and / or payment authorizations or balances). In this regard, a user's budget or BNPL extension may, for example, include a $2,000 credit repayment or balance payment over a revolving credit billing cycle or period (e.g., repayment of a deferred credit balance), or, in a BNPL-type payment authorization and plan, a user's budget or BNPL extension may be approved on a per-transaction basis. A user's BNPL-type plan may allow the user to finance or obtain loans for part or all of their transaction balance. In this regard, the determination of loans, loan extensions, and terms (including interest rates, fees, repayment plans and / or schedules, number of payments, installment loan payment amounts, etc.) can be determined in real time during and / or at times related to the transaction. Therefore, each individual transaction may require approval on a per-transaction basis or on a batch of transactions that have been collected simultaneously or nearly simultaneously.

[0016] Users can utilize mobile and / or resident software applications on computing devices and / or websites to access digital accounts and / or digital account credit limits via digital wallets. These interfaces allow users to view and / or request processing of transactions and payments based on one or more rules, regulations, and / or budgets associated with the user. For example, government and / or regulatory laws or rules can set available limits for users. Furthermore, these limits can be set based on the user's budget, income, past repayment data, credit rating, or other user data. These limits can also be determined using rule-based and / or machine learning (ML)-based artificial intelligence (AI) engines, which can pre-calculate and recalculate these limits based on real-time and / or available user data, as well as merchant data, merchant agreements, and other data. Additionally, such AI and ML engines can be used during transactions to calculate and / or determine risks, fraud probability, repayment or loss risk, or potential risks, which can be used to determine whether to approve or deny payments and transactions, including those utilizing BNPL programs and requests. Therefore, risk and fraud engines, models, and / or rule sets can be used to authorize, approve, and / or reject account-specific transactions requested via digital wallets (e.g., using contactless payment mechanisms and payment networks / TSPs).

[0017] Transactions can be processed using digital wallets and contactless payment terminals / devices with one or more digital accounts. These terminals / devices can generate and process transaction data on a digital payment network with a back-end payment processor and a TSP. Transaction data can be generated and may include information such as the identifier of one or more items, item cost (e.g., item-by-item) and / or total cost, transaction time, corresponding merchant or merchant identifier, other users involved in the transaction, transaction location, MCC (Match Code for each transaction) and / or other transaction data identifying the specific category of each transaction. Online transaction processors can provide electronic transaction and payment processing services for processing transactions using transaction data and / or card data. To receive this data, the online transaction processor may need to interface with a back-end card processor, TSP, and / or electronic card, payment, or transaction network that sends, receives, and / or processes transaction data based on associated payment instrument data. In this regard, the online transaction processor can utilize application programming interfaces (APIs) to communicate and integrate with one or more APIs of the electronic payment network. This allows the online transaction processor to detect, receive, and process transaction data. Subsequently, transaction data can be detected and / or sent to an online transaction processor via one or more APIs. This can include receiving and processing data in real time (e.g., as a transaction occurs) to provide approval and authorization for each transaction for the BNPL program.

[0018] When an online transaction processor receives transaction data when a transaction is requested for processing, it can analyze the data based on risk assessment or analysis to determine whether the transaction is authorized and whether it can be approved or rejected. To receive transaction data, data transmission, reading, and / or scanning events can be performed on the corresponding transaction information generated by the merchant device. For example, a mobile device can utilize a mobile application of a digital wallet, which stores data about a digital account that can be used by the transaction processor. The mobile device can interact with nearby or adjacent POS or other merchant devices and / or terminals, which may include readers or scanners for magnetic stripe, EMV chip, NFC, or RFID transceivers, etc., which read data from local devices or data storage facilities. The mobile device can provide an identifier (e.g., a BIN) pre-configured and / or generated for the account via the digital wallet and / or the corresponding mobile application for use by TSPs and other back-end processors on the payment network. The mobile device can utilize the digital wallet to send tokens including the identifier, which can be pre-established for the account based on the identifier (e.g., a DPAN token of a BIN provided by the TSP to the digital wallet) or generated. This can be provided from mobile devices to merchant devices (e.g., via local transceivers or other terminal communication modules) via contactless payment and short-range wireless communication, where authorization and processing of DPAN or other tokens are requested on the payment network.

[0019] Online transaction processors can be established in conjunction with payment networks to receive incoming communications from payment networks, merchants, point-of-sale (POS) devices, etc., and to identify electronic transaction payments requested through digital accounts. When processing a transaction, after a merchant device receives a token or identifier and other data via contactless reading or data transfer, the merchant device can request authorization from a back-end payment processor or system (e.g., QUICPay™ and / or iD™) on the payment network. This back-end payment processor or system can de-tokenize the token using a TSP associated with the token and identifier (e.g., by converting a DPAN to an FPAN, etc., for use with a BIN or other identifier). Once the identifier is de-tokenized, it can be processed by the online transaction processor along with the transaction data to approve or reject the transaction.

[0020] For example, if a transaction complies with restrictions, the online transaction processor may approve the transaction or allow it to be approved on the payment network (e.g., by not rejecting the transaction or by not requesting the electronic card network and / or back-end credit card processing system to reject it). However, if a transaction violates restrictions or otherwise fails to comply with restrictions (e.g., if the transaction amount causes the digital account and / or the digital account balance to exceed the limit balance cap), the online transaction processor may reject the transaction by refusing to process it and / or requesting the network and / or back-end processing system to reject or refuse the transaction. If a transaction exceeds or violates restrictions, the online transaction processor may refuse to process the transaction and / or send a message with a notification or alert to the user's device. The device may include an application with one or more interface options, elements, or graphics (which may include executable options, actions, and / or optional elements) to view the approval or rejection of transaction processing, as well as transaction status, balance, loan information, etc.

[0021] In this way, accounts utilizing real-time and / or transaction-on-demand approval and authorization mechanisms can be compatible with digital wallets and digital wallet providers that handle transactions separately from the account. This allows for the integration of digital accounts with previously incompatible computing systems and networks used for data processing, including tokenization requirements and TSPs. Furthermore, providing specific identifiers for use through digital wallets allows different systems to coordinate and send data quickly and efficiently, enabling real-time data processing and transaction authorization during face-to-face and / or contactless payments at physical merchants and other seller locations. Thus, systems can be coordinated to use previously incompatible data formats, components, and networks that would otherwise have hindered use and interaction between these platforms.

[0022] Figure 1 This is a block diagram of a networking system 100 suitable for implementing the processes described herein, according to embodiments. As shown, system 100 may include or implement multiple devices, servers, and / or software components that operate to perform various methods according to the embodiments. Exemplary devices and servers may include devices running operating systems such as MICROSOFT® OS, UNIX® OS, LINUX® OS, or other suitable device- and / or server-based OSs, as well as standalone and enterprise-class servers. It will be understood that... Figure 1 The devices and / or servers shown may be deployed in other ways, and for a given embodiment, the operations performed and / or services provided by these devices and / or servers may be combined or separated, and may be performed by more or fewer devices and / or servers. One or more devices and / or servers may be operated and / or maintained by the same or different entities.

[0023] System 100 includes a user device 110, a transaction processor 120, and a digital wallet platform 140, all communicating via a network 150. The user device 110 can be used to establish transactions and process payments using accounts managed by the user device 110. In this regard, when processing transactions, transaction data can be provided to the transaction processor 120 via a transaction network available on the network 150. The user device 110 can utilize the digital wallet provided by the digital wallet platform 140 to process transactions face-to-face and / or via wireless communication and protocols using a contactless payment system. The transaction processor 120 can log in to the digital wallet platform 140 using the account utilized by the user device 110 and register that account with other processors and protocols used by the TSP and payment network for use with the digital wallet provided by the digital wallet system 140.

[0024] User device 110, transaction processor 120, and digital wallet platform 140 may each include one or more processors, memory, and other suitable components for executing instructions, such as program code and / or data stored on one or more computer-readable media, to implement the various applications, data, and steps described herein. For example, such instructions may be stored in one or more computer-readable media, such as internal and / or external memory or data storage devices of various components of system 100, and / or memory or data storage devices accessible via network 150.

[0025] User equipment 110 can be implemented using any suitable hardware and software configured to communicate wired and / or wirelessly with merchant equipment, payment terminals, contactless payment transceivers and devices, and / or transaction processor 120 to process transactions using a digital wallet provided by digital wallet platform 140. User equipment 110 may correspond to a user processing payments and sales through an executable software application. In various embodiments, user equipment 110 may be implemented as a personal computer (PC), smartphone, laptop / tablet, watch with suitable computer hardware resources, other types of wearable computing devices, and / or other types of computing devices capable of sending and / or receiving data. Although only one computing device is shown, multiple computing devices can operate similarly.

[0026] Figure 1 User equipment 110 includes a payment application 112, a database 116, and a network interface component 118. The payment application 112 may correspond to an executable process, procedure, and / or application with associated hardware. In other embodiments, user equipment 110 may include additional or different modules with dedicated hardware and / or software as needed.

[0027] Payment application 112 may correspond to one or more processes that execute software modules and related components of user device 110 to provide functions, services, and other operations to a user via network 150. These functions, services, and operations may include accessing and utilizing computing services provided by transaction processor 120 and / or digital wallet platform 140. In this regard, payment application 112 may correspond to dedicated software used by a user of user device 110 to access websites or applications (e.g., mobile applications, rich internet applications, or resident software applications) that may display one or more user interfaces that allow interaction with the computing services of transaction processor 120 and / or digital wallet platform 140. In various embodiments, payment application 112 may correspond to a general-purpose browser application configured to retrieve, present, and transmit information via the Internet (e.g., utilizing resources on the World Wide Web) or a dedicated network. For example, payment application 112 may provide a web browser that can send and receive information via network 150, including retrieving website information, presenting website information to a user, and / or transmitting information to a website. However, in other embodiments, payment application 112 may include a transaction processor 120, a digital wallet platform 140, or a dedicated application of another entity. Payment application 112 can be used to access and utilize a digital wallet 113 provided and / or services by the digital wallet platform 140, which may contain an account 114 provided and services by the transaction processor 120, wherein account 114 may provide BNPL services, installment payments, or financing loans for purchases.

[0028] Payment application 112 may be associated with account information, user financial information, and / or transaction history. However, in further embodiments, different services may also be provided via payment application 112, including social networking, media publishing or sharing, microblogging, data browsing and searching, online shopping, and other services available through transaction processor 120. Therefore, payment application 112 may also correspond to different service applications, etc. When using payment application 112 and transaction processor 120, payment application 112 may request transaction processing from transaction processor 120, such as payment requests and / or contactless data transmission, to process payments using account 114. Data of account 114 may be provided by digital wallet 113 during contactless payments via the corresponding protocols, operations, and / or applications of digital wallet 113 and / or digital wallet platform 140.

[0029] For example, a payment request or other interaction for a transaction may correspond to requesting, establishing, and / or processing a transaction using payment application 112 to make a payment using account 114, which may utilize real-time and / or per-transaction approval and authorization mechanisms (e.g., for financing and / or payments of BNPL type). Digital wallet 113 may be used to send a BIN or other identifier generated and / or pre-configured for account 114 on the payment network for contactless payments, the BIN or identifier being tokenized and / or encoded as a DPAN or other FPAN-compatible token. Such identifier and token for account 114 may be generated during the login and creation process of account 114 for use in digital wallet 113, as described herein, and transaction processor 120 may process the digital wallet via digital wallet platform 140. Subsequently, via the operation of digital wallet 113, the token may be wirelessly sent, such as through short-range wireless communication for contactless payment protocols, devices, and technologies, which allows account 114 to be used for payment of transactions. After registration, payment application 112 can use the protocol of digital wallet 113 and the tokenized identifier of account 114 to make payment requests to one or more contactless payment devices, terminals, transceivers, etc. of one or more merchants. Subsequently, payment application 112 can be used to view the results of transaction processing through one or more interfaces.

[0030] In various embodiments, user equipment 110 includes other applications that may be required in a particular embodiment to provide functionality to user equipment 110. For example, other applications may include security applications for implementing client-side security functions, programmable client applications for interfacing with appropriate application programming interfaces (APIs) via network 150, or other types of applications. Other applications may also include email, text, voice, and instant messaging (IM) applications that allow users to send and receive emails, calls, texts, and other notifications via network 150. In various embodiments, other applications may include financial applications, such as banking applications. Other applications may include social networking applications, media viewing, and / or merchant applications.

[0031] Other applications may include location detection applications that can be used to determine the user's location, such as maps, compasses, and / or GPS applications, which may include a dedicated GPS receiver for determining the location information of user equipment 110. Other applications may include device interface applications and other display modules that can receive input from and / or output information to the user. For example, other applications may include processor-executable software programs, including graphical user interfaces (GUIs) configured to provide an interface to the user. Therefore, other applications may use components of user equipment 110, such as display devices capable of displaying information to the user, and other output devices, including speakers.

[0032] User equipment 110 may also include a database 116 stored on transient and / or non-transitory memory of user equipment 110. This database can store various applications and data and be used during the execution of various modules of user equipment 110. Database 116 may include, for example, identifiers such as operating system registry entries, cookies associated with payment application 112 and / or other applications, identifiers associated with the hardware of user equipment 110, or other suitable identifiers, such as identifiers for payment / user / device authentication or identification, which can be transmitted to transaction processor 120 to identify the user / user equipment 110. In addition, database 116 may include data of digital wallet 113 and / or account 114, which may include identifiers and / or tokens for contactless and / or wireless payment processing and data transmissions via digital wallet and payment protocols and networks provided by transaction processor 120 and digital wallet platform 140.

[0033] User equipment 110 includes at least one network interface component 118 adapted to communicate with transaction processor 120, digital wallet platform 140, and / or other devices and servers via network 150. In various embodiments, network interface component 118 may include a DSL (e.g., digital subscriber line) modem, PSTN (Public Switched Telephone Network) modem, Ethernet device, broadband device, satellite device, and / or various other types of wired and / or wireless network communication devices, including microwave, radio frequency, infrared, Bluetooth, and near-field communication devices.

[0034] Transaction processor 120 may be maintained by, for example, an online service provider, which can provide processes for offering account services and processing payments. In this regard, transaction processor 120 includes one or more processing applications that can be configured to interact with user device 110, digital wallet platform 140, and / or other devices / servers to facilitate communication and transactions between users. Transaction processor 120 may be maintained by or include other types of platform or service providers, such as transaction processors like PAYPAL® Inc. of San Jose, California, USA. While transaction processor 120 and digital wallet platform 140 are discussed as separate devices and servers, in some embodiments, one or more of the described processes may alternatively be provided by other devices or servers or by the same devices or servers.

[0035] Figure 1The transaction processor 120 includes a transaction processing platform 130 with a transaction processing application 122, a database 126, and a network interface component 128. The transaction processing platform 130 and the transaction processing application 122 may correspond to executable processes, procedures, and / or applications with associated hardware. In other embodiments, the transaction processor 120 may include additional or different modules with dedicated hardware and / or software as needed.

[0036] Transaction processing platform 130 may correspond to the modules and associated dedicated hardware that execute transaction processor 120 to process one or more processes of item transactions with user device 110 and one or more merchant or seller devices. This may be based on account 114 registered and established in digital wallet 113 for face-to-face, short-range wireless and / or contactless payments, data transmission, communication, etc. In this respect, transaction processing platform 130 may correspond to the dedicated hardware and / or software used by the user to establish account 134 (including account 114 used by user device 110) through BNPL service 132. Account 134 may be created by providing personal and / or financial information to transaction processor 120 and selecting authentication credentials. In various embodiments, financial information may include payment instrument information, such as account number / card number and information. The account can be used to purchase items and / or transfer funds. The payment account can be accessed and / or used through browser applications and / or dedicated payment applications. However, in other embodiments, account 134 can be used through digital wallet platform 140 to process transactions and payments via a digital wallet provided by digital wallet platform 140, such as payment processing using digital wallet protocols and operations, including contactless data transfer and payment processing. BNPL service 132 can be used to request and / or receive transaction restrictions, approve transactions in real-time or on a per-transaction basis for loans and / or financing of the BNPL type, etc. BNPL service 132 can process payments and can provide a transaction history for transaction authorization, approval, or rejection.

[0037] BNPL service 132 may correspond to the services of transaction processor 120 that can be used by end users to perform electronic payments, transfers, etc., using one or more accounts and / or financial instruments. BNPL service 132 may also include or utilize different processors, engines, or models required for authentication, account creation and maintenance, electronic transaction processing, deposits and / or withdrawals, dispute resolution, etc. BNPL service 132 may include integration and / or interaction with one or more APIs of the payment network to detect, receive, and monitor transaction data for approving and / or complying with payment restrictions of account 134. Therefore, BNPL service 132 may interact with the network through one or more API calls to the API interfaces of transaction processing platform 130 with the digital payment network and back-end processors. BNPL service 132 may determine transaction data of transactions processed on the network based on received communications and may process these transactions in real time and / or on a per-transaction basis based on risks such as user, transaction, and / or account repayment, fraud, default, etc.

[0038] BNPL service 132 can receive transaction data from transactions processed using accounts accessible through user device 110 and / or other devices or servers. BNPL service 132 can then determine spending limits set for the use of available balances, credit lines, and / or other funds in a user's digital account, as well as account data used to perform real-time risk analysis, assessment, and checks to approve or reject corresponding transactions. In this regard, an AI engine of the transaction processing platform can be executed to calculate the risk and / or availability of installment loans, financing, etc., based on user data, budget, account assets or balances, available or future funds, etc. Using API calls to the payment network on network 150, devices (e.g., user device 110 and / or merchants, POS, or payment devices) and their corresponding transactions can be detected and processed. BNPL service 132 can determine whether a transaction complies with spending limits and / or whether it can be authorized and approved in real time and / or for a specific transaction. If so, the transaction can be approved or authorized. However, if a transaction does not comply with spending limits or exceeds risk or electronic transaction processing approval limits and / or credit / balance limits, BNPL service 132 may be used to refuse transaction processing or instruct the back-end credit processor to refuse processing the transaction. Furthermore, BNPL service 132 may send messages to user device 110 and / or other devices to notify the user of the transaction's approval or rejection.

[0039] In some embodiments, BNPL service 132 may employ one or more AI engines and / or models, such as rule-based, ML, or neural network (NN) models and / or engines, for intelligent decision-making regarding risk and / or transaction approval. These AI engines and / or models may include rule-based engines that process user data, transaction data, and / or merchant data that can be used to determine the approval of a requested transaction when a transaction occurs. Furthermore, BNPL service 132 may utilize machine learning engines or other AI models or engines to determine risk and / or transaction approval. In some embodiments, machine learning engines may include AI models, such as ML or neural network (NN) models. AI models can generally correspond to any artificial intelligence that performs decision-making, such as rule-based engines. However, AI models may also include subcategories including ML models and NM models that provide intelligent decision-making using algorithmic relationships. Typically, NN models may include deep learning models and may correspond to a subset of ML models that attempt to mimic human thought by modeling data through different neural network graphs using various algorithms, where neurons comprise data representation nodes based on algorithms that can interconnect with different nodes. ML models can similarly utilize one or more of these mathematical models and generate layers and connection nodes between layers in a manner similar to neurons in NN models.

[0040] When building an ML model for a machine learning engine, training data can be used to generate one or more classifiers and provide suggestions, predictions, or other outputs based on these classifications and the ML model. When a transaction is requested to be processed using account 134, the training data can be used to determine input features for training predicted scores and / or outputs such as risk, transaction approval, or rejection, where account 134 can be used by merchants or payment devices via one or more digital wallets and digital wallet platform 140. For example, the ML model of the machine learning engine may include one or more layers, including an input layer, hidden layers, and an output layer with one or more nodes, but different layers may also be utilized. For example, as many hidden layers as necessary or appropriate may be utilized. Each node within a layer connects to nodes in adjacent layers, where a set of input values ​​can be used to generate one or more output scores or classifications. Within the input layer, each node may correspond to a different attribute or input data type used to train the ML model of the machine learning engine.

[0041] Subsequently, ML algorithms, computations, and / or techniques can be used to train the hidden layer with these attributes and corresponding weights. For example, each node in the hidden layer generates a representation that may include a mathematical ML computation (or algorithm) that generates values ​​based on the input values ​​of the input nodes. The ML algorithm can assign different weights to each data value received from the input nodes. The hidden layer nodes may include different algorithms and / or different weights assigned to the input data, thus producing different values ​​based on the input values. The values ​​generated by the hidden layer nodes can be used by the output layer nodes to generate one or more output values ​​for the ML models of machine learning engines that attempt to perform classification and / or provide outputs for transaction approval. Therefore, when the ML models of machine learning engines are used to perform predictive analytics and outputs, the inputs can provide corresponding outputs based on the classifications trained for the ML models of the machine learning engines.

[0042] The ML model of a machine learning engine can be trained using training data. By providing training data, the nodes in the hidden layers can be trained (tuned) to produce optimal outputs (e.g., classification) in the output layer based on the training data. The ML model (specifically, the representations of nodes in the hidden layers) can be trained (tuned) to improve its data classification performance by continuously providing different training datasets and penalizing the ML model when its output is incorrect. Tuning the ML model may involve adjusting the weights associated with each node in the hidden layers. Therefore, training data can be used as input / output datasets that allow the ML model to classify based on input attributes. The output classification of the ML model trained for the machine learning engine could be a classification used by BNPL service 132 for risk and / or transaction processing.

[0043] In addition, transaction processing platform 130 processes wallet registration requests 138 for digital wallet registration accounts 134 provided to digital wallet platform 140. Wallet registration request 138 may correspond to a received request to register account 134 with the corresponding digital wallet for use by those digital wallets (e.g., when performing contactless or short-range wireless transaction processing and other data transmissions). This can be achieved by pre-configuring and / or generating BINs or other identifiers, which can be tokenized as PANs, such as DPANs, or other tokens used for processing contactless payments on a payment network. In this regard, digital wallets may require FPAN or DPAN fields when registering accounts or financial instruments for contactless payments via the digital wallet, which can be accomplished using pre-configured BINs or other identifiers. For example, for a wallet registration request 138, an identifier 136 can be generated and / or pre-configured for use by digital wallet 113 for electronic transaction processing via wallet-utilized account 114 for contactless payments and / or other payment processing using digital wallet 113. This can be accomplished by combining a digital wallet platform 140, a TSP for tokenization / detoxification, a backend processor and payment network that interacts with the front end (e.g., front-end processor, server, system, device, etc.) of digital wallet 113 and account 114, and / or applications / websites of digital wallet platform 140 and / or transaction processor 130. See below for reference. Figure 2A-5B Further discussion of such identifiers, tokens, components, and examples of operations for creating and utilizing accounts 134, identifier 136, and other identifiers for digital wallets.

[0044] Transaction processing application 122 may correspond to one or more processes that execute the modules and associated dedicated hardware of transaction processor 120 to process transactions or provide another service to customers, merchants, and / or other end users and entities of transaction processor 120. In this regard, transaction processing application 122 may correspond to dedicated hardware and / or software used by transaction processor 120 to provide computing services to users, which may include electronic transaction processing and / or other computing services using account 134 provided by transaction processor 120, such as electronic transaction processing of transactions initiated using a digital wallet with registered account 134 in response to receiving transaction data with a routing identifier 124. In some embodiments, transaction processing application 122 may be used by a user (e.g., a user associated with user device 110) to establish user and / or payment accounts and digital wallets that can be used to process transactions. Account 134 may be accessed and / or used through one or more instances of web browser applications and / or dedicated software applications executed by user device 110 and participate in the computing services provided by transaction processing application 122. The computing services of transaction processing application 122 may also correspond to messaging, social networking, media publishing or sharing, microblogging, data browsing and searching, online shopping, and other services available through transaction processor 120.

[0045] In various embodiments, and in certain embodiments, the transaction processing platform 130 may need to provide functionality to the transaction processor 120. For example, the transaction processing platform 130 may include a security application for implementing server-side security features, a programmable client application for interfacing with an appropriate application programming interface (API) via the network 150, or other types of applications. The transaction processing platform 130 may include processor-executable software programs, including a graphical user interface (GUI) configured to provide an interface to a user when accessing the transaction processor 120 via one or more user devices 110, wherein the user or other users can interact with the GUI to more easily view and transmit information. In various embodiments, the transaction processing platform 130 may include additional connectivity and / or communication applications that can be used to transmit information via the network 150.

[0046] In addition, transaction processor 120 includes database 126. Database 126 can store various identifiers associated with user device 110. Database 126 can also store account data, including payment instruments and authentication credentials, as well as transaction processing history and data on processed transactions. Database 126 can store received user-related data, such as transaction data and spending limits for electronic transaction processing. Furthermore, database 126 can be used to store data for account 134, which can be used to generate, store, and / or transmit identifiers and / or tokens used for registering and creating accounts in digital wallets and processing transactions via account 134.

[0047] In various embodiments, the transaction processor 120 includes at least one network interface component 128 adapted to communicate with user equipment 110, digital wallet platform 140, and / or other devices / servers via network 150. In various embodiments, the network interface component 128 may include a DSL (e.g., digital subscriber line) modem, a PSTN (Public Switched Telephone Network) modem, an Ethernet device, a broadband device, a satellite device, and / or various other types of wired and / or wireless network communication devices, including microwave, radio frequency (RF), and infrared (IR) communication devices.

[0048] Digital wallet platform 140 may be maintained by, for example, third parties, application providers, merchants, transaction processors, and / or other online service providers that offer, use, and / or maintain digital wallets that users can use during electronic transaction processing. Digital wallet platform 140 may be used by one or more physical and / or online merchant marketplaces, sales platforms, point-of-sale (POS) devices, websites, and / or online resources accessible to users to purchase items through processes and funds provided by the digital wallet maintained by digital wallet platform 140. For example, digital wallet platform 140 may be used to process transactions by one or more POS devices at physical merchant locations and websites and / or application-accessible digital platforms (on which users can perform electronic transaction processing). Digital wallet platform 140 may also include other platforms, websites, and resources that allow users to participate in electronic transaction processing, such as platforms, websites, and resources associated with payment processors, funds transfers, utility or living expense payments, and other payment or purchase platforms that users may use that may require payment for due balances of certain products, services, or other items. In some embodiments, the digital wallet platform 140 can be implemented as a single or networked personal computer (PC), server, smartphone, laptop, wearable computing device, and / or other type of computing device. While only one wallet provider platform is shown, multiple platforms can function similarly.

[0049] Figure 1 The digital wallet platform 140 includes a digital wallet application 142. The digital wallet application 142 may correspond to an executable process, procedure, and / or application with associated hardware. In other embodiments, the digital wallet platform 140 may include additional or different software as needed.

[0050] Digital wallet application 142 can provide and / or process transactions through user device 110 and / or users associated with user device 110 and / or on behalf of user device 110 and / or users associated with user device 110 (e.g., using one or more digital wallets 144 with payment sources, including payment cards, digital accounts, cash, etc., and accounts 134 registered for use with digital wallet 144). In some embodiments, digital wallet application 142 can be accessed via the Internet and can be made available via network 150 for use by user device 110 and transaction processor 120. Digital wallet application 142 can be used at physical merchant locations, such as POS devices for providing sales at physical locations, including contactless payment and transaction processing using data transmission via short-range wireless communication, signals, and protocols. Therefore, digital wallet application 142 can be used to log account 134 to digital wallet 144, including logging account 114 to digital wallet 113 using identifier 136. In this regard, digital wallet application 142 can be used to receive one or more identifiers, which can be tokenized and stored in digital wallet 144 for payment processing using payment networks, TSPs, other backend payment processors and systems, as described below. Figure 2A-5B Further details are discussed below. Payments can be made using digital accounts by routing transaction data and routing identifier 124 back to transaction processor 120 for payment. After the digital account receives the payment and / or confirms the digital account transfer, digital wallet platform 140 can then use the account, identifier, and payment tools to process payments to merchants or other sellers through transaction processor 120, including loans or financing provided by financing or BNPL type loans or financing, which can be approved and / or processed in real time and / or on a per-transaction basis.

[0051] Network 150 can be implemented as a single network or a combination of multiple networks. For example, in various embodiments, network 150 may include the Internet or one or more intranets, terrestrial networks, wireless networks, and / or other suitable types of networks. Thus, network 150 may correspond to small communication networks accessible to various components of system 100, such as private or local area networks, or large networks, such as wide area networks or the Internet.

[0052] Figure 2A and 2B Exemplary illustrations 200a and 200b are provided according to embodiments for establishing a digital account via a digital wallet provided by a separate platform and using the digital account for short-range wireless data processing with merchant devices. Figure 2A and 2BThe diagrams 200a and 200b can correspond to the operational flow and data communication between devices, servers, and / or systems when interacting via payment accounts using a separate wallet provider's digital wallet to provide contactless payments, for example, see reference. Figure 1 The system 100 discusses the interaction between user devices 110, transaction processors 120, and / or digital wallet platforms 140.

[0053] exist Figure 2A Figure 200a illustrates various interactions, inputs, data communications, and / or processing operations for establishing a digital account in a digital wallet for use with payment networks to process transactions, such as using contactless payments and BNPL-type or other financing payment services. Initially at interaction 1, a consumer 202, such as a customer of an online transaction processor or other service provider that can process transactions with merchants and other sellers, can interact with BNPL application 204 to request that the account be added to the digital wallet of a digital wallet provider separate from the online transaction processor providing the account. This account may correspond to a BNPL-type account and / or an account utilizing BNPL services, such as financing transactions through loans, installment loans, and / or periodic repayment plans, and other financing services. Therefore, the account may require real-time and / or per-transaction risk and fraud analysis, processing, and / or approval via the digital wallet. Consequently, the account may initially be incompatible with the digital wallet and / or the payment network used by the digital wallet.

[0054] Consumer 202 can interact with BNPL application 204 via a dedicated software application and / or website or web application. This BNPL application can retrieve and / or obtain a public certificate from a digital wallet and backend 208 in interaction 2. The digital public certificate can be used for trust operations, such as signing and verifying signatures, and establishing chains of trust to verify other certificates that allow secure communication, trusted data, and signing. Therefore, the public certificate can be used to generate and / or pre-configure identifiers (e.g., BINs or other identifiers, numbers, alphanumeric codes, etc.) for accounts used for trusted payment processing, and can be used for other signing and trust operations during payment processing and other account or digital wallet activities. Then, at interaction 3, BNPL application 204 provides the public certificate to BNPL backend 206, which stores the public certificate. Before the public certificate is transmitted to BNPL backend 206 and / or stored, it can be encrypted using any random number or random number signature for secure storage. At interaction 4, the BNPL backend 206 responds to the BNPL application 204 with encrypted data, such as encrypted card data. This encrypted card data can mimic or emulate credit cards, debit cards, or other payment cards and communications used for payment processing by having an identifier (e.g., a BIN) (which can be used on card processing and / or payment networks and / or by card processing terminals, including contactless, RFID, NFC, or other short-range wireless terminals, devices, transceivers). Identifiers for pre-configured and / or agent cards or other data can be generated and / or pre-configured for accounts to be compatible with the corresponding payment networks and TSPs (such as TSP 210). Thus, the identifier can correspond to a BIN that allows entry in FPAN fields or other PAN fields for form fields used to register an account with a digital wallet, thereby allowing tokenization and use of the corresponding payment network.

[0055] In Interaction 5, encrypted (card) data is sent from BNPL application 204 to digital wallet and backend 208 for processing, where digital wallet and backend 208 may correspond to a token requester. Digital wallet and backend 208 can identify the encrypted data as pre-provisioned or proxy data mimicking or imitating card data, such as the BIN of a payment card, which can be used for electronic transaction processing via digital wallet. The data can be encrypted using a shared key (e.g., a public key from a public certificate), so digital wallet and backend 208 can decrypt and verify the data for account registration. Therefore, the encrypted data may include an identifier to be registered and / or stored for an account, which can be tokenized in a DPAN or other FPAN type format for use in payments on the payment network. In Interaction 6, encrypted data and / or the identifier are provided from digital wallet and backend 208 to a token service provider (TSP) 210, which can tokenize the data for storage and use during electronic transaction processing. TSP 210 can correspond to a computing service that generates tokens to represent data without leaking the data to ensure security, wherein the resolution of tokens for receiving and / or processing data can be solved by TSP 210.

[0056] To register accounts and identifiers with the digital wallet and backend 208, BNPL backend 206 performs account identification and / or processing account identification checks with TSP 210 at interaction 7. The TSP can provide data tokens of DPAN, FPAN, or other PAN types for use on the payment network. At interaction 8, terms and conditions are provided to the digital wallet and backend 208, and at interaction 9, the digital wallet and backend 208 request consumer 202 to approve and agree to the terms and conditions. Consumer 202 can then agree to the terms and conditions for using the digital wallet and account for payment processing (including contactless and / or short-range wireless data transmission and payment processing) via the digital wallet. At interaction 10, BNPL backend 206 performs eligibility checks on the account and identifier with TSP 210 for tokenization and use on the payment network, where tokens can be generated in response to determining that the account and / or identifier are eligible. At interaction 11, the token, such as the identifier DPAN or other data from the digital wallet and backend 208, is returned from TSP 210 to the digital wallet and backend 208 for storage. The token can be stored in the consumer 202's digital wallet and / or stored for use in the consumer 202's digital wallet, and associated with a digital account and / or BNPL type payment service available to the consumer 202. Therefore, the token enables electronic transaction processing, including contactless payment processing via cards and / or contactless payment terminals. API calls and data processing events used to create accounts in the digital wallet are... Figure 2A As shown in the image, and below regarding... Figure 3A and3B Further description.

[0057] exist Figure 2B Figure 200b illustrates various interactions, inputs, data communications, and / or processing operations for processing payments from a digital account using a digital wallet via a payment network (e.g., contactless payments and BNPL type or other financial payment services). At interaction 21, the contactless payment terminal 222 reads, receives, or detects short-range wireless signaling and / or communications, and / or otherwise determines that a data token or similar data representing or acting as an agent of a card has been transmitted from a contactless device or object to the contactless payment terminal 222. For example, a mobile phone can be used to open a software application or website via a web browser application and request electronic transaction processing by sending data to a nearby or adjacent device via short-range wireless communication. The contactless payment terminal 222 can then read or receive this data, and at interaction 21, authorization for the corresponding transaction can be requested based on the data transmission of the agent card data or other data representing an identifier (e.g., a token, etc.), thereby allowing payment processing using the application.

[0058] Authorization can be requested from payment network 224, such as QUICPay™ and / or iD™, which provides payment networks that process and parse digital tokens between front-end contactless devices and terminals, mobile devices and applications, websites, digital wallet services, etc., and back-end payment networks, processors, etc. At interaction 22, payment network 224 provides TSP 226 with proxy data that it reads, scans, or receives, such as tokens with identifiers. TSP 226 can detoxify the tokens into another form or identifier that can identify the corresponding back-end processor, host, or system processing the payment transaction. TSP 226 detoxifies the tokens (such as DPAN) into corresponding data (such as BIN or other identifiers), and at interaction 23, provides the detoxified data, along with transaction data, to BNPL service 228 or other computational services for real-time processing of account transactions and / or processing transactions on a per-transaction basis to provide approval or rejection of transactions. Such processing, based on risk assessment and factors, user data and / or balance, deferred credit or loans, etc., can be used to determine the financing and / or eligibility for BNPL services and the funds of the transaction.

[0059] Figure 3A and 3B These are exemplary illustrations 300a and 300b illustrating data processing calls and operations between an online transaction processor system and a digital wallet provider system when establishing and logging into a digital account in a digital wallet, according to an embodiment. Figure 3A and 3BIllustrations 300a and 300b include API calls and data processing events from interactions between devices, servers, applications, and / or systems. These interactions can be used to establish and use digital accounts (such as digital accounts providing BNLP-type payment services) in digital wallets used as payment tools. In this regard, these interactions can be referenced... Figure 1 The system 100 discusses the execution of user devices 110, transaction processors 120, and / or digital wallet platforms 140.

[0060] Interaction between user device 110, digital wallet platform 140, and transaction processor 120 can be used to configure the digital wallet to use a specific digital account as a payment or fund transfer tool during electronic transaction processing, including contactless payment processing and system-wide electronic transaction processing. Initially, user 302 can utilize BNPL application 304 to use the digital account for BNPL payments and financial services. User 302 can also use a separate digital wallet platform 306, which utilizes wallet server 308 to provide computing services via applications and websites and processes data using backend components, servers, systems, etc. Payments can be processed via payment network 310, which can interact with TSP 312 for tokenization / detoxification of data, such as identifiers that can be processed, for example, via BNPL host 314 for payment and / or transaction approval, authorization, and / or payment.

[0061] At interaction 31, BNPL application 304 first requests a master account (PAN) from BNPL host 314 via an API call or request. This PAN may correspond to a master identifier, etc., used to identify the account of user 302. At interaction 32, BNPL application 304 also performs an eligibility check on digital wallet 306 to determine its eligibility to add the account and / or BNPL payment processing service to digital wallet 306 as a payment instrument for face-to-face and / or digital payments and transactions. This may include performing API calls for eligibility checks and checking existing routes for adding security elements. Subsequently, if the eligibility check is passed and BNPL application 304 and / or digital wallet 306 provide the option to register and / or enroll an account in the wallet, user 302 selects the option to add the account to digital wallet 306 at interaction 33. This corresponds to an API call between BNPL application 304 and digital wallet 306 requesting the account to be added to digital wallet 306.

[0062] Based on the request, during interaction 34, the public certificate is retrieved and encrypted for use in the account registration process with digital wallet 306. Digital wallet 306 may first request the public certificate from wallet server 308 via an API request. Wallet server 308 may respond to digital wallet 306 via an API response using the public certificate and a random number (random and / or non-repeating value to ensure initial or real-time data transmission of the public certificate). Digital wallet 306 may generate a random number signature using the random number and may provide the random number, random number signature, and public certificate to BNPL application 304. At interaction 35, BNPL application 304 then encrypts the public certificate, random number, and random number signature using the account's PAN and sends the encrypted data to BNPL host 314.

[0063] At interaction 36, BNPL host 314 then provides an API response to BNPL application 304 using encrypted data (with an encrypted PAN or other identifier). The encrypted PAN may correspond to a BIN or other identifier, where the BIN / identifier may be a DPAN used as a required field during account registration (e.g., a form field such as FPAN when registering an account with digital wallet 306). The API response may further include activation data as an encrypted one-time password (OTP) and a temporary public key for encrypted operations, signing, and / or security. At interaction 37, BNPL application 304 may set the encrypted PAN or other identifier, the encrypted OTP or other activation data, and the temporary public key to wallet server 308 for use by digital wallet 306 of the account. This may correspond to setting encrypted data as proxy card data or similar proxy or provisioned data that mimics funds allocation or payment instruments (e.g., payment cards) and completes the payment instrument registration of the account (where digital wallet 306 serves as a payment instrument available during electronic transaction processing). Therefore, digital wallet 306 can use the encrypted data set and established for payment processing, such as face-to-face payments, contactless payments, wireless payments, and / or digital payments on the internet.

[0064] refer to Figure 3BIn Figure 300b, the process of registering a digital account with the BNPL service via digital wallet 306 and providing user 302 with access to the digital account can then be completed. At interaction 38, digital wallet 306 and wallet server 308 set up an encrypted PAN or other identifier and a temporary public key for use. This includes data validity checks to ensure its validity as a payment mechanism within the digital wallet. At interaction 39, wallet server 308 can determine or identify the TSP based on the BIN or other identifier used for the encrypted PAN. This can include requesting a network check card from TSP 312 using the encrypted PAN and temporary public key. TSP 312 acts as a token provider (e.g., FeliCa® TSP) for the tokenization and detoxification process. TSP 312 can then check card eligibility via an API call to BNPL host 314, which responds with a product identifier and an issuer reference identifier. Subsequently, during interaction 40, TSP 312 requests agreement to the terms and conditions (T&C), which are provided to digital wallet 306 and then forwarded or presented to user 302. User 302 agrees to the T&C via digital wallet 306, and activation data is sent to TSP 312. During interactions 41 and 42, activation is completed, wherein during interaction 41, TSP requests the digitization of the encrypted card data from BNPL host 314, for example, by tokenization, and BNPL host 314 provides a trust level for data tokenization and / or digitization. TSP 312 then issues a token at interaction 42, which is provided to digital wallet 306 as a DPAN for payment processing. This DPAN can be de-tokenized from the FPAN field and / or data in the transaction into a BIN or other identifier of the digital account in digital wallet 306. Digital wallet 306 then displays the successful activation of the account via BNPL application 304.

[0065] Figure 4 This is an example set of user interfaces 400 according to embodiments for use by mobile device applications when registering a digital account with an online transaction processor for use via a digital wallet through a separate digital wallet platform. User interface 400 can be displayed on a computing device (including a mobile smartphone or other mobile device, such as a reference ROM). Figure 1 The user device 110 discussed in System 100. In this regard, the user interface 400 includes separate user interfaces 402, 404, 406, 408, and 410, which can be displayed when registering for and / or logging into a digital account for use during payment and transaction processing.

[0066] exist Figure 4In interface 402, a software application, such as a desktop or mobile application, can present an interface that allows the user to request the addition of payment instruments to a digital wallet. These payment instruments include digital accounts for payment services separate from the digital wallet provider. For example, digital accounts may provide transaction processing and payment services via BNPL computing services, which approve transactions in real-time and / or on a per-transaction basis. This may require specific transaction approval operations at the time of the transaction and / or during the transaction processing request. Interface 402 displays an add-to-wallet request, where the user viewing interface 402 can then choose to add specific payment instruments, such as cards, keys, passwords, or other accounts, including BNPL or other digital accounts.

[0067] Once the request to add a payment tool is selected from interface 402, interface 404 displays the BNPL account addition, where the user can select an online transaction processor for BNPL services and an account to register and enroll in the user's corresponding digital wallet. This may include selecting a card or account identifier representing the account and the online transaction processor, and further informing the user that the account can be used in the digital wallet for face-to-face and / or contactless payment processing, such as via short-range wireless communication. The selection of the transaction processor leads to interface 406, which requests the input of identification and / or authentication credentials or other contact identifiers, such as email and mobile phone numbers, to verify and complete account information. In some embodiments, a password or other confidential information may be requested for account login and / or verification.

[0068] If contact and other verification information are entered, a two-factor or secret query may be issued to the user and / or the user's secure or verified device or contact address / account (e.g., phone number and text message, email address, etc.). For example, an OTP may be requested from the user's device in interface 408, where the OTP is sent to a trusted and / or verified device or account (e.g., via SMS, email, etc.). Interface 408 may then request the user to enter the OTP for verification. If entered and verified, interface 410 displays a successful registration after performing the above steps and operations to register and enroll the user's digital wallet and other digital accounts (BNPL or other digital accounts). The application presents interface 410 and / or another account or digital wallet application, which can then process electronic transactions through that account.

[0069] Figure 5A This is a flowchart 500a, which illustrates an exemplary process for establishing a digital account in a digital wallet during cross-platform data processing according to an embodiment. Note that one or more steps, processes, and methods described in flowchart 500a may be omitted, performed in a different order, or combined as needed or appropriately.

[0070] In step 502, a request to use the account in a digital wallet separately hosted from the account is received. This request may be received via a software application or website of an online transaction processor providing the account or a digital wallet platform providing the digital wallet. The request may be received after determining that the account is eligible and usable with the digital wallet (e.g., by determining that the user is entitled to use the account and / or authorize payment processing). For example, a system that approves and / or authorizes each transaction based on the user's eligibility for financing, loans, installment loans, or other credit or funding extensions to cover a specific transaction (e.g., BNPL type) may confirm that the user is eligible for installment loans or financing.

[0071] In step 504, a public certificate associated with the digital wallet is obtained. The public certificate can be used for trust verification, digital signatures, encryption, etc., and can be used to verify digital wallet providers, etc., to enable secure communication with online transaction processors when registering and signing accounts with the digital wallet. In step 506, encrypted data with a BIN containing the FPAN field required to populate the digital wallet is obtained. The encrypted data may include an account identifier, such as a PAN, which can be encrypted and used as an FPAN or DPAN during tokenization and payment processing using the digital wallet. The encrypted data may also include or be associated with an encrypted OTP and temporary public key provided and verified during the request.

[0072] In step 508, encrypted data is provided to the digital wallet platform. API calls can be exchanged and processed between the online transaction processor and the digital wallet provider's platform and system, where the online transaction processor can provide data for tokenization and subsequent processing and use during electronic transaction processing. In step 510, the account and BIN are identified by the back-end payment processor. The online transaction processor can perform this identification to verify the account and BIN or other identifiers on the payment network with the back-end payment processor and system (including TSPs that can tokenize data). Once identified and verified, in step 512, the account is activated using the BIN for use by the digital wallet. This allows transaction processing via the digital wallet using the account, such as contactless payments using tokens of encrypted data (e.g., DPANs) (including BINs or other identifiers). This may require solutions on the payment network, as detailed below. Figure 5B The subject of discussion.

[0073] Figure 5B This is flowchart 500b, an exemplary process for using a digital account across platforms in a separate digital wallet during short-range data processing, according to an embodiment. Note that one or more steps, processes, and methods described in flowchart 500b may be omitted, performed in a different order, or combined as needed or appropriately.

[0074] In step 522, a request to process a transaction is received from a payment network used by the merchant device to parse payment data transmitted via short-range wireless communication. For example, interactions detected between the user and the merchant for electronic transaction processing can be identified, where the interactions may correspond to the data transmission of tokens containing a BIN or other identifier of the account. These interactions can be conducted via short-range wireless communication used to transmit the token to the merchant's appropriate payment device or terminal via contactless and / or wireless transmission. The merchant's device can utilize the payment network and back-end processor to process the received data, including de-tokenizing and using the BIN or other identifier along with the transaction data to request transaction approval and payment. Transactions can be processed based on user data, including user financial data, historical payment and / or repayment data, credit value, etc., and merchant data, including merchant agreements on deferred credit levels, merchant balances, and / or credit values, etc. Such data can be accessed from one or more data repositories, computing devices, etc., associated with the user and merchant.

[0075] In step 524, the identifier of the account used in the payment data is determined. This identifier can be determined by detoxifying the data transmitted during contactless or short-range wireless data communication. This can be accomplished by a TSP on the payment network in use, which can provide the operation of retrieving the FPAN (e.g., a BIN or other identifier pre-assigned to the account) from a DPAN set using a digital wallet. In step 526, the identifier is used to determine the account and whether the account is registered with the digital wallet for payment via short-range wireless communication. The online transaction processor providing the account can provide account lookup and authentication operations to identify the account and determine parameters, source of funds, and / or authorization to make payments via the account.

[0076] In step 528, one or more risk models or rules regarding the transaction are executed for the installment loan plan. For example, transaction data, user, and / or merchant data may be received, wherein the data, characteristics, etc., are extracted and processed by one or more transaction approval and risk engines of the online transaction processor. This can be performed to determine the eligibility of the transaction to be approved, such as eligibility for loans, financing, BNPL payment services, etc. In step 530, the transaction is processed on the payment network. If the transaction is approved, payment can be made to the corresponding account of the merchant or other seller on the network. However, if the risk model or rules reject the transaction, the transaction may be rejected and the rejection processed on the payment network. The results, receipts, and / or transaction history can be provided to the merchant's device and the user's device and / or account via the network.

[0077] In other embodiments, a system includes: a non-transitory memory; and one or more hardware processors coupled to the non-transitory memory and configured to read instructions from the non-transitory memory to cause the system to perform operations including: detecting a request to add a user's account to a user's digital wallet using a payment processing service associated with the system, wherein the digital wallet is hosted by a digital wallet platform separate from the system; determining proxy wallet data for the user's account, wherein the proxy wallet data includes an identifier that uniquely identifies the account to a backend payment processing network and enables payment processing via the payment processing service; sending the proxy wallet data to the digital wallet platform in association with the request; identifying the user's account using the backend payment processing network, which processes the transaction via the payment processing service using the identifier, wherein sending and identification results in the device account in the user's digital wallet being associated with the account being used via the payment processing service; and activating the payment processing service for the account using the user's digital wallet.

[0078] In various embodiments of the above system, 1) determining the proxy wallet data includes receiving an application programming interface (API) response from the system's backend that generates the proxy wallet data; 2) encrypting the proxy wallet data using an encryption key associated with the digital wallet platform before sending the proxy wallet data to the digital wallet platform; 3) before sending the proxy wallet data, the operation further includes passing a request to the digital wallet platform; receiving a public digital certificate with a random number and a random number digital signature from the digital wallet platform; and providing the backend with an API request associated with the public digital certificate, the random number, and the random number digital signature for association with the proxy wallet data; 4) providing the backend with the public digital certificate includes encrypting the public digital certificate, the random number, and the random number digital signature using the account's master account, wherein the public digital certificate, the encrypted random number, the encrypted random number digital signature, and the encrypted master account are provided to the backend via the API request; 5) the proxy wallet data also includes at least information associated with a payment processing service. 6) The identifier is an identification number of a financial institution associated with the near-field communication payment processing service, and wherein the digital wallet platform requires the funds identifier to add an account to the digital wallet, and wherein the funds identifier is provided using an identification number from proxy wallet data; 7) prior to activation, the operation also includes eligibility checks on at least one of the users or accounts to use the account via the digital wallet, wherein activation is performed based on the eligibility checks; 8) the operation also includes receiving a request to use the account for a transaction based on short-range wireless communication used by the digital wallet to the merchant device for transmitting a token associated with the identifier, wherein the request is routed to the payment processing service associated with the system using an identifier de-tokenized from the token; and processing the transaction to use the account based on the request; and / or 9) the payment processing service is associated with an installment payment service and verifies transactions against the account on a per-transaction basis based on one or more risk models during payment processing.

[0079] In other embodiments, a method includes: receiving a request to add a user's account to a user's digital wallet using a payment processing service of an online transaction processor, wherein the digital wallet is hosted by a digital wallet platform separate from the online transaction processor; forwarding the request to the digital wallet platform; receiving one or more public certificates from the digital wallet platform that verify the digital wallet platform for use of the digital wallet through the user's account; generating provisioning data for the user's account based on the one or more public certificates and an account identifier of the user's account, wherein the account identifier uniquely identifies the account to a backend payment processing network during payment processing using the account through the payment processing service; and sending the provisioning data to the digital wallet platform in association with adding the account to the digital wallet for payment processing using the payment processing service of the online transaction processor.

[0080] In various embodiments of the above method, 1) a command delivery request is made using a software application on the user's computing device that displays a user interface that allows an account to be added to a digital wallet using provisioned data; 2) one or more public certificates each have a corresponding random number and a random number digital signature; 3) prior to generation, the method further includes encrypting one or more public certificates and their corresponding random numbers and random number digital signatures with a master account; and providing the encrypted one or more public certificates and their corresponding random numbers and random number digital signatures to the host system of the online transaction processor; 4) the provisioned data is generated based on the provision, and an account identifier is encrypted in the provisioned data; and / or 5) the payment processing service includes a Buy-Now-Pay-Later (BNPL) payment processing service that verifies the account's transaction during the transaction time via the payment processing service based on one or more risk models.

[0081] In another embodiment, a non-transitory machine-readable medium stores machine-readable instructions that are executable to cause a machine to perform operations including: receiving a request to add a user's account to a digital wallet separately hosted by the payment processing service; providing the request to an online platform associated with the digital wallet; receiving a digital certificate from the online platform that verifies the online platform during use of the digital wallet using the account; using the digital certificate to determine encrypted data of the user's account, wherein the encrypted data includes an account identifier that uniquely identifies the account to a backend payment processing network that uses the payment processing service for payment processing; sending the encrypted data in association with the request to the digital wallet platform; and activating the account in the user's digital wallet.

[0082] In various embodiments of the aforementioned non-transitory machine-readable medium, 1) prior to activation, the operation further includes identifying an account and account identifier to a backend payment processing network to request the account to be added to a digital wallet; and associating the device account with the account in the user's digital wallet to use the payment processing service, wherein, during payment processing via the payment processing service, the device account is used by detoxing the funds account associated with the account identifier; 2) the operation further includes storing the device account associated with the account using the digital wallet; and / or 3) the encrypted data further includes activation data, which includes at least an encrypted one-time password and a temporary public key associated with the payment processing service.

[0083] Figure 6 It is adapted to implement according to the embodiments. Figure 1A block diagram of a computer system 600 comprising one or more components. In various embodiments, the communication device may include a personal computing device capable of communicating with a network (e.g., a smartphone, tablet, personal computer, laptop, wearable computing device such as glasses or a watch, Bluetooth device, smart key, badge, etc.). Service providers may utilize network computing devices (e.g., web servers) capable of communicating with a network. It should be understood that each device utilized by the user and the service provider can be implemented as computer system 600 in the following manner.

[0084] Computer system 600 includes bus 602 or other communication mechanisms for transmitting information data, signals, and information between various components of computer system 600. Components include input / output (I / O) component 604, which processes user actions such as selecting keys from a keypad / keyboard, selecting one or more buttons, images, or links, and / or moving one or more images, and sends corresponding signals to bus 602. I / O component 604 may also include output components such as display 611 and cursor controls 613 (such as a keyboard, keypad, mouse, etc.). Optional audio input / output component 605 may also be included to allow the user to use voice input information by converting audio signals. Audio I / O component 605 allows the user to listen to audio. Transceiver or network interface 606 sends and receives signals between computer system 600 and other devices (such as another communication device, service device, or service provider server) via network 150. In one embodiment, the transmission is wireless, although other transmission media and methods may also be suitable. One or more processors 612 (which may be a microcontroller, digital signal processor (DSP), or other processing component) process these various signals, such as for display on computer system 600 or for transmission to other devices via communication link 618. The processors 612 may also control the transmission of information, such as cookies or IP addresses, to other devices.

[0085] The computer system 600 also includes a system memory component 614 (e.g., RAM), a static storage device component 616 (e.g., ROM), and / or a disk drive 617. The computer system 600 performs specific operations by means of one or more processors 612 and other components by executing one or more sequences of instructions contained in the system memory component 614. The logic may be encoded in a computer-readable medium, which can refer to any medium that participates in providing instructions to the processors 612 for execution. Such a medium can take many forms, including but not limited to non-volatile media, volatile media, and transmission media. In various embodiments, non-volatile media include optical discs or magnetic disks, volatile media include dynamic memory such as the system memory component 614, and transmission media include coaxial cables, copper wires, and optical fibers, including cables forming bus 602. In one embodiment, the logic is encoded in a non-transitory computer-readable medium. In one example, the transmission medium may take the form of acoustic or optical waves, such as those generated during radio wave, optical, and infrared data communications.

[0086] Some common forms of computer-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tapes, any other magnetic media, CD-ROMs, any other optical media, punched cards, paper tapes, any other physical media with a perforated pattern, RAM, PROMs, EEPROMs, FLASH-EEPROMs, any other memory chips or cassettes, or any other media that a computer is adapted to read.

[0087] In various embodiments of this disclosure, the execution of the instruction sequence of this disclosure may be performed by computer system 600. In various other embodiments of this disclosure, multiple computer systems 600 coupled to a network (e.g., such as a LAN, WLAN, PTSN, and / or various other wired or wireless networks, including telecommunications, mobile, and cellular telephone networks) via communication link 618 may execute instruction sequences to practice this disclosure in a coordinated manner.

[0088] Where applicable, the various embodiments provided in this disclosure may be implemented using hardware, software, or a combination of hardware and software. Furthermore, where applicable, the various hardware and / or software components described herein may be combined into composite components including software, hardware, and / or both, without departing from the spirit of this disclosure. Where applicable, the various hardware and / or software components described herein may be divided into sub-components including software, hardware, or both, without departing from the scope of this disclosure. Furthermore, where applicable, it is contemplated that a software component may be implemented as a hardware component, and vice versa.

[0089] According to the software disclosed herein, program code and / or data may be stored on one or more computer-readable media. It is also contemplated that the software described herein may be implemented using one or more general-purpose or special-purpose computers and / or computer systems in a networked and / or other manner. Where applicable, the order of the various steps described herein may be changed, combined into compound steps, and / or separated into sub-steps to provide the features described herein.

[0090] The foregoing disclosure is not intended to limit this disclosure to the precise form or specific field disclosed. Therefore, it is contemplated that various alternative embodiments and / or modifications to this disclosure, whether expressly described or implied herein, are possible. After such description of embodiments of this disclosure, those skilled in the art will recognize that changes in form and detail may be made without departing from the scope of this disclosure. Therefore, this disclosure is limited only by the claims.

Claims

1. A system comprising: a non-transitory memory; and one or more hardware processors coupled to the non-transitory memory and configured to read instructions from the non-transitory memory to cause the system to perform operations comprising: receiving, from a payment processing network, a request to process a transaction using an account, wherein the request is received in response to a merchant device receiving a data transmission of proxy wallet data via short-range wireless communication; determining, from the request, an identifier that uniquely identifies the account at the payment processing network, wherein the identifier is usable to enable payment processing services using the account, and wherein the identifier is pre-de-tokenized from a token of the proxy wallet data; based on the identifier, determining that the account is registered to a digital wallet hosted by a digital wallet platform separate from the system, wherein the data transmission is performed using the digital wallet; identifying the account and an available payment balance of the account; and processing, by the payment processing network and based on the request and the available payment balance, the transaction for the merchant device using the account and the payment processing services.

2. The system of claim 1, wherein, the proxy wallet data emulates digital wallet data read from a short-range wireless transceiver of a mobile device, and wherein the proxy wallet data is based on the identifier, an encrypted one-time password, and a temporary public key associated with at least the payment processing services.

3. The system of claim 2, wherein, prior to receiving the request to process the transaction, the operations further comprising: detecting a request to add the account to the digital wallet; determining the proxy wallet data for the account; and sending the proxy wallet data to the digital wallet platform in association with the request to add the account to the digital wallet.

4. The system of claim 3, wherein, prior to sending the proxy wallet data, the operations further comprising: passing a request to add the account to the digital wallet platform; receiving, from the digital wallet platform, a public digital certificate having a random number and a digital signature of the random number; and providing, to a processor of the system, an API request associated with the public digital certificate, the random number, and the digital signature of the random number for association with the proxy wallet data.

5. The system of claim 3, wherein, prior to receiving the request to process the transaction, the operations further comprising: identifying, by a payment processor on the payment processing network, the account; in the digital wallet, associating a device account number with the identifier; and based on the device account number, activating, by the digital wallet and the payment processor, the payment processing services for the account.

6. The system of claim 1, wherein, the account is authorized for per-transaction based payments only when used via the digital wallet.

7. The system of claim 1, wherein, the merchant device comprises a merchant point-of-sale (POS) device comprising a communication module comprising at least one of an RFID reader, an NFC reader, a Bluetooth transceiver, or a WiFi transceiver, and wherein the communication module is used for the short-range wireless communication, which utilizes exchangeable tokens for processing via the payment processing network.

8. The system of claim 1, wherein, prior to processing the transaction, the operations further comprise: running a risk engine using the transaction and the account, the risk engine comprising at least a machine learning (ML)-based risk model or a rule-based risk ruleset; and based on a result of the running, determining whether the transaction meets a risk assessment requirement.

9. The system of claim 8, wherein, the operations further comprise: based on determining whether the transaction meets the risk assessment requirement, generating one of an approval or a denial of the transaction; and processing, by the merchant device, one of the approval or the denial via the payment processing network.

10. The system of claim 8, wherein, the payment processing service is associated with an installment service and verifies transactions of the account on a per-transaction basis via the payment processing service using the risk engine, wherein the available payment balance is associated with a time-period-based loan repayment schedule of the installment service for the account, and wherein the risk engine manipulates the transaction in accordance with the time-period-based loan repayment schedule.

11. A method comprising: receiving, by an online transaction processor from a payment processor on a payment network, a request to process a transaction using an account for the online transaction processor, wherein the request includes an identifier that uniquely identifies the account to the online transaction processor on the payment network, and wherein the request is de-tokenized from a token generated by a merchant device based on data received by the merchant device via short-range wireless communication with a mobile device; based on the identifier, determining that a digital wallet hosted by a digital wallet platform separate from the online transaction processor is used by the mobile device via the short-range wireless communication to the merchant device; based on the identifier, identifying the account and an available source of funds for the account; based on the digital wallet being separate from the online transaction processor, determining a payment processing service that enables processing of the transaction by the merchant device and the digital wallet platform; and based on the transaction and the available source of funds, performing one or more operations of the payment processing service.

12. The method of claim 11, further comprising: based on the request and the available source of funds, processing the transaction for the merchant device via the one or more operations of the payment processing service by the payment network.

13. The method of claim 12, wherein, prior to processing the transaction, the method further comprises: performing a risk engine, the risk engine comprising at least one of a rule-based model or a machine learning (ML)-based model; based on a result of the performing, determining a risk assessment of authorizing the account to use the available source of funds for the transaction; and determining whether the risk assessment meets a risk threshold of the authorization.

14. The method of claim 11, wherein, the one or more operations comprise at least one of a user authentication operation, an ML risk assessment operation, a rule-based risk assessment operation, an available balance inquiry for the account, a future balance forecast for the account, or an installment loan authorization for a payment associated with the transaction.

15. The method of claim 11, further comprising: determining that the transaction failed a risk assessment determined using a risk engine performing the one or more operations; and rejecting the transaction for processing on the payment network.

16. The method of claim 11, wherein, The payment processing service includes a buy now, pay later (BNPL) service that authorizes the transaction based on one or more risk models when the transaction is requested for processing via the short-range wireless communication.

17. The method of claim 11, wherein, Prior to receiving the request, the method further includes: generating the data for the account based on one or more public certificates and the identifier of the account; and sending the data with a request to add the account to the digital wallet to the digital wallet platform for payment processing using the payment processing service of the online transaction processor.

18. A non-transitory machine-readable medium having stored thereon machine-readable instructions executable to cause a machine to perform operations comprising: receiving a payment request for a transaction from a payment processing network, the payment request having an identifier for an account of an online transaction processor; determining that the transaction was generated by a merchant device in response to receiving a data transmission of a token associated with the identifier from a mobile device utilizing a digital wallet associated with the account via a short-range wireless communication, wherein the payment processing network is used by the merchant device to detokenize the token and route the identifier from the detokenized token to the online transaction processor for a payment processing service; determining the identifier from the payment request, wherein the identifier uniquely identifies the account for processing a payment via the payment processing service of the online transaction processor; based on the request and the identifier of the account, identifying the account and an available payment balance of the account; based on the identifier, determining that the digital wallet was used to generate the payment request with the data transmission via the short-range wireless communication and that the digital wallet is hosted by a digital wallet platform separate from the online transaction processor; and performing the payment processing service that processes the transaction using the account.

19. The non-transitory machine readable medium of claim 18, wherein, The operations further include: causing the identifier to be stored in the digital wallet by the digital wallet platform in association with the account, wherein the identifier is associated with an identification number of a financial institution associated with payment processing using the short-range wireless communication with a wireless terminal of the merchant device.

20. The non-transitory machine-readable medium of claim 19, wherein, The identifier is stored with an encrypted one-time password and a temporary public key associated with at least the payment processing service of the online transaction processor.

Images