Braintree customer billing lookup for support agents

Build me an internal billing lookup console for my support agents, so they can answer "where is my refund" style questions without logging into the Braintree Control Panel. It is one screen per customer: the billing history and the support conversation together, plus the buttons to act on both.

Landing view: a single search box where an agent types an email address, a name, or a customer ID, backed by Braintree Search Customers. Show the matches as a compact list with name, email, customer ID and created date. Picking one opens the customer screen. Keep the search box available at the top of the customer screen so agents can jump to the next person without going back.

Customer screen header: name, email, customer ID, and quick totals (lifetime amount charged, amount refunded, number of transactions). If this customer has ever filed a dispute, show a persistent warning badge in the header, for example "Has filed disputes (2)", using a semantic warning style rather than a raw color, and keep it visible no matter which panel the agent is looking at.

Billing timeline: the main panel, from Braintree Search Transactions scoped to this customer, newest first, with load-more paging. Each row shows date, amount and currency, status (authorized, submitted for settlement, settled, settling, voided, refunded, failed, gateway rejected), the payment method used with card brand and last four, and the order ID if there is one. Style the status as a labelled badge so an agent can scan the column. Mark any row whose transaction is tied to a dispute with an inline flag.

Side panels on the same screen, each collapsible so the page stays readable. Disputes, from Braintree Search Disputes for this customer: status (open, won, lost, accepted), reason, amount, case number, received date and reply-by date, split into open and resolved. Card checks, from Braintree Search Verifications: the recent verification attempts with status, processor response and date, so an agent can tell a genuinely dead card from a one-off decline. Cards on file: the payment methods currently in this customer's vault as returned with the customer record, showing brand, last four, expiration and whether it is the default.

Support conversation panel: Zendesk Search Tickets using the customer's email address, showing the ten most recent tickets with subject, status, requester, created and updated dates. Expanding a ticket loads its latest comment through Zendesk List Ticket Comments, with the author and timestamp, plus a link out to the ticket in Zendesk. The point is that the agent never has to alt-tab mid-chat, so load these alongside the billing data rather than behind a separate tab.

Actions available from the same screen. On a settled transaction, Refund, which opens a dialog with a full-or-partial choice, an amount field defaulting to the full amount and validated against it, and a required reason field, then calls Braintree Refund Transaction. On an unsettled transaction, Void, with a required reason, calling Braintree Void Transaction. Show only the action that applies to that transaction's status. On a card in the vault, Remove card, with a required reason, calling Braintree Delete Payment Method From Vault, behind a confirm step because it is permanent. The submit button stays disabled until the reason field has content, on every one of these dialogs.

Refund threshold: keep a configurable amount in app settings, default 250 in your account currency, editable from a small settings panel in the app. A refund at or above that amount requires a second confirmation step after the reason dialog: a summary of what is about to happen (customer, transaction, amount, reason) and a confirm field where the agent retypes the refund amount before the button enables. Below the threshold, the single dialog is enough. This is in-app behaviour rather than a permissions model, and the same applies to the mandatory reason.

After any successful refund, void or card removal, post to a configurable support channel with Slack Send a Message: the acting agent's name, the customer name and email, the action taken, the amount, the transaction or payment method ID, the reason text, and the timestamp. Format it so finance can read the channel as an audit log. If the Braintree call fails, surface the error inline on the row and do not post to Slack.

Customer confirmation email: after a refund or a void, offer to email the customer with Gmail Send a Message, prefilled from an editable template that states what was done, the amount, the payment it relates to and roughly when the money will land. The agent can edit the subject and body before sending, and can skip the email. Default the offer to on for refunds and voids, and off for card removals.

Persistence and identity: store an action log in the app (customer, action, amount, reason, acting agent, timestamp, resulting IDs, whether an email was sent) and show the recent actions for that customer at the bottom of their screen, so the next agent sees what a colleague already did. Handlers run as the app owner, so identify the acting agent from the signed-in app user where available, and otherwise have each agent pick their name once from a configurable roster and remember it for their session. Do not design this around platform viewer or approver roles.

General behaviour: everything is one screen with panels, not a wizard. Show loading states per panel so the billing timeline is usable while tickets are still loading, and handle the case where a customer exists in Braintree but has no tickets, no disputes or no vaulted cards with a quiet empty state rather than an error.