Phase 104 evaluated whether Accrue should treat Braintree plus
Hyperwallet as first-party marketplace parity under
Accrue.Connect. The answer is no for the current strategic track.
Final verdict
Braintree marketplace parity through Hyperwallet is strategically out of bounds unless the project boundary changes. This is not a soft "maybe later" note. reopening requires an explicit strategy change plus a new milestone.
Why the spike landed on no-go
- Braintree recurring billing is incompatible with Marketplace.
- Hyperwallet is a separate payout program with separate webhook URLs, admin users, and API-credential recipients.
- Braintree pay-ins and Hyperwallet payouts are separate truths.
- Pretending the combined system behaves like Stripe Connect would create misleading product semantics and support debt.
Narrow if-go contract, if strategy ever changes
If the project boundary changes in a future milestone, the smallest honest slice is minimal seller onboarding + payouts only.
That slice still does not imply Stripe-style marketplace semantics. The following remain loud exclusions:
- destination charges
- separate charge-and-transfer
- login-link parity
- unified connected-account balance
Any future work must keep Braintree pay-ins and Hyperwallet payouts as separate truths in docs, capability labels, and failure modes.
What this means for Accrue today
Accrue.Connect remains a Stripe-first marketplace surface. Accrue does
not currently offer Braintree marketplace parity, and this phase does
not add new runtime APIs, callbacks, dependencies, or pseudo-abstractions
that would imply otherwise.