The name on the receipt assigns your tax registrations and your chargeback queue

The posted handler does two things before it writes anything. It verifies the Stripe signature with `stripe.webhooks.constructEvent` and returns a 400 on failure ^[6]. Then it looks up `event.id` in a `processedEvents` table and returns early if the row exists ^[7]. Stripe retries events, so duplicates arrive ^[8]. The row is written after the grant or revoke runs, just before the handler returns ^[9]. A process that dies in that gap leaves the event unrecorded, and the next retry replays the grant, so `grantEntitlement` has to be safe to call twice.

Two lines decide what a customer actually gets. The plan comes from `sub.items.data[0].price.lookup_key ?? "pro"` ^[10], so a price created without a lookup key grants pro, and only the first line item is read. Expiry is `new Date(sub.current_period_end * 1000)` ^[11], and grants fire on `checkout.session.completed` and `invoice.paid`, with revocation on `customer.subscription.deleted` ^[12]. Dyne notes that proration, trials, dunning and mid-cycle upgrades each add branches to that switch ^[13].

Dyne puts the processor at around 3% ^[3] and a merchant of record at roughly 5% plus a fixed fee ^[15]. Two percentage points on 100,000 of annual sales is 2,000 a year, before the fixed fees ^[27]. For that, Paddle or Lemon Squeezy is the seller on the receipt, calculates, collects and remits tax everywhere, and eats the chargebacks ^[14]; the post says the EU, UK, India and Australia are open on day one with zero registrations ^[16]. On the Stripe path, Stripe Tax calculates the tax and registration and filing stay with you ^[4], and dispute evidence is yours to assemble ^[5]. Payouts from a merchant of record arrive bi-weekly or monthly, inside their checkout and subscription model ^[17].

On native, the platform is the seller and in-app purchase is a constraint ^[19], at 15 to 30% depending on program tier and revenue ^[20]. At the top of that band the store takes about ten times what the processor takes, and five times at the bottom ^[28]. Cancellations and refunds happen in the store and your server reacts to events ^[22]. Two platforms, two receipt formats and two server-notification systems with different semantics is the reason Dyne gives for RevenueCat existing ^[21].

Sarah Dyne wrote on dev.to: "Payments look like a checkout button. Underneath it's a question of who is on the receipt, and that question decides most of your operational load for the next two years." ^[23][29] The post does not quantify that load. The percentages are one practitioner's ranges, and they hold for your product only if your jurisdictions, your program tier with Apple and Google, and your dispute rate resemble the ones behind them. The shape of the handler is portable: the Paddle branch calls the same grant and revoke functions with different event names ^[18]. That is where Dyne's sequencing advice comes from: write the entitlement layer before the second payment channel ^[24]. Her split of the options is Stripe for web SaaS with a team that can own billing, marketplaces and custom pricing ^[25], and a merchant of record for indie products, digital downloads and anyone without a finance function ^[26].