Why

HybridCheckoutDrawer currently derives payment methods in a way that leaks business policy into downstream apps.

For a real adopter, payment methods must be explicit capabilities, not package guesses.

Deliverables

• remove implicit Cash at Visit from generic defaults
• require explicit payment options and explicit cash allowance when relevant
• support connected-account-aware Stripe configuration as part of the public contract
• add package-level tests proving no hidden payment methods appear

Completion Metrics

• a downstream app can disable cash without forking package code
• payment options rendered by the package are explicit and deterministic
• connected-account-aware Stripe inputs are first-class contract inputs
• package tests fail if implicit payment policy reappears

Related Work

• child of #41
• paired with MassageIthaca#122