feat(billing): generic partner billing provider for marketplace partners

Problem

Partner platforms increasingly want to front the billing relationship for their users — they receive invoices and usage from PostHog, collect from their users on their own billing infrastructure, and pay PostHog out-of-band per the marketplace contract. This is the "Vercel for Platforms" pattern.

Vercel uses this model today via a one-off VercelClient in the billing service. As more partners ask for the same shape, we need to lift the Vercel-specific implementation into a generic MarketplaceBillingProviderClient abstraction so adding the next partner is config + a registration flag, not net-new infrastructure.

Goal

A single BillingProviderClient shape any marketplace partner can plug into:

• Wire up via partner's CIMD registration (or admin) by setting provisioning_billing_provider on the OAuthApplication
• On Customer creation during agentic provisioning, stamp the right provider on the customer record (immutable, matches existing Vercel contract)
• Billing pipeline dispatches every per-customer invoice and usage submission through that provider's client

Scope

• Core abstraction — extract MarketplaceBillingProviderClient base from VercelClient. Re-implement Vercel as an instance of the generic shape, no behavior change for Vercel.
• Generic invoice submission webhook — child issue, see sub-issues.
• Generic usage submission webhook — child issue, see sub-issues.
• Provisioning-side wiring — provisioning_billing_provider: str = "" field on OAuthApplication. Partner registration sets it. Customer creation reads it and stamps Customer.billing_provider.
• OrganizationIntegration — extensible kind so each new partner has a place to store auth credentials.

Open architectural decision: auth scheme

The biggest unresolved call. PostHog needs to authenticate to the partner's API on every invoice/usage submission. Three reasonable shapes, all already in use somewhere in the PostHog integration ecosystem:

Initial lean: B — long-lived API key — for the first new partner. Lowest lift, easy to rotate when needed, degrades cleanly to a slot future partners can fill in. Doesn't preclude offering A or C later as additional supported schemes per partner.

Tracking the decision here rather than splitting to its own issue because the answer determines a chunk of the base class API. Open to input.

First concrete user

Insforge — YC backend-as-a-service for AI coding agents (~25k devs). Met 2026-05-01. They want PostHog to feel native inside their platform with Insforge fronting the billing relationship. They'll be the first partner using the generic shape end-to-end. They want invoice + usage submission so they can show real-time usage in their own UI. Spec for the Insforge-specific surface is internal.

Reference

• Existing Vercel client: billing/billing_providers/clients/vercel.py
• Existing Vercel formatter: billing/billing_providers/formatters/vercel.py
• billing/notes/billing_providers/README.md
• Provisioning side: posthog/models/oauth.py (provisioning_* fields), ee/api/agentic_provisioning/views.py (Customer creation)

RFC reference

RFC #1077 — Self-serve agentic provisioning platform (merged). Doesn't cover billing-provider integration explicitly; this issue is the natural follow-on for partners that want partner-mediated billing in addition to provisioning.