Assumption #1 — Vendor (user-provided)
Statement: We assume Stripe's payment-method support covers all our customer regions.
Validation method: Pull region/coverage matrix from Stripe docs + cross-reference against our customer-base region distribution.
Cost to validate: 2 hours
If wrong: Some regions need a 3rd acquirer or a workaround; could add 4-6 weeks to scope.
Confidence today: Medium
Validate by: End of week 1

Assumption #2 — Technical (user-provided)
Statement: We assume the existing reconciliation format can stay unchanged through migration.
Validation method: Walk through current reconciliation flow with the Finance team; confirm the new provider produces compatible export shape.
Cost to validate: 1 half-day workshop with Finance + payments engineer.
If wrong: Reconciliation rewrite adds 4-8 weeks; Finance team also affected.
Confidence today: Medium
Validate by: End of week 2

Assumption #3 — Capability
Statement: We assume our payments engineers can ramp on Stripe's API conventions within 2 weeks.
Validation method: One engineer prototypes a full payment flow against the Stripe sandbox in week 1; measure time-to-working-flow.
Cost to validate: 1 engineer × 1 week.
If wrong: Add 1-2 weeks of ramp / training; compresses build window.
Confidence today: Medium-high
Validate by: End of week 1

Assumption #4 — Schedule
Statement: We assume compliance review starts no later than month 3 (gives us 3 months to address findings before launch).
Validation method: Email compliance lead to confirm review-window booking.
Cost to validate: 1 email + 1 reply.
If wrong: Compliance review compresses, potentially gating launch; this is the single biggest schedule risk.
Confidence today: Low
Validate by: End of week 1

Assumption #5 — Budget
Statement: We assume the engineering effort fits within the 8-engineer × 6-month capacity allocation, with 10% buffer for unknowns.
Validation method: Estimate the 5 largest workstreams in person-weeks; total must be < 86 person-weeks (with buffer).
Cost to validate: Half-day estimation session with team.
If wrong: Need to descope, extend timeline, or borrow capacity.
Confidence today: Medium
Validate by: End of week 2

Assumption #6 — Customer / User
Statement: We assume enterprise customers will tolerate a 5-minute downtime window during cutover if announced 30 days in advance.
Validation method: Sample 5 enterprise customers; confirm via Customer Support lead. Look at past customer-incident comms tolerance.
Cost to validate: 5 calls × 30 min, or a single CS lead conversation referencing past incidents.
If wrong: Cutover strategy changes — either zero-downtime architecture (more effort) or compensation for affected customers.
Confidence today: Medium
Validate by: End of week 4

Assumption #7 — Compliance / Regulatory
Statement: We assume PCI scope doesn't expand under the new architecture (i.e. we remain a "Service Provider" Level 1 with no new attestation requirements).
Validation method: Compliance + InfoSec review of the architecture diagram. Confirmed in writing.
Cost to validate: 1 review meeting + follow-up doc.
If wrong: New compliance attestation timeline adds 8-12 weeks plus external audit cost.
Confidence today: Medium-high (architecture is similar to current)
Validate by: End of month 1

Assumption #8 — Vendor
Statement: We assume the backup acquirer can be brought online in parallel with Stripe (not sequentially) without doubling the integration burden.
Validation method: Architecture session — confirm shared abstraction layer is feasible.
Cost to validate: 1 architecture session (2 hours).
If wrong: Backup-acquirer effort sequentially instead of in parallel — could push backup integration to phase 2 (post-launch).
Confidence today: Medium
Validate by: End of week 3

Assumption #9 — Internal Stakeholder
Statement: We assume the Customer Support team will own customer comms during cutover (not Marketing).
Validation method: 15-min conversation with CS lead + Marketing director.
Cost to validate: Two short calls.
If wrong: Cross-team coordination cost; possibly delayed comms readiness at cutover.
Confidence today: Medium
Validate by: End of week 2

Assumption #10 — Data
Statement: We assume historical payment data (3 years) is exportable from the legacy provider in a usable format and within 30 days.
Validation method: Request a sample export from legacy provider. Test that it imports into our analytics tooling without transformation.
Cost to validate: 1 vendor email + 2 days of vendor response.
If wrong: Historical data migration becomes a separate workstream; may require building an ETL adapter.
Confidence today: Low
Validate by: End of month 1

Top 3 to validate THIS WEEK:
1. Assumption #4 (compliance review window) — biggest schedule risk, cheapest to check (an email). Don't leave this hanging.
2. Assumption #1 (Stripe regional coverage, user-flagged) — affects scope; 2-hour cost to validate.
3. Assumption #2 (reconciliation format, user-flagged) — biggest "stealth scope" risk; 1 half-day to validate.