A method for managing payment submissions includes receiving, at an acquirer computing system, an authorization request submitted by a merchant computing system for a transaction of a predefined amount, the merchant computing system being associated with a merchant, and the authorization request identifying account information for an account that is associated with a payment card network and an issuer processor; and re-transmitting the authorization request for less than the predefined amount and greater than a configurable threshold value, until the authorization request is approved by the issuer processor or until the authorization request falls below the configurable threshold value.

Systems and methods for determining interchange rate designator (IRD) values are provided. A microservice, provided at acquiring servers to determine the IRD value, receives a transaction clearing service request from acquiring servers. The transaction clearing service request includes details of payment card and details of payment transaction. The microservice validates the details of a payment card and the card payment transaction. Based on the details, the microservice identifies a card program identifier (CPI) and product ID associated with the payment card from a member parameter extract data. The microservice identifies business service arrangements (BSAs) applicable on the payment transaction based on the CPI, the details of the payment card and the details of the card payment transaction. The microservice validates each BSA and determines one or more IRD values for each validated BSA, and further validates each IRD value and determines an optimal IRD value from the validated IRD values.

Described is a reactive hierarchical blockchain architecture, system, and methodology for Global Trade Management (GTM). The system includes a comprehensive suite of GTM applications and leverages multi-national content to deliver efficient cross-boarder transactions anywhere in the world. The tiered computer-implemented system and method allow development of distributed GTM blockchain solutions capable of processing enormous amounts of global content at scale to meet huge transaction volume. The hierarchical blockchain architecture further assures scalability of the GTM solutions described herein by reducing the need for performing extensive calculations on multiple blockchain nodes. The GTM blockchain systems can be standalone or they can feed information into on or more main International Trade (ITC) blockchains. Smart contracts for specific GTM operations are segregated among appropriate childchains and verified by integrated GTM applications executed on permissioned nodes. Various embodiments can store, analyze, and track GTM endorsements and events to help coordinate and maintain contractual obligations of service partners as well as monitor their performance.

A one-time password (OTP) is transmitted to an authorized wireless device for use an authentication factor, even though the OTP may be intercepted or otherwise viewed with an unauthorized device. When a secure request is initiated that requires entry of an OTP as an authentication factor, a hyperlink is transmitted to a wireless device from which the secure request is initiated. When the hyperlink is selected, a connection is established with an entity that determines mobile number information associated with the SSL connection. Comparison of the determined mobile number information and the mobile number of the wireless device to which the hyperlink was intended to be sent indicates whether the wireless device that has established the SSL connection is the authorized wireless device. The OTP is displayed on the wireless device after that device has been verified as the authorized wireless device.

Methods and systems for dynamically generating a verification value for a transaction and for utilizing such value to verify the authenticity of the payment service application. The dynamically created verification value may be generated on a payment device, such as an integrated circuit credit card or smart card, embedded into the payment data, and transmitted to a point of sale terminal. Alternatively, payment data is sent by a payment device to a point of sale terminal, which generates a verification value and embeds it into the payment data. The embedded verification value is used by a service provider to verify the authenticity of the transaction. The methods and systems may be used in a contactless (wireless) environment or a non-wireless environment.

In accordance with embodiments, there are provided mechanisms and methods for facilitating prevention of duplicate transactions across multiple transaction entities in database systems according to one embodiment. In one embodiment and by way of example, a method includes receiving a request to facilitate a financial transaction, wherein the request is received from an external computing device and includes an idempotency key that is unique to the request, and verifying, based on the idempotency key, the request as being a valid request or an invalid request, wherein the valid request is registered, and classifying, based on the idempotency key and a gateway log, the valid request as an original request or a duplicate request that is a successful duplicate request or an unsuccessful duplicate request.

A virtual wallet application and a split services server can support multi-card payment processing using a virtual card. The virtual wallet application can receive a selection of at least two payment cards of two or more payment cards in the virtual wallet application, a corresponding amount for each of the at least two payment cards, and an indication to perform the split payment. In response to receiving the indication to perform the split payment, the virtual wallet application can validate the user and create a transaction request. The transaction request can include the virtual card, tokens of the at least two payment cards and their corresponding portions of the split payment amount, and a split payment flag indicator. The transaction request can be routed by an acquirer to the split services server, which extracts the information of the multiple cards and manages pre-authorization requests to the corresponding issuers.

A request is received from an account holder to link a payment card to a payment card account owned by an account holder. The request is submitted by the account holder and receipt of the request includes receiving a payment card identification number displayed in association with the payment card. The payment card identification number is used to look up a payment token electronically stored in the payment card. The payment card identification number is different from the payment token. The payment token is mapped to a payment card account number that identifies the payment card account owned by the account holder.

A secondary authentication system and computer-implemented method for obtaining real-time cardholder authentication of a payment transaction associated with a cardholder's payment card includes a memory device for storing data and a processor communicatively coupled to the memory device. The processor is programmed to receive a payment authorization request message including a primary account number corresponding to a payment account of the cardholder for funding the payment transaction. In addition, the processor is programmed to determine whether the payment account requires secondary authentication by the cardholder for the payment transaction, and if, based on the determination, the payment account requires secondary authentication of the payment transaction, place the payment transaction on hold. Furthermore, the processor is programed to identify a mobile device associated with the payment account of the cardholder, transmit an authentication request message to the identified mobile device, and receive, from the mobile device, an authentication response message.

Systems and methods are provided for blocking charges from a merchant to a payment account of a user. An exemplary system may include one or more memory devices storing instructions and one or more processors configured to execute the instructions to perform various operations. The operations may include receiving, from the user, a dispute request to dispute a charge to the payment account applied by the merchant. In response to the dispute request, the operations may include determining whether to block subsequent charges applied by the merchant to the payment account, based on a history of charging activities of the merchant. Responsive to a determination to block subsequent charges, the operations may include adding the merchant to a block-charge list associated with the payment account.