{"slug":"exemplar-stripe","meta":{"title":"What Stripe Figured Out","slug":"exemplar-stripe","kind":"exemplar","summary":"That money software is read far more often than it is written, so the product is built around inspecting a past event rather than performing a new one.","problem":"Financial tools are usually designed around the transaction — the form that takes the payment. But almost all the time anyone spends in one is afterwards, asking what happened to a specific payment and why.","family":["inspect","scan"],"principles":["progressive-disclosure","orientation"],"status":"stable","visibility":"public","related":[{"title":"Activity Timeline","url":"/patterns/activity-timeline","summary":"The pattern their payment view is built on — history first, fields second."},{"title":"Dense Operational Table","url":"/patterns/dense-operational-table","summary":"Their ledger, and the columns they refused to add."},{"title":"Object Identity Header","url":"/patterns/object-identity-header","summary":"Amount and status first, because those two facts resolve most visits."}]},"body":"## The insight\n\n**A payment is a story, not a record.** People do not open a payment to read its\nfields; they open it because something is unexplained — it failed, it was\ndisputed, the customer says they paid, the amount is wrong. All of those are\nquestions about *what happened over time*.\n\nMost financial software answers with a field list. Stripe answers with a\ntimeline, and puts the two facts that resolve most visits — the amount and the\nstatus — above it.\n\n## What is worth stealing\n\n**Lead with the answer, not the metadata.** The payment page opens with amount\nand status. Not created-at, not the object id. Those exist, further down, for\nthe rare visit that needs them.\n\n**The timeline is the body of the record.** Authorised, captured, refund\nrequested, refund succeeded — each with a time and, crucially, a *reason* when\nthere is one. \"Payment failed — insufficient funds\" answers the support question\non its own, which is the difference between a log and an explanation.\n\n**Ruthless column discipline.** The payment object has dozens of fields; about\nsix reach the ledger table. Amount right-aligned in tabular figures, status as a\nword with a small dot, and almost nothing else. What is absent is the design.\n\n**Search is a matching problem, not an interface problem.** Their search takes\nan amount, an email, a card fingerprint or an object id and routes each to the\nright kind of record. The box is trivial; the ranking is the product.\n\n**Almost nothing is modal.** Reading a ledger is not a bounded interruption, so\nmodals are reserved for confirmations and short forms — which is why the ones\nthat do appear carry weight.\n\n## Where it does not transfer\n\nStripe's audience is technical and its records are immutable events. Both make\nthe timeline model easier than it will be for you: mutable records need\n[version history](/patterns/version-history) as well as an activity log, and a\nnon-technical audience needs the vocabulary translated out of the schema.\n\nTheir density also assumes daily use. The same table shown to someone who visits\nmonthly needs more labelling than they provide.\n\n## The extraction\n\n\u003e **When a record exists to explain something, its history is the record and\n\u003e its fields are the footnotes.**\n\nAsk, for any record type: do people arrive here to *read the values*, or to\n*understand what happened*? If it is the second, the page should open with the\nsequence of events and treat the field list as reference material.\n"}