Ivan Antonov - payments from strategy to working software
What is it? A natural-language chatbot answering questions about transaction data. Merchant payment teams can ask questions and get answers in seconds, without the need to rely on other BI or analytics teams
What problem does it solve? Payment teams get real-time visibility on approval rates, provider outages and costs, as well as recommended actions - something that previously required several days of analysis
How it works? The chatbot runs an LLM query across the transaction dataset. On this page, a synthetic dataset with 100k transactions is used, reproducing the statistical patterns of a book at this scale. In a production setting when deployed at a merchant, the chatbot can be connected to the company's systems and data sources
Read more and try it →What is it? A mock payment gateway modeling five processor archetypes (global acquirer, regional bank processor, regional card specialist, cross-border FX specialist, high-risk / orchestrator) with realistic patterns for decline codes, 3DS flows, latency and retry behavior
What problem does it solve? When a merchant integrates a new provider, provider sandboxes always return clean outputs, but reality in production is different. This tool simulates what merchants actually see in production, so integrations can be built and tested correctly before going live
How does it work? The simulator is built as an API-first service in Python / FastAPI that reproduces realistic transaction outcomes. More than 600 payment patterns are encoded into the simulation layer to mimic the approval, decline, latency and retry behaviors merchants see in production. The simulator can be either set up in merchant infrastructure or called through an API
Read more and try it →What is it? A recovery decision engine that assesses card declines and recommends whether to retry, skip, or defer the next attempt, and at which delay
What problem does it solve? Many transactions which were initially declined do succeed if retried, but the retry decision logic is complex, while blind retries increase costs and negatively affect the customer experience. This engine assesses declines, prioritizes those with the highest expected value, picks the optimal retry delay, and shows why each recommendation was made
How does it work? A LightGBM recoverability model and a second timing model are trained on retry-chain data derived from a synthetic transactions book. A business policy layer converts probability and delay into expected net recovery value. Merchants deploy it in their own stack, or call it through an API
Read more and try the demo →I build and optimize payments for financial institutions, fintechs and merchant payment teams, from strategy to working software