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 teams
What problem it solves? Payment teams get real-time visibility on provider outages, costs and approval rates, as well as recommendations on actions to take – something that required a few days of analysis before
How it works? A synthetic dataset with 100k transactions, reproducing the statistical patterns of a book at this scale. The chatbot runs an LLM query across the dataset. In a production setting, the chatbot can be connected to the company’s systems and data sources
Read more and try it →What is it? A multi-archetype mock payment gateway modeling five processor archetypes – global-acquirer, regional-bank-processor, APM-specialist, cross-border-FX-specialist, and high-risk orchestrator – with realistic ISO 8583 decline codes, 3DS v2.2 flows, and HMAC-signed webhooks
What problem does it solve? Sandbox environments approve on magic cards; production behaves differently. Merchant integration teams cannot test routing logic against realistic declines until customers complain. The simulator returns what merchants actually see in production, so integrations ship correct the first time
How does it work? Python with FastAPI, a Postgres payment state machine, Redis idempotency cache, a Kafka event bus, and Celery webhook workers. Installable via pip install payment-routing-simulator, live API under /routing-simulator/api/, and wired into Case 01’s chatbot as a routing-recommendation tool
What is it? A merchant-side recovery decision engine that scores soft card declines and recommends whether to retry, skip, or defer the next attempt. It is designed to plug into the merchant payment flow rather than sit as a manual per-transaction screen.
What problem does it solve? Recovery teams know many soft declines are salvageable, but blind retries create processor cost, customer friction, and issuer fatigue. This engine prioritizes the declines with the best expected value and shows why each recommendation was made.
How does it work? A LightGBM model is trained on synthetic retry-chain data derived from a realistic payment book, then wrapped in a business policy layer that optimizes net recovery value. Merchants can deploy it in their own stack, call it through an API, and use the portfolio demo to inspect sample decisions and SHAP-style explanations.
Read more and try the demo →I build and optimize payments for financial institutions, fintechs and merchant payment teams, from strategy to working software