Phase 01 — Strategic Context
OKRs, product principles, Opportunity Solution Tree and assumptions map.
Main OKR
Objective
Make payments invisible to the ECP ecosystem — any app processes any payment method with a single call, without knowing gateways, without duplicating code, without depending on external services to develop.
Timeline: Q2-Q3 2026 | 5 measurable Key Results
KR-01
Reduce integration time for a new app with payments from weeks to hours
Average time for a new app to process its first payment via ECP Pay (from first import to confirmed payment in staging)
Q2 202685%
KR-02
Centralize 100% of ecosystem transactions in a single observable ledger
Percentage of ECP ecosystem financial transactions that pass through ECP Pay (vs. direct gateway calls)
Q3 202660%
KR-03
Ensure gateway swap requires no changes to any consumer app
Number of lines of code changed in consumer apps when switching provider (e.g., Asaas to Stripe)
Q2 2026100%
KR-04
Eliminate dependency on external services for development and testing
Percentage of payment test scenarios that run without internet connection (internal mode)
Q2 2026100%
KR-05
Achieve production reliability measured by availability and event delivery
API availability (uptime) and webhook delivery rate on first attempt
Q3 202670%
Product Principles
PP-01
Contract above implementation — ECP Pay's value lies in API contract stability. Internal provider changes MUST NEVER leak to consumers.
PP-02
Development without external dependencies — Internal mode is a first-class feature ensuring any dev runs the full ecosystem with a single command.
PP-03
Observability as a first-class citizen — Every operation must be auditable, every failure investigable, every webhook traceable.
PP-04
Security by design, not by checklist — Sensitive data is never stored. Tokens replace real data. Security is in the architecture.
PP-05
Operational before beautiful — The admin panel prioritizes information density, powerful filters and quick actions over aesthetics. Inspiration: Stripe Dashboard.
PP-06
Idempotency is non-negotiable — In financial systems, processing an operation twice is worse than not processing it. Every mutation must be idempotent by design.
Opportunity Solution Tree (OST)
15 opportunities mapped to 5 Key Results, organized by type (pain, need, desire). Each opportunity identified from product briefing and tech spec evidence.
| ID | Opportunity | Type | KRs |
|---|---|---|---|
| OPP-01 | Each app reimplements all Asaas integration logic, generating weeks of repetitive work | pain | KR-01 |
| OPP-02 | Developers need to understand each gateway's proprietary API instead of consuming a single contract | pain | KR-01 |
| OPP-03 | New devs need a quick path to run the ecosystem and test payments without complex setup | need | KR-01 |
| OPP-04 | Operators have no consolidated view of transactions — must access separate dashboards per gateway | pain | KR-02 |
| OPP-05 | Owner needs to understand how much each app transacts and the distribution across payment methods | need | KR-02 |
| OPP-06 | Investigating failures requires accessing logs in multiple systems, with no correlation between order and gateway status | pain | KR-02 |
| OPP-07 | If Asaas changes fees or API, all apps need to be updated simultaneously | pain | KR-03 |
| OPP-08 | Ecosystem wants freedom to negotiate with multiple gateways without rework in the apps | desire | KR-03 |
| OPP-09 | Consumer apps need contractual stability — the contract cannot break due to infra decisions | need | KR-03 |
| OPP-10 | Automated tests depend on Asaas sandbox that is slow, unstable and requires credentials per dev | pain | KR-04 |
| OPP-11 | Demos and presentations are held hostage to connectivity and sandbox availability | pain | KR-04 |
| OPP-12 | Staging needs to be deterministic and controllable for validation before production | need | KR-04 |
| OPP-13 | Apps need guarantee that callbacks will be delivered even in temporary failure scenarios | need | KR-05 |
| OPP-14 | Without idempotency, retries can cause duplicate charges or inconsistent processing | pain | KR-05 |
| OPP-15 | Operators need webhook replay, reprocessing and refunds accessible without engineering | need | KR-05 |
Open Questions
OQ-01
What is the expected transaction volume in the first quarter? This impacts infrastructure decisions and the availability target.
OQ-02
Is there a forecast for when the Stripe adapter will be needed, or is Asaas sufficient for the 2026 roadmap?
OQ-03
Will payment split be used only in ecp-food or is there demand in other apps?
OQ-04
How will the KR-01 baseline be measured? Use ecp-food's integration time with Asaas as reference?
Assumptions
AS-01
The three initial apps will migrate to consume ECP Pay
Risk: If any app chooses to keep direct integration, KR-02 (100% centralization) will not be achieved.
AS-02
Internal mode will have complete functional parity with Asaas in the API contract
Risk: If there is a contract divergence between modes, apps will behave differently in dev vs. production.
AS-03
Transaction volume compatible with SQLite in the first year
Risk: If volume grows beyond expectations, SQLite may become a bottleneck sooner than planned.
AS-04
Asaas will be the only production gateway in v1
Risk: Low — the provider interface guarantees extensibility even if Stripe is delayed.