Money came in, but there was nowhere to see it.
Stripe processed the payments. The orders showed a status. But there was no single view that answered: who paid, how much, with what card, and when? An operator who wanted to reconcile their week had to open Stripe in one tab and the order list in another, matching records by amount and date.
The Invoices page changed that. A new route at /invoices showing every paid order with six columns: status, customer, address, amount paid, card brand and last four digits, payment date. Stats chips at the top: total revenue, payment count, prepaid count. A "View in Stripe" link on each row for the operator who wants to see the full charge detail.
Three new columns on the orders table store what Stripe knows about the payment: the payment intent ID, the card brand, the last four digits. The confirmPayment() method now extracts card details from the charge after confirmation — wrapped in try/catch so a Stripe API hiccup never blocks payment completion.
The clever part was reusing existing infrastructure. The usePipelinePage composable — built for the leads/quotes/jobs pipeline — gained an options pattern that supports non-stage pages. The Invoices page passes paidOnly: true and a custom default sort. Same pagination, same filtering, same lazy-loading. Different question, same answer mechanism.