Description:TECHNICAL FIELD
[0001] The present disclosure relates to the field of payment processing systems. More particularly, a system to manage transactions during availability and unavailability of an internet connection, and a method thereof.

BACKGROUND
[0002] Background description includes information that may be useful in understanding the present disclosure. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed disclosure, or that any publication specifically or implicitly referenced is prior art.
[0003] The field of electronic payment processing has grown significantly over recent decades, spurred by the increasing reliance on card-based transactions across diverse commercial sectors. Point-of-sale systems or embedded payment system, which serve as interfaces between consumers and financial institutions, now operate in environments that can demand both real-time connectivity and robust offline capabilities. As these systems evolve, they are required to support secure data capture, authorization, and transaction settlement processes. Such environments naturally necessitate strategies that maintain operational reliability whether or not continuous network connectivity is available. The dynamic nature of the processes has spurred ongoing exploration into methods that can better integrate various functional aspects to support the seamless processing of transactions.
[0004] In numerous commercial applications, there is a clear goal to enhance transaction efficiency while upholding rigorous standards of security. Merchants and financial service providers strive to ensure that payment systems remain reliable even under challenging conditions, such as intermittent connectivity or heavy transactional loads. To achieve this, solutions are often designed with multiple layers of validation and fallback strategies that protect against potential errors or interruptions. Primary objectives include maintaining a smooth customer experience, preventing transactional delays, and ensuring strong adherence to security protocols. In addition, clear and consistent transaction logging and reconciliation are regarded as critical components for sustaining operational integrity across differing modes of transaction processing.
[0005] Despite numerous efforts to create resilient transaction processing systems, broad challenges persist in maintaining continuous service during periods of connectivity disruption. Systems that rely solely on real-time communication can experience interruptions that negatively affect transaction authorization, while existing backup methods may not fully address all authorization or risk management challenges. The interplay between various operational modes can result in inconsistencies, particularly when transitioning between centralized online processes and localized offline assessments. Such conditions may lead to delays or discrepancies in account validation and risk evaluation. The gap in operational continuity underscores the need for enhanced approaches that can bridge service interruptions and deliver consistent, secure transactions regardless of network conditions.
[0006] More specifically, reconciling the discrepancies between online and offline transaction handling presents a formidable challenge. When network connectivity is lost, systems are required to autonomously manage transaction data while continuing to enforce rigorous authentication and risk assessment criteria. This independent handling can complicate the detection and resolution of outstanding balances, as well as the consistent application of promotional or risk-based rules. Furthermore, without the benefit of real-time system-wide feedback, offline modules may struggle to adapt to swiftly changing risk environments. These challenges emphasize the importance of innovations that can seamlessly integrate intelligent local assessment with centralized processing, ensuring that all transactions, whether processed online or offline, adhere to comprehensive security and operational standards.
[0007] Patent document, “EP 2,281,272 A1” titled “Apparatus, method and system for facilitating payment of monetary transactions” discloses an apparatus, method and system for facilitating payment of a monetary transaction using a card device, the card device comprising a microchip for storing encrypted information including a plurality of selectable digital notes and/or a plurality of selectable digital coins associated with a plurality of selectable denominations and a denomination non-specific balance, wherein the card device is rechargeable with further monetary amounts and allows a balance of a transaction to be credited to the card.
[0008] Hence, in view of the aforementioned challenges and shortcomings in prior art, there is a dire need in the art to a system and a method of managing transactions during availability and unavailability of an internet connection.

OBJECTS OF THE PRESENT DISCLOSURE
[0009] Some of the objects of the present disclosure, which at least one embodiment herein satisfies are as listed herein below.
[0010] It is a general object of the present disclosure to overcome the limitations of existing systems of payment processing systems.
[0011] It is an object of the present disclosure is to provide a system and a method of managing transactions during availability and unavailability of an internet connection.
[0012] It is another object of the present disclosure to provide a system and a method that dynamically transitions between online and offline modes, ensuring uninterrupted transaction processing.
[0013] Yet another object of the present disclosure is to provide a system and a method that bi-directional synchronizes fraud rules between local and central systems reduces fraud risks and improves transaction security.
[0014] Yet another object of the present disclosure to provide a system and a method that allow blocking of fraud transactions by analyzing a set of features extracted from payment data and assess entitlement of a payment instrument to a predefined benefit or promotion based on eligibility metrics.

SUMMARY
[0015] Within the scope of this application, it is expressly envisaged that the various aspects, embodiments, examples, and alternatives set out in the preceding paragraphs, in the claims and/or in the following description and drawings, and in particular the individual features thereof, may be taken independently or in any combination. Features described in connection with one embodiment are applicable to all embodiments unless such features are incompatible.
[0016] Aspects of the present disclosure relate to the field of payment processing systems. More particularly, a system to manage transactions during availability and unavailability of an internet connection, and a method thereof.
[0017] In an aspect, the system may be implemented to manage a transaction request during both availability and unavailability of an internet connection. The system may include a memory to store a set of instructions and a processor to execute the instructions. Upon receiving a transaction request, the system may capture payment data associated with a payment instrument. The system may determine whether an internet connection is available at a point-of-sale terminal. In the absence of an internet connection, the processor may invoke an offline evaluation model to assess the eligibility of the transaction request based on predefined offline authorization criteria. The offline evaluation model may analyze the payment data to extract a set of features and may approve or deny the transaction request based on the criteria.
[0018] In an aspect, when a transaction request is approved during offline mode, the system may store the request in a queue for deferred transmission and may send the queued request to a server once the internet connection is restored. The system may support various types of payment data, including tokenized card data, hashed card data, and non-encrypted card data, and may support multiple forms of payment instruments such as credit cards, debit cards, prepaid cards, digital wallets, and mobile payment tokens.
[0019] In such aspect, the system may also log denied transaction attempts and may update the offline evaluation model based on feedback from the authorization result of the queued requests. The system may further store and analyze promotion eligibility metrics to evaluate promotional offers during offline processing and may display eligible promotions to the user through a display panel.
[0020] In an aspect, the offline evaluation model may map extracted features against fraud detection criteria to further determine transaction approval or denial and may store records of declined transactions for future reference.
[0021] In yet another aspect, the processor (106) is further configured to process the transaction request by transmitting the captured payment data to a payment gateway for real-time authorization when internet connectivity is available.
[0022] Various objects, features, aspects, and advantages of the inventive subject matter will become more apparent from the following detailed description of preferred embodiments, along with the accompanying drawing figures in which like numerals represent like components.

BRIEF DESCRIPTION OF DRAWINGS
[0023] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale; emphasis is instead placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that the disclosure of such drawings includes the disclosure of electrical components, electronic components or circuitry commonly used to implement such components.
[0024] FIG. 1 illustrates an exemplary representation of a block diagram of a system to manage a transaction request during availability and unavailability of an internet connection, in accordance with an exemplary embodiment of the present disclosure.
[0025] FIG. 2 illustrates an exemplary representation of a flow chart that illustrates a method of managing a transaction request during the availability and unavailability of an internet connection, in accordance with an exemplary embodiment of the present disclosure.
[0026] FIGs. 3 (A-B) illustrates exemplary representations of a flowchart illustrating a standard payment processing sequence in online environment, and a step-by-step illustration of current offline process flow diagram, in accordance with an exemplary embodiment of the present disclosure.
[0027] FIG. 4 illustrates exemplary representations of a flowchart illustrating payment transactions with the proposed system, in accordance with an exemplary embodiment of the present disclosure.
[0028] FIGs. 5 (A-B) illustrates an exemplary representation of flow diagrams illustrating card fraud detection, prevention, and retrieval during online environment, and offline Bank Identification Number (BIN), hashed card number, or tokenized number-based promotions check, in accordance with an exemplary embodiment of the present disclosure.
[0029] Other objects, advantages, and novel features of the disclosure will become apparent from the following more detailed description of the present embodiment when taken in conjunction with the accompanying drawings.

DETAILED DESCRIPTION
[0030] The following is a detailed description of embodiments of the disclosure depicted in the accompanying drawings. The embodiments are in such detail as to clearly communicate the disclosure. However, the amount of detail offered is not intended to limit the anticipated variations of embodiments; on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure as defined by the appended claims.
[0031] The present disclosure relates to the field of payment processing systems. More particularly, a system to manage transactions during availability and unavailability of an internet connection, and a method thereof.
[0032] Hereinafter, exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings FIGs. 1-5.
[0033] FIG. 1 illustrates an exemplary representation of a block diagram (100) of a system (102) to manage a transaction request during the availability and unavailability of an internet connection, in accordance with an exemplary embodiment of the present disclosure.
[0034] In an embodiment of the present disclosure, the system (102) can include a memory (104) and a processor (106), wherein the memory (104) can store a set of executable instructions, and the processor (106) can be connected to the memory (104). The processor (106), upon executing the stored instructions, can enable the system (102) to manage transaction requests during both availability and unavailability of an internet connection at a point-of-sale (POS) terminal (114). The system (102) can be configured to receive a transaction request initiated when a customer presents a payment instrument at the POS terminal (114). The payment instrument can include but is not limited to, a magnetic stripe card, EMV chip card, contactless card, or a mobile wallet application. In response to receiving the transaction request, the processor (106) can capture payment data from the payment instrument. The captured payment data can include card number, cardholder name, expiry date, cryptographic authorization values, and terminal identification details.
[0035] In an embodiment, the processor (106) can further determine the availability of an internet connection at the POS terminal. In a scenario where the internet connection is available, the processor (106) can be configured to transmit the captured payment data to a payment gateway or a remote transaction server for standard authorization. However, upon detecting the absence of an internet connection, the processor (106) can invoke an offline evaluation model (106-1). The offline evaluation model (106-1) can be implemented to assess the eligibility of the transaction request in accordance with a predefined set of offline authorization criteria. The offline authorization criteria can be configured in advance by a merchant, payment processor, or card issuer based on acceptable risk levels and transaction thresholds.
[0036] In an exemplary implementation of the embodiment, the offline evaluation model (106-) can include but is not limited to, a rule-based decision engine, Artificial Intelligence (AI) model, Machine Learning (ML) model trained on historical transaction data, or Heuristic-based scoring system.
[0037] In such embodiment, the offline evaluation model (106-1) can analyze the captured payment data to extract a set of features that may include, by way of example, transaction amount, previous transaction patterns, terminal behavior history, time of transaction, and cardholder usage frequency. The extracted set of features can then be mapped against the predetermined offline authorization criteria to determine the eligibility of the transaction request. When the extracted features satisfy the offline authorization criteria, the offline evaluation model (106-1) can approve the transaction request. If the extracted features fail to meet the offline authorization criteria, the offline evaluation model (106-1) can deny the transaction request. For the transaction requests that are approved in the offline mode, the processor (106) can store such approved requests in a queue for deferred transmission.
[0038] In such embodiment, the queue can be stored within the memory (104) or on a secure local storage medium integrated with the system (102). Upon restoration of the internet connection, the processor (106) can transmit the queued transaction request to a server (108) for subsequent authorization and processing. The server (108) can represent a backend system of the acquiring bank, that is responsible for validating, and settling the transaction. In an embodiment, the system (102) can be implemented at retail points-of-sale located in remote or mobile environments where internet connectivity may be intermittent. The ability of the system (102) to perform eligibility assessments and queue management during offline conditions can allow the merchant to continue accepting transactions without interruption while maintaining compliance with predefined authorization criteria.
[0039] In an embodiment, the payment data can include but not limited to tokenized card data, hashed card data, or non-encrypted card data, depending on the encryption and data protection mechanisms employed at the point-of-sale (POS) terminal. Tokenized card data can refer to a surrogate value replacing the original card number, while hashed card data can involve a one-way cryptographic transformation of the card details. Non-encrypted card data can consist of raw cardholder information collected in a secure manner at the POS terminal (114). Further, in an embodiment, tokenization can be happened at the server (108) and can be stored at the POS terminal (114) in case of card is black-listed or grey-listed based on offline authorization criteria.
[0040] In an embodiment, the payment instrument used to initiate the transaction can include, but is not limited to, credit card, debit card, prepaid card, smart card, digital wallet credential, and mobile payment token. Upon capturing the transaction request, the processor (106) can determine the status of internet connectivity and, in the absence of connectivity, can invoke the offline evaluation model (106-1). The offline evaluation model (106-1) can extract a set of transaction features from the payment data. The set of transaction features can include any or a combination of card issuer identification number (IIN), bank identification number (BIN), card number, tokenized card value, hash of the card number, transaction amount, merchant identifier (MID), and device identifier such as Terminal ID (TID) associated with the POS terminal. These features in combination with historical transaction data can serve as indicators of transaction behavior and origin, providing the basis for offline decision-making.
[0041] Further, the predetermined offline authorization criteria can include but are not limited to parameters such as offline transaction limit, floor limit associated with the payment instrument, the maximum number of allowed offline transactions, BIN range eligibility rule, blacklist entry, or grey list entry associated with the payment instrument, past due balance rule, and fraud risk threshold. For example, an offline transaction limit can define the maximum amount permitted in an offline state, while a floor limit can restrict certain card types from performing offline transactions entirely. BIN range eligibility rules can determine whether specific card types or issuers are permitted in offline mode. Blacklist or grey list entries can identify payment instruments that are temporarily or permanently restricted. The fraud risk threshold can assess the potential exposure associated with the transaction based on prior history or predictive scoring models.
[0042] In such embodiment, if the offline evaluation model (106-1) denies the transaction request due to a mismatch with the offline authorization criteria, the processor (106) can be further configured to log the denied transaction attempt without initiating any payment authorization. Such logs can be stored locally in the memory (104) or in an auxiliary secure storage associated with the system (102) to facilitate future audits or analytics. In an embodiment, the logs can be send to the server (108) and can be stored in centralized manner when the internet connection restored. Further, upon restoration of the internet connection, the processor (106) can transmit any previously approved transaction request to server (108) for final authorization and settlement. Based on the result of the authorization response received from the server (108), the offline evaluation model (106-1) and the predetermined offline authorization criteria can be updated. For instance, if an offline-approved transaction is later declined by the server (108), the offline evaluation model (106-1) can adjust its internal parameters to tighten future approval conditions. Likewise, successful offline approvals validated by the server (108) can reinforce confidence in the corresponding authorization criteria.
[0043] Such dynamic adaptation of the offline evaluation model (106-1) based on real-time feedback allows the system (102) to evolve in accordance with changing transaction risk profiles and operational realities. The overall configuration of the system (102), integrating real-time logging, conditional approval, deferred queuing, and adaptive learning, can facilitate secure, continuous transaction processing even in environments where internet access can be inconsistent or unavailable.
[0044] In such embodiment, the system (102) can further enhance transaction processing functionality by enabling promotional engagement in offline environments through the integration of a database (112) and a display panel (110). The processor (106) can be configured to store a set of promotion eligibility metrics in the database (112), wherein the promotion eligibility metrics can be derived from a set of attributes associated with the payment instrument. Such attributes can include card type, card issuer, frequency of usage, spending behavior, transaction amount, merchant category, and customer loyalty parameters. Upon capturing the payment data in response to a transaction request, the processor (106) can analyze the eligibility for a promotion by comparing the attributes of the captured payment data against the stored promotion eligibility metrics. When the analysis confirms that the payment instrument qualifies for a promotion, the processor (106) can display the eligible promotion to the user on the display panel (110). The display panel (110) can be integrated into the point-of-sale terminal and can present promotional content in the form of discounts, cashback, loyalty rewards, or voucher codes during the offline transaction approval phase.
[0045] In such embodiment, the offline evaluation model (106-1) can be further configured to evaluate transaction requests based not only on offline authorization criteria but also on a set of offline fraud detection criteria. The offline fraud detection criteria can be stored in the memory (104) or the database (112) and can define risk parameters associated with the transaction environment. The offline fraud detection criteria can include but are not limited to, behavioral patterns, historical chargeback indicators, device-level transaction anomalies, blacklisted identifiers, or frequency thresholds associated with specific cards or users.
[0046] In an exemplary implementation of the embodiment, the offline fraud detection criteria can further include but not limited to, known fraudulent card Bank Identification Numbers (BINs), identifiers of customers listed in a greylist or blacklist database, behavioral patterns associated with known fraudulent customers, behavioral patterns associated with known fraudulent users operating the POS terminal (114), known fraudulent payment data including card tokens, card hashes, or non-encrypted card numbers, offline transaction floor limits and per-BIN offline transaction limits, offline transaction limits based on customer profiles, user profiles, and transaction use cases, or a threshold for maximum allowable time since last synchronization with the server (108) and maximum transaction frequency from a same payment instrument.
[0047] The offline evaluation model (106-1) can analyze the extracted set of features from the captured payment data and map those features against the offline fraud detection criteria. The offline evaluation model (106-1) can approve the transaction request only when the offline fraud detection criteria are satisfied. If the offline evaluation model (106-1) determines that the transaction request does not meet the fraud detection criteria, the transaction can be declined. In such instances, the processor (106) can log the declined transaction request and store the logged record in the database (112) for further review or future analysis.
[0048] In such embodiment, in an online scenario where internet connectivity is available at the point-of-sale (POS) terminal, the processor (106) can be further configured to process the transaction request by transmitting the captured payment data to a payment gateway (308) for real-time authorization. The payment gateway (308) can serve as an intermediary that forwards the transaction request to a card network and subsequently to the issuing bank for authorization and approval. The response received from the issuing bank, whether an approval or a denial, can be returned through the same communication path and displayed on the point-of-sale terminal. This conditional routing mechanism allows the system (102) to dynamically adapt its behavior based on the real-time availability of the internet connection, thereby ensuring uninterrupted transaction processing through either the offline evaluation model (106-1) or standard online authorization channels.
[0049] In one embodiment, the processor (106) can be embedded within the point-of-sale (POS) terminal (114), thereby enabling local execution of the set of instructions without dependency on external computing devices. Such a configuration may allow for faster decision-making and uninterrupted transaction handling during periods of network unavailability. The offline evaluation model may also be locally deployed in the terminal, allowing immediate access to stored authorization criteria and enabling real-time processing of payment data.
[0050] In an alternative embodiment, the processor (106) can be positioned within a dedicated computing module connected to the point-of-sale terminal or embedded payment devices. over a local communication interface. In such a configuration, the point-of-sale terminal may capture the payment data and transfer it to the computing module for further processing. The computing module may invoke the offline evaluation model stored in its memory to assess the transaction eligibility and execute deferred transaction storage and later transmission upon restoration of the internet connection. The arrangement can be beneficial in environments where centralized management of transaction processing across multiple terminals is preferred.
[0051] In yet another embodiment, the processor may be located in a mobile payment device or smart accessory configured to communicate with the point-of-sale terminal. The payment device may process the transaction request locally and manage offline authorization independently. Upon detecting restored connectivity, the mobile payment device may transmit the queued transactions directly to the server one by one for final authorization, reducing the reliance on the terminal for post-processing.
[0052] FIG. 2 illustrates an exemplary representation of a flow chart that illustrates a method (200) of managing a transaction request during the availability and unavailability of an internet connection, in accordance with an exemplary embodiment of the present disclosure.
[0053] Referring to FIG. 2, in an embodiment, the method (200) for managing a transaction request during the availability and unavailability of the internet connection can include multiple steps performed using the various components illustrated hereinafter. The method (200) can include the memory (104) configured to store a set of instructions and the processor (106) connected to the memory (104) for executing the set of instructions. The method (200) can be initiated when the transaction request is received at the POS terminal (114).
[0054] At block 202, the processor (106) can capture payment data associated with a payment instrument in response to receiving the transaction request. The payment data can include one or more tokenized card data, hashed card data, or non-encrypted card data. The payment instrument can include but is not limited to, a credit card, debit card, prepaid card, smart card, mobile payment token, or digital wallet credential. The captured payment data can be used to uniquely identify the transaction source and to perform subsequent validation of transaction eligibility.
[0055] At block 204, the processor (106) can determine the availability of an internet connection at the POS terminal (114). In an example embodiment, the determination can involve a network check routine that attempts to establish communication with a remote server (108) or a known network endpoint to assess network status. If the internet connection is determined to be available, the processor (106) may proceed with transmitting the transaction request for standard online authorization. However, if the internet connection is found to be unavailable, the processor (106) can invoke the offline evaluation model (106-1) as illustrated in step (206).
[0056] At block 206, the offline evaluation model (106-1) may be triggered by the processor (106) to assess the eligibility of the transaction based on a predetermined offline authorization criteria. The offline evaluation model (106-1) can be pre-configured and stored locally to allow the transaction to proceed in the absence of a network connection. The offline evaluation model (106-1) can be trained or constructed using prior transaction behavior, security parameters, and user profile data to determine the authenticity and risk associated with the transaction.
[0057] At block 208, the offline evaluation model (106-1) can analyze the captured payment data to extract a set of features relevant to authorization. The extracted set of features may include transaction amount, merchant identification, device information, historical transaction pattern, or time of transaction.
[0058] At block 210, the extracted set of features may be mapped against the predetermined offline authorization criteria to determine whether the transaction request satisfies the conditions for approval.
[0059] At block 212, the offline evaluation model (106-1) can perform a decision operation by comparing the extracted set of features to the authorization criteria. If the features meet the required conditions, the transaction request may be approved. Conversely, if the features do not align with the authorization criteria, the transaction request may be denied. The decision can be based on configurable thresholds and pre-established rules that define acceptable levels of transaction risk in offline mode.
[0060] Following approval, at block 214, the offline evaluation model (106-1) may store the approved transaction request in a queue for deferred transmission. This queue can reside in local memory (104) or within a designated transaction cache accessible to the processor (106). The queuing mechanism ensures that the approved transactions are retained securely until internet connectivity is restored.
[0061] At block 216, upon restoration of the internet connection, the queued transaction request may be transmitted by the offline evaluation model (106-1) to the server (108) for authorization processing. The server (108) may be communicably connected to the processor (106) and the POS terminal (114), and may perform backend validation, risk analysis, and final approval or rejection of the transaction. The server (108) may also return a response to update the status of the queued transaction, and the processor (106) can log the outcome for reporting and audit purposes.
[0062] The method (200) described herein can allow for secure and efficient processing of transaction requests regardless of internet availability, by enabling conditional offline decision-making and deferred synchronization for network-based authorization.
[0063] FIGs. 3 (A-B) illustrates exemplary representations (300A, 300B) of a flowchart illustrating standard payment processing sequence in online environment, and a step-by-step illustration of current offline process flow diagram, in accordance with an exemplary embodiment of the present disclosure.
[0064] Referring to FIG. 3A (300A), the process starts (302) with capturing payment data associated with a payment instrument such as a contact, contactless, or mobile-enabled card when a customer taps, inserts, or swipes the card at the POS terminal, as shown in step 304. The POS terminal can capture the card details (306) and determine the availability of an internet connection. If the internet is available, the POS terminal can send transaction details to a payment gateway (308), which forwards them to a card network (310) and subsequently to an issuing bank (312). The issuing bank can then approve (318) or decline (316) the transaction based on internal authorization logic at step 314. The result of the transaction can be communicated back to the POS terminal (114) at step (320), which can display the outcome step (322-1 and 322-2). At step 322-1 the declined transaction displayed on POS terminal (114) and at step 322-2, confirmed or accepted transaction request is displayed on POS terminal (114). The transaction can later be settled by banking systems at step (324) before the process concludes at step (326). In the absence of internet connectivity, the processor (106) can invoke the offline evaluation model (106-1) configured to assess transaction eligibility based on predetermined offline authorization criteria.
[0065] Referring to FIG. 3B, the process illustrated in the accompanying drawing initiates at step 402, where the transaction session begins. At step 404, a customer can initiate a transaction by tapping, inserting, or swiping a payment card. Following the initiation, the point-of-sale (POS) terminal (114) can capture the card details at step 406. The POS terminal can include hardware and software components configured to securely capture payment credentials, including card numbers, expiry dates, and optionally encrypted or tokenized identifiers. After the card details are captured, the POS terminal can check for offline approval settings at step 408. The offline approval settings can include configuration parameters stored in memory that define whether offline processing is permissible and under what constraints.
[0066] At step 410, the system (102) can determine whether offline mode is enabled. When offline mode is not enabled, the process can proceed to step 412 where the POS terminal can prompt the user to opt for online processing or decline the transaction, thereby terminating the transaction flow at step 414. When offline mode is enabled, the system (102) can proceed to perform basic validation of the card credentials at step 416. This validation can include checks against the card number format and the expiry date to confirm that the card is not expired or malformed. In step 418, the system (102) can evaluate the card's Bank Identification Number (BIN) to determine eligibility against pre-defined criteria such as allowed BIN ranges or merchant-specific BIN lists.
[0067] Subsequently, at step 420, the system (102) can perform risk checks including assessments of offline limits and floor limits associated with the payment instrument. Offline limits can represent the maximum permissible amount for a single offline transaction, while floor limits can define merchant-specific thresholds below which transactions can proceed without online approval. At decision step 422, the system (102) can determine whether the transaction meets the approval criteria based on the outcomes of validation and risk checks. If the transaction is not approved, the system (102) can mark the transaction as declined at step 424 and display an appropriate decline message on the POS terminal at step 426, concluding the process at step 428. If the transaction is approved at step 422, the transaction can be marked as an offline transaction approved at step 430. The approved offline transaction can then be stored locally in the POS terminal for later settlement at step 432. An approval message can be displayed to the customer on the POS terminal at step 434. Following the display, the transaction can be queued for upload when internet connectivity is restored at step 436. The process can then conclude at step 438. The process illustrated in the flow chart enables the system (102) to ensure transaction continuity in offline conditions by evaluating predefined criteria and storing eligible transactions for deferred settlement.
[0068] FIG. 4 illustrates exemplary representations of a flowchart (400) illustrating payment transactions with the proposed system (102), in accordance with an exemplary embodiment of the present disclosure.
[0069] Referring to FIG. 4, flowchart 400 illustrates a transaction processing sequence that enables the handling of payment requests in both online and offline scenarios. The process begins at step 502, where the transaction session is initiated. At step 504, the customer can initiate the transaction by tapping, inserting, or swiping a card. Following this, the point-of-sale (POS) terminal can capture the card details at step 506. The card details can include parameters such as card number, expiry date, and associated identifiers in tokenized or encrypted formats. At step 508, the system (102) can check whether an internet connection is available to determine the appropriate processing route.
[0070] When internet connectivity is detected, the transaction request can be sent directly to a payment gateway (308) at step 510. The payment gateway (308) can act as an intermediary that routes the transaction to the card network at step 522. The card network can forward the transaction request to the issuing bank at step 524, where authorization checks can be performed in real-time. Further, the POS terminal can display the success message to the user at step 530, and process concludes at step 532. . If the issuing bank declines the transaction, the POS terminal can show a transaction declined message at step 534 before ending the flow at step 540.
[0071] When internet connectivity is not available at step 508, the system (102) can invoke the offline authorization mechanism at step 512. offline authorization can include the execution of offline evaluation model (106-1) configured to assess the eligibility of the transaction based on predetermined offline authorization criteria stored in the memory (104). At decision step 514, the system (102) can determine whether the offline evaluation results in an approved transaction. If the offline authorization is successful, a success message can be displayed on the POS terminal at step 516. Further, the transaction can be queued for later processing at step 518, and. The queued transaction can then be stored and marked for upload to the gateway when connectivity is restored, as shown in step 520.
[0072] If the offline evaluation does not result in authorization approval at step 514, the system (102) can log the failed transaction attempt at step 526. The logged failed transaction can be transmitted to the payment gateway (308) for record keeping such transaction attempted or rejected once online connectivity is restored, as indicated in step 528. This ensures a record is retained for further review or audit while maintaining consistency in transaction handling. The steps from the gateway to the issuing bank follow the same path as in the online processing flow, ensuring that once connectivity is re-established, the queued or failed transaction attempts.
[0073] FIGs. 5 (A-B) illustrates an exemplary representation of flow diagrams (500A, 500B) illustrating card fraud detection, prevention, and retrieval during online environment, and offline Bank Identification Number (BIN), hashed card number, or tokenized number-based promotions check, in accordance with an exemplary embodiment of the present disclosure.
[0074] Referring to FIG. 5A, the flow diagram (500A) illustrates a transaction processing method that allows both online and offline handling of card transactions with past due balance consideration. The process begins at step 602 where a transaction is initiated, and a tokenized card number is captured at step 604 through a point-of-sale (POS) terminal (114). At step 606, the system (102) checks for the availability of an internet connection. If internet connectivity is available, the processor (106) proceeds to step 608 to check for any past due amount by accessing the database (112). At decision step 610, if a past due amount is found, the amount is shown on the POS terminal at step 612. At step 614, the customer is prompted to confirm willingness to settle the past due amount. If the customer agrees, the processor (106) adjusts the total transaction value accordingly at step 616 and proceeds with online transaction processing at step 632. If no past due is found at step 630, the transaction continues with standard online card processing at step 632. If the customer refuses to settle the due amount at step 614, the transaction is blocked at step 634, and the process terminates at step 640.
[0075] Furthermore, when internet connectivity is not available as determined in step 606, the processor (106) invokes offline authorization model (106-1) using offline authorization at step 620. At decision step 620, the transaction is evaluated against offline authorization criteria. If the transaction is approved, a success message is shown on the POS terminal at step 622 and it is stored locally at step 624, and. The system (102) waits for internet reconnection at step 630, after which the stored transaction is sent to a gateway at step 638 for further processing. If the offline authorization fails at step 624, the transaction attempt is logged without approval at step 640, and the process ends at step 642. The steps referenced in the flow diagram (500A) represent a comprehensive mechanism for managing transaction approvals in both connected and disconnected scenarios while enforcing past-due balance considerations.
[0076] The flow diagram (500B) illustrates a transaction handling process incorporating both online and offline authorization mechanisms, and further integrates eligibility checks for promotions during offline processing. The process begins at step 702 with the initiation of a transaction. At step 704, a tokenized card number is captured through the point-of-sale (POS) terminal (114). The processor (106) then checks for the availability of internet connectivity at step 706. If the internet is available, the processor (106) connects to the database (112) at step 708 to check for any past-due obligations associated with the payment instrument. If a past due record is detected at decision step 710, the due amount is displayed on the POS display panel (110) at step 714. The user is then prompted at step 716 to decide whether to settle the outstanding amount. If the user agrees, the total transaction value is adjusted at step 718 to include the due amount, and the transaction is processed online at step 720. If no past due is found at step 710, the transaction directly proceeds with standard online processing at step 712. In the event the user does not agree to settle the outstanding dues, the transaction is blocked at step 722, and the process concludes at step 746. In an embodiment, the processor (106) can analyse the eligibility for promotions if applicable for the payment instrument.
[0077] Further, if internet connectivity is not available as determined in step 706, the processor (106) initiates offline authorization using the offline evaluation model (106-1) at step 724. At decision step 728, the transaction is evaluated to determine whether it passes offline authorization criteria. If the offline authorization fails, the transaction attempt is logged and not approved at step 728. If offline authorization is successful, the processor (106) proceeds to check for eligible promotions in a locally stored promotion eligibility metric database (112) and card details at step 730. If a promotion is available as determined at step 732, the applicable promotion is applied or shown to the user on the POS display panel (110) at step 734. If no promotion is available, the process proceeds without applying for any promotional benefit at step 736. Following this, a success message is displayed on the POS terminal (114) at step 738 and the transaction is stored locally for later synchronization with the server (108) at step 740. The processor (106) waits for the internet to reconnect at step 742 and subsequently sends the stored transaction to the payment gateway (308) at step 744. The flow diagram (500B) and the specified steps define the process flow for conditional transaction approval in an integrated online-offline POS system environment.
[0078] A use case of the system (102) is described hereinafter.
[0079] The system (102) is deployed in a retail environment to manage a transaction request during both availability and unavailability of an internet connection. The system (102) includes the memory (104) configured to store a set of instructions and the processor (106) connected to the memory (104) for executing the stored set of instructions. The system (102) operates in conjunction with point-of-sale (POS) terminal (114) located at a retail billing counter/ Inflight/ Onboard etc. During operation, when a customer initiates a transaction using a payment instrument such as a debit card, the POS terminal (114) receives the transaction request. The processor (106) captures payment data associated with the debit card. The captured payment data includes tokenized card information such as a surrogate value representing the actual card number. Upon receiving the transaction request, the processor executes a check to determine whether the POS terminal (114) is currently connected to the internet. The internet connection status is verified using a standard connectivity check to a known endpoint or the server (108). If the processor (106) detects that the internet connection is unavailable, the processor invokes offline evaluation model (106-1) stored within the memory (104). The offline evaluation model (106-1) is configured to analyze the captured payment data to extract the set of features. The offline evaluation model (106-1) maps the extracted features against predetermined offline authorization criteria. Based on the result of the mapping, the offline evaluation model (106-1) approves the transaction request if the extracted features satisfy the offline authorization criteria. For instance, if the transaction amount is within a specified limit and the card was used previously without any flagged activity, the transaction may be approved. Upon approval, the transaction request is stored in a local queue designated for deferred transmission.
[0080] Further, the queued transaction request remains stored until the POS terminal (114) re-establishes internet connectivity. Once the connection is restored, the offline evaluation model initiates the transmission of the queued transaction request to the backend server for authorization processing. The server (108), connected to the processor (106) and the POS terminal (114), performs standard authorization processes such as validation with the issuing bank or payment gateway (308). The response from the server (108) is used to finalize the transaction status.
[0081] What are described above are merely preferred embodiments of the present invention, and are not to limit the present invention; any modification, equivalent replacement, and improvement within the principle of the present invention should be included in the protection scope of the present invention.
[0082] References back that are used in dependent claims indicate the further embodiment of the subject matter of the main claim by way of the features of the respective dependent claim; they should not be understood as dispensing with obtaining independent protection of the subject matter for the combinations of features in the referred-back dependent claims. Furthermore, with regard to interpreting the claims, where a feature is concretized in more specific detail in a subordinate claim, it should be assumed that such a restriction is not present in the respective preceding claims.

ADVANTAGES OF THE DISCLOSURE
[0083] The proposed disclosure provides a system and a method for managing a transaction request during availability and unavailability of an internet connection.
[0084] The proposed disclosure provides a system and a method that prompts customers to settle past-due balances during online transactions, reducing outstanding liabilities.
[0085] The proposed disclosure provides a system that includes a Card Based promotional subsystem that maximizes opportunities for discounts and offers during offline transactions.
[0086] The proposed disclosure provides a system and a method that maintains consistency across online and offline modes through periodic synchronization of authentication databases and feedback transmission.
[0087] The proposed disclosure provides a system and a method that allow detection and blocking of fraud transactions by analyzing a set of features extracted from payment data and assess entitlement of a payment instrument to a predefined benefit or promotion based on eligibility metrics.
, Claims:1. A system (102) to manage a transaction request during availability and unavailability of an internet connection, the system (102) comprising:
a memory (104) storing a set of instructions; and
a processor (106) communicatively coupled to the memory (104), the processor (106) executing the set of instructions, causes the system (102) to:
capture payment data associated with a payment instrument in response to receiving a transaction request;
determine availability of an internet connection at a point-of-sale (POS) terminal; and
invoke an offline evaluation model (106-1) in response to detecting absence of the internet connection, to assess transaction eligibility based on a predetermined offline authorization criteria, wherein the offline evaluation model (106-1) is configured to:
analyze the captured payment data to extract a set of features;
map the extracted set of features against the predetermined offline authorization criteria;
perform at least one of: approve the transaction request when the extracted set of features meets the predetermined offline authorization criteria, or deny the transaction request when the extracted set of features fails to meet the pre-determined offline authorization criteria;
store the approved transaction request in a queue for deferred transmission upon approving the transaction request; and
transmit the queued transaction request to a server (108) for authorization processing upon restoring the internet connection, wherein the server (108) is communicably coupled to the processor (106) and the POS terminal (114).
2. The system as claimed in claim 1, wherein the payment data comprises any or a combination of tokenized card data, hashed card data, and non-encrypted card data.
3. The system (102) as claimed in claim 1, wherein the processor (106) is further configured to:
log, by the offline evaluation model (106-1), the denied transaction attempt without authorizing payment upon denial of the transaction request; and
update the offline evaluation model (106-1) and the predetermined offline authorization criteria based on feedback from authorization result of the queued transaction request received upon restoration of the internet connectivity.
4. The system (102) of claim 1, wherein the payment instrument comprises any or a combination of credit card, debit card, prepaid card, smart card, digital wallet credential, and mobile payment token.
5. The system (102) of claim 1, wherein the set of transaction features comprises any or a combination of card issuer identification number (IIN), BIN, card number, tokenized card value, hash of the card number, transaction amount, merchant identifier (MID), device identifier and Terminal ID (TID).
6. The system (102) of claim 1, wherein the predetermined offline authorization criteria comprises any or a combination of offline transaction limit, floor limit associated with the payment instrument, maximum number of allowed offline transactions, BIN range eligibility rule, blacklist entry or grey list entry associated with the payment instrument, past due balance rule, and fraud risk threshold.
7. The system (102) as claimed in claim 1, wherein the processor (106) further configured to:
store a set of promotion eligibility metric in a database (112) based on a set of attributes associated with the payment instrument, wherein the database (112) is operatively coupled to the processor (106);
analyse eligibility for a promotion based on the captured payment data and the stored set of promotion eligibility metric; and
display, by a display panel (110), the eligible promotion to the user during the offline transaction approval based on the analysis.
8. The system (102) of claim 7, wherein the offline evaluation model (106-1) is further configured to:
analyse the extracted set of features by mapping against a set of offline fraud detection criteria;
approve the transaction request upon satisfying the offline fraud detection criteria;
decline the transaction request upon failure to satisfy the offline fraud detection criteria; and
log the declined transaction request and store the logged transaction request in the database (112).
9. The system (102) as claimed in claim 1, wherein the processor (106) is further configured to process the transaction request by transmitting the captured payment data to a payment gateway (308) for real-time authorization when internet connectivity is available.
10. A method (200) of managing a transaction request during availability and unavailability of an internet connection, the method (200) comprising:
capturing (202), by a processor (106), payment data associated with a payment instrument in response to receiving a transaction request, wherein a memory (104) stores a set of instructions; and the processor (106) communicatively coupled to the memory (104) for executing the set of instructions;
determining (204), by the processor (106), availability of an internet connection at a point-of-sale (POS) terminal (114);
invoking (206), by the processor (106), an offline evaluation model (106-1) in response to detecting absence of the internet connection, to assess transaction eligibility based on a predetermined offline authorization criteria;
analyzing (208), by the offline evaluation model (106-1) the captured payment data to extract a set of features;
mapping (210), by the offline evaluation model (106-1), the extracted set of features against the predetermined offline authorization criteria;
performing (212), by the offline evaluation model (106-1), at least one of: approving the transaction request when the extracted set of features meets the predetermined offline authorization criteria, or denying the transaction request when the extracted set of features fails to meet the pre-determined offline authorization criteria;
storing (214), by the offline evaluation model (106-1), the approved transaction request in a queue for deferred transmission upon approving the transaction request; and
transmitting (216), by the offline evaluation model (106-1), the queued transaction request to a server (108) for authorization processing upon restoring the internet connection.