Declined Payment Reprocessing via New Merchant-of-Record Routing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing payment transaction systems fail to effectively handle declined transactions, leading to inefficiencies, customer friction, and lost sales due to repetitive processing, lack of real-time data integration, and reliance on a single merchant-of-record framework, resulting in high false positives and delayed resolution methods.
Innovation Solution
A system that processes declined transactions through a third-party service, leveraging real-time data enrichment, probabilistic modeling, and adaptive routing to reprocess transactions via a new merchant-of-record, allowing for customer interaction when necessary, without requiring the originating merchant to manage liability or risk assessment.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If the system immediately re-processes the same transaction via a different payment provider, then the transaction is attempted again, but the issuer receives the same transaction again a few seconds later and declines it, leading to almost total failure of re-processed transactions
Solution Approach 1:
The patent segments the payment processing system by introducing a new merchant-of-record entity separate from the original merchant. This creates distinct processing contexts that allow the transaction to be evaluated independently by the issuer, avoiding the velocity checks and duplicate suppression logic that trigger on identical transactions from the same merchant account.
Solution Approach 2:
The new merchant-of-record acts as an intermediary between the original merchant and the payment processor/issuer. This intermediary layer enables the transaction to be routed through different processing pathways and evaluated by the issuer as a new transaction rather than a duplicate, thereby avoiding automatic decline while maintaining security.
2Adaptability or versatility
If the system notifies the customer and requests alternative payment form, then the customer can provide different payment details, but this process creates significant customer friction and leads to session abandonment
Solution Approach 1:
The system automatically evaluates failed transactions and determines alternative processing pathways without requiring customer intervention. The new merchant-of-record framework enables automated re-evaluation of transactions using updated risk models and alternative routing strategies, eliminating the need for customers to manually select alternative payment methods or provide additional information.
3Productivity
If the system uses traditional retry logic within the same merchant account context, then the transaction is re-attempted, but the issuer's velocity checks and duplicate suppression logic treat it as a replay and auto-decline it
Solution Approach 1:
The patent creates a segmented merchant account structure where the original merchant and the new merchant-of-record are separate entities. This segmentation allows the same transaction to be processed under different merchant identifiers, preventing the issuer's velocity checks from flagging it as a duplicate or replay attack, thereby enabling successful re-attempts without triggering automatic decline.
4Device complexity
If the system lacks real-time data enrichment and uses static heuristics for retry decisions, then the decision process is simple, but this leads to elevated false positives and increased issuer friction
Solution Approach 1:
The system performs preliminary data enrichment by collecting and preparing additional transaction context, customer information, and risk indicators before the retry decision is made. This pre-processing of data enables more accurate and nuanced evaluation of transaction risk, allowing the system to make informed decisions about which transactions merit reprocessing and under what conditions, thereby reducing false positives while maintaining operational efficiency.
Data Source
AI summary
Systems and methods for purchasing (typically under a factoring model but other models are still possible), on a selected basis, declined payment transactions; receive, for assessment, the failed payment transaction via API; enrich the data received for the failed transaction with external and internal data; define, via one or more predictive models, the expected cause of payment failure; define, via the one or more predictive models the probability of successfully process in the following days the transactions successfully, calculating the associated cost of risk; interact in real-time with the customer where needed; confirm to the party invoking the service, for each transaction sent for assessment, the purchase or not of the failed payment transaction.