Lemon Squeezy revenue becomes useful for AI unit economics only after store scope, signed order facts, refund timing, and product identity all agree. Link the provider customer to one internal account, then use that same account on server-side model calls.
Keep every order inside the selected store
Verify the API key, selected store ID, and each order's store_id before importing revenue. A valid key that can see another store must never mix that store's customers or sales into this website.
Use signed events for ongoing revenue facts
Validate the Lemon webhook signature against the raw request body, store the provider event once, and return success only after it is durably accepted. Orders, subscription payments, and refunds remain separate facts with their original IDs and timestamps.
Join the Lemon customer to one internal account
await telemetry.identifyAccount({
accountId: "account_123",
lemonCustomerId: "customer_456",
});Use the same accountId in the SDK context around each model call. Do not join through customer email: addresses change, can be shared, and can represent more than one workspace.
Keep refunds on the event timeline
An order snapshot can show that money was refunded, but its current updated_at does not necessarily prove when the refund occurred. Prefer signed refund event time; otherwise mark the reporting window partial and withhold confident profit.
Observed customer contribution profit = store-scoped revenue − exact refunds − fully priced AI usage for the same account, currency, and window.
What this evidence can and cannot prove
Lemon order totals are observed sales evidence, not proof of final merchant payout after every platform adjustment. Customer-level contribution profit remains unavailable when the store, currency, identity link, refund time, or AI price coverage is incomplete.