Step 2c — sell subscriptions against PlanPrice

[mitchelljkotler]

Stacks on #784.

Switches the sign-up flow onto PlanPrice before the migration, not after. That's what lets #800 be a single run rather than a sweep that has to be repeated — every subscription taken out after this ships already has a price recorded, so the migration has genuinely nothing to do for it.

Nothing existing changes. Current subscribers keep billing their legacy Stripe Plan until #800 runs.

What changed

SubscriptionItem.objects.resolve_purchase(plan, nonprofit) — returns (canonical_plan, plan_price) for a plan a customer picked. The plan they pick is not always the plan they end up on: annual and nonprofit are separate Plan rows today, and both collapse onto a canonical tier where the difference is carried by the price's interval and label.

plan_mapping.py now covers the ten purchasable slugs as well as the legacy ones. One table drives both the sign-up flow and the migration, so a new subscription is recorded exactly as a migrated one is. resolve_target(allow_comped=False) is what stops a self-service purchase resolving to a comped price.

The billing shape follows the resolved price, not plan.annual. Trusting the flag would let an annual price land on a subscription recorded as monthly — which groups it onto the wrong invoice and picks the wrong collection method. This is the subtle one.

get_plan_data() reads the nonprofit rate from PlanPrice rather than string-substituting the slug and reading base_price off a separate sunlight-nonprofit-* Plan. Display and billing now resolve the same way, so the figure shown is the figure sold — and it unblocks archiving those rows in #806. Falls back to the variant row while no PlanPrice exists.

add_subscription() takes nonprofit, threaded through from the form's checkbox.

Degrades safely

resolve_purchase returns (plan, None) when there's nothing to resolve to — which is every plan until consolidate_stripe_products has run on production, and any plan the mapping doesn't cover. That leaves the subscription on the legacy plan and legacy Stripe id, exactly as it would have been. So this is safe to ship before that command runs; it just does nothing useful yet.

QA

Before the consolidation command has run, everything below should behave exactly as it does on master — that's the fallback path, and it's worth confirming first.

After consolidate_stripe_products has run on the preview deploy:

• Buy an Organization plan (monthly). The new SubscriptionItem has a plan_price at organization / monthly / standard, and plan points at the canonical Organization row. Check Stripe: the subscription bills the new Price id, not squarelet_plan_organization.
• Buy an annual plan. The parent Subscription.interval is annual — not monthly. This is the bug the third bullet above prevents; if it's wrong the line lands on the wrong invoice group.
• Buy a Sunlight plan with the nonprofit box ticked. The price recorded is label="nonprofit", and the amount charged is the nonprofit rate.
• The Sunlight plan page shows the nonprofit price, and the number matches what ticking the box actually charges.
• Buy two plans of the same interval for one organization. Both lines land on one subscription and one invoice (that's Cancel one plan of several, not the whole subscription #784's behaviour, worth re-confirming here).
• Buy an annual and a monthly plan for one organization. Two separate subscriptions, two invoices — Stripe requires one interval per subscription.
• A comped organization is unaffected — no self-service purchase should ever resolve to a comped price.

Worth checking in the admin afterwards: every subscription created during QA has a non-null plan_price. That is the property #800 depends on.

🤖 Generated with Claude Code

https://claude.ai/code/session_0151rwxtvLg1vKEiz7XsJfzf