platform-types 1.10.748 → 1.10.750

package/dist/cjs/store.js

@@ -20,7 +20,8 @@ exports.CUSTOM_DOMAIN_SLOT_LIMIT = 2;
 exports.CUSTOM_DOMAIN_ROW_LIMIT = 10;
 /**
  * Every `StoreOnboardingReviewArea` — the ONE list. `PATCH /store` validates
- * `config.onboarding.reviewed` against it, so an area is added in one place.
+ * both `config.onboarding.reviewed` and `onboardingReviewAdd` against it, so an
+ * area is added in one place.
  */
 exports.STORE_ONBOARDING_REVIEW_AREAS = ['payments', 'delivery', 'pricing'];
 /**

package/dist/order.d.ts

@@ -1641,24 +1641,21 @@ declare global {
     interface LinkedPaymentEntry {
         source: 'mp' | 'stripe' | 'mp_movement';
         /**
-         * The amount this store CURRENTLY holds for this payment, net of refunds
-         * — **not** the amount originally settled. It is what
+         * The amount this payment counts toward the order. It is what
          * `deriveOrderFinancialAxis` sums, so it has to mean money the order can
          * still count.
          *
-         * ⚠️ It SHRINKS. A partial refund against the payment lowers it to the
-         * un-refunded remainder (`payment total − every refund so far`) and
-         * restates the order's `financialStatus` in the same write; a refund that
-         * exhausts the payment removes the entry from the map outright. It never
-         * grows — no writer on the refund path may raise it — so a reader may
-         * treat it as monotonically non-increasing after the link is created.
-         *
-         * ⚠️ **FORWARD-ONLY, and that is the reading that matters for anything
-         * historical.** Entries written before refunds began shrinking this field
-         * still carry their PRE-REFUND figure, and nothing is backfilled: an order
-         * partially refunded earlier reads as if the store kept the whole payment.
-         * A consumer reconciling against provider refund history will find those
-         * rows disagree, and the disagreement is the back catalogue, not a bug.
+         * ⚠️ **No writer shrinks it on a refund.** A refund or settled chargeback
+         * MercadoPago reports later is detected and recorded on the payment's
+         * status observation, never here: the entry keeps its linked figure until
+         * the operator mirrors the refund by hand (an unlink removes the entry).
+         * Entries on HISTORICAL orders may carry a smaller figure (or be gone):
+         * the removed outbound MercadoPago refund lowered a partially refunded
+         * entry to its un-refunded remainder and removed an exhausted one, and
+         * those rows keep what it wrote. Entries written before that refund
+         * existed carry their pre-refund figure; nothing is backfilled either way,
+         * so a consumer reconciling against provider refund history will find
+         * rows that disagree, and the disagreement is the back catalogue, not a bug.
          *
          * ⚠️ Denominated in `currency` below — the PAYMENT's denomination, not the
          * order's. Never sum this field across entries without converting.

package/dist/payment.d.ts

@@ -35,6 +35,41 @@ declare global {
             source: PaymentReceivedSource;
             paidAt: number;
         };
+        /**
+         * MercadoPago's CUMULATIVE refunded amount for this payment, in its own currency
+         * (`transaction_amount_refunded`, else the sum of `refunds[]` with status
+         * `approved`; never less than the full `amount` on `providerStatus: 'refunded'`). Written by
+         * the payment status service (`mercadopagoPaymentStatus.ts`) on every observation
+         * — the webhook and the poller's re-check alike. Absent means none observed, never
+         * an unknown. Present ⇒ a link refuses the payment (`LINK_LOCKED` `refunded-payment`).
+         */
+        refundedAmount?: number;
+        /**
+         * MercadoPago's `refunds[]` as last observed, same writer: `id` is MercadoPago's
+         * numeric refund id as a string, `amount` in the payment's currency, `status` as
+         * MercadoPago states it (`approved` once the money moved, `in_process` before), and
+         * `at` its `date_created` in epoch ms. Absent when MercadoPago listed none.
+         */
+        refunds?: {
+            id: string;
+            amount: number;
+            status: string;
+            at: number;
+        }[];
+        /**
+         * A dispute on the payment, same writer: present while `providerStatus` is
+         * `charged_back` or `in_mediation`. A later observation that shows neither clears it,
+         * except a SETTLED chargeback, which is kept through a later `approved`. On
+         * `charged_back`, `statusDetail` says what happened to the money: `settled` (taken for
+         * the full amount — reported for the operator to mirror by hand; the books are not
+         * changed), `reimbursed` (MercadoPago covered the seller) or `in_process` (still
+         * open). Any other detail, and a mediation, reads as still open. Present ⇒ a link
+         * refuses the payment.
+         */
+        chargeback?: {
+            status: string;
+            statusDetail?: string;
+        };
     }
     /** GET /payments/pending returns this page inside the standard data envelope. */
     interface MpPaymentObservationPage {

package/dist/store.d.ts

@@ -875,8 +875,14 @@ declare global {
              * Guided-setup onboarding progress (ADR-0020). First-login is derived
              * FE-side (absent, or neither `completed` nor `skipped` ⇒ show wizard).
              * `reviewed` lists the seeded setup areas the admin confirmed with «Ya
-             * lo revisé»; absent ⇒ none reviewed. The block is replaced wholesale on
-             * `PATCH /store`, so a writer must carry `reviewed` forward.
+             * lo revisé»; absent ⇒ none reviewed. No `PATCH /store` removes a mark: a
+             * body carrying this block writes `step` / `completed` / `skipped` as sent
+             * (member by member onto a stored block) and never SETs `reviewed` — each
+             * incoming area is appended conditionally after that write, so the result
+             * is the stored list followed by every new area, a block sent without
+             * `reviewed` keeps the stored list, and a mark another browser lands while
+             * the request is in flight survives. To ADD a mark without sending the
+             * block, use `StoreUpdateInput.onboardingReviewAdd`.
              */
             onboarding?: {
                 step: number;
@@ -1686,6 +1692,23 @@ declare global {
         newPhotoURL?: string;
         /** Leaves to REMOVE from the row — see `StoreRemovableField`. */
         removeFields?: StoreRemovableField[];
+        /**
+         * `PATCH /store` only (the closed `POST /store` body refuses it 400). Adds
+         * each area to `config.onboarding.reviewed` with its own conditional
+         * append on the store row — no read-modify-write — so two browsers marking
+         * different areas at once both persist, and an area already present is a
+         * no-op. At least one area; repeats collapse; any value outside
+         * `STORE_ONBOARDING_REVIEW_AREAS` is a 400 with nothing written. A store
+         * with no `config.onboarding` gets `{ step: 0, completed: false, skipped:
+         * false }` plus the added areas, which the wizard reads as absence did.
+         * Writable by every role that may write `config.onboarding` (USER
+         * included). Applied AFTER the rest of the same body, together with any
+         * areas in a `config.onboarding.reviewed` sent alongside it (that list's
+         * first); the block itself never SETs the list, so it cannot drop an area.
+         * The main write committing and an append then failing answers an error but
+         * still broadcasts the row as it stands.
+         */
+        onboardingReviewAdd?: StoreOnboardingReviewArea[];
     }
     interface Method {
         id: number;
@@ -2117,7 +2140,8 @@ export declare const CUSTOM_DOMAIN_SLOT_LIMIT = 2;
 export declare const CUSTOM_DOMAIN_ROW_LIMIT = 10;
 /**
  * Every `StoreOnboardingReviewArea` — the ONE list. `PATCH /store` validates
- * `config.onboarding.reviewed` against it, so an area is added in one place.
+ * both `config.onboarding.reviewed` and `onboardingReviewAdd` against it, so an
+ * area is added in one place.
  */
 export declare const STORE_ONBOARDING_REVIEW_AREAS: readonly ["payments", "delivery", "pricing"];
 /**

package/dist/store.js

@@ -17,7 +17,8 @@ export const CUSTOM_DOMAIN_SLOT_LIMIT = 2;
 export const CUSTOM_DOMAIN_ROW_LIMIT = 10;
 /**
  * Every `StoreOnboardingReviewArea` — the ONE list. `PATCH /store` validates
- * `config.onboarding.reviewed` against it, so an area is added in one place.
+ * both `config.onboarding.reviewed` and `onboardingReviewAdd` against it, so an
+ * area is added in one place.
  */
 export const STORE_ONBOARDING_REVIEW_AREAS = ['payments', 'delivery', 'pricing'];
 /**

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "platform-types",
-	"version": "1.10.748",
+	"version": "1.10.750",
 	"description": "Shared wire and entity contracts for the platform.",
 	"type": "module",
 	"main": "dist/index.js",