@v-office/website-sdk 2.20.4 → 2.22.0

package/dist/instructions/README.md

@@ -13,7 +13,8 @@ Use this directory as the consumer-facing reference for the package:
 - `search.md`: `sdk.live.search.search`.
 - `availability.md`: date-picker availability flows.
 - `quote.md`: quote booking-card modifiers, additional services, cancellation policy, and insurance flows.
-- `booking.md`: booking and payment option submission.
+- `booking.md`: booking, payment option submission, and
+  `sdk.static.payment.getBankTransferDetails` (read-only bank details).
 - `contact.md`: contact submission.
 - `document-structured-json.md`: `sdk.static.documents.getTermsAndPrivacyPolicy` and structured document JSON rendering rules.
 - `CHANGELOG.md`: versioned changelog index.

package/dist/instructions/booking.md

@@ -134,6 +134,11 @@ Sample:
 
 `paymentOptions` is present only when the SDK can currently perform that payment. Future or on-site steps remain visible without payment options.
 
+`lines` is present on a step or alternative only when the backend states a deposit
+included in its amount. It contains the formatted deposit and, when nonzero, the
+amount excluding the deposit. Without a stated deposit there are no `lines`;
+never derive a deposit from `amount` and a percentage.
+
 An optional `insurancePaymentOptions` array is returned only when post-booking insurance payment is available.
 
 Sites upgrading from 2.12.0 must replace the former `paymentSchedules` output. See
@@ -141,11 +146,42 @@ Sites upgrading from 2.12.0 must replace the former `paymentSchedules` output. S
 
 Payment option variants:
 
-- `bank_transfer`: display-only payment details.
+- `bank_transfer`: display-only payment details. `holder`, `iban`, `swiftOrBic` and
+  `institution` are the PMS payment settings' values; `holder`, `swiftOrBic` and
+  `institution` are absent when the PMS has none. `holder` is never another name:
+  render the row only when present. `remittanceText` is emitted on `v9`.
 - `redirect`: redirect the browser to the payment URL.
 - `form_post`: submit a generated HTML form, currently used for PayPal-style flows.
 - `stripe_checkout`: open Stripe Checkout. Emitted on `v9` only.
 
+## Bank Transfer Details
+
+The bank details a guest is told to transfer to must be right before a site goes
+live. On `v10`, read them without creating a booking:
+
+```ts
+const accounts = await sdk.static.payment.getBankTransferDetails();
+// [{ holder: "Example GmbH", iban: "DE02120300000000202051", swiftOrBic: "BYLADEM1001", institution: "Example Bank" }]
+```
+
+Returns `Promise<ReadonlyArray<BookingBankTransferDetails>>`: the bank account of
+the PMS's primary document settings, the same single account the booking output
+shows, or an empty array when that account has no IBAN. Never placeholder values. The call runs the same PMS query and mapping the
+booking output uses for its `bank_transfer` payment options, so what it returns
+is exactly what the next booking's confirmation will show. It creates no booking,
+reservation or other PMS write. Compare the result with the PMS payment settings
+before launch, or run the CLI:
+
+```sh
+website-sdk --backend v10 bank-transfer-details
+```
+
+The call is not available on `v9`: the v9 hub exposes bank details only inside
+a booking response. Do not verify them with a test booking against the v9 demo
+hub: the demo hub and the production hub front the same PMS account, so a
+booking through either is a real booking in the PMS. Verify the payment
+settings in the PMS itself instead.
+
 ## Payment Submission
 
 Use `sdk.live.booking.submitPaymentOption(option)` or the top-level `submitPaymentOption(option)` export for every option except `bank_transfer`, which is display-only. Submission requires a browser environment and fails outside one.

package/dist/instructions/search.md

@@ -374,6 +374,35 @@ requested locale; backend numeric amounts and modifier type keys are not exposed
 individual modifier lines. Exact-period results are returned in `items`;
 alternative-period suggestions are returned in root-level `alternatives`.
 
+On legacy v9 only, an exact match may include `matchingPeriods` when the backend
+chose the dates itself in a window search (`start`/`end` plus `minNights`/`maxNights`).
+The field exists only on the v9 facade: `sdk.live.search.search` of a
+`WebsiteSDKV9` returns `V9SearchSearchOutput`, whose items are
+`V9SearchSearchOutputItem`. Narrow on `sdk.backend === "v9"` to read it. Each entry has the same shape as an `alternativePeriods` entry: `start`, `end`,
+and the optional `formattedTotal` and `discount` for that period. Entries keep the
+backend order. The item's own `formattedTotal` and `discount` are the price of the
+first entry when that entry has one; otherwise they are the backend's overall price
+for the hit. Show `matchingPeriods[0]` as the dates the card price is for, and open
+the rental page with those dates so card and detail price agree. For a
+fixed-period search without a window, the dates are the requested ones and
+`matchingPeriods` is absent, never an empty array.
+
+```json
+{
+  "id": "214950",
+  "nameOrLabel": "Ferienhaus Seeblick",
+  "timeZone": "Europe/Berlin",
+  "formattedTotal": "1.144,10 €",
+  "matchingPeriods": [
+    {
+      "start": "2026-10-01",
+      "end": "2026-10-08",
+      "formattedTotal": "1.144,10 €"
+    }
+  ]
+}
+```
+
 `appliedFilters` reports what the backend actually applied, and is what a "remove
 this filter" chip should be built from. `label` is localized presentation and can
 repeat, so it cannot identify a filter; `key` plus `value` can. `value` is the
@@ -421,6 +450,10 @@ projection:
   and booking flow.
 - Pagination uses the backend `from`/`size` window behind the same opaque `cursor`,
   capped at 1,000 results.
+- v10 items have no `matchingPeriods`. A v10 hit counts as exact only when its period
+  equals the requested fixed period; a hit the backend priced for other dates,
+  including every hit of a `minNights`/`maxNights` window search, is returned in
+  `alternatives` with its dates in `alternativePeriods`.
 
 ### Legacy v9
 
@@ -442,6 +475,12 @@ shape:
   formatted original total.
 - The same mapping applies to exact-period items and individual alternative
   periods.
+- For an exact match, every `additional_voffice_data.matchingPeriods` entry with
+  both dates becomes a `matchingPeriods` entry (`fromdate`/`tilldate` become
+  `start`/`end`, its `calc` becomes the period's price fields); entries without
+  dates are dropped. In a window search the guest enters a window and a stay
+  length, not the stay itself. The backend returns the bookable stays inside the
+  window, earliest first; the SDK keeps that order.
 - v9 never executes a custom-attribute search filter.
 
 The field is omitted when v9 returns no final total or when its original total is

package/dist/instructions/versions/2.21.0/CHANGELOG.md

@@ -0,0 +1,46 @@
+# Changelog: 2.21.0
+
+Two faults in the v9 bank-transfer confirmation, found on a pilot one step
+before go-live, and a read-only call to verify bank details before launch.
+
+Against a v9 hub that sends no account holder, the SDK filled the
+`bank_transfer` option's `holder` with the booking's customer name. Every
+confirmation told the guest to pay an account held by themselves; with EU
+payee-name verification the guest's bank flags that transfer as a name
+mismatch. Separately, when the hub stated neither a booking total nor a deposit,
+the SDK derived a total from the rounded prepayment and its percentage and
+labelled the rounding remainder a deposit: a booking of 486.50 € with a 20 %
+prepayment rounded to 97.00 € showed "486.50 €" with the lines "485.00 €" and a
+deposit of "1.50 €".
+
+## Added
+
+- `sdk.static.payment.getBankTransferDetails()` on `v10`: the bank account the
+  next booking's `bank_transfer` payment options will show (`holder?`, `iban`,
+  `swiftOrBic?`, `institution?`; at most one entry), read from the PMS's primary
+  document settings through the same query and mapping the booking output uses. Creates no booking. Empty when
+  the account offers no bank transfer. Not available on `v9`: the v9 hub exposes
+  bank details only inside a booking response, and its demo hub is not a sandbox
+  (see `booking.md`).
+- CLI: `website-sdk --backend v10 bank-transfer-details`.
+
+## Changed
+
+- `holder` on a `bank_transfer` payment option is optional. It is the PMS
+  payment settings' holder or absent; never the guest's name.
+- `lines` on a payment step or the `full_amount` alternative are emitted only
+  when the hub states a deposit amount. They then read the deposit and, when
+  nonzero, the amount excluding it. Without a stated deposit there are no
+  lines; the step's `amount` stands alone.
+
+## Fixed
+
+- `v9`: the `bank_transfer` holder is no longer the booking customer's name.
+- `v9`: no deposit line is invented from a rounded prepayment. Nothing is
+  derived from percentages or totals any more.
+
+## Unchanged
+
+- `payment.schedule` and `payment.alternatives` structure, amounts, labels,
+  `dueOn`, `remittanceText`, and the other payment option variants.
+- The `v10` booking output apart from the optional `holder`.

package/dist/instructions/versions/2.21.0/MIGRATION.md

@@ -0,0 +1,30 @@
+# Migration: 2.20.4 to 2.21.0
+
+## 1. Upgrade
+
+```sh
+pnpm add @v-office/website-sdk@2.21.0
+```
+
+## 2. Optional `holder`
+
+`holder` on a `bank_transfer` payment option is now `string | undefined`.
+Render the holder row only when it is present, as for `swiftOrBic` and
+`institution`. A site that replaced the holder with its own value to work
+around the guest-name fault can remove that workaround.
+
+## 3. Payment lines
+
+`lines` on a payment step or alternative are absent unless the hub states a
+deposit. A site that hid the lines to work around the invented deposit can
+show them again.
+
+## 4. Verify bank details before launch (`v10`)
+
+```ts
+const accounts = await sdk.static.payment.getBankTransferDetails();
+```
+
+or `website-sdk --backend v10 bank-transfer-details`. Compare the result with
+the PMS payment settings. On `v9` this call is not available; see the note in
+`booking.md`.

package/dist/instructions/versions/2.22.0/CHANGELOG.md

@@ -0,0 +1,30 @@
+# Changelog: 2.22.0
+
+On a v9 hub, a search over a date window (`start`/`end` with `minNights`/`maxNights`)
+lets the hub pick the stay itself: the earliest bookable stay in the window. Such a hit came back as an exact result with a price but without the
+dates that price was for. A site could only link the rental page with the
+window the guest typed, and the detail page then showed a different price than
+the card.
+
+## Added
+
+- `v9`: exact search results carry `matchingPeriods` when the hub chose the
+  dates. Each entry has `start`, `end` and the optional `formattedTotal` and
+  `discount` for that period, in the hub's order. The field is absent for a
+  fixed-period search, never an empty array.
+- Types `V9SearchSearchOutput` and `V9SearchSearchOutputItem`.
+  `sdk.live.search.search` of a `WebsiteSDKV9` now returns
+  `V9SearchSearchOutput`; narrow on `sdk.backend === "v9"` to read
+  `matchingPeriods`.
+
+## Changed
+
+- `v9`: the `formattedTotal` and `discount` of an exact result are the price of
+  its first `matchingPeriods` entry when that entry has a price.
+
+## Unchanged
+
+- Fixed-period searches on v9: same items, same prices, no new field.
+- Alternatives and their `alternativePeriods`.
+- The v10 backend. v10 items have no `matchingPeriods`; a v10 hit for other
+  dates than the requested ones is still returned in `alternatives`.

package/dist/instructions/versions/2.22.0/MIGRATION.md

@@ -0,0 +1,27 @@
+# Migration: 2.21.0 to 2.22.0
+
+## 1. Upgrade
+
+```sh
+pnpm add @v-office/website-sdk@2.22.0
+```
+
+No changes are required. The v9 search result type is a superset of the
+previous one, so existing code compiles and renders as before.
+
+## 2. Show the dates of a window-search hit (`v9`)
+
+A v9 site that offers a date window with a night range should show
+`matchingPeriods[0]` on the result card as the dates the price is for, and open
+the rental page with those dates instead of the typed window. Card and detail
+page then show the same price.
+
+```ts
+if (sdk.backend === "v9") {
+  const output = await sdk.live.search.search(input);
+  for (const item of output.items) {
+    const period = item.matchingPeriods?.[0];
+    // period?.start, period?.end: dates for the card and the rental link
+  }
+}
+```

package/dist/{rentals-wTGB1cL6.mjs → rentals-DfNu7s7w.mjs}

@@ -1,4 +1,4 @@
-import { Ht as V9_FACILITY_ATTRIBUTE_KEYS } from "./client-BGeG3B_l.mjs";
+import { Ut as V9_FACILITY_ATTRIBUTE_KEYS } from "./client-BtZ30vTP.mjs";
 import { c as parseVofficeUnitData, i as VofficeUnitDataPropertyMetadata, n as VofficeUnitDataPropertyCategoryLabelKeys, o as parseVofficeFacilityData, r as VofficeUnitDataPropertyCategoryValues, s as parseVofficeFeedbackData, t as VofficeUnitDataFieldSchemas } from "./v9-data-BnYxa2Ek.mjs";
 import { a as toAddress, c as rentalFacilitiesForObjectGroupRelationQuery, d as rentalsAllFeedbacksQuery, f as rentalsAllWithoutFeedbacksQuery, i as toImages, l as rentalIdsQuery, n as renderVofficePropertyAttribute, o as toLocalizedString, r as toFacilityImages, t as toRentalHighlights, u as rentalsAllByFacilityObjectGroupsWithoutFeedbacksQuery } from "./to-rental-highlights-CN-wpRh3.mjs";
 import { CoreSDKError, makeTranslate, renderResolvedCustomAttribute, toCustomAttributeList, toResolvedCustomAttributeCategoryTranslationKey } from "@v-office/sdk-core";

package/dist/{search-D3oV3tAf.mjs → search-CZ1TRGAB.mjs}

@@ -1,4 +1,4 @@
-import { a as parseQueryParameters, i as collectQueryParameters, n as makeV9CustomAttributeFilterCapabilities, o as toQueryString, r as toBasicQueryInputs, s as applyVofficeFilterDerivedBasicQueryInputs } from "./client-BGeG3B_l.mjs";
+import { a as parseQueryParameters, i as collectQueryParameters, n as makeV9CustomAttributeFilterCapabilities, o as toQueryString, r as toBasicQueryInputs, s as applyVofficeFilterDerivedBasicQueryInputs } from "./client-BtZ30vTP.mjs";
 import { c as parseVofficeUnitData, t as VofficeUnitDataFieldSchemas } from "./v9-data-BnYxa2Ek.mjs";
 import { a as toAddress, i as toImages, s as searchQuery, t as toRentalHighlights } from "./to-rental-highlights-CN-wpRh3.mjs";
 import { CoreSDKError, STABLE_SEARCH_INPUTS, daysBetweenLocalDates, expandCustomAttributeFilterCompositions, parseChildrenAges, parseOccupancyCount, resolveExpandedCompositions, toFormattedSearchPrice, toIsoDateFromPeriodQueryDate, toStableSearchInputBackendQueryKeys, toStableSearchInputParameterValues, toStableSearchInputQueryKeys, toUnusedFilterKeys } from "@v-office/sdk-core";
@@ -235,12 +235,18 @@ const toQueryInput = ({ query, sort, customAttributeFilterDefinitions, locale, t
 //#region src/legacy-v9/parser/search/resolve-exact-match.ts
 const resolveExactMatch = (additionalData) => {
 	const alternatives = additionalData?.alternatives ?? [];
-	const calc = additionalData?.calc ?? additionalData?.matchingPeriods?.[0]?.calc;
-	const isExactMatch = additionalData?.foundExactMatch === true || additionalData?.foundExactMatch == null && alternatives.length === 0 && calc != null;
+	const matchingPeriods = additionalData?.matchingPeriods ?? [];
+	const calcCandidates = [
+		matchingPeriods.find((period) => period.fromdate != null && period.tilldate != null)?.calc,
+		additionalData?.calc,
+		matchingPeriods[0]?.calc
+	];
+	const calc = calcCandidates.find((candidate) => candidate?.total != null);
+	const isExactMatch = additionalData?.foundExactMatch === true || additionalData?.foundExactMatch == null && alternatives.length === 0 && calcCandidates.some((candidate) => candidate != null);
 	return {
 		isExactMatch,
 		exactMatchCalc: isExactMatch ? calc : void 0,
-		periods: isExactMatch ? [] : alternatives
+		periods: isExactMatch ? matchingPeriods : alternatives
 	};
 };
 //#endregion
@@ -302,15 +308,15 @@ const toSearchOutputItem = ({ locale, imageProxyBaseUrl, rentalHighlightPrioriti
 	return item;
 });
 //#endregion
-//#region src/legacy-v9/parser/search/output/to-alternative-periods.ts
-const toAlternativePeriods = ({ locale, alternatives }) => Effect.succeed((alternatives ?? []).flatMap((alternative) => {
-	if (alternative.fromdate == null || alternative.tilldate == null) return [];
+//#region src/legacy-v9/parser/search/output/to-search-periods.ts
+const toSearchPeriods = ({ locale, periods }) => Effect.succeed((periods ?? []).flatMap((period) => {
+	if (period.fromdate == null || period.tilldate == null) return [];
 	return [{
-		start: alternative.fromdate,
-		end: alternative.tilldate,
+		start: period.fromdate,
+		end: period.tilldate,
 		...toSearchPriceFields({
 			locale,
-			calc: alternative.calc
+			calc: period.calc
 		})
 	}];
 }));
@@ -318,4 +324,4 @@ const toAlternativePeriods = ({ locale, alternatives }) => Effect.succeed((alter
 //#region src/legacy-v9/runtime/search.ts
 const defaultSearchDataAttributes = Object.keys(VofficeUnitDataFieldSchemas);
 //#endregion
-export { defaultSearchDataAttributes, resolveExactMatch, searchQuery, toAlternativePeriods, toQueryInput, toSearchOutputItem };
+export { defaultSearchDataAttributes, resolveExactMatch, searchQuery, toQueryInput, toSearchOutputItem, toSearchPeriods };

package/instructions/CHANGELOG.md

@@ -4,6 +4,8 @@
 
 Release notes of `@v-office/website-sdk`, newest first. Each version has its own directory.
 
+- `versions/2.22.0/CHANGELOG.md`: release notes for 2.22.0
+- `versions/2.21.0/CHANGELOG.md`: release notes for 2.21.0
 - `versions/2.20.4/CHANGELOG.md`: release notes for 2.20.4
 - `versions/2.20.3/CHANGELOG.md`: release notes for 2.20.3
 - `versions/2.20.2/CHANGELOG.md`: release notes for 2.20.2

package/instructions/MIGRATION.md

@@ -4,6 +4,8 @@
 
 Migration guides of `@v-office/website-sdk`, newest first. Apply them in order when skipping versions.
 
+- `versions/2.22.0/MIGRATION.md`: Migration: 2.21.0 to 2.22.0
+- `versions/2.21.0/MIGRATION.md`: Migration: 2.20.4 to 2.21.0
 - `versions/2.20.4/MIGRATION.md`: Migration: 2.20.3 to 2.20.4
 - `versions/2.20.3/MIGRATION.md`: Migration: 2.20.2 to 2.20.3
 - `versions/2.20.2/MIGRATION.md`: Migration: 2.20.1 to 2.20.2

package/instructions/README.md

@@ -13,7 +13,8 @@ Use this directory as the consumer-facing reference for the package:
 - `search.md`: `sdk.live.search.search`.
 - `availability.md`: date-picker availability flows.
 - `quote.md`: quote booking-card modifiers, additional services, cancellation policy, and insurance flows.
-- `booking.md`: booking and payment option submission.
+- `booking.md`: booking, payment option submission, and
+  `sdk.static.payment.getBankTransferDetails` (read-only bank details).
 - `contact.md`: contact submission.
 - `document-structured-json.md`: `sdk.static.documents.getTermsAndPrivacyPolicy` and structured document JSON rendering rules.
 - `CHANGELOG.md`: versioned changelog index.

package/instructions/booking.md

@@ -134,6 +134,11 @@ Sample:
 
 `paymentOptions` is present only when the SDK can currently perform that payment. Future or on-site steps remain visible without payment options.
 
+`lines` is present on a step or alternative only when the backend states a deposit
+included in its amount. It contains the formatted deposit and, when nonzero, the
+amount excluding the deposit. Without a stated deposit there are no `lines`;
+never derive a deposit from `amount` and a percentage.
+
 An optional `insurancePaymentOptions` array is returned only when post-booking insurance payment is available.
 
 Sites upgrading from 2.12.0 must replace the former `paymentSchedules` output. See
@@ -141,11 +146,42 @@ Sites upgrading from 2.12.0 must replace the former `paymentSchedules` output. S
 
 Payment option variants:
 
-- `bank_transfer`: display-only payment details.
+- `bank_transfer`: display-only payment details. `holder`, `iban`, `swiftOrBic` and
+  `institution` are the PMS payment settings' values; `holder`, `swiftOrBic` and
+  `institution` are absent when the PMS has none. `holder` is never another name:
+  render the row only when present. `remittanceText` is emitted on `v9`.
 - `redirect`: redirect the browser to the payment URL.
 - `form_post`: submit a generated HTML form, currently used for PayPal-style flows.
 - `stripe_checkout`: open Stripe Checkout. Emitted on `v9` only.
 
+## Bank Transfer Details
+
+The bank details a guest is told to transfer to must be right before a site goes
+live. On `v10`, read them without creating a booking:
+
+```ts
+const accounts = await sdk.static.payment.getBankTransferDetails();
+// [{ holder: "Example GmbH", iban: "DE02120300000000202051", swiftOrBic: "BYLADEM1001", institution: "Example Bank" }]
+```
+
+Returns `Promise<ReadonlyArray<BookingBankTransferDetails>>`: the bank account of
+the PMS's primary document settings, the same single account the booking output
+shows, or an empty array when that account has no IBAN. Never placeholder values. The call runs the same PMS query and mapping the
+booking output uses for its `bank_transfer` payment options, so what it returns
+is exactly what the next booking's confirmation will show. It creates no booking,
+reservation or other PMS write. Compare the result with the PMS payment settings
+before launch, or run the CLI:
+
+```sh
+website-sdk --backend v10 bank-transfer-details
+```
+
+The call is not available on `v9`: the v9 hub exposes bank details only inside
+a booking response. Do not verify them with a test booking against the v9 demo
+hub: the demo hub and the production hub front the same PMS account, so a
+booking through either is a real booking in the PMS. Verify the payment
+settings in the PMS itself instead.
+
 ## Payment Submission
 
 Use `sdk.live.booking.submitPaymentOption(option)` or the top-level `submitPaymentOption(option)` export for every option except `bank_transfer`, which is display-only. Submission requires a browser environment and fails outside one.

package/instructions/search.md

@@ -374,6 +374,35 @@ requested locale; backend numeric amounts and modifier type keys are not exposed
 individual modifier lines. Exact-period results are returned in `items`;
 alternative-period suggestions are returned in root-level `alternatives`.
 
+On legacy v9 only, an exact match may include `matchingPeriods` when the backend
+chose the dates itself in a window search (`start`/`end` plus `minNights`/`maxNights`).
+The field exists only on the v9 facade: `sdk.live.search.search` of a
+`WebsiteSDKV9` returns `V9SearchSearchOutput`, whose items are
+`V9SearchSearchOutputItem`. Narrow on `sdk.backend === "v9"` to read it. Each entry has the same shape as an `alternativePeriods` entry: `start`, `end`,
+and the optional `formattedTotal` and `discount` for that period. Entries keep the
+backend order. The item's own `formattedTotal` and `discount` are the price of the
+first entry when that entry has one; otherwise they are the backend's overall price
+for the hit. Show `matchingPeriods[0]` as the dates the card price is for, and open
+the rental page with those dates so card and detail price agree. For a
+fixed-period search without a window, the dates are the requested ones and
+`matchingPeriods` is absent, never an empty array.
+
+```json
+{
+  "id": "214950",
+  "nameOrLabel": "Ferienhaus Seeblick",
+  "timeZone": "Europe/Berlin",
+  "formattedTotal": "1.144,10 €",
+  "matchingPeriods": [
+    {
+      "start": "2026-10-01",
+      "end": "2026-10-08",
+      "formattedTotal": "1.144,10 €"
+    }
+  ]
+}
+```
+
 `appliedFilters` reports what the backend actually applied, and is what a "remove
 this filter" chip should be built from. `label` is localized presentation and can
 repeat, so it cannot identify a filter; `key` plus `value` can. `value` is the
@@ -421,6 +450,10 @@ projection:
   and booking flow.
 - Pagination uses the backend `from`/`size` window behind the same opaque `cursor`,
   capped at 1,000 results.
+- v10 items have no `matchingPeriods`. A v10 hit counts as exact only when its period
+  equals the requested fixed period; a hit the backend priced for other dates,
+  including every hit of a `minNights`/`maxNights` window search, is returned in
+  `alternatives` with its dates in `alternativePeriods`.
 
 ### Legacy v9
 
@@ -442,6 +475,12 @@ shape:
   formatted original total.
 - The same mapping applies to exact-period items and individual alternative
   periods.
+- For an exact match, every `additional_voffice_data.matchingPeriods` entry with
+  both dates becomes a `matchingPeriods` entry (`fromdate`/`tilldate` become
+  `start`/`end`, its `calc` becomes the period's price fields); entries without
+  dates are dropped. In a window search the guest enters a window and a stay
+  length, not the stay itself. The backend returns the bookable stays inside the
+  window, earliest first; the SDK keeps that order.
 - v9 never executes a custom-attribute search filter.
 
 The field is omitted when v9 returns no final total or when its original total is

package/instructions/versions/2.21.0/CHANGELOG.md

@@ -0,0 +1,46 @@
+# Changelog: 2.21.0
+
+Two faults in the v9 bank-transfer confirmation, found on a pilot one step
+before go-live, and a read-only call to verify bank details before launch.
+
+Against a v9 hub that sends no account holder, the SDK filled the
+`bank_transfer` option's `holder` with the booking's customer name. Every
+confirmation told the guest to pay an account held by themselves; with EU
+payee-name verification the guest's bank flags that transfer as a name
+mismatch. Separately, when the hub stated neither a booking total nor a deposit,
+the SDK derived a total from the rounded prepayment and its percentage and
+labelled the rounding remainder a deposit: a booking of 486.50 € with a 20 %
+prepayment rounded to 97.00 € showed "486.50 €" with the lines "485.00 €" and a
+deposit of "1.50 €".
+
+## Added
+
+- `sdk.static.payment.getBankTransferDetails()` on `v10`: the bank account the
+  next booking's `bank_transfer` payment options will show (`holder?`, `iban`,
+  `swiftOrBic?`, `institution?`; at most one entry), read from the PMS's primary
+  document settings through the same query and mapping the booking output uses. Creates no booking. Empty when
+  the account offers no bank transfer. Not available on `v9`: the v9 hub exposes
+  bank details only inside a booking response, and its demo hub is not a sandbox
+  (see `booking.md`).
+- CLI: `website-sdk --backend v10 bank-transfer-details`.
+
+## Changed
+
+- `holder` on a `bank_transfer` payment option is optional. It is the PMS
+  payment settings' holder or absent; never the guest's name.
+- `lines` on a payment step or the `full_amount` alternative are emitted only
+  when the hub states a deposit amount. They then read the deposit and, when
+  nonzero, the amount excluding it. Without a stated deposit there are no
+  lines; the step's `amount` stands alone.
+
+## Fixed
+
+- `v9`: the `bank_transfer` holder is no longer the booking customer's name.
+- `v9`: no deposit line is invented from a rounded prepayment. Nothing is
+  derived from percentages or totals any more.
+
+## Unchanged
+
+- `payment.schedule` and `payment.alternatives` structure, amounts, labels,
+  `dueOn`, `remittanceText`, and the other payment option variants.
+- The `v10` booking output apart from the optional `holder`.

package/instructions/versions/2.21.0/MIGRATION.md

@@ -0,0 +1,30 @@
+# Migration: 2.20.4 to 2.21.0
+
+## 1. Upgrade
+
+```sh
+pnpm add @v-office/website-sdk@2.21.0
+```
+
+## 2. Optional `holder`
+
+`holder` on a `bank_transfer` payment option is now `string | undefined`.
+Render the holder row only when it is present, as for `swiftOrBic` and
+`institution`. A site that replaced the holder with its own value to work
+around the guest-name fault can remove that workaround.
+
+## 3. Payment lines
+
+`lines` on a payment step or alternative are absent unless the hub states a
+deposit. A site that hid the lines to work around the invented deposit can
+show them again.
+
+## 4. Verify bank details before launch (`v10`)
+
+```ts
+const accounts = await sdk.static.payment.getBankTransferDetails();
+```
+
+or `website-sdk --backend v10 bank-transfer-details`. Compare the result with
+the PMS payment settings. On `v9` this call is not available; see the note in
+`booking.md`.

package/instructions/versions/2.21.0/release.json

@@ -0,0 +1,3 @@
+{
+  "componentsAffectedByHeadlessChange": []
+}

package/instructions/versions/2.22.0/CHANGELOG.md

@@ -0,0 +1,30 @@
+# Changelog: 2.22.0
+
+On a v9 hub, a search over a date window (`start`/`end` with `minNights`/`maxNights`)
+lets the hub pick the stay itself: the earliest bookable stay in the window. Such a hit came back as an exact result with a price but without the
+dates that price was for. A site could only link the rental page with the
+window the guest typed, and the detail page then showed a different price than
+the card.
+
+## Added
+
+- `v9`: exact search results carry `matchingPeriods` when the hub chose the
+  dates. Each entry has `start`, `end` and the optional `formattedTotal` and
+  `discount` for that period, in the hub's order. The field is absent for a
+  fixed-period search, never an empty array.
+- Types `V9SearchSearchOutput` and `V9SearchSearchOutputItem`.
+  `sdk.live.search.search` of a `WebsiteSDKV9` now returns
+  `V9SearchSearchOutput`; narrow on `sdk.backend === "v9"` to read
+  `matchingPeriods`.
+
+## Changed
+
+- `v9`: the `formattedTotal` and `discount` of an exact result are the price of
+  its first `matchingPeriods` entry when that entry has a price.
+
+## Unchanged
+
+- Fixed-period searches on v9: same items, same prices, no new field.
+- Alternatives and their `alternativePeriods`.
+- The v10 backend. v10 items have no `matchingPeriods`; a v10 hit for other
+  dates than the requested ones is still returned in `alternatives`.

package/instructions/versions/2.22.0/MIGRATION.md

@@ -0,0 +1,27 @@
+# Migration: 2.21.0 to 2.22.0
+
+## 1. Upgrade
+
+```sh
+pnpm add @v-office/website-sdk@2.22.0
+```
+
+No changes are required. The v9 search result type is a superset of the
+previous one, so existing code compiles and renders as before.
+
+## 2. Show the dates of a window-search hit (`v9`)
+
+A v9 site that offers a date window with a night range should show
+`matchingPeriods[0]` on the result card as the dates the price is for, and open
+the rental page with those dates instead of the typed window. Card and detail
+page then show the same price.
+
+```ts
+if (sdk.backend === "v9") {
+  const output = await sdk.live.search.search(input);
+  for (const item of output.items) {
+    const period = item.matchingPeriods?.[0];
+    // period?.start, period?.end: dates for the card and the rental link
+  }
+}
+```

package/instructions/versions/2.22.0/release.json

@@ -0,0 +1,3 @@
+{
+  "componentsAffectedByHeadlessChange": ["searchResults"]
+}