Reconciliation breaks first, almost always before throughput does. Payment systems scale their happy path comfortably; what does not scale is the manual work around the edges, meaning unmatched settlements, partial reversals and provider discrepancies, because that work grows with volume while the team handling it does not. The number that predicts the wall is not payments per second, it is exceptions per day and how many of them a human touches.
This is counterintuitive because throughput is the thing that gets load-tested. A system demonstrated at ten times current volume can still fail at twice it, if the exception rate is a fixed percentage and each exception costs fifteen minutes of an operations analyst who does not exist in triplicate.
The second thing to go is usually the provider reconciliation. Every payment provider returns settlement files on their own schedule, in their own format, with their own definition of a completed transaction. And matching those against internal records is trivial at a hundred a day and a full-time function at a hundred thousand. Teams that treated it as a reporting task discover it is a core system.
Database contention arrives later than expected but arrives suddenly, and almost always on the ledger's hot rows: a small number of control or nostro accounts that every posting touches. The fix is structural, partitioning the contention away, and it is significantly easier before those rows are the busiest thing in production.
The useful discipline is to instrument the exception path from day one with the same rigour as the happy path: how many, of what kind, how long each takes, and how many required a person. That number, tracked over time, tells you where the wall is long before you hit it.