← All Square work Square · decision memo

The Stripe competitor we shut down.

In 2017, Square invested $25M in Eventbrite and became its payments partner. I led the platform we built to power it — twelve APIs, an alpha with ten marketplaces live in production. Then Eventbrite left for Stripe, and I wrote the shutdown recommendation myself. This is that memo, told straight.

RoleLead PM — Marketplaces platform
When2018 – 2020
OutcomeShut down — deliberately
Read~5 minutes
What this demonstrates
  • An owned failure, accounted for structurally. Not "we learned a lot" — the specific reason a well-funded bet lost: payment-facilitator economics put Square in the liability chain, and that made piecemeal adoption impossible.
  • Knowing when to stop. I recommended shutting down a program I led, against sunk cost and a public commitment, and executed the wind-down myself.
  • Salvage as strategy. The API decomposition built for marketplaces became Square's modern public platform, and the strategy the failure forced — serve Square sellers, not any seller — is the one the business still runs on.

The bet

In September 2017, Square announced a partnership with Eventbrite: Square would become the ticketing platform's payments provider, and the deal included a $25M Square investment in Eventbrite — championed by Square's then-CFO, who now runs finance at OpenAI. The strategic logic was real. Marketplaces were where online payment volume was concentrating, Stripe had built a franchise on exactly that ground, and Eventbrite was proof that a serious platform would put its money flows on Square. If we could power Eventbrite, we could power any marketplace — and open up volume far beyond Square's own sellers.

I was the lead PM for the platform that had to deliver it.

What we built

A marketplace can't run on seller tooling. It needs the payments stack itself, exposed as APIs: onboard sellers programmatically, manage their bank accounts, move and split funds, handle disputes — all without anyone ever opening a Square dashboard. So we decomposed Square's payments stack into twelve public-facing APIs — accounts, balances, bank accounts, cards, disputes, payments, refunds, and payment configurations among them.

The work nobody sees from the outside was the hardest part: winning PAN acceptance for PCI Level 1 partners, structuring money-transmission fund flows that regulators would accept, and writing API terms of service that our own compliance team would sign. Card brands, state regulators, and internal counsel — in that order, repeatedly.

It worked, as far as it went. The alpha was live with ten marketplaces in production — theCut and Porter were among them — processing real payments for real sellers. On the surface, a platform being born.

The wall

The problem wasn't execution. It was structural, and it lived in how Square makes money. Square is a payment facilitator: the master merchant of record for every seller it onboards. Square underwrites the seller, carries the fraud and credit risk, and answers to the card networks for everything that seller does. That structure is a superpower when the seller is yours — it's why a food truck can take cards in ten minutes.

It's a straitjacket when the seller belongs to someone else's platform. Powering a marketplace meant pulling its entire seller base into Square's liability chain — our underwriting, our risk models, our fund flows — all at once. There was no way to adopt us piecemeal. Stripe had spent a decade making the opposite bet: modular primitives a platform could take one piece at a time, holding its own relationship with its own sellers. For a marketplace CTO, one of these is an integration; the other is a migration of their whole business.

Square — payment facilitator
  • Square is merchant of record for every seller
  • Square underwrites; Square carries the risk
  • Platform's sellers become Square's sellers
  • Adoption is all-or-nothing — a migration
Stripe — modular primitives
  • Platform keeps its own seller relationships
  • Take payments alone; add pieces later
  • Risk and compliance surface area is scoped
  • Adoption is incremental — an integration
The structural read from the post-mortem: for a marketplace, one of these is an afternoon; the other is a bet on the company.

There was a second wall behind the first. Square's whole company — sales, support, risk, pricing, brand — was tuned for small sellers. Marketplace customers are platform engineering teams with procurement cycles, custom fund-flow requirements, and a competitor whose entire company existed to serve them. My own line from the post-mortem: don't try to compete with Stripe in your spare time.

Eventbrite felt both walls before we named them. Frustrated with the shape of the integration, they exited the agreement and moved to Stripe.

The call

After Eventbrite left, the honest options were two, and neither was the one the org would drift into by default. We could double down: stand up a separate business unit with its own P&L, its own go-to-market, and a multi-year commitment to out-invest a focused competitor on its home turf. Or we could shut it down. The default — keep a skeleton crew on it and hope — was the only indefensible choice, because it paid the strategic cost of competing with Stripe without the investment required to actually do it.

The double-down case failed on its own terms. As I put it then: we were effectively trying to spin out AWS without a separate P&L — running a platform business for other companies' sellers out of the spare capacity of a company built to serve its own. And nobody was going to grant that P&L, for a good reason: Square's core seller business was working, and every dollar here was a dollar not compounding there.

I recommended shutdown, and then I executed it: wound down the alpha, worked migration paths for the ten platforms, and retired the marketplace APIs. The deal that opened with a $25M investment closed with our flagship partner on our competitor. That sentence still stings, which is part of why I keep it in the memo.

What the wreckage became

The bet failed; the engineering didn't. Decomposing the payments stack for marketplaces had forced us to build what Square had never had — its core capabilities as clean, public-grade APIs. That decomposition became the spine of Square's modern public developer platform: the cards, bank accounts, disputes, and underwriting APIs that shipped publicly over the following years, several of them growing into standing teams that exist today.

The failure also handed us the strategy. The post-mortem's conclusion — we win by serving Square sellers, not any seller — became the developer platform's operating thesis, and it's the one the business still runs on. What that platform grew into is its own memo: hundreds of partners, an SEC-filed disclosure about mid-market volume, and a business I later ran.

I'm deliberately not dressing this section up with recovered-value numbers. The honest accounting is: the program lost, the parts were worth keeping, and the lesson was worth more than the parts.

What I'd do differently

  • Run the structural analysis as a pre-mortem, not a post-mortem. Everything in section 03 was knowable in 2017. Nobody wrote it down before the deal, because the deal was exciting and the analysis wasn't. I now write the shutdown memo first and make the bet argue against it.
  • Set kill criteria on day one. We defined what success looked like and never defined what failure would look like, so the program's end had to arrive as a crisis instead of a checkpoint.
  • If it needs its own P&L and can't have one, that's the answer. A platform business inside a product company either gets real structural commitment or it's a hobby with enterprise customers. I'd force that decision at the start — and accept "no" as a valid, cheap outcome.