@blamejs/blamejs-shop 0.4.43 → 0.4.45

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.45 (2026-06-13) — **Sales tax is computed on the discounted price, so a discounted order is no longer over-taxed.** Checkout calculated sales tax on the full pre-discount subtotal even though the tax primitive's documented contract is to receive the post-discount subtotal (lib/tax.js: "Tax is computed against subtotal_minor (post-discount, pre-shipping)"). So every order carrying an automatic discount or a coupon was taxed on merchandise value the customer didn't pay for, over-collecting tax and overstating the order total. The tax base is now the subtotal minus the discount, computed by resolving the discount before the tax call. Shipping rates still gate on the pre-discount merchandise value — a free-shipping threshold is earned on what's in the cart, not the post-discount total — and an order with no discount is unaffected. No migration to apply. **Fixed:** *A discounted order is taxed on the price actually paid* — Sales tax now applies to the post-discount subtotal: the automatic-discount and coupon reduction is resolved first and subtracted from the taxable base before tax is calculated. Previously tax was computed on the full pre-discount subtotal, so a discounted or couponed order was over-taxed and its total overstated by the tax on the discounted-away amount. An order with no discount sees no change, and free-shipping thresholds continue to be evaluated against the pre-discount merchandise value.
+
+- v0.4.44 (2026-06-13) — **Close three integrity gaps: loyalty tier ratcheting, an unenforced per-customer promo cap, and a double-counted referral funnel.** Three confirmed correctness fixes. Cancelling a loyalty redemption refunded the points to the customer's lifetime total as well as their spendable balance — but a redemption only ever debited the spendable balance, so repeatedly redeeming and cancelling ratcheted the lifetime total, which drives tier placement, upward without limit; the refund now credits the spendable balance only and never the lifetime total. A promo bundle's per-customer redemption cap was stored and editable but never consulted at redemption, so a capped bundle was redeemable an unlimited number of times by one customer; the cap is now enforced with an atomic count-and-insert that also holds when a customer's checkouts race. And recording a referred customer's first purchase read the funnel-completion flag and then wrote it in separate steps, so two concurrent recordings — a double-submit or a re-delivered purchase webhook — could both complete the funnel and credit the referrer twice; the completion is now claimed atomically and counts exactly once. No migration to apply. **Fixed:** *Loyalty tier can no longer be ratcheted by redeem-then-cancel* — Cancelling a redemption now refunds the debited points to the spendable balance only, through a new balance-only credit that never touches the lifetime total. Previously the refund went through the general adjustment path, which also credits the lifetime total and recomputes the tier — but a redemption never reduced the lifetime total in the first place, so each redeem-then-cancel cycle inflated it and a repeated loop could climb the tier ladder without ever earning the points. · *A promo bundle's per-customer cap is now enforced* — A bundle's per-customer redemption cap is now checked when a redemption is recorded: the ledger insert is conditional on the customer's existing redemption count for that bundle being below the cap, in a single atomic statement, so two concurrent checkouts for the same customer can't both slip past a nearly-full cap. The cap was previously stored and editable but never consulted, leaving a per-customer-capped bundle redeemable any number of times by one customer. A bundle with no per-customer cap is unchanged. · *A referral funnel is counted once under concurrency* — Recording a referred customer's first qualifying purchase now claims the funnel-completion transition atomically — the referrer's count is incremented only by the call that wins the claim. Previously the flag was read and then written in separate steps, so two concurrent recordings (a double-submit, or a purchase webhook re-delivered) could both pass the not-yet-completed check and credit the referrer twice. Signup attribution is likewise claimed atomically so two different customers can't both be pinned to the same pending invitation.
+
 - v0.4.43 (2026-06-13) — **Harden input handling: linear-time pattern matching on caller-influenced strings, complete escaping, and redacted edge-bridge error responses.** A set of input-handling hardening fixes. Several internal pattern matches that run on caller-influenced strings used regular expressions whose shape could be driven into super-linear (polynomial) backtracking by a long run of a single character — a denial-of-service shape. These are rewritten to linear-time equivalents that accept and reject exactly the same inputs: the email-shape guard in the analytics and clickstream PII filters, a whitespace trim in the captcha gate, and the trailing-slash trim on the D1 and R2 bridge URLs. A JSON-escape helper in the catalog draft path now escapes backslashes as well as quotes so a crafted value can't smuggle an escape. And the edge worker's database- and storage-bridge error responses no longer return internal error detail to the caller — the detail is logged at the edge and the client receives only a generic failure code. No migration to apply. **Security:** *Pattern matching on caller-influenced input is now linear-time* — The email-shape detector used by the analytics and clickstream PII guards, the whitespace trim in the captcha gate, and the trailing-slash trim applied to the D1 and R2 bridge URLs were regular expressions whose backtracking could grow polynomially with the input length — a long run of one character could pin a request thread. Each is replaced with a linear-time form (a bounded, unambiguous regex; a native trim; a small character loop) proven to accept and reject the identical set of inputs, so the same values still pass and fail while a crafted long input can no longer cause super-linear work. · *Edge bridge errors no longer leak internal detail* — The Cloudflare Worker's database-bridge and storage-bridge endpoints returned the underlying error message in their 500 responses. They now return only a generic failure code to the caller and log the (redacted) detail at the edge, so an internal error string or stack fragment is never exposed in a response body. · *Complete escaping in the catalog draft lookup* — The catalog draft path builds a JSON-fragment match string from a SKU; its escape step now escapes backslashes before quotes, so the escaping is complete and a value containing a backslash cannot break out of the quoted fragment.
 
 - v0.4.42 (2026-06-13) — **A return refund is now recorded against the order, so it can't be paid out a second time from the order console.** Issuing a provider refund for a return moved the money but never recorded it against the order, so order.refundedTotalMinor didn't count it. The order console's refund caps each refund at the order's remaining un-refunded balance — but with the return refund invisible to that balance, an operator could refund the full order total a second time from the order screen, paying the customer back twice. A return's provider refund now writes to the order's refund ledger, stamped with the provider refund id so the entry collapses with the payment provider's own refund webhook — whether the console or the webhook records it first, the same refund is counted exactly once. The order's move to a fully-refunded state and the gift-card / loyalty reversals remain driven by the refund webhook, as before. No migration to apply. **Fixed:** *A return refund now counts against the order's refunded total* — When the returns console issues a provider refund, the amount is now recorded against the order through the same deduplicating ledger path a partial console refund uses, stamped with the provider refund id. Previously the money moved but the order's refunded total never saw it, so the order console's over-refund cap — which limits a refund to the order's remaining balance — could be cleared again and pay the customer back a second time. Keying the entry on the provider refund id makes it idempotent against the provider's refund webhook: whichever path records first, a refund mirrored by both is counted exactly once. The order's terminal refunded state and the gift-card / loyalty reversals stay driven by the refund webhook.

package/lib/asset-manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.4.43",
+  "version": "0.4.45",
   "assets": {
     "css/admin.css": {
       "integrity": "sha384-imfe0otYErcB8rr2h6KLSGTtStirysptpXETSPY4zLv3bZoIT75Lo1dOvkOav+xL",

package/lib/checkout.js

@@ -1139,10 +1139,22 @@ function create(deps) {
     }
 
     var sub = pricing.subtotal(lines, { currency: c.currency });
+
+    // Resolve the automatic discount BEFORE tax: sales tax is owed on the
+    // DISCOUNTED price the customer actually pays, not the pre-discount
+    // subtotal, so the discount has to be known to compute the tax base. The
+    // resolver clamps to [0, subtotal] and falls back to 0 on any failure, so
+    // the math is identical to the un-wired flow whenever no rule applies.
+    // (Pure computation here — the redemption CLAIM happens later, in confirm.)
+    var autoDisc = await _resolveAutoDiscount(lines, sub.amount_minor, c.customer_id || null, input.codes);
+    var taxableMinor = Math.max(0, sub.amount_minor - autoDisc.discount_minor);
+
     var taxRow = await tax.calculate({
       shipTo:         input.ship_to,
-      subtotal_minor: sub.amount_minor,
+      subtotal_minor: taxableMinor,
     });
+    // Shipping rates still gate on the PRE-discount subtotal — a free-shipping
+    // threshold is earned on merchandise value, not the post-discount total.
     var ratesRow = await shipping.rates({
       shipTo:         input.ship_to,
       lines:          enrichedLines,
@@ -1182,13 +1194,6 @@ function create(deps) {
 
     var shippingMinor = selected ? selected.amount_minor : 0;
 
-    // Automatic discounts: consult the operator-authored rule engine
-    // (when wired) for the subtotal reduction this cart earns. The
-    // resolver clamps the result to [0, subtotal] and falls back to 0
-    // on any failure, so the total math below is identical to the
-    // un-wired flow whenever no rule applies.
-    var autoDisc = await _resolveAutoDiscount(lines, sub.amount_minor, c.customer_id || null, input.codes);
-
     var totals = pricing.totals(c, lines, {
       tax_minor:      taxRow.tax_minor,
       shipping_minor: shippingMinor,

package/lib/loyalty-redemption.js

@@ -10,8 +10,9 @@
  *   checkout. This primitive composes:
  *
  *     - `loyalty` (required) — points-ledger writes. The redemption
- *       debits points via `loyalty.redeem` and refunds them via
- *       `loyalty.adjust` on cancellation.
+ *       debits points via `loyalty.redeem` and refunds them to the
+ *       spendable balance via `loyalty.creditBalance` on cancellation
+ *       (balance only — lifetime stays where redeem left it).
  *     - `coupons` (optional) — when injected, redemption mints a
  *       single-use coupon code via `coupons.issueSingleUseFromReward`
  *       (or whichever handle the operator wires). When absent, the
@@ -45,10 +46,11 @@
  *
  *     - `cancelRedemption({ redemption_id, reason })`
  *       FSM transition active → cancelled. Refunds the debited points
- *       via `loyalty.adjust(+points)`. A consumed/expired/cancelled
- *       redemption is refused — operators issue a manual
- *       `loyalty.adjust` row if the points need to come back after
- *       consumption.
+ *       to the SPENDABLE balance via `loyalty.creditBalance` — never to
+ *       the lifetime total, so a redeem→cancel loop can't ratchet the
+ *       tier. A consumed/expired/cancelled redemption is refused —
+ *       operators issue a manual `loyalty.adjust` row if the points
+ *       need to come back after consumption.
  *
  *     - `getRedemption(redemption_id)` / `redemptionsForCustomer(id,
  *       { limit?, cursor? })` — read paths.
@@ -614,7 +616,6 @@ function create(opts) {
       throw bad;
     }
 
-    var ts = _now();
     var r = await query(
       "UPDATE loyalty_redemptions SET status = 'cancelled', cancel_reason = ?1 " +
       "WHERE id = ?2 AND status = 'active'",
@@ -627,20 +628,18 @@ function create(opts) {
       throw raceErr;
     }
 
-    // Refund the debited points via loyalty.adjust. Positive
-    // delta — `loyalty.adjust` will credit lifetime as well, which
-    // matches the customer's lived experience (the redemption never
-    // happened, the points come back, the tier-driving lifetime
-    // total returns to where it was). Note that the underlying
-    // `loyalty.adjust` lifetime semantics only credit on positive
-    // delta, which is exactly what we want here.
-    await loyalty.adjust({
+    // Refund the debited points to the SPENDABLE balance only —
+    // `loyalty.redeem` debited balance and left lifetime untouched, so
+    // the refund mirrors that. Using `loyalty.adjust(+points)` here
+    // would credit lifetime, inflating the tier-driving total above
+    // what was earned; a redeem→cancel loop would then escalate the
+    // tier without limit. `creditBalance` never moves lifetime.
+    await loyalty.creditBalance({
       customer_id: current.customer_id,
       points:      current.points_debited,
       source:      "redemption-refund",
       notes:       "redemption:" + redemptionId + " " + reason,
     });
-    void ts;
 
     return await getRedemption(redemptionId);
   }

package/lib/loyalty.js

@@ -545,6 +545,42 @@ function create(opts) {
       };
     },
 
+    // Credit the SPENDABLE balance only, never lifetime. The
+    // refund-the-burn counterpart to `redeem`: redeem debits balance
+    // and leaves lifetime alone, so giving the points back must mirror
+    // that — touching lifetime here would inflate the tier-driving
+    // total above what was actually earned, and a redeem→cancel loop
+    // would escalate the tier without limit. Unlike `adjust(+points)`,
+    // which credits lifetime on a positive delta, this never moves
+    // lifetime and never recomputes tier. Relative-atomic so a
+    // concurrent earn/redeem can't clobber the credit. Writes an
+    // `adjust`-type ledger row so the audit trail records the refund.
+    creditBalance: async function (input) {
+      if (!input || typeof input !== "object") {
+        throw new TypeError("loyalty.creditBalance: input object required");
+      }
+      var customerId = _uuid(input.customer_id, "customer_id");
+      var points     = _positiveInt(input.points, "points");
+      var source     = _source(input.source);
+      var notes      = _notes(input.notes);
+
+      var ts = _now();
+      await _ensureAccountRow(customerId, ts);
+      await query(
+        "UPDATE loyalty_accounts SET balance_points = balance_points + ?1, " +
+        "updated_at = ?2 WHERE customer_id = ?3",
+        [points, ts, customerId],
+      );
+      await _writeTx(customerId, "adjust", points, source, null, notes, ts);
+
+      var after = await _readAccount(customerId);
+      return {
+        balance:  after.balance_points,
+        lifetime: after.lifetime_points,
+        tier:     after.tier,
+      };
+    },
+
     expire: async function (input) {
       if (!input || typeof input !== "object") {
         throw new TypeError("loyalty.expire: input object required");

package/lib/promo-bundles.js

@@ -62,7 +62,13 @@
  *       `max_redemptions_total` (the cap is checked under the same
  *       statement that increments the counter via a guarded UPDATE so
  *       two simultaneous checkouts cannot both succeed on the final
- *       slot). UNIQUE(slug, order_id) gives idempotency — replaying a
+ *       slot). Also refuses once a customer reaches `max_per_customer`
+ *       — that cap is enforced on the ledger INSERT itself (the row
+ *       materializes only while the customer's existing redemption
+ *       count for the slug is below the cap), so concurrent checkouts
+ *       for one customer cannot both clear an N-1 count. A null cap or
+ *       an anonymous (no customer_id) redemption is unlimited.
+ *       UNIQUE(slug, order_id) gives idempotency — replaying a
  *       redemption for the same order is a no-op that returns the
  *       existing row.
  *
@@ -643,13 +649,43 @@ function create(opts) {
     )).rows[0];
     if (existing) return _hydrateRedemption(existing);
 
-    // Cap check + increment in one guarded UPDATE so two concurrent
-    // checkouts cannot both claim the last slot. SQLite's statement
-    // atomicity guarantees the row update is all-or-nothing; the
-    // WHERE filters out a slot-exhausted race losing-side.
     var ts = _now();
     var redemptionId = b.uuid.v7({ now: ts });
 
+    // Per-customer cap: enforce it on the ledger INSERT itself so the
+    // count-and-insert is one atomic statement. The INSERT...SELECT
+    // materializes a row only while the customer's existing redemption
+    // count for this slug is still below the cap; two concurrent
+    // checkouts for the same customer cannot both observe N-1 and both
+    // win, because SQLite serializes the writes and the second sees the
+    // first's committed row. A null cap or anonymous (customer_id null)
+    // redemption is unlimited, so it takes the plain unconditional
+    // INSERT. The ledger row is written before the total-cap counter
+    // UPDATE so a per-customer refusal never ticks redemptions_used.
+    if (bundle.max_per_customer != null && customerId != null) {
+      var perCustRes = await query(
+        "INSERT INTO promo_bundle_redemptions (id, slug, order_id, customer_id, savings_minor, occurred_at) " +
+        "SELECT ?1, ?2, ?3, ?4, ?5, ?6 WHERE " +
+        "(SELECT COUNT(*) FROM promo_bundle_redemptions WHERE slug = ?2 AND customer_id = ?4) < ?7",
+        [redemptionId, slug, orderId, customerId, savingsMinor, ts, bundle.max_per_customer],
+      );
+      if (Number(perCustRes.rowCount || 0) === 0) {
+        var perCustErr = new Error("promoBundles.recordRedemption: customer has hit max_per_customer for bundle " + JSON.stringify(slug));
+        perCustErr.code = "BUNDLE_PER_CUSTOMER_CAP_REACHED";
+        throw perCustErr;
+      }
+    } else {
+      await query(
+        "INSERT INTO promo_bundle_redemptions (id, slug, order_id, customer_id, savings_minor, occurred_at) " +
+        "VALUES (?1, ?2, ?3, ?4, ?5, ?6)",
+        [redemptionId, slug, orderId, customerId, savingsMinor, ts],
+      );
+    }
+
+    // Total-cap check + increment in one guarded UPDATE so two concurrent
+    // checkouts cannot both claim the last slot. SQLite's statement
+    // atomicity guarantees the row update is all-or-nothing; the
+    // WHERE filters out a slot-exhausted race losing-side.
     var updateSql, updateParams;
     if (bundle.max_redemptions_total == null) {
       updateSql = "UPDATE promo_bundles SET redemptions_used = redemptions_used + 1, updated_at = ?1 WHERE slug = ?2";
@@ -661,8 +697,10 @@ function create(opts) {
     }
     var updateRes = await query(updateSql, updateParams);
     if (Number(updateRes.rowCount || 0) === 0) {
-      // Lost the race for the last slot — re-read to confirm and
-      // surface the cap error with the row's actual state.
+      // Lost the race for the last slot — the ledger row is already
+      // written, so roll it back to keep redemptions_used and the audit
+      // rows in step before surfacing the cap error.
+      await query("DELETE FROM promo_bundle_redemptions WHERE id = ?1", [redemptionId]);
       var after = await getBundle(slug);
       if (after && after.max_redemptions_total != null && after.redemptions_used >= after.max_redemptions_total) {
         var capErr = new Error("promoBundles.recordRedemption: bundle " + JSON.stringify(slug) + " has hit max_redemptions_total");
@@ -674,12 +712,6 @@ function create(opts) {
       throw new Error("promoBundles.recordRedemption: failed to claim a redemption slot for " + JSON.stringify(slug));
     }
 
-    await query(
-      "INSERT INTO promo_bundle_redemptions (id, slug, order_id, customer_id, savings_minor, occurred_at) " +
-      "VALUES (?1, ?2, ?3, ?4, ?5, ?6)",
-      [redemptionId, slug, orderId, customerId, savingsMinor, ts],
-    );
-
     return {
       id:            redemptionId,
       slug:          slug,

package/lib/referrals.js

@@ -361,36 +361,54 @@ function create(opts) {
         throw miss;
       }
       var ts = _now();
+      // Idempotent fast-path: if this customer already signed up under
+      // this code, this is a no-op — re-tracking must NOT pin the same
+      // friend to a SECOND pending invitation (which would over-count the
+      // funnel). Returns null, the same "nothing new recorded" signal the
+      // caller already treats as already-attributed.
+      var existing = await query(
+        "SELECT id FROM referral_invitations " +
+        "WHERE referral_code_id = ?1 AND signed_up_customer_id = ?2 LIMIT 1",
+        [row.id, customerId],
+      );
+      if (existing.rows.length) return null;
       // Pin the signup to the oldest pending invitation under this
       // code that doesn't have a customer attached yet — the same
       // friend can be invited by multiple referrers, but only one
       // (the code they actually landed through) gets the funnel
-      // attribution.
-      var candidate = await query(
-        "SELECT id FROM referral_invitations " +
-        "WHERE referral_code_id = ?1 AND signed_up_customer_id IS NULL " +
-        "ORDER BY invited_at ASC LIMIT 1",
-        [row.id],
-      );
-      if (!candidate.rows.length) {
-        // No pending invitation — record nothing. The caller can
-        // surface this if they want to gate signup-bonuses to known
-        // referrals.
-        return null;
+      // attribution. The claim is atomic (`signed_up_customer_id IS
+      // NULL` in the WHERE) so two different customers signing up
+      // concurrently can't both pin the same oldest invitation; the
+      // loser re-reads the next pending candidate. Bounded by the
+      // number of pending rows so a fully-claimed code returns null.
+      for (;;) {
+        var candidate = await query(
+          "SELECT id FROM referral_invitations " +
+          "WHERE referral_code_id = ?1 AND signed_up_customer_id IS NULL " +
+          "ORDER BY invited_at ASC LIMIT 1",
+          [row.id],
+        );
+        if (!candidate.rows.length) {
+          // No pending invitation — record nothing. The caller can
+          // surface this if they want to gate signup-bonuses to known
+          // referrals.
+          return null;
+        }
+        var invitationId = candidate.rows[0].id;
+        var claim = await query(
+          "UPDATE referral_invitations " +
+          "SET signed_up_at = ?1, signed_up_customer_id = ?2 " +
+          "WHERE id = ?3 AND signed_up_customer_id IS NULL",
+          [ts, customerId, invitationId],
+        );
+        if (Number(claim.rowCount || 0) === 0) continue;   // lost the claim — try the next pending row
+        var updated = await query(
+          "SELECT id, referral_code_id, signed_up_customer_id, signed_up_at, reward_status " +
+          "FROM referral_invitations WHERE id = ?1",
+          [invitationId],
+        );
+        return updated.rows[0] || null;
       }
-      var invitationId = candidate.rows[0].id;
-      await query(
-        "UPDATE referral_invitations " +
-        "SET signed_up_at = ?1, signed_up_customer_id = ?2 " +
-        "WHERE id = ?3",
-        [ts, customerId, invitationId],
-      );
-      var updated = await query(
-        "SELECT id, referral_code_id, signed_up_customer_id, signed_up_at, reward_status " +
-        "FROM referral_invitations WHERE id = ?1",
-        [invitationId],
-      );
-      return updated.rows[0] || null;
     },
 
     // Recorded when a referred customer makes their first qualifying
@@ -426,13 +444,38 @@ function create(opts) {
         };
       }
       var ts = _now();
-      await query(
+      // Claim the funnel completion atomically — the
+      // `first_purchase_at IS NULL` predicate is the serialization
+      // point so two concurrent calls (a double-submit or a
+      // re-delivered purchase webhook) can't both pass the null check
+      // above and both bump the leaderboard. Only the call that wins
+      // the claim (rowCount === 1) increments referrals_count; a loser
+      // returns the already-recorded shape.
+      var claim = await query(
         "UPDATE referral_invitations " +
         "SET first_purchase_at = ?1, first_order_id = ?2, " +
         "reward_status = 'both-rewarded' " +
-        "WHERE id = ?3",
+        "WHERE id = ?3 AND first_purchase_at IS NULL",
         [ts, orderId, inv.id],
       );
+      if (Number(claim.rowCount || 0) === 0) {
+        // Lost the claim — another concurrent call already recorded the
+        // first qualifying purchase. Re-read so the loser reports the
+        // winner's pinned values, not a stale snapshot.
+        var lost = await query(
+          "SELECT id, reward_status, first_purchase_at " +
+          "FROM referral_invitations WHERE id = ?1",
+          [inv.id],
+        );
+        var lostRow = lost.rows[0] || null;
+        if (!lostRow) return null;
+        return {
+          id:                lostRow.id,
+          reward_status:     lostRow.reward_status,
+          first_purchase_at: lostRow.first_purchase_at,
+          status:            "already-recorded",
+        };
+      }
       // Bump the referrer's running count. `referrals_count` is the
       // leaderboard key; it counts completed funnels (a friend who
       // signed up but never purchased doesn't count).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/blamejs-shop",
-  "version": "0.4.43",
+  "version": "0.4.45",
   "description": "Open-source framework built on blamejs. Vendored stack, zero npm runtime deps, PQC-first crypto, security-on by default.",
   "main": "lib/index.js",
   "scripts": {