System and method for card swiping transaction processing
By receiving checkout requests, determining TPAs, retrieving card information, and verifying access tokens, the problem of low efficiency in card transaction processing for FSA users in e-commerce systems has been solved. This enables efficient transaction processing without the need for manual card information input, improving both security and efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-14
- Publication Date
- 2026-04-03
AI Technical Summary
Existing e-commerce systems have failed to effectively address the need for Flexible Spending Account (FSA) users to avoid manually entering payment card information during card transactions, resulting in inefficient transaction processing.
By receiving a checkout request, the system determines whether the user has a third-party payment administrator (TPA), retrieves card information in a private session, and verifies the access token using an OAuth session, ensuring the security and validity of the card information and providing alternative payment methods to complete the transaction.
It enables efficient processing of FSA card transactions without requiring users to manually enter card information, improving transaction efficiency and security while reducing transaction processing complexity.
Smart Images

Figure CN121794705A_ABST
Abstract
Description
Cross-reference to related applications
[0001] This application claims the benefit of U.S. Provisional Application No. 63 / 581,284, filed on September 8, 2023, pursuant to Articles 4 and 8 of the Stockholm text of the Paris Convention for the Protection of Industrial Property, the contents of which are incorporated herein by reference in their entirety. Technical Field
[0002] This disclosure generally relates to e-commerce, and more specifically to e-commerce transactions in which users do not need to enter payment card credentials at any time, even if they complete a purchase using a card. Background Technology
[0003] A flexible spending account (FSA), also known as a flexible spending arrangement, is one of many tax-advantaged financial accounts that can save on payroll taxes. The most common type of flexible spending account is the medical expense FSA (also known as a health FSA or health FSA), which is similar to a health savings account (HSA) or health reimbursement account (HRA). Paper form or an FSA debit card can be used to access account funds. The FSA debit card was developed to eliminate “double-dipping” by allowing employees direct access to their FSA. It also simplified the verification requirements that would otherwise require labor-intensive claims processing. The debit card also enhanced the effectiveness of “pre-funded” health FSAs. However, the verification requirements themselves have not disappeared and have even been extended to the debit card environment by the Internal Revenue Service (IRS); therefore, the issue of exiting the FSA remains. Current e-commerce companies have developed websites specifically for FSA-compliant programs, but have failed to provide users with efficient transaction processing. Summary of the Invention
[0004] Based on the aspects described herein, a system and method are provided to facilitate purchase transaction processing without requiring users to manually enter payment card information.
[0005] In an exemplary embodiment, the method includes: receiving a checkout request; determining whether the user has a third-party administrator (TPA) for card payments; if the user has a third-party administrator for card payments, determining whether card information is available in a private session; if the card information is not available in the private session, retrieving the card information; and directing the card information to the private session.
[0006] In an exemplary embodiment, the step of retrieving card information includes: sending a request to the TPA for the card information and one or more access tokens corresponding to the user; and verifying that the one or more access tokens correspond to the user. In an exemplary embodiment, the method further includes: determining whether the card information was successfully retrieved before directing the card information to a private session. In an exemplary embodiment, the method further includes: determining that the card information was not successfully retrieved; and directing the user to provide an alternative payment method.
[0007] In an exemplary embodiment, the method further includes: if card information is available in a private session, determining whether the card information in the private session has expired. In an exemplary embodiment, the method further includes: if the card information in the private session has expired, sending a request to the TPA for the card information and one or more access tokens corresponding to the user; and verifying that one or more access tokens correspond to the user. In an exemplary embodiment, the method further includes: determining whether separate payment is required; and directing the user to a billing page. In an exemplary embodiment, the method further includes: deleting the card information from the private session (therefore never storing or "saving" the card for future use).
[0008] According to the aspects described herein, a computer system for facilitating card transaction processing is provided, comprising: one or more computer processors, one or more computer-readable storage media, and program instructions stored on the computer-readable storage media, the program instructions being executed by at least one of the one or more computer processors, the program instructions including: program instructions for receiving a checkout request; program instructions for determining whether a user has a card payment third-party administrator (TPA); program instructions for determining whether card information is available in a private session if the user has a card payment TPA; program instructions for retrieving card information if card information is not available in the private session; and program instructions for directing card information to the private session.
[0009] In an exemplary embodiment, the program instructions for retrieving card information include: program instructions to send a request to the TPA for the card information and one or more access tokens corresponding to the user; and program instructions to verify that one or more access tokens correspond to the user. In an exemplary embodiment, the program instructions further include: program instructions to determine whether the card information has been successfully retrieved before program instructions to direct the card information to a private session. In an exemplary embodiment, the program instructions further include: program instructions to determine that the card information has not been successfully retrieved; and program instructions to guide the user to provide an alternative payment method.
[0010] In an exemplary embodiment, the program instructions further include: program instructions to determine whether the card information in the private session has expired if the card information is available in the private session. In an exemplary embodiment, the program instructions further include: if the card information in the private session has expired, sending a request to the TPA for the card information and one or more access tokens corresponding to the user; and program instructions to verify that one or more access tokens correspond to the user. In an exemplary embodiment, the program instructions further include: program instructions to determine whether separate payment is required; and program instructions to redirect the user to a billing page. In an exemplary embodiment, the program instructions further include: program instructions to delete the card information from the private session.
[0011] According to the aspects described herein, a computer program product for facilitating card transaction processing is provided, comprising: a computer-readable storage medium and program instructions stored on the computer-readable storage medium, the program instructions including: program instructions for receiving a checkout request; program instructions for determining whether a user has a card payment third-party administrator (TPA); program instructions for determining whether card information is available in a private session if the user has a card payment TPA; program instructions for retrieving card information if card information is not available in the private session; and program instructions for directing card information to the private session.
[0012] In an exemplary embodiment, the program instructions for retrieving card information include: program instructions to send a request to the TPA for the card information and one or more access tokens corresponding to the user; and program instructions to verify that one or more access tokens correspond to the user. In an exemplary embodiment, the program instructions further include: program instructions to determine whether the card information has been successfully retrieved before program instructions to direct the card information to a private session. In an exemplary embodiment, the program instructions further include: program instructions to determine that the card information has not been successfully retrieved; and program instructions to guide the user to provide an alternative payment method.
[0013] These and other objects, features, and advantages of this disclosure will become apparent from the accompanying drawings and the appended claims, and from the following detailed description of this disclosure. Attached Figure Description
[0014] Various embodiments are disclosed by way of example only, with reference to the accompanying schematic diagrams, wherein corresponding reference numerals denote corresponding parts, wherein:
[0015] Figure 1 This is a functional block diagram illustrating an environment according to some embodiments of the present disclosure.
[0016] Figure 2 It is a flowchart describing the operational steps of processing a credit card transaction.
[0017] Figure 2A It is a flowchart describing the operational steps of processing a credit card transaction.
[0018] Figure 3 It is a flowchart describing the operational steps of processing a credit card transaction.
[0019] Figure 4 This is a block diagram of the internal and external components of a computer system according to exemplary embodiments of the present disclosure. Detailed Implementation
[0020] First, it should be recognized that the same reference numerals in different figures denote the same or similar structural elements. It should be understood that the claims are not limited to the disclosed aspects.
[0021] Furthermore, it should be understood that this disclosure is not limited to the specific methods, materials, and modifications described, and therefore variations are naturally possible. It should also be understood that the terminology used herein is for the purpose of describing particular aspects only and is not intended to limit the scope of the claims.
[0022] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It should be understood that any method, apparatus, or material similar to or equivalent to those described herein may be used in the practice or testing of the exemplary embodiments.
[0023] It should be recognized that the term "substantially" is synonymous with terms such as "almost," "very close," "approximately," "probably," "near," "close to," "more or less," "basically," "close to," and "in the vicinity," and these terms may be used interchangeably in the specification and claims. It should be recognized that the term "proximately" is synonymous with terms such as "nearby," "close to," "adjacent," "adjacent," "right next to," and "adjacent to," and these terms may be used interchangeably in the specification and claims. The term "probably" refers to a value within ten percent of the specified value.
[0024] It should be understood that, unless otherwise stated, the use of “or” in this application is a “non-exclusive” arrangement. For example, when saying “item x is A or B”, it should be understood that this can mean one of the following: (1) item x is only one or the other of A and B; (2) item x is both A and B. In other words, the word “or” is not used to define an “exclusive or” arrangement. For example, an “exclusive or” arrangement stating “item x is A or B” would require that x can only be one of A and B. Furthermore, as used herein, “and / or” is intended to be a grammatical conjunction used to indicate that one or more elements or conditions may be included or appear. For example, an apparatus including a first element, a second element, and / or a third element is intended to be interpreted as any of the following structural arrangements: an apparatus including a first element, an apparatus including a second element, an apparatus including a third element, an apparatus including a first element and a second element, an apparatus including a first element and a third element; an apparatus including a first element, a second element, and a third element, or an apparatus including a second element and a third element.
[0025] Furthermore, as used herein, the phrases “comprises at least one of” and “comprising at least one of” combined with a system or element are intended to express that the system or element comprises one or more elements listed after the phrase. For example, an apparatus comprising at least one of a first element, a second element, and a third element is intended to be interpreted as any of the following structural arrangements: an apparatus comprising a first element, an apparatus comprising a second element, an apparatus comprising a third element, an apparatus comprising a first element and a second element, an apparatus comprising a first element and a third element, an apparatus comprising a first element, a second element, and a third element, or an apparatus comprising a second element and a third element. When the phrase “for at least one” is used herein, it is intended to be interpreted similarly.
[0026] Now refer to the attached diagram, Figure 1 This is a functional block diagram of a card swipe transaction processing environment (typically designated as 100) according to an embodiment of the present disclosure. Figure 1This illustration only provides one embodiment and does not imply any limitation on the environments in which different embodiments can be implemented. Those skilled in the art can make many modifications to the depicted environment without departing from the scope of this disclosure as set forth in the claims. In an exemplary embodiment, environment 100 includes a user third-party administrator (TPA) 130, an open authentication (OAuth) provider 160, an application programming interface (API) 140, a health e-commerce (HEC) retailer or e-commerce retailer 150, and a computing device 180 connected to network 110. In an exemplary embodiment, environment 100 further includes a fraud and refund prevention module 170 connected to network 110. In an exemplary embodiment, network 110 further includes a user 120 capable of communicating with network 110.
[0027] Network 110 can be, for example, a local area network (LAN), a wide area network (WAN) (such as the Internet), or a combination of both, and can include wired, wireless, or fiber optic connections.
[0028] Computing device 180 may be a hardware device that receives user-related data and communicates with various entities and components to complete a purchase transaction without requiring the user to input card information (e.g., FSA debit card, credit card, HSA debit card, etc.) using card transaction processing procedure 182. Computing device 180 is capable of communicating with network 110, user 120, TPA 130, API 140, HEC 150, OAuth provider 160, and / or fraud detection module 170. In an exemplary embodiment, computing device 180 may include a computer. In an exemplary embodiment, as referenced... Figure 4 In further detail, computing device 180 may include internal and external hardware components. In an exemplary embodiment, a card transaction processing program 182 is implemented on a network server, which may be a management server, a web server, or any other electronic device or computing system capable of receiving and sending data. When accessed over a network, the network server may represent a computing system utilizing a cluster of computers and components as a single pool of seamless resources. In an exemplary embodiment, the network server may be hosted internally or by a third-party cloud service provider. (See also: [link to relevant documentation]). Figure 4 In further detail, a network server may include internal hardware components and external hardware components.
[0029] The card transaction processing program 182 can coordinate inputs from multiple entities (such as user 120, TPA 130, and HEC 150) and complete a purchase transaction for user 120 without requiring the user to manually enter card information. The card transaction processing program 182 typically includes any software capable of authenticating user information without requiring debit / credit card information input and can communicate via network 110 with user 120, TPA 130, API 140, HEC 150, OAuth 160, fraud protection module 170, and / or card processing platform 190 to receive real-time data from various entities and components.
[0030] A TPA 130 is an organization that manages FSA, HSA, or similar tax-advantaged consumer-driven health plan (CDHP) accounts, processes claims, or handles certain aspects of individual entity employee benefit plans. In an exemplary embodiment, the TPA 130 is an administrator of an FSA, HSA, or similar tax-advantaged CDHP account.
[0031] API 130 is an application programming interface that allows two or more computer programs to communicate with each other. API 130 is a software interface that provides services to other software. In an exemplary embodiment, API 130 includes a programming interface built using the MULESOFT® integration platform.
[0032] HEC 150 is a health e-commerce retailer whose products are eligible for purchase using an FSA, HAS, or similar tax-advantaged CDHP account. In an exemplary embodiment, e-commerce retailer 150 is any e-commerce seller of the product.
[0033] OAuth 160 is an open standard authorization protocol or framework that provides applications with the ability to securely specify access. OAuth 160 does not share password data; instead, it uses an authorization token to verify the identity between user 120 and HEC 150. OAuth 160 is an authentication protocol that allows a user to authorize an application to interact with another application on their behalf without revealing the user's password. Specifically, OAuth 160 authenticates user 120's identity via TPA 130 to conduct transactions using HEC 150.
[0034] Fraud protection module 170 utilizes behavioral analysis, resilient links, proxy detection, and / or machine learning to detect and prevent fraud and refunds. In an exemplary embodiment, fraud protection module 170 includes RiskFied® fraud protection software.
[0035] The card processing platform 190 is operable to provide, in particular, secure and immediate delivery of new or replacement card credentials to secure applications. In an exemplary embodiment, the card processing platform 190 includes Fidelity National Information Service (FIS) financial services technology.
[0036] Figure 2 A flowchart 200 is shown, describing the steps involved in processing a credit card transaction.
[0037] In step 202, the card transaction processing procedure 182 displays the TPA portal. In an exemplary embodiment, the TPA portal is displayed via TPA 130.
[0038] In step 204, the card transaction processing procedure 182 receives input from user 120. For example, user 120 may click the link presented in step 202 to provide consent and initiate the process. In an exemplary embodiment, the input submitted by user 120 occurs in a TPA entry provided by TPA 130.
[0039] In step 206, the transaction processing procedure 182 sends the status generated by HEC 150 to the OAuth provider 160. In an exemplary embodiment, the transaction processing procedure 182 directs user 120 to an e-commerce platform that allows user 120 to access HEC 150 and shop on HEC 150. In an exemplary embodiment, the e-commerce platform includes Salesforce Commerce Cloud (SFCC). HEC 150 utilizes SFCC to facilitate user authentication, e-commerce, and product purchases.
[0040] In step 208, the transaction processor 182 creates an OAuth session, generates a temporary code, and sends the temporary code from the OAuth provider to HEC 150 (e.g., SFCC). The OAuth session is created to handle authorization and token endpoints. The transaction processor 182 uses the OAuth session to authorize devices, API 140, servers, and applications with access tokens instead of credentials. In an exemplary embodiment, in additional step 210, the transaction processor 182 processes the OAuth session created in step 208 (e.g., via TPA 130). In step 210, the OAuth provider 160 authenticates the connection between HEC retailer 150 and TPA 130, enabling TPA 130 to process the connection request.
[0041] In step 212, the card transaction processing program 182 receives a temporary code and the corresponding credentials (i.e., credentials associated with user 120), and retrieves an authentication token based on this.
[0042] In step 214, the card transaction processing procedure 182 receives the authentication token and creates an initial user information request. In an exemplary embodiment, the initial user information request is created only if the user information is not stored in the authentication token. In an exemplary embodiment, the initial user information request is generated by HEC 150.
[0043] In step 216, the card transaction processing procedure 182 sends a user information request to the TPA 130 (or sends the user information if it is stored in the authentication token).
[0044] In step 218, the card transaction processor 182 initiates the verification of the authentication token. In an exemplary embodiment, the authentication token is verified via OAuth provider 160.
[0045] In step 220, the card transaction processing procedure 182 directs the storage of user information in the consumer profile. In an exemplary embodiment, the user information is sent from TPA 130 to HEC 150.
[0046] In step 222, the card transaction processing program 182 redirects user 120 to the login page.
[0047] In step 224, the card transaction processing procedure 182 receives input from user 120 related to the selection of purchased products. For example, in step 224, user 120 browses the website of retailer HEC 150 and adds products to the shopping cart for purchase.
[0048] In step 226, the card transaction processing program 182 receives input from user 120 to proceed with checkout. The process then proceeds to checkout, which will be described below. Figure 3 The flowchart in section 300 describes this process.
[0049] After the checkout process, in step 228, the card transaction processing program 182 generates an order for the products purchased by user 120.
[0050] In step 230, the card transaction processing program 182 generates an order confirmation. In an exemplary embodiment, the card transaction processing program 182 displays the order confirmation and / or sends the order confirmation to the user 120.
[0051] In an exemplary embodiment, after step 228, in step 232, the card transaction processing program 182 guides the created order through the fraud protection module 170, which uses behavioral analysis, resilient links, proxy detection and / or machine learning to detect and prevent fraud.
[0052] In step 232, if the card transaction processing procedure 182 determines that there is no fraud, then in step 234, the card transaction processing procedure 182 fulfills the order and sends an order confirmation.
[0053] In step 232, if the transaction processing procedure 182 determines that fraud has occurred, then in step 236, the transaction processing procedure 182 rejects and cancels the order. In an exemplary embodiment, the transaction processing procedure 182 further notifies the user 120 that fraud has been detected and / or the order has been rejected. In an exemplary embodiment, the transaction processing procedure 182 further reports the existence of detected fraud. In an exemplary embodiment, the transaction processing procedure 182 further stores data indicating that fraud has been detected in association with user information.
[0054] Figure 2A A flowchart 250 is shown, describing the operational steps of a login process. In an exemplary embodiment, flowchart 250 depicts the operational steps of a login process via security assertion markup language (SAML), which allows the identity provider (IDP) to pass authorization credentials to the service provider.
[0055] In step 252, the transaction processing procedure 182 receives input, such as a request for login or login credentials, or an assertion. For example, user 120 may click a link to initiate the process. In an exemplary embodiment, the input is submitted by user 120 and occurs in a TPA entry provided by TPA 130. In an exemplary embodiment, the transaction processing procedure 182 directs the request to HEC 150 and / or the SAML input controller. In an exemplary embodiment, the assertion is an encrypted Extensible Markup Language (XML) package that is decrypted, verified, and processed. In an exemplary embodiment, the assertion may include a name, email address, member ID, and / or patient ID. The transaction processing procedure 182 processes the assertion and decrypts the encrypted XML package therein.
[0056] In step 254, the card transaction processing program 182 determines whether the decryption of the processing assertion was successful.
[0057] In step 254, if the transaction processing procedure 182 determines that the decryption of the processing assertion was unsuccessful, then in step 256, the transaction processing procedure 182 indicates an error. In an exemplary embodiment, the transaction processing procedure 182 directs the user 120 to a website for shopping and purchasing items (e.g., an FSA store website) and displays a message / pop-up window indicating that an error has occurred. In an exemplary embodiment, the transaction processing procedure 182 displays a query to the user to 1) continue shopping, or 2) return to the TPA's entry point and try logging in again.
[0058] In step 254, if the card transaction processing program 182 determines that the decryption of the processing assertion was successful, then in step 258, the card transaction processing program 182 determines whether the assertion contains valid XML.
[0059] In step 258, if the transaction processing procedure 182 determines that the assertion does not contain valid XML, then in step 256, the transaction processing procedure 182 indicates an error, for example as described above.
[0060] In step 258, if the transaction processing procedure 182 determines that the assertion contains valid XML, then in step 260, the transaction processing procedure 182 continues with the file flow or file authentication, for example, directing user 120 to an e-commerce platform (e.g., SFCC), as described above regarding step 206 of flowchart 200, as described above regarding... Figure 3 As stated above.
[0061] In step 262, the card transaction processing procedure 182 performs balance processing or balance authentication, for example, using at least one of API 140, HEC 150, OAuth provider 160 and TPA 130 to authenticate the balance of user 120.
[0062] In step 264, the card transaction processing procedure 182 directs user 120 to a website for shopping and purchasing items (e.g., an FSA store website). In an exemplary embodiment, the website is provided by HEC retailer 150.
[0063] Figure 3 A flowchart 300 is shown, describing the steps involved in processing a credit card transaction (i.e., checkout processing).
[0064] In step 302, the card transaction processing procedure 182 directs user 120 to pay directly. For example, user 120 may be directed to the checkout page on HEC 150.
[0065] In step 304, the card transaction processing procedure 182 determines the amount of payment required after applying any store points (i.e., the user's balance).
[0066] In step 306, the card transaction processing program 182 checks the user's balance. In an exemplary embodiment, the card transaction processing program 182 checks the updated account balance retrieved from the TPA 130 and displays the account balance to the user 120.
[0067] In step 308, the card transaction processing procedure 182 determines whether the user 120 has a card payment TPA.
[0068] In step 308, if the card transaction processing program 182 determines that user 120 has a card payment TPA, then in step 310, the card transaction processing program 182 determines whether user 120's credit card / debit card information is available.
[0069] In step 310, if the transaction processing program 182 determines that the credit card / debit card information of user 120 is unavailable, then in step 314, the transaction processing program 182 requests the credit card / debit card information.
[0070] In step 310, if the card transaction processing program 182 determines that the credit card / debit card information of user 120 can be obtained from the card processing platform 190, then in step 312, the card transaction processing program 182 determines whether the obtainable credit card / debit card information has expired.
[0071] In step 312, if the transaction processing procedure 182 determines that the available credit / debit card information is expired, then in step 314, the transaction processing procedure 182 requests the credit / debit card information.
[0072] In step 312, if the card transaction processing procedure 182 determines that the available credit / debit card information has not expired, then in step 328, the card transaction processing procedure 182 determines whether separate payments are required.
[0073] In step 308, if the card transaction processing program 182 determines that the user 120 does not have a card payment TPA, then in step 328, the card transaction processing program 182 determines whether separate payment is required.
[0074] In step 316, the transaction processing procedure 182 initiates a credit / debit card information request from the card processing platform 190 or TPA 130 via the card information (info) API. If the card information is not obtained from the card processing platform 190 or TPA 130 for any reason, the transaction processing procedure 182 will attempt to obtain the information again via the retry mode API.
[0075] In step 318, the card transaction processing program 182 receives the user's card information from the card processing platform 190 or TPA 130 via its card API.
[0076] In step 320, the card transaction processing procedure 182 obtains and uses a security token (e.g., a bearer token or access credential) to securely retrieve card information. In an exemplary embodiment, the card transaction processing procedure 182 uses a security token previously obtained from the TPA 130 or the card processing platform 190 as a bearer token or credential to securely request card information and prevent unauthorized access to the card information.
[0077] In step 322, the card transaction processing procedure 182 determines whether the credit card / debit card information has been successfully retrieved.
[0078] In step 322, if the transaction processing procedure 182 determines that the credit card / debit card information has been successfully retrieved, then in step 324, the transaction processing procedure 182 inputs the encrypted credit card / debit card information into the private session response for quick lookup. For example, the transaction processing procedure 182 can put the encrypted card response into session privacy and quickly look it up within the plain text validity period.
[0079] In step 322, if the transaction processing program 182 determines that the credit card / debit card information was not successfully retrieved, then in step 326, the transaction processing program 182 redirects the user 120 to regular checkout without direct payment. In an exemplary embodiment, the transaction processing program 182 may further display a message that direct payment is unavailable and guide the user 120 to use an alternative payment method for checkout.
[0080] In step 328, if the card transaction processing procedure 182 determines that separate payments are not required, then in step 330, the card transaction processing procedure 182 directs the user 120 to a billing page with only direct payments.
[0081] In step 328, if the transaction processing procedure 182 determines that separate payments are required, then in step 334, the transaction processing procedure 182 directs the user 120 to a billing page with direct payment and additional payment methods. For example, in step 334, the user 120 can pay part of the balance using direct payment and the remaining balance using a separate credit card.
[0082] In step 332, the card transaction processing program 182 receives input from user 120 to submit an order.
[0083] In step 334, the card transaction processing program 182 processes the payment using the direct payment card swipe settings.
[0084] In step 336, the card transaction processing procedure 182 decrypts the credit card information from a private session (e.g., session privacy) into the basket.
[0085] In step 338, the card transaction processing program 182 executes the transaction through a payment processing module that verifies the payment method. In an exemplary embodiment, the payment processing module may include TEMPUSTECHNOLOGIES™ secure payment technology or a similar card processing platform. In step 338, the card transaction processing program 182 obtains approval for the payment using card information from a basket of private sessions. If the payment method is rejected, the user 120 is routed to an alternative payment method.
[0086] In step 338, if the transaction processing program 182 receives approval for the payment method from the payment processing module, then in step 340, the transaction processing program 182 deletes the credit / debit card information from the private session (e.g., session privacy). Processing then proceeds to step 228, where an order is created (see...). Figure 2 (and the above explanation).
[0087] It should be recognized that other payment methods can be used. For example, user 120 can pay using a credit card or debit card by manually entering card information in steps 342 and 344. In an exemplary embodiment, user 120 can use store points to pay in step 350. In an exemplary embodiment, user 120 can use the direct payment swipe option to pay in steps 346 and 348, wherein the user's associated credit / debit card information is not retrieved, and this information is not required to complete the payment process.
[0088] Figure 4 A computing device 400 according to an exemplary embodiment of the present invention (representing...) Figure 1 A block diagram of the internal and external components of a computing device. It should be recognized that... Figure 4 The illustrations provided are merely one example of an implementation and do not imply any limitation on the environments in which different embodiments can be implemented. Figure 4 The components shown represent any electronic device capable of executing machine-readable program instructions. This can be achieved by... Figure 4Examples of computer systems, environments, and / or configurations represented by the components shown include, but are not limited to: personal computer (PC) systems, server computer systems, thin clients, fat clients, laptop computer systems, tablet computer systems, cellular phones (i.e., smartphones), multiprocessor systems, microprocessor-based systems, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices.
[0089] The computing device 400 includes a communication structure 402 that provides communication between one or more processing units 404, memory 406, permanent storage devices 408, communication units 410, and one or more input / output (I / O) interfaces 412. The communication structure 402 can be implemented by any architecture designed to transfer data and / or control information between processors (such as microprocessors, communication and network processors, etc.), system memory, peripheral devices, and any other hardware components within the system. For example, the communication structure 402 can be implemented using one or more buses.
[0090] Memory 406 and permanent storage device 408 are computer-readable storage media. In this embodiment, memory 406 includes random access memory (RAM) 416 and cache memory 418. Typically, memory 406 may include any suitable volatile or non-volatile computer-readable storage medium. Software is stored in permanent storage device 408 for execution and / or access by one or more respective processors 404 via one or more memories of memory 406.
[0091] Persistent storage device 408 may include, for example, multiple magnetic hard disk drives. Alternatively, or in addition to magnetic hard disk drives, permanent storage device 408 may include one or more solid-state hard disk drives, semiconductor storage devices, read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, or any other computer-readable storage medium capable of storing program instructions or digital information.
[0092] The media used in persistent storage device 408 can also be removable. For example, a removable hard disk drive can be used for persistent storage device 408. Other examples include optical discs and disks, thumb drives and smart cards, which are inserted into the drive to transfer data to another computer-readable storage medium that is also part of persistent storage device 408.
[0093] Communication unit 410 provides communication with other computer systems or devices via a network. In this exemplary embodiment, communication unit 410 includes a network adapter or interface (such as a Transmission Control Protocol (TCP) / Internet Protocol (IP) adapter card, a wireless Wi-Fi interface card, or a 3G, 4G, or 5G wireless interface card, or other wired or wireless communication links. The network may include, for example, copper wires, fiber optics, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. Software and data used to practice embodiments of this disclosure can be downloaded to computing device 400 via communication unit 410 (i.e., via the Internet, a local area network, or another wide area network). Software and data can also be loaded from communication unit 410 onto permanent storage device 408.
[0094] One or more I / O interfaces 412 allow data input and output with other devices that can be connected to computing device 400. For example, I / O interface 412 can provide connectivity to one or more external devices 420, such as a keyboard, computer mouse, touchscreen, virtual keyboard, touchpad, pointing device, or other human-computer interface devices. External devices 420 may also include portable computer-readable storage media, such as thumb drives, portable optical discs, or disks and memory cards. I / O interface 412 is also connected to display 422.
[0095] The display 422 provides a mechanism for users to display data and can be, for example, a computer monitor. The display 422 can also be an integrated display and can be used as a touchscreen, such as the built-in display of a tablet computer.
[0096] This invention can be a system, method, and / or computer program product. The computer program product may include a computer-readable storage medium (or medium) having computer-readable program instructions thereon for causing a processor to execute aspects of this disclosure.
[0097] Computer-readable storage media can be tangible devices that retain and store instructions used by instruction execution devices. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanical encoding devices (such as punched cards or raised structures in recesses on which instructions are recorded), and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.
[0098] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network) to an external computer or external storage device. The network may include copper transmission cables, optical fiber transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the corresponding computing / processing device.
[0099] The computer-readable program instructions used to perform the operations of this invention may be assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, etc., and conventional programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)) or may be connected to an external computer (e.g., via the Internet through an Internet service provider). In exemplary embodiments, electronic circuits (e.g., including programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs)) can execute computer-readable program instructions by utilizing state information of computer-readable program instructions to personalize the electronic circuits, thereby performing aspects of this disclosure.
[0100] This document describes aspects of the invention with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.
[0101] These computer-readable program instructions can be provided to the processor of a general-purpose computer, special-purpose computer, or other programmable data processing device to produce a machine, such that the instructions, which execute through the processor of the computer or other programmable data processing device, can create tools for implementing the functions / actions specified in the flowcharts and / or block diagrams. These computer-readable program instructions can also be stored in a computer-readable storage medium that can direct a computer, programmable data processing device, and / or other equipment to operate in a particular manner, such that the computer-readable storage medium storing the instructions includes an article of manufacture comprising instructions that implement aspects of the functions / actions specified in one or more blocks of the flowcharts and / or block diagrams.
[0102] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing mechanism or other device to cause a series of operational steps to be performed on the computer, other programmable mechanism or other device, thereby producing computer-implemented processing, such that the instructions, which are executed on the computer, other programmable mechanism or other device, implement the functions / actions specified in one or more blocks of a flowchart and / or block diagram.
[0103] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, fragment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a non-consecutive order. For example, two blocks shown consecutively may actually execute substantially simultaneously, or these blocks may sometimes execute in reverse order, depending on the functions involved. It will also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a system based on dedicated hardware that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.
[0104] It should be recognized that the various aspects of the above disclosure, as well as other features and functions or alternatives thereof, can be combined with many other different systems or applications as needed. Those skilled in the art can then make various substitutions, modifications, variations, or improvements thereto that are not currently foreseen or anticipated, and these are also intended to be covered by the claims. Reference figures 100 credit card transaction processing environment 110 Network 120 users 130 Third-Party Administrators (TPA) 140 Application Programming Interface (API) 150 Health E-commerce (HEC) Retailers 160 Open Authentication (OAuth) Provider 170 Fraud Protection Module 180 computing devices 182 Credit Card Transaction Processing Procedure 190 Card Processing Platform 200 Flowchart Steps 202-236 250 Flowchart Steps 252-264 300 Flowchart Steps 302-350 400 computing devices 402 communication structure 404 processing unit 406 memory 408 Permanent Storage Device 410 Communication Unit 412 Input / Output (I / O) Interface 416 Random Access Memory (RAM) 418 Cache Memory 420 external devices 422 monitor
Claims
1. A method for facilitating credit card transaction processing, comprising: Receive checkout request; Determine if the user has a third-party administrator (TPA) for card payment; If the user has a card payment TPA, determine whether the card information is available in a private session; If the card information is not available in the private session, then retrieve the card information; as well as The card information is directed to the private session.
2. The method according to claim 1, wherein, The steps for retrieving the card information include: Send a request to the TPA for card information and one or more access tokens corresponding to the user; and Verify that the one or more access tokens correspond to the user.
3. The method according to claim 1, further comprising: Before directing the card information to the private session, it is determined whether the card information has been successfully retrieved.
4. The method of claim 3, further comprising: It has been determined that the card information was not successfully retrieved; as well as Guide the user to provide alternative payment methods.
5. The method of claim 1, further comprising: If the card information is available in the private session, then determine whether the card information in the private session has expired.
6. The method of claim 5, further comprising: If the card information in the private session expires, a request for the card information and one or more access tokens corresponding to the user is sent to the TPA. as well as Verify that the one or more access tokens correspond to the user.
7. The method of claim 1, further comprising: Determine whether separate payments are required; as well as The user is then directed to the billing page.
8. The method of claim 1, further comprising: Delete the card information from the private session.
9. A computer system for facilitating card transaction processing, comprising: One or more computer processors; One or more computer-readable storage media; Program instructions stored on the computer-readable storage medium, the program instructions being executed by at least one of the one or more computer processors, the program instructions comprising: Program instructions for receiving checkout requests; Determine whether the user has the program instructions for a third-party administrator (TPA) for card payment; If the user has a card payment TPA, then determine whether the card information is available in a private session using program instructions. If the card information is not available in the private session, then program instructions for retrieving the card information; and The program instructions that direct the card information to the private session.
10. The computer system according to claim 9, wherein, The program instructions for retrieving the card information include: A program instruction to send a request to the TPA for card information and one or more access tokens corresponding to the user; and The program instructions that verify the one or more access tokens corresponding to the user.
11. The computer system according to claim 9, wherein, The program instructions further include: A program instruction that determines whether the card information has been successfully retrieved before directing the card information to the private session.
12. The computer system according to claim 11, wherein, The program instructions further include: The program instruction to determine that the card information was not successfully retrieved; and The program instructions guide the user to provide alternative payment methods.
13. The computer system according to claim 9, wherein, The program instructions further include: If the card information is available in the private session, then the program instruction determines whether the card information in the private session has expired.
14. The computer system according to claim 13, wherein, The program instructions further include: If the card information in the private session expires, a program instruction is sent to the TPA requesting the card information and one or more access tokens corresponding to the user; and The program instructions that verify the one or more access tokens corresponding to the user.
15. The computer system according to claim 9, wherein, The program instructions further include: Procedure instructions to determine whether separate payments are required; and The program instructions that direct the user to the billing page.
16. The computer system according to claim 9, wherein, The program instructions further include: Program instructions to delete the card information from the private session.
17. A computer program product for facilitating card transaction processing, comprising: A computer-readable storage medium and program instructions stored on the computer-readable storage medium, the program instructions comprising: Program instructions for receiving checkout requests; Determine whether the user has the program instructions for a third-party administrator (TPA) for card payment; If the user has a card payment TPA, then determine whether the card information is available in a private session. If the card information is not available in the private session, then program instructions for retrieving the card information; and Program instructions to direct the card information to the private session.
18. The computer program product according to claim 17, wherein, The program instructions for retrieving the card information include: A program instruction to send a request to the TPA for card information and one or more access tokens corresponding to the user; and The program instructions that verify the one or more access tokens corresponding to the user.
19. The computer program product according to claim 17, wherein, The program instructions further include: A program instruction to determine whether the card information has been successfully retrieved before directing the card information to the private session.
20. The computer program product according to claim 19, wherein, The program instructions further include: The program instruction to determine that the card information was not successfully retrieved; and The program instructions guide the user to provide alternative payment methods.