@blamejs/blamejs-shop 0.4.44 → 0.4.46

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.4.x
 
+- v0.4.46 (2026-06-14) — **A refund webhook records its own amount, so refunds processed out of order can't over-count the refunded total.** The Stripe charge.refunded mirror recorded the difference between the charge's cumulative refunded figure and the order's recorded refund total. When two refunds happen close together and the second refund's webhook is processed before the first's has been recorded — including two webhooks racing on the same order — both read the same not-yet-updated recorded total, so the later one records the full cumulative difference and double-counts the earlier refund, overstating the order's refunded total (and, with the over-refund cap keyed on that total, potentially distorting later refund limits). The mirror now records each event's own refund amount — the charge lists its refunds newest-first — keyed on the refund id, so a re-delivery or the console's own mirror of the same refund is still de-duplicated. Each refund is counted exactly once regardless of the order or timing its webhooks arrive in. No migration to apply. **Fixed:** *A refund webhook records its own amount, not the cumulative difference* — The charge.refunded mirror now records the specific refund that triggered the event, taken from the charge's own refunds list, instead of the difference between the charge's cumulative refunded figure and the order's ledger. The previous difference-based approach read the recorded total once and could record a value that included an earlier refund whose webhook hadn't landed yet — so when that earlier webhook arrived, the order's refunded total over-counted. Keying each entry on the refund id keeps re-deliveries and the console's own mirror de-duplicated, so the same refund is never recorded twice and the total converges on the true figure whatever order the webhooks arrive in.
+
+- 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.

package/lib/asset-manifest.json

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

package/lib/checkout.js

@@ -444,14 +444,14 @@ function create(deps) {
     var remaining = grand - refundedSoFar;
     var delta     = cumulative - refundedSoFar;
     var meta = { stripe_event_id: event.id };
-    // Stamp the provider refund id (the charge carries its refunds newest-
-    // first) so a console refund recorded AFTER this webhook dedupes against
-    // it — recordPartialRefund keys idempotency on the refund id, and without
-    // it a webhook-first refund and the console write would both land,
-    // double-counting the refunded total on a split-tender order.
-    var _stripeRefundId = charge && charge.refunds && Array.isArray(charge.refunds.data) &&
-      charge.refunds.data[0] && charge.refunds.data[0].id;
-    if (_stripeRefundId) { meta.stripe_refund_id = _stripeRefundId; }
+    // The charge lists its refunds newest-first; the [0] entry is the refund
+    // that triggered THIS event. Its id keys idempotency (so a console mirror
+    // or a re-delivery dedupes — recordPartialRefund dedupes on the refund id),
+    // and its amount is THIS refund's own figure, used below instead of the
+    // cumulative-minus-ledger delta.
+    var _latestRefund = (charge && charge.refunds && Array.isArray(charge.refunds.data))
+      ? charge.refunds.data[0] : null;
+    if (_latestRefund && _latestRefund.id) { meta.stripe_refund_id = _latestRefund.id; }
     if (charge.refunded === true || cumulative >= grand) {
       // Charge fully refunded — terminal edge. (On a split-tender order the
       // charge covers only the provider-paid share; a full charge refund
@@ -470,12 +470,21 @@ function create(deps) {
       // console mirrored this refund when it issued it.
       return { handled: true, event_type: eventType, order: o, skipped: "already-recorded" };
     }
+    // Record THIS refund's own amount, NOT the cumulative-minus-ledger delta:
+    // two concurrent distinct-refund webhooks both read `refundedSoFar` before
+    // either writes, so the delta double-counts the earlier refund. The event's
+    // own refund amount is exact and, keyed on the refund id, dedupes a
+    // re-delivery or the console's mirror. Fall back to the delta only when the
+    // event doesn't carry the refund's amount.
+    var _refundAmount = (_latestRefund && Number.isInteger(_latestRefund.amount) && _latestRefund.amount > 0)
+      ? _latestRefund.amount
+      : delta;
     var updatedPartial = await order.recordPartialRefund(o.id, {
-      amount_minor: delta,
+      amount_minor: _refundAmount,
       reason:       "stripe:" + eventType,
       metadata:     meta,
     });
-    return { handled: true, event_type: eventType, order: updatedPartial, partial: true, amount_minor: delta };
+    return { handled: true, event_type: eventType, order: updatedPartial, partial: true, amount_minor: _refundAmount };
   }
 
   // Reprice a list of cart lines through the quantity-discount engine.
@@ -1139,10 +1148,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 +1203,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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/blamejs-shop",
-  "version": "0.4.44",
+  "version": "0.4.46",
   "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": {