StudioPay

StudioPay turns failed payments into recovered revenue through intelligent, policy-driven automation.

Comment

StudioPay — Agentic Revenue Recovery for Media & Entertainment

Team: Samridhi Sinha and Puja Kumari
Hackathon: Agentic Cinema: The Blockbuster Hackathon
Partner Track: ClickHouse

A failed payment is not always lost revenue; sometimes, it is revenue waiting for the right next action.

Inspiration

Behind every film, advertisement, series or digital production is a large network of studios, VFX teams, sound engineers, equipment-rental companies, artists and other vendors. When a production payment fails, work can be delayed while a finance operator manually investigates the failure, contacts the customer, chooses a recovery method and later confirms whether the money was recovered.

Not every failure should receive the same response. An expired card needs a new payment method, a temporary gateway failure may succeed after a delay, and a high-value bank-declined transaction may require human approval.

This inspired us to build StudioPay, an agentic revenue-recovery platform for media and entertainment finance operations. StudioPay transforms failed production payments into explainable, controlled and verifiable recovery actions.

What it does

StudioPay gives finance and payment-operations teams a single Revenue Command Center for monitoring and recovering failed payments.

It calculates important metrics such as:

  • Revenue at Risk
  • Recovered Revenue
  • Recovery Rate
  • Active Recoveries
  • Automatic Actions
  • Cases Requiring Approval

Instead of blindly retrying every transaction, StudioPay evaluates the payment status, failure reason, amount, previous attempts and configured business policy.

It then selects one of four recovery actions:

  1. Send a Razorpay Payment Link when the customer needs a different payment method, such as after an expired-card failure.
  2. Schedule a Smart Retry when the failure is temporary, such as a gateway error or UPI timeout.
  3. Request Manual Review when a high-value transaction exceeds the automatic-recovery threshold.
  4. Stop Recovery when the payment is already complete or the retry limit has been reached.

For Payment Link recovery, StudioPay sends the verified invoice reference, amount, currency and available customer contact information to Razorpay. Razorpay creates a secure hosted payment page and can be requested to notify the customer through email or SMS.

After payment completion, StudioPay verifies the Razorpay webhook or reconciliation result before recording the payment as recovered. It checks the internal payment ID, Razorpay Payment Link ID, amount, currency and captured payment status.

Duplicate webhook events are handled idempotently, preventing the same successful recovery from being recorded more than once.

StudioPay also includes an AI Recovery Agent powered by Hugging Face Qwen. A finance operator can ask questions such as:

Which production payments require manual approval, and why?

The agent uses current payment information from ClickHouse to produce a grounded explanation. AI supports analysis, while deterministic policies remain responsible for authorizing and executing financial actions.

Why it fits Agentic Cinema

StudioPay treats payment recovery as a controlled, multi-step agentic workflow:

  1. Observe: Read the current payment state and recovery history from ClickHouse.
  2. Interpret: Understand the failure reason, amount and previous attempts.
  3. Decide: Apply deterministic financial policies to select the safest next action.
  4. Act: Create a Razorpay Payment Link, schedule a retry, request approval or stop recovery.
  5. Verify: Reconcile the provider response, webhook status, amount and currency.
  6. Remember: Store the recovery outcome so future decisions use the latest state.

This workflow helps studios and creative-production businesses recover revenue without replacing financial controls with unpredictable model output.

How we built it

StudioPay follows a layered architecture:

Streamlit Admin Dashboard
          |
          v
     FastAPI Backend
          |
    +-----+---------------------+
    |             |             |
    v             v             v
ClickHouse     Razorpay     Hugging Face
Cloud          Test APIs       Qwen

Frontend

We built the administrator dashboard using Streamlit.

It contains separate sections for:

  • Revenue and payment overview
  • Payment filtering and search
  • Automatic Recovery Center
  • Manual Reviews
  • AI Recovery Assistant
  • Integration status

Streamlit caching reduces repeated API calls, while session state preserves chat history and recovery-action results across application reruns.

Backend

The backend uses FastAPI with separate routes and services for:

  • Dashboard analytics
  • Payment ingestion
  • Policy recommendations
  • Recovery execution
  • Manual approvals
  • Razorpay webhooks
  • AI-assisted analysis

Pydantic validates payment IDs, monetary amounts, currencies, phone numbers and request bodies before business logic runs.

ClickHouse data layer

We use ClickHouse Cloud to store and analyze:

  • Payments
  • Vendors
  • Recovery attempts
  • Recovery outcomes

ClickHouse is not just passive storage in StudioPay. It provides the operational payment context used by the dashboard, policy workflow and AI Recovery Agent.

It allows StudioPay to calculate financial metrics, aggregate payment states and retrieve recovery context efficiently. The dashboard derives an effective payment status: if the original payment failed but a successful recovery record exists, StudioPay displays it as recovered without deleting the original failure information.

Through the Model Context Protocol, relevant ClickHouse data is supplied to the AI agent so its explanations remain grounded in current records rather than generic assumptions.

Recovery policy

The deterministic recovery policy considers:

  • Failure code
  • Failure reason
  • Payment amount
  • Attempt count
  • Current payment status
  • Automatic-recovery threshold
  • Maximum retry limit

Keeping this policy separate from the language model ensures that financial actions remain predictable, testable and explainable.

Razorpay integration

StudioPay integrates with Razorpay Payment Links in Test Mode.

Before creating a link, the backend:

  • Normalizes the currency
  • Converts rupees into paise
  • Validates customer information
  • Adds the StudioPay payment ID to Razorpay notes
  • Checks whether a compatible link already exists

When Razorpay reports a completed payment, StudioPay verifies the webhook signature using the raw request body and reconciles the provider details with the internal payment record.

AI integration

The AI Recovery Agent uses:

  • Hugging Face
  • Qwen/Qwen3-8B
  • Model Context Protocol
  • Grounded ClickHouse payment context

The model receives only relevant financial information and returns an explanation together with its model, provider and data-source metadata. It does not directly move money or bypass the recovery policy.

Challenges we faced

ClickHouse UUID mismatch

Some queries compared a ClickHouse UUID column with a String value, causing a NO_COMMON_TYPE error.

We fixed this with parameterized queries and consistent UUID conversion on both sides of the comparison.

Customer phone number disappearing

The API request contained customer_phone, but it was missing from the response and stored as an empty string.

The field was being dropped before insertion. We added it to the Pydantic model, service layer, insertion values, column list and API response. We also enabled extra="forbid" so unexpected fields produce a visible validation error instead of being silently ignored.

Invalid Razorpay currency

ClickHouse returned the currency as a bytes value such as b'INR'. Converting it directly produced an invalid Razorpay currency.

We created a normalization function that decodes bytes, removes whitespace and converts the currency to uppercase.

Incorrect Payment Link reuse

An older Payment Link was reused after a phone number had been added, but that link had been created without SMS notification.

We improved the reuse logic so an existing link is reused only when its customer phone and notification settings match the current recovery request.

Paid payment still appearing as failed

Razorpay showed that a test payment was captured, while the dashboard continued to display the original failed status.

We solved this by deriving the effective status from successful recovery records and clearing cached dashboard data after recovery actions.

Duplicate webhook processing

Payment providers may deliver the same webhook more than once.

We added an idempotency check that detects whether a payment has already been recovered. Repeated valid events return already_processed: true without inserting duplicate recovery records.

Deployment schema mismatch

The deployed backend expected the customer_phone column, but one ClickHouse environment had not received the migration.

We learned that changing a table-creation script does not modify an existing database. Schema changes must be applied through explicit, versioned migrations in every environment.

MCP SDK compatibility

The deployed MCP package exposed is_error, while our code expected isError. The actual failure was hidden inside a TaskGroup exception.

Full traceback logging helped us identify the incompatible field. We corrected the result handling and learned the importance of pinning dependency versions.

Streamlit loading time

Streamlit reruns an application after every interaction. This initially caused repeated dashboard, payment, recommendation and integration requests.

We improved responsiveness with cached read operations, session state, page-specific rendering and controlled cache invalidation after mutations.

What we learned

Building StudioPay taught us that payment recovery is not simply another retry button.

A dependable financial workflow must verify:

  • Who the payment belongs to
  • Which invoice is being recovered
  • Whether the amount and currency match
  • Whether the selected action is allowed by policy
  • Whether the payment has already been processed
  • Whether a human must approve the action

We also learned that AI should support financial decision-making without directly controlling money movement. StudioPay therefore uses AI for grounded explanations and deterministic services for execution.

Most importantly, a successful external API response is not enough. Financial systems require validation, reconciliation, idempotency and clear state transitions.

What makes StudioPay special

StudioPay does more than report a failed payment.

It understands the type of failure, selects an appropriate recovery strategy, applies financial controls, integrates with Razorpay, verifies the final outcome and uses ClickHouse as shared operational memory.

This combination of AI-assisted analysis, deterministic financial policy, human approval, provider reconciliation and ClickHouse-grounded context turns StudioPay into an agentic production-finance workflow rather than a generic payment dashboard.

Current scope and future development

The current project is an administrator-focused Agentic Cinema MVP demonstrated with Razorpay Test Mode and synthetic media-and-entertainment payment data.

Smart retries are currently recorded as scheduled recovery actions; we do not claim that a durable background worker automatically executes them. Notification requests are sent to Razorpay, but provider acceptance is not treated as guaranteed inbox or SMS delivery.

Our next production-focused improvements would include:

  • Authentication and role-based access control
  • A durable worker queue for scheduled retries
  • Provider notification-delivery tracking
  • Versioned database migrations
  • PostgreSQL for transactional workflow state
  • ClickHouse for scalable financial analytics and agent context
  • Monitoring, tracing and webhook-failure alerts
  • Vendor-specific recovery policies

Closing

StudioPay gives every failed production payment the right next scene: observe, decide, act and verify.

Built With

  • clickhouse-cloud
  • fastapi
  • github
  • hugging-face
  • model-context-protocol
  • pandas
  • pydantic
  • python
  • qwen
  • razorpay
  • render
  • requests
  • rest-api
  • streamlit
  • streamlit-community-cloud
  • uvicorn
  • webhooks
Share this project:

Updates

Submission history