Firebase support desk with account actions and Stripe billing

Build me an internal support desk app for our Firebase-backed product. A support agent opens it, types a customer's email address, phone number, or Firebase uid into a single search box, and gets that one person's entire account on one screen, so the team stops pinging an engineer for every lookup.

The search resolves the identifier against both systems at once. Use Firebase Look Up Auth Users to find the auth record by uid, email, or phone number. Use Stripe Search Customers with a query on the email to find the billing record. Handle mismatches plainly instead of erroring out. If the person exists in Firebase but no Stripe customer matches, render the profile normally and put a line on the Billing tab saying no Stripe customer was found for this email, with the email shown so the agent can go check Stripe by hand. If a Stripe customer matches but no Firebase auth user does, show a billing-only view with a banner explaining that this customer pays us but has no app account under that address, which usually means they signed up with a different email. If several Stripe customers share the email, list them and let the agent pick which one to view.

The page header is the Firebase Auth record: display name and photo if present, email with a verified or unverified badge, phone number, the uid with a copy button, the sign-in providers on the account (password, Google, Apple and so on), the created date, the last sign-in date, and an unmissable enabled or disabled state. Any custom claims already set on the account render as chips in the header, since those claims are the entitlements support cares about.

An App data tab lists that person's records from the Firestore collections we care about, keyed by their uid. Use Get Firestore Document to fetch their main user document (usually users/{uid}) and show it at the top of the tab, then use Run Firestore Query with a filter on the uid field for each configured collection, ordered newest first with a small limit, rendering each collection as its own section with a readable table and a raw JSON toggle for the awkward nested fields. Which collections appear, and which field holds the uid in each one, must be configurable in a settings screen rather than hardcoded, because every app names these differently.

A Billing tab shows the Stripe side. Use List Subscriptions filtered to the customer for the current plan, its status, and the renewal or cancellation date. Use List Invoices filtered to the customer with a limit of twelve for recent invoice history, each row showing amount, date, and a paid, open, or failed badge with the failure reason where Stripe provides one. Use List Refunds for the customer so an agent can immediately see whether this person has been refunded before. Stripe returns amounts in the smallest currency unit, so format them as real money everywhere. If our Firestore already mirrors Stripe data, which it does when the official Run Payments with Stripe extension is installed and writing customers/{uid} documents with subscriptions and invoices underneath, read those mirrored documents as well and show them next to the live Stripe data, flagging anything that disagrees.

An Actions panel handles the four things support always has to escalate for. First, disable or re-enable the account using Firebase Update Auth User, behind a confirmation dialog with a required reason. Second, grant or remove an entitlement by setting a custom claim, also with Update Auth User: a small form where the agent picks a claim key from a configured allow list, such as a plan tier or a beta flag, and sets its value. Setting a claim must merge with the existing claims rather than overwrite them, and the UI should say that custom claims reach the customer's device within about an hour or on their next sign-in, so agents stop asking why nothing changed instantly. Third, send that one person a push notification: read the device token off their user document and use Send Push Notification (FCM), with title and body fields and a preview of what the customer will actually see. Fourth, issue a full or partial refund with Stripe Create Refund, launched from a specific invoice or charge row rather than a free-floating form, requiring the agent to type the word REFUND to confirm, choose full or a partial amount, and write a reason.

Every action writes an audit document using Create Firestore Document into a support audit collection: the action taken, the target uid and email, the before and after values, the reason the agent typed, the name and email of the signed-in agent taken from the app viewer, and a timestamp. No action happens without its audit document. The profile renders the most recent audit entries for that customer inline, so an agent can see the last handful of things done to this account before touching anything.

Refunds above a configurable ceiling are blocked rather than executed. When an agent requests one, the app does not call Stripe at all. It posts a full context card to a Slack channel using Slack Bot Send a Message: the customer's email and uid, the charge and invoice details, the amount requested, the reason the agent gave, the account's refund history, and the plan they are on, so a manager has everything needed to approve or decline from that one message. The app tells the agent plainly that the request went to a manager for approval, and writes the same audit document with a blocked status.

Add an Investigate this account button that starts a background agent scoped to that customer. The agent reads the Firebase Auth record with Look Up Auth Users, the person's recent Firestore documents across the configured collections with Run Firestore Query, their billing history with List Invoices, List Subscriptions and List Refunds, and the existing support audit entries, then writes a plain-English timeline of what has happened to this account: when they signed up and how, what they did in the app, when payments failed, what support already changed and why, and the most likely explanation for whatever they are complaining about now. It writes that timeline with Create Firestore Document into a Firestore support notes collection, keyed by uid with a timestamp and the name of the agent who started it. The profile renders those support notes inline in reverse chronological order, so the next agent who opens this account sees what already happened instead of starting from zero. Show a running state on the button and refresh the notes list when the agent finishes.

A settings screen holds the configuration: which Firestore collections appear on the App data tab and the uid field name in each, the paths for the support audit and support notes collections, the field on the user document that holds the push device token, the allowed custom claim keys and values, the refund ceiling amount, and the Slack channel for manager approvals.

Design it for speed in a support queue: one search box that accepts any of the three identifiers, a dense profile that mostly fits without scrolling, tabs rather than accordions, human dates and formatted money everywhere, and destructive actions visibly separated from safe ones. A read failure on one tab must never blank the page: show what loaded and say plainly which part could not be fetched.