Problem
#4791 ("Settlement & refund handling") is confirmed AMS/Rent-a-Loop-scoped only — its deliverables tie to #6098's SettlementBackend.reversePayout, all loop-settlement concepts (completed/killed/failed loop runs). Nothing analogous exists for ORB's own hosted-SaaS subscription billing (#4919/#4920) — no issue defines what happens when an ORB customer's card is declined, they dispute a charge, or cancel mid-billing-cycle. Different product, different billing shape (subscription vs. compute-metered), genuinely separate problem from #4791.
Area
Product spec / ORB billing (#4919/#4920's cluster).
Proposal
Define, at spec level: declined-payment handling, dispute/chargeback response, and cancellation/proration behavior for ORB's subscription billing specifically. Depends on #4919/#4920 landing first (can't spec refund mechanics against a billing system that doesn't exist yet) and on the payment-processor decision (Stripe vs. other — see the accompanying decision list), since refund/dispute mechanics differ materially by processor.
Deliverables
Resources
Boundaries
Spec only, and explicitly blocked on the payment-processor decision — don't scope real numbers or a processor-specific implementation until that's chosen.
maintainer-only — business/product decision, not a build task.
Problem
#4791 ("Settlement & refund handling") is confirmed AMS/Rent-a-Loop-scoped only — its deliverables tie to #6098's
SettlementBackend.reversePayout, all loop-settlement concepts (completed/killed/failed loop runs). Nothing analogous exists for ORB's own hosted-SaaS subscription billing (#4919/#4920) — no issue defines what happens when an ORB customer's card is declined, they dispute a charge, or cancel mid-billing-cycle. Different product, different billing shape (subscription vs. compute-metered), genuinely separate problem from #4791.Area
Product spec / ORB billing (#4919/#4920's cluster).
Proposal
Define, at spec level: declined-payment handling, dispute/chargeback response, and cancellation/proration behavior for ORB's subscription billing specifically. Depends on #4919/#4920 landing first (can't spec refund mechanics against a billing system that doesn't exist yet) and on the payment-processor decision (Stripe vs. other — see the accompanying decision list), since refund/dispute mechanics differ materially by processor.
Deliverables
Resources
Boundaries
Spec only, and explicitly blocked on the payment-processor decision — don't scope real numbers or a processor-specific implementation until that's chosen.
maintainer-only — business/product decision, not a build task.