Estimating a payment integration

The story where the ticket says 'add Stripe' and the work says half a quarter.

Payments have a public API surface that fits on one page and a private decision surface that doesn't. Picking a provider is a one-day spike. Wiring up the happy-path checkout is a couple of days. Everything that comes after — the refund flow, the webhook retry policy, the idempotency keys, the reconciliation report finance is going to ask for in month two — is the actual feature, and none of it is on the ticket.

The story that says "integrate Stripe" is rarely the story being estimated. The story being estimated is "we can take money, refund it, prove we took it, and survive a disputed charge." Until the room is voting on that scope, the number is a guess about a different thing.

What gets said in the room

Backend: "Sandbox is straightforward. The library does most of it."

SRE: "Webhooks need idempotency. What's our retry strategy if Stripe redelivers?"

Finance: "How are refunds reconciled? Partial refunds?"

Compliance: "Are we touching card numbers, or staying SAQ-A?"

PM: "What does the failed-payment email say, and who writes it?"

Questions worth asking before voting

  • Sandbox-only first, or live keys in scope from day one?
  • Refunds and partial refunds — UI, API, or admin-only?
  • Webhook idempotency and retry handling — who owns the dedupe table?
  • PCI scope: are we keeping SAQ-A by never touching the PAN?
  • Reconciliation: who builds the report, and against which source of truth?
  • Failure UX: declined card, expired card, 3DS challenge — all in scope?

The right move on a story like this is often to split it. "Take money" is one story; "refund money" is another; "reconcile money" is a third. Estimating them as one is how the integration ships in week three and finance asks where the report is in week eight.

Adjacent: common mistakes on splitting stories late; other techniques for stories this fuzzy. Open a session when refinement is ready.