-
-
demo
Inspiration
Payment API failures can be difficult to investigate. An error message alone doesn't tell the whole story, and an AI-generated explanation is not the same as verified evidence.
We built PayGuard Flight Recorder to explore a better approach: combine real PayPal sandbox API interactions, local AI analysis, and independent verification into one investigation workflow.
What it does
PayGuard Flight Recorder captures a controlled PayPal sandbox failure and presents the investigation as a structured, four-stage timeline:
- Failed order lookup: Reproduce and record a failed order lookup, including the HTTP response and request latency.
- Local AI investigation: Use a locally running Qwen model through Ollama to generate an advisory diagnosis.
- Replacement order creation: Create a replacement sandbox order and record the actual API response.
- Independent order retrieval: Retrieve the replacement order and verify that its returned ID matches the created order.
The dashboard presents the transaction evidence, recovery verification, and AI diagnosis together. The AI output is explicitly marked as generated and not independently verified, keeping its conclusions separate from observed API results.
The demonstration does not capture a payment, and the original failed order is not represented as repaired. Instead, PayGuard verifies a separate replacement order.
How we built it
We built PayGuard in C# on .NET 10, with a local web dashboard, a dedicated trace and investigation executable, and a core library containing the payment authorization and trace logic.
We also developed deterministic regression tests for authorization rules, replay prevention, approval binding, trace validation, and sensitive-data rejection.
The dashboard was exercised against the PayPal sandbox, and the complete investigation workflow was verified, including the failed lookup, local AI diagnosis, replacement creation, and matching replacement retrieval.
Challenges we faced
One of the central challenges was distinguishing an AI suggestion from a fact supported by external evidence. We addressed this by keeping the AI diagnosis advisory and using actual HTTP responses and matching order identifiers for recovery verification.
We also worked through deployment and integration issues, including executable path resolution, multi-event recovery verification, and presenting structured investigation results without treating untrusted AI output as HTML.
Our goal is not simply to produce an explanation for a payment failure. It is to make the investigation traceable, understandable, and verifiable.
What's next
We are preparing the application for distribution, improving deployment reliability, and documenting setup and verification so other developers can reproduce the investigation workflow.
Log in or sign up for Devpost to join the conversation.