@mercurjs/docs 2.3.4-canary.0 → 2.3.4-canary.10

package/content/references/api/admin/products/batch-product-attributes.mdx

@@ -39,6 +39,7 @@ Applies attribute changes to the product in the order `remove` → `add` → `up
     <ParamField body="title" type="string">New attribute title.</ParamField>
     <ParamField body="add" type="(string | object)[]">Value names (or `{ value }` objects) to add to the selection.</ParamField>
     <ParamField body="remove" type="string[]">Value IDs to remove from the selection.</ParamField>
+    <ParamField body="value_ids" type="string[]">The complete set of value IDs the product should hold for this attribute. Resolved into the equivalent `add` / `remove` delta, so it cannot be combined with either.</ParamField>
     <ParamField body="value" type="string | number | boolean">New scalar value for non-select types.</ParamField>
   </Expandable>
 </ParamField>

package/content/references/api/vendor/products/batch-product-attributes.mdx

@@ -46,6 +46,7 @@ Stages attribute operations as a pending change request instead of applying them
     <ParamField body="title" type="string">New attribute title.</ParamField>
     <ParamField body="add" type="(string | object)[]">Values to select, plain strings or `{ "value": "..." }` objects.</ParamField>
     <ParamField body="remove" type="string[]">Value IDs to deselect.</ParamField>
+    <ParamField body="value_ids" type="string[]">The complete set of value IDs the product should hold for this attribute. Resolved into the equivalent `add` / `remove` delta, so it cannot be combined with either.</ParamField>
     <ParamField body="value" type="string | number | boolean">New scalar value for `text`, `unit`, or `toggle` attributes.</ParamField>
   </Expandable>
 </ParamField>

package/content/references/api/vendor.mdx

@@ -114,8 +114,8 @@ Full RMA suites exist per domain, following the same action pattern Medusa uses
 | `GET` `POST` `DELETE` | `/vendor/shipping-options/:id` | Retrieve / update / delete an option |
 | `POST` | `/vendor/shipping-options/:id/rules/batch` | Batch manage option rules |
 | `GET` | `/vendor/shipping-option-types[/:id]` | List option types |
-| `GET` `POST` | `/vendor/shipping-profiles` | List / create profiles |
-| `GET` `POST` `DELETE` | `/vendor/shipping-profiles/:id` | Retrieve / update / delete a profile |
+| `GET` | `/vendor/shipping-profiles` | List operator-defined profiles |
+| `GET` | `/vendor/shipping-profiles/:id` | Retrieve a profile |
 | `DELETE` | `/vendor/fulfillment-sets/:id` | Delete a fulfillment set |
 | `POST` | `/vendor/fulfillment-sets/:id/service-zones` | Create a service zone |
 | `GET` `POST` `DELETE` | `/vendor/fulfillment-sets/:id/service-zones/:zone_id` | Manage a service zone |

package/content/resources/integrations/stripe-connect.mdx

@@ -193,9 +193,17 @@ You need **two separate webhook endpoints** in Stripe: one for payment events, o
       - `payment_intent.succeeded`
       - `payment_intent.amount_capturable_updated`
       - `payment_intent.payment_failed`
-      - `charge.refunded`
+      - `payment_intent.partially_funded` (optional, only if you support that recovery flow)
 
     Copy the signing secret and set it as `STRIPE_WEBHOOK_SECRET` in your `.env`.
+
+    <Note>
+      With `capture: false`, Stripe sends `payment_intent.amount_capturable_updated` as soon as the payment is authorized, which can be before the storefront calls `POST /store/carts/:id/complete`. A webhook-driven completion runs `completeCartWithSplitOrdersWorkflow` under the same cart lock as the store route, so it still produces an order group with per-seller orders. It also completes carts whose customer left right after authenticating, so keep it enabled.
+    </Note>
+
+    <Warning>
+      Don't rely on `charge.refunded` for seller reconciliation. The Medusa Stripe provider doesn't act on it, and it never reverses Stripe Connect Transfers. See [Refunds and reversals](#refunds-and-reversals).
+    </Warning>
   </Step>
   <Step title="Add the payout webhook (Mercur)">
     Add a second webhook endpoint in the Stripe Dashboard.
@@ -298,6 +306,8 @@ Refunding a charge does **not** automatically reverse the associated transfers.
 1. **Refund the PaymentIntent.** Returns funds to the customer's payment method
 2. **Reverse the Transfer(s).** Claws back funds from the connected account(s)
 
+Mercur doesn't reverse transfers for you. The Stripe Connect payout provider only handles `account.updated`, and a `charge.refunded` event is not confirmation that any seller transfer was reversed. If you refund after a seller has been paid out, reconcile their side yourself, either with a transfer reversal or by deducting the amount from their next payout.
+
 For a full refund of a multi-seller order, you would need to reverse each seller's transfer individually. For partial refunds, you need to calculate how much to reverse from each seller based on which items are being refunded.
 
 <Info>

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mercurjs/docs",
-  "version": "2.3.4-canary.0",
+  "version": "2.3.4-canary.10",
   "repository": {
     "type": "git",
     "url": "https://github.com/mercurjs/mercur",