fix(billing): make billable-GMV event types explicit + extensible - #70
Open
keithfawcett wants to merge 1 commit into
Open
fix(billing): make billable-GMV event types explicit + extensible#70keithfawcett wants to merge 1 commit into
keithfawcett wants to merge 1 commit into
Conversation
Metering counted only invoice_paid + subscription_created toward attributed GMV, so a merchant reporting revenue under a CUSTOM event type accrued partner commissions but escaped the platform % (revshare 3% / flex 1.5%). Make the billable set an explicit, documented semantic: default to the two Stripe- native types, extend via OPENPARTNER_BILLABLE_EVENT_TYPES_EXTRA (comma- separated) for operator-known custom revenue types. aggregateAttributedGmv now takes the event-type set (default = configured) so it's explicit at the call site and testable. Chosen (with the user) as the safe option: it changes NO existing invoice and locks in no possibly-wrong auto-semantic — no GMV definition is fully dodge-proof on self-reported data (percent-base just moves the dodge to fixed commissions; count-all over-bills mislabeled values). Per-tenant granularity + auto-detection are follow-ups. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem (audit #3 — HIGH)
Metering counted only
invoice_paid+subscription_createdtoward attributed GMV. A merchant reporting revenue under a custom event type (e.g.order_paid) accrued partner commissions but escaped the platform % (revshare 3% / flex 1.5%).Fix (the safe option, chosen with the owner)
Make the billable set an explicit, documented semantic: default to the two Stripe-native types; extend via
OPENPARTNER_BILLABLE_EVENT_TYPES_EXTRA(comma-separated) for operator-known custom revenue types.aggregateAttributedGmvnow takes the event-type set (default = configured).Why this over the alternatives
No GMV definition is fully dodge-proof on merchant self-reported data:
The allowlist changes no existing invoice, makes the semantic explicit (what the review asked for), and lets the operator add a tenant's custom revenue type the moment it's noticed. Per-tenant granularity + auto-detection are follow-ups.
Tests
A custom
order_paidconversion is excluded by default (reproduces the leak) and counted once it's in the billable set. Typecheck clean.🤖 Generated with Claude Code