PaySentinel

Autonomous payment-failure triage: PaySentinel turns a plain-English report into log evidence, root-cause diagnosis, and a Jira ticket in about 90 seconds.

Comment

About the project Inspiration

PaySentinel was inspired by a real operational gap that happens whenever digital payments fail: the person hearing the customer complaint is often not the same person who can diagnose the system failure.

In a typical incident, a business analyst hears something like “customers cannot complete checkout,” creates a vague Jira ticket, and then a developer has to manually search logs under pressure. By the time the root cause is found, customers may already be abandoning purchases, support teams are overwhelmed, and engineering time has been lost.

We wanted to build an agent that closes that gap.

PaySentinel turns a plain-English payment failure report into a structured investigation. Instead of acting like a chatbot that only explains possibilities, it behaves like an autonomous incident triage agent: it forms hypotheses, searches transaction logs, compares current failures against baseline behavior, generates a diagnosis, creates a developer-ready Jira ticket, and stores the incident for future reference.

What it does

PaySentinel helps teams diagnose payment failures faster.

A business analyst can describe an issue in plain language, such as:

Customers are reporting UPI payment failures in Mumbai after the afternoon deployment.

PaySentinel then runs an autonomous investigation workflow:

Builds an investigation plan using Gemini. Converts the report into concrete hypotheses and search filters. Searches transaction logs through Elastic MCP / Elasticsearch. Retrieves failed transaction evidence. Compares current failures against historical baseline behavior. Identifies anomalous patterns by payment method, gateway, bank, region, device type, error code, and failure stage. Generates a root-cause diagnosis. Creates a Jira ticket with the technical context developers need. Persists the incident back into Elasticsearch so future investigations can reference prior incidents.

The goal is simple:

Reduce payment incident triage from 30–45 minutes of manual log digging to an approximately 90-second agent-assisted workflow.

How we built it

We built PaySentinel as a full-stack agent workflow.

The frontend is a React + Vite application designed as a fintech incident-response command center. It lets a business analyst enter a natural-language payment issue, optionally add operational context like region, payment method, start time, and notes, then watch the autonomous investigation unfold step by step.

The backend is a Node.js + Express service that exposes the investigation API and streams progress updates to the frontend using Server-Sent Events. This lets the UI show the agent’s live execution path instead of waiting for a single final response.

Gemini is used as the reasoning layer. It first creates an investigation plan before looking at logs, then later receives the actual evidence and produces a structured diagnosis. This helps make the system more agentic because each step depends on the results of the previous step.

Elastic MCP and Elasticsearch power the evidence layer. The agent searches payment transaction logs, groups failure patterns, compares against baseline behavior, and identifies anomalies. Jira REST API is used to turn the diagnosis into a developer-ready incident ticket.

The system is designed around a realistic payment data model with fields such as payment method, gateway, bank, failure stage, response time, device type, region, retry count, and transaction status.

Challenges we ran into

One of the biggest challenges was making the project clearly feel like an agent instead of a chatbot. A chatbot could simply answer, “This might be a gateway issue.” PaySentinel needed to show actual autonomous behavior: planning, tool use, evidence gathering, analysis, diagnosis, ticket creation, and incident memory.

Another challenge was designing the frontend so judges could understand the value quickly. The project touches several systems: Gemini, Elastic MCP, Elasticsearch, Jira, transaction logs, and incident response workflows. We had to make the interface explain that complexity visually without overwhelming the user.

We also had to balance realism with hackathon speed. Payment systems are high-stakes, so we designed the workflow around realistic synthetic transaction data and a practical incident-response pattern that could later connect to real production logs.

Accomplishments that we are proud of

We are proud that PaySentinel demonstrates a complete agent workflow, not just a prompt-based demo.

The project goes from plain-English business context to technical evidence, then from technical evidence to an actionable Jira ticket. It shows how agents can reduce the translation gap between business teams and engineering teams during live incidents.

We are also proud of the frontend experience. The interface now communicates the product story quickly: what failed, what the agent checked, what evidence it found, what the likely root cause is, and what developers should do next.

What we learned

We learned that the strongest agent experiences are not just about model output. They are about orchestration, evidence, trust, and action.

For an incident-response agent to be useful, it has to explain what it checked, why it checked it, what evidence supports the diagnosis, and what action was taken. We also learned that a good hackathon demo needs to make the workflow visible so judges can immediately see the difference between a chatbot and an autonomous agent.

What’s next

Next, we would like to connect PaySentinel to real payment observability pipelines, expand the incident memory system, and support more integrations beyond Jira. Future versions could include Slack alerts, PagerDuty escalation, rollback recommendations, richer anomaly dashboards, and support for multiple payment providers.

Long term, PaySentinel could become an autonomous incident triage layer for fintech, e-commerce, and any organization where failed payments directly affect revenue and customer trust.

Built With

Share this project:

Updates