Ivan Antonov - payments from strategy to working software
Over the two weeks I built three products that a payments team could use day-to-day:
Test each one below
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. In 3 minutes, chatbot produces analysis which previously required 3 days of work, and it can be launched via Whatsapp
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. Merchant teams take 2-3 months to test the new flows, and even then many issues surface only after launch in production. 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. Merchants maintain the retry logic in Excel, leaving on the table optimization opportunities. 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