The insight
A payment is a story, not a record. People do not open a payment to read its fields; they open it because something is unexplained — it failed, it was disputed, the customer says they paid, the amount is wrong. All of those are questions about what happened over time.
Most financial software answers with a field list. Stripe answers with a timeline, and puts the two facts that resolve most visits — the amount and the status — above it.
What is worth stealing
Lead with the answer, not the metadata. The payment page opens with amount and status. Not created-at, not the object id. Those exist, further down, for the rare visit that needs them.
The timeline is the body of the record. Authorised, captured, refund requested, refund succeeded — each with a time and, crucially, a reason when there is one. "Payment failed — insufficient funds" answers the support question on its own, which is the difference between a log and an explanation.
Ruthless column discipline. The payment object has dozens of fields; about six reach the ledger table. Amount right-aligned in tabular figures, status as a word with a small dot, and almost nothing else. What is absent is the design.
Search is a matching problem, not an interface problem. Their search takes an amount, an email, a card fingerprint or an object id and routes each to the right kind of record. The box is trivial; the ranking is the product.
Almost nothing is modal. Reading a ledger is not a bounded interruption, so modals are reserved for confirmations and short forms — which is why the ones that do appear carry weight.
Where it does not transfer
Stripe's audience is technical and its records are immutable events. Both make the timeline model easier than it will be for you: mutable records need version history as well as an activity log, and a non-technical audience needs the vocabulary translated out of the schema.
Their density also assumes daily use. The same table shown to someone who visits monthly needs more labelling than they provide.
The extraction
When a record exists to explain something, its history is the record and its fields are the footnotes.
Ask, for any record type: do people arrive here to read the values, or to understand what happened? If it is the second, the page should open with the sequence of events and treat the field list as reference material.