SaaS Platform

FinOps Ops Console

FinOps Ops Console gives merchants and support teams a single operational view of refund and dispute risk across payment providers. Instead of treating refunds as isolated events, it tracks them as a time-sensitive workflow with automatic risk classification, alerting, and universal search — and seeds realistic demo data straight from the Stripe API so the risk logic can be seen working on genuine data shapes.

3 monthsSource

The Problem

In most payment stacks, refunds arrive as scattered emails or isolated events with no clear deadline visibility. Teams have no way to see which refunds are about to become disputes, and by the time a chargeback appears, the window to prevent it has usually already closed.

The Solution

Built a Django console that classifies every refund into SAFE, DUE_SOON, AT_RISK, or OVERDUE based on SLA logic, raises alerts automatically as refunds approach risk thresholds, and provides universal search across customer, transaction, refund, and order data — with a demo-seeding pipeline that generates real Stripe test payments and time-shifts them to naturally produce every risk state.

Architecture

Django backend with workspace-scoped authentication and core domain models for transactions, refunds, and alerts

Refund SLA and risk-state logic (SAFE / DUE_SOON / AT_RISK / OVERDUE)

Encrypted provider credential storage for Stripe, Shopify, and Paystack connections

Stripe demo seeding that generates test payments and refunds, then time-shifts them to populate every risk state

Tailwind-styled dashboard UI with alert-driven navigation

Technologies Used

DjangoPostgreSQLTailwind CSSStripe APIDocker

Challenges

1Modeling refund risk as a continuous, time-based state rather than a simple binary status
2Building demo data realistic enough to genuinely exercise the risk engine, not just fake the UI
3Storing and managing multiple provider credentials securely across Stripe, Shopify, and Paystack

Engineering Trade-offs

1Built the SLA and risk logic before any live provider integration — the tool was demonstrably useful early, at the cost of validating assumptions against real provider data later than ideal
2Chose real Stripe test-API seeding over static JSON fixtures for demo data — the risk engine is exercised against genuine data shapes, at the cost of a slower, network-dependent seeding process
3Modeled refund risk as four fixed states (SAFE / DUE_SOON / AT_RISK / OVERDUE) instead of a free-form status field — predictable UI and alerting logic, at the cost of less flexibility if a future edge case doesn't cleanly fit one of the four

Lessons Learned

1Most chargebacks are missed deadlines, not fraud — solving for visibility prevents more disputes than solving for detection after the fact
2An ops tool earns trust faster when it's convincing in demo mode before a single real provider is connected