Knowing the cost of every payment.

Square's founding genius was one number: 2.75%, every card, every seller, no surprises. But underneath that flat rate, the cost of accepting a payment varies wildly — interchange differs by card type, network, transaction size, and how the card is presented. A rewards credit card keyed in over the phone costs Square several times what a debit card tapped in person does. Charge everyone 2.75% and some payments are very profitable, some lose money — and Square couldn't reliably tell which were which.

That blindness got expensive the moment Square wanted bigger sellers. Mid-market merchants negotiate price; you can't negotiate what you can't cost. Every large deal became a guess, and the flat rate that made Square legible to a food truck made it uncompetitive for a restaurant group. I joined Square in 2016 and founded the Payments Intelligence team to attack exactly this.

The insight was that this is a data problem before it's a pricing problem — and it has two halves that need different machinery.

Looking backward: reconcile what every payment actually cost. We built transaction-cost data — pipelines and heuristics matching every payment against the network fees it incurred — so the business could finally see per-payment profitability. The first discoveries were the kind that reorganize a roadmap: whole seller categories we'd assumed were fine turned out to lose money on the flat rate.

Looking forward: predict what a payment will cost. Interchange is published as hundreds of rate tables full of qualification rules; a payment's true cost isn't knowable with certainty until the networks settle it. So we built ML models predicting per-transaction interchange cost before the transaction settles — the capability that turns cost data into a pricing engine. That work was granted a US patent.

The product built on that data was interchange-plus pricing — cost plus a transparent margin, the pricing structure larger sellers expect. Two PMs before me had tried and stalled, both times for the same reason: scoped as a pricing project, it dragged in billing, risk, sales, and finance until it collapsed under its own coordination cost. I scoped it as a data product with a pricing surface, cut everything that wasn't required to quote and bill a real seller, and shipped it to GA in six months with one dedicated engineer.

The named trade-offs, because they were the actual decisions:

• Simplicity vs. margin. Every custom-priced seller erodes the one-rate story that made Square legible. We held the line: custom pricing stayed a negotiated, upmarket capability — a tool for deals the flat rate couldn't win, never the default.
• Prediction vs. settlement truth. Pricing on predicted cost means sometimes being wrong on a single payment. We accepted per-payment error in exchange for portfolio-level accuracy the models could defend — and reconciliation caught the drift.
• Six months vs. complete. V1 quoted and billed; it did not automate the sales workflow around it. Two prior efforts died trying to ship everything. Shipping the kernel got the capability into deals years earlier.

The forward vision — pricing as an automated, data-driven system rather than an annual spreadsheet exercise — I presented to Jack Dorsey, who asked me to present it at Square's company all-hands. For a team that had started as a data problem nobody owned, that was the moment the company understood what it had.

Two outcomes, one internal to the pricing system and one visible on Square's public price tag.

First: the transaction-cost data and custom-pricing capability became part of the machinery behind Square's move upmarket — mid-market sellers grew from about a quarter of Square GPV (Q4 2019) to 40% (Q4 2023), per Block's quarterly disclosures. Named platform customers like Shake Shack — whose cashless kiosks ran on Square — are the kind of seller that simply doesn't sign without negotiated economics, and negotiated economics don't exist without cost data.

Second: in 2019, Square changed its flagship rate for the first time in the company's history — from 2.75% to 2.6% + 10¢. My team's transaction-cost models supported that repricing — the first change Square ever made to the number the company was built on, made with the per-payment economics finally visible.

• Treat reconciliation as a product, not a project. Cost data decays — networks change rate tables, acquirers have bugs, categories drift. We built the pipelines and then had to keep re-earning their accuracy. I'd staff the maintenance as deliberately as the build from day one.
• Bring sales into the room at the design stage. V1 gave deal teams a capability but not a workflow, and adoption ran on heroics for the first year. The people who negotiate price should have shaped the tool that quotes it.
• Write down the automated-pricing end state earlier. The vision that ended up at the all-hands existed in fragments for a year before I committed it to one document. The document did more than the fragments ever did — a lesson I've applied to every platform bet since.