Repository navigation
V2 - #34
Merged
Merged
V2#34
Conversation
- Removed `plans/`, `docs/website-deployment.md`, `render.yaml`, and `.github/workflows/mirror-to-public.yml` from the public tree so the published repo is protocol material rather than private sprint plans, private Render preview config, a dormant private-to-public force-push job, or Pages DNS operator notes - Updated `docs/ucp-native-demo-merchant-profile.example.json` to match specification §7.2 (including `holds: true` on availability and the §7.2 `accepted_mechanisms` set) while keeping `ucp.keys` dual-published with the `signing_keys` transition alias, because that file is the copyable paid UCP-Native profile and had drifted from the normative example - Aligned the site-docs UCP-Native full and free-service profile examples with §7.2 (`spec`/`schema` on every capability, plus `payment_handlers` on the paid profile) so the website does not publish a thinner or invalid profile than the specification - Dropped the `website-deployment.md` exception from `tools/usp_check.py` authority allowlists because that file no longer exists - Switched `.github/workflows/ci.yml` to GitHub-hosted `ubuntu-latest` and removed the repository-name skip, so public pull requests get the same schema, ref, vector, site-build, and authority checks without naming a private repository or requesting self-hosted runners ---
- Replaced placeholder Stripe UCP handler examples (`com.stripe.agentic_commerce.shared_payment_token`, `stripe_spt_demo_h1`, `shared_payment_token` instrument) with the published `com.stripe.payments` handler (`2026-06-25`) in `specification.md` §7.2, §7.4, and §7.7.2, because Stripe's handler schema is now available and issue [#108](wix-private/universal-scheduling-protocol-spec#108) requires real wire shapes instead of pre-schema placeholders - Added normative prose that UCP-Native platforms **MUST** read `network_id` from checkout `available_instruments` (`type: "link"`, `config.network_id`) and that Link Agent Wallet submits `stripe_payment_token` on instrument `type: "link"`, demoting `link-cli mpp decode` and merchant HTTP 402 probing to fallback/Standalone-only paths so agent docs stop treating merchant probe as the default SPT acquisition route - Mirrored the same handler mapping and payment-handler guidance in `site-docs/deployment-modes/ucp-native.md` and `docs/ucp-native-demo-merchant-profile.example.json` so the published site and copyable demo profile stay aligned with the normative spec ---
# Conflicts: # CHANGE_LOG.md # site-docs/deployment-modes/ucp-native.md
- Replaced placeholder Stripe UCP handler examples (`com.stripe.agentic_commerce.shared_payment_token`, `stripe_spt_demo_h1`, `shared_payment_token` instrument) with the published `com.stripe.payments` handler (`2026-06-25`) in `specification.md` §7.2, §7.4, and §7.7.2, because Stripe's handler schema is now available and issue [#108](wix-private/universal-scheduling-protocol-spec#108) requires real wire shapes instead of pre-schema placeholders - Added normative prose that UCP-Native platforms **MUST** read `network_id` from checkout `available_instruments` (`type: "link"`, `config.network_id`) and that Link Agent Wallet submits `stripe_payment_token` on instrument `type: "link"`, demoting `link-cli mpp decode` and merchant HTTP 402 probing to fallback/Standalone-only paths so agent docs stop treating merchant probe as the default SPT acquisition route - Mirrored the same handler mapping and payment-handler guidance in `site-docs/deployment-modes/ucp-native.md` and `docs/ucp-native-demo-merchant-profile.example.json` so the published site and copyable demo profile stay aligned with the normative spec ---
- Added a human-confirmation requirement to `specification.md` §8.5: an agent MAY facilitate a paid Standalone booking, but the buyer MUST authorize the charge on a trusted, deterministic surface unless a negotiated mechanism supplies AP2-equivalent cryptographic proof of authorization. Standalone Mode previously had no such rule, so a conforming implementation could charge a buyer with no human confirmation, while UCP-Native inherits UCP checkout's trusted-UI rule through the capability `dev.usp-protocol.services.paid_bookings` extends. The addition is parity with UCP, states no vendor or product, adds no wire field, and leaves §7 unchanged - Defined what counts as a trusted, deterministic surface (business-hosted `continue_url` page, a checkout system or payment provider confirmation surface, or a deterministic platform component) so the requirement is testable without USP prescribing which party renders it - Clarified §8.5.4 that "programmatically" describes charge mechanics rather than buyer authorization, and changed §8.6.3 from "the buyer **MAY** complete payment on the business-hosted page" to a statement that the page is the trusted surface for the redirect path, because both readings otherwise contradicted the new §8.5 rule - Mirrored the rule in `site-docs/deployment-modes/standalone.md` (Payment Integration, embedded flow, redirect flow) and added a Standalone security-checklist row in `site-docs/security.md` marked inherited for UCP-Native, so the site does not describe agent-completable payment after the spec forbids it ---
# Conflicts: # CHANGE_LOG.md # specification.md
- Added non-normative §9.7 Observability join recommending optional `USP-Correlation-Id` / `_meta.usp.correlation_id` propagation across money-path hops, because Track S (#160) needs a single vendor-neutral join convention without making observability a USP conformance gate - Placed the recommendation once under Transport Bindings with per-binding carriage (REST/A2A HTTP header, MCP `_meta`, ESP `correlation_id`) and explicit "omitting this is conformant" language, matching how idempotency and profile already pair REST headers with MCP fields - Documented optional overlays in `openapi/usp-rest.json` and `openrpc/usp-mcp.json`, mirrored the join on `site-docs/transport/` pages, and listed `USP-Correlation-Id` under future IANA registration so machine-readable bindings stay aligned with the advisory spec text --- ## 23/08/26 at 14:10:26 by [Ran Yahalom](mailto:ranya@wix.com) - Rewrote UCP-Native payment-handler prose in `specification.md` and `site-docs/deployment-modes/ucp-native.md` as protocol rules only (checkout `available_instruments` authority, `handler_id` matching), and removed the site-docs GitHub issue link plus Stripe/CLI/402 probing from normative text, because those were implementation details and tracker references rather than USP requirements. Stripe handler JSON remains in examples only ---
# Conflicts: # CHANGE_LOG.md # specification.md
- Fixed §10.1.6 identity binding so trust-on-first-use is **keyed by principal**, not by profile URI, because the previous MUST rejected any principal that did not match the one recorded for a URI and would lock out every later instance of a shared platform profile after the first caller - Left the converse case (a different key presenting an already-seen URI) as optional flag-or-rate-limit only, because a single keyless profile document is deliberately shared across a population of personal agents and that presentation is the normal case, not impersonation - Aligned the §9.2.2 MCP restatement and `site-docs/security.md` plus REST/MCP transport pages with the same direction so the site and the MCP "bound to" sentence cannot be read as URI-to-principal rejection ---
# Conflicts: # CHANGE_LOG.md
A binding that neither emits webhooks nor advertises sending them can satisfy the MUST lists without implementing webhook signing or MCP notifications, while emitters remain bound to §10.1.1 and JSON-RPC notification shape.
Record the converged plan for conditioning Booking expiry MUSTs on advertised expires_at.
Omission is conformant when nothing is held; advertising the deadline remains a hard MUST. Payment-action expiry stays independent.
…deadline. The previous description required the field for pending and requires_action, which would mark honest omission as invalid.
Keep published docs aligned with §5.2 so omission is documented as conformant when nothing is held.
Document why omission is conformant when nothing is held and why an advertised deadline stays a MUST.
Keep both registry search parameters aligned with the canonical schema instead of repeating an underspecified array shape.
Preserve the required rationale entry and acknowledge the independent webhook-signing landing before rebasing.
Acknowledge the independent booking expiry landing before rebasing onto integration.
- Conditioned §9.2.3 signature verification on emitted webhook payloads so that section cannot be read as requiring outbound webhooks after the REST and MCP checklists became outbound-only MUSTs - Restated `confirmation_mode` on the service-catalog site page with the advertised `expires_at` cancellation rule, because the shortened "approval within 24 hours" line no longer matched the booking-expiry advertisement condition - Restated standalone payment-action expiry to match §8.5.4: the payment clock is independent of Booking `expires_at`, and a payment action deadline SHOULD not outlive an advertised booking deadline or an existing hold ---
- Completed the §7.2 free-service-only UCP profile example with the same `business` identity object as the paid example, because `business_schema` requires `business` and the published free-service fence could not be copied as a valid document - Added a `usp_check.py schemas` instance check that extracts §7.2 `ucp` documents, validates them against `business_schema`, and requires the UCP-Native site-docs profile examples to match, so those published examples cannot drift from the canonical schema or from each other ---
- Added specification §7.5.1 (merchant policy parity and eligibility, UCP overlay), because Track S required a UCP-first decision on mandatory acceptances, eligibility, and recurring scope without inventing parallel USP wire types - Clarified that §10.1.4 buyer consent is privacy-only and that mandatory checkboxes use UCP checkout escalation or USP `requires_action`, so implementers do not overload consent categories for merchant policy gates - Mirrored the overlay in `site-docs/deployment-modes/ucp-native.md`, `site-docs/specification/service-catalog.md` (service policies, links), and `site-docs/roadmap.md` (recurring enrollment out of the current release), keeping the published site aligned with the normative text ---
- Added approved design and implementation plans plus a bitmap mental model and end-to-end data flow, because registry implementers need to understand why Roaring sets are used and how their operations produce coverage, density, and soonness - Expanded intent projection into complete worked groups for grid boundaries, unions, occupancy, duration selection, invalid hints, flag modes, freshness, horizon arithmetic, and pagination, correcting the before-origin soonness calculation and making every intermediate ranking value derivable - Restored the service-catalog and discovery-registry site pages as full implementer-facing mirrors, because the previous summaries omitted wire decoding details, ranking rationale, dominance and refresh rules, and most planned edge cases - Added data-driven projection vectors, known-empty and all-open checks, validity-boundary assertions, and tutorial coverage sentinels, so calculations and public documentation cannot silently regress or become abbreviated again - Reordered the implementation tutorial from bitmap construction through ranking output and corrected its links to targets that will exist after publication, so producer, registry, and agent owners can follow one verified reading path --- ## 29/08/26 at 17:17:50 by [Ran Yahalom](mailto:ranya@wix.com) - Added `AvailabilitySlotBitmap`, non-empty `slot_bitmaps`, optional `valid_until`, and registry `DesiredServiceTimePreference`, `RankSignals`, `desired_service_time_ranges`, and `prefer_sooner_availability_slots` in canonical schemas, because discovery ranking needs one portable bitmap contract and disclosed rank ingredients without duplicating shapes in bindings - Wrote normative specification sections 3.6.2-3.6.6 and 6.3.2-6.3.4 (projection, scoring, freshness cutout, dominance invariant, edge-case matrix) and fixed the `AvailabilitySlotBitmap` anchor slug, so implementers can derive the same coverage, density, and soonness results from the prose - Extended OpenRPC `usp_registry_search_services` with the new request parameters and thin `DesiredServiceTimePreference` / `RankSignals` component references, because MCP callers need the same ranking inputs as REST without inline schema duplication - Adapted the playground Swedish massage fixture to Back Massage with the verified two-duration Roaring32 hint, removed summary-only hints elsewhere, and added `tools/availability_ranking_checks.py` plus `usp_check.py` schema, projection, scoring, rejection, and dominance assertions (with `pyroaring` in `requirements-dev.txt`), so fixtures and CI enforce the bitmap ranking contract - Removed the dead `site-docs/migration.md` allowlist entry from `check_authority`, because the migration page is already gone and v2 has no published predecessor on the site --- ## 29/08/26 at 17:14:49 by [Ran Yahalom](mailto:ranya@wix.com) - Expanded `site-docs/specification/service-catalog.md` with availability bitmap subsections (what gets published through The JSON), updated field tables, removed 6-hour decay language, and replaced summary-only hint examples with `slot_bitmaps`, so the published catalog docs match the normative bitmap ranking model - Added availability ranking sections to `site-docs/specification/discovery-registry.md` (search request usage, reading it back, intent projection edge cases), plus `desired_service_time_ranges`, `prefer_sooner_availability_slots`, and `rank_signals` on search examples, so registry discovery docs stay aligned with bitmap-based reranking - Updated `site-docs/specification/availability.md` caching tier text to reference `valid_until` instead of 1-6 hour hint TTL, because freshness is now a usability cutout rather than continuous score decay - Removed invalid summary-only `availability_hint` objects from `site-docs/playground/scenarios/services.json` (unknown availability is omitted), pending the main playground fixture update with the back-massage bitmap example - Deleted `site-docs/migration.md` and removed its MkDocs nav entry, because v2 has no published predecessor to migrate from on the site ---
- Trimmed availability-hint and registry-ranking prose to the interoperability boundary: sections 3.6 and 6.3 now carry wire shapes, semantic guarantees, and response-state rules only, because projection procedures, scoring formulas, horizons, weights, dominance arithmetic, and worked ranking walkthroughs are registry-specific implementation detail that does not belong in normative protocol text - Consolidated the former 6.3.2-6.3.4 subsections into one "Availability Ranking Context and Response Signals" section that states the advisory request shapes, the observable guarantees a client can rely on, and a response-state table separating unknown (`hint_usable: false` with null values) from known non-overlap (`coverage: 0`), so agents stop inferring unavailability from a registry that simply had no structured evidence - Made `slot_bitmaps` optional inside `AvailabilityHint` in `schemas/catalog.json` and the prose, since a producer that never sampled a grid previously had to drop the natural-language summary as well; a summary-only hint is now valid and yields the unknown response state - Required all five `RankSignals` members whenever the object is emitted in `schemas/registry.json`, because a partially populated object made unknown and known-empty indistinguishable for clients re-ordering a page - Mirrored the same boundary in `site-docs/specification/service-catalog.md` and `site-docs/specification/discovery-registry.md` so the published site does not describe an algorithm the specification no longer states - Simplified the playground availability fixture to one structured hint and added a summary-only hint, so the fixtures exercise both hint forms now that structured rulers are optional - Rewrote `tools/availability_ranking_checks.py` and the availability check in `tools/usp_check.py` to assert the public contract (bitmap decoding and index bounds, index-to-time mapping across offsets, the exclusive `valid_until` cutout, age-neutral usability, and every response state) and to fail if registry-specific ranking material reappears in public sources - Aligned the section 4 caching tier with the validity model instead of a fixed 1-6 hour window, which contradicted the producer-declared `valid_until` cutout ---
- Corrected Section 7.6.1, which claimed UCP checkout cannot express a deposit with a remainder owed at service time. Verified against the current UCP specification: the payment terms extension `dev.ucp.common.payment.terms` models exactly that, and carries the accepted term onto the order so the outstanding amount stays machine-readable. The claim was true only of the UCP version the specification still pinned, and read as a protocol limitation rather than a stale dependency.
- Rewrote Section 7.6.1 so all three payment timings are specified for UCP-Native Mode, with a capability column stating what each one requires beyond base checkout. `deposit_required` needs only the UCP payment terms extension; `at_service` additionally needs the new USP extension below. The fail-closed rule is retained but now keys on whether the business declared the required capabilities, rather than on the timing being unspecified.
- Added Section 11.3, the Pay-at-Service Settlement Extension (`dev.usp-protocol.services.pay_at_service`), with `schemas/pay_at_service.json`. UCP payment terms can disclose that money falls due after completion but assumes a stored instrument will be charged for it, requiring that instrument to be capable of every schedule on the selected term. A buyer paying cash at the counter supplies no instrument, so a checkout that will never charge anything had no specified completion path. The extension adds one declaration that a named term is settled offline, which is what lets a business offer the term with no payment handler and a platform complete with no instrument instead of inferring it from an absence.
- Constrained the extension so a platform that does not implement it still behaves correctly: the `at_service` timing class is not `immediate`, and UCP already defines an unrecognized timing class as not due at completion, so an unaware platform concludes the payment is outstanding rather than taken.
- Required `due_at` on every pay-at-service schedule even though UCP makes it optional. UCP tells businesses to omit it when the date depends on a future event; a booked slot is a time known at checkout, so requiring it lets a platform set a reminder rather than parse prose.
- Gave `at_service` two conforming paths in UCP-Native Mode rather than one. An earlier draft of this change required a checkout for it, which would have put checkout infrastructure in front of precisely the cash-only businesses least equipped to run one. The direct path (no checkout, same steps as a free booking) is now normative and extended to Section 7.6, and the checkout path with the settlement extension is required only when a checkout is actually used, which is what a mixed cart needs.
- Clarified in Sections 2.2.1 and 2.2.2 that "checkout-free" describes payment rather than the checkout object, since pay-at-service may optionally run through a zero-collection checkout. Without this a reader would conclude from `status: not_required` and `amount_due: 0` that nothing is owed, when the obligation lives on the payment term.
- Bumped every UCP version pin from 2026-01-11 to 2026-08-25 across the specification, site-docs, the demo merchant profile, and the home page. A profile declaring the payment terms extension at 2026-08-25 alongside a core version of 2026-01-11 would have been incoherent. Verified first that the UCP checkout status values the specification cites informationally are unchanged in the newer version.
- Repaired every UCP documentation link, all of which had gone stale: the checkout specification moved under `shopping/`, the REST binding page moved again to `shopping/checkout/rest/`, the checkout JSON Schema moved under `latest/`, and the shopping OpenAPI document moved from `schemas/` to `services/`. Two of the four were returning 404 rather than redirecting.
- Registered `pay-at-service-settlement-extension` as a canonical specification fragment in `tools/usp_check.py` and added the matching anchor to the site-docs specification index, so the capability's profile `spec` URL resolves on the published site rather than pointing at a fragment that does not exist.
- Synced site-docs: the UCP-Native profile examples (which CI asserts match Section 7.2 byte for byte), the payment timings section, a new extensions page section for the settlement extension, and the core-concepts commerce-mode table.
- Added the two conditional capability entries to the Section 7.2 example profile with a note that they are required only for the timings that need them, so the example does not read as making them mandatory.
---
## 11/09/26 at 14:37:14 by [Ran Yahalom](mailto:ranya@wix.com)
- Rebuilt Section 9.4 as three disjoint error families (business outcome, protocol error, ESP frame code) with a total code matrix, because `site-docs/errors/` had registered RFC 9457 Problem `type` URIs for codes the spec classified as HTTP 200 business outcomes, so a conforming client could not tell from the spec whether to read `messages[]` or a Problem body
- Replaced the unscoped "`booking_not_found` returns 200" rule with a per-operation rule keyed on where the identifier appears: path-addressed operations return 404, body-identified batch operations report unknown ids in `messages[]`. The previous blanket rule contradicted the OpenAPI binding, which was already correct
- Declared the JSON-RPC number a coarse bucket and `data.code` the authoritative, mandatory discriminator, which resolves the conflict between the spec's per-code -32001..-32009 assignment and OpenRPC's single -32600, and also unblocks future codes now that the -32001..-32009 range is fully allocated
- Added `hold_limit_exceeded` to the matrix and made Section 10.1.2 require it. The code existed only as an orphan site-docs page while the section mandating concurrent hold limits named no code, leaving platforms unable to distinguish "you already hold this slot" from generic rate limiting
- Standardized feed pagination on `next_cursor` as an opaque token over `(modified_at, id)` ascending with `id` as the deterministic tie-break, and removed the claim that the cursor is a timestamp string. Without a tie-break, records sharing a `modified_at` could be skipped or repeated across pages
- Made the Section 7.5 atomicity guarantee operable as six numbered rules (check before charge, never leave a charge without a booking, no partial state on failure, idempotent retry after an unknown outcome, hold disposition on failure, reconciliation). "No partial state changes are permitted" was unfalsifiable and silent on the case that actually occurs: the PSP charge succeeds and the booking write fails
- Split hold-expiry failures into `hold_expired` when the slot is still bookable and `slot_unavailable` when it is not. Requiring `slot_unavailable` for both told platforms to discard a slot that was still free
- Added Section 4.2.1 requiring atomic hold-to-booking conversion, with a failure matrix and the rule that `party_size` **MUST NOT** exceed the hold's `spots`. The relationship between the two capacity counters was previously undefined, so a booking could claim spots that were never reserved
- Required reschedule to acquire the new slot before releasing the original, since the unordered "original slot is released and the new slot is occupied" permitted an implementation that leaves the buyer with no booking at all
- Added Section 5.1.1, a per-operation booking state transition table plus `invalid_transition`. The lifecycle diagram showed which statuses follow which but never which operation is legal from a given status, and a stale "MUST return a 409" in the reschedule section contradicted the 200-plus-`messages[]` business-outcome rule
- Rescoped the Section 7.2 profile requirement to USP-owned capability keys and removed USP's assertion about what makes a UCP profile valid overall. USP has no authority to define UCP profile validity, and a consumer that cannot resolve the checkout capability now fails closed for checkout-backed services rather than rejecting the whole profile
- Added Section 7.6.1 forbidding UCP-Native businesses from advertising `at_service` or `deposit_required`, neither of which has a specified payment path in that mode. Letting a platform improvise produces a booking that looks confirmed to the buyer while the business has no record of how it will be paid
- Renamed the Section 2.2 commerce modes to No payment / Pay at service / Pay at booking / Deposit at booking, because two of them were called "Standalone", which collided with the Standalone deployment mode and made an ordinary configuration read as a contradiction
- Extended Section 10.1.3 with platform-side privacy requirements (log minimization, redaction in error echoes, cache bounds, no secondary use, limited onward transfer). All three prior bullets constrained only the business, while the platform holds the same data across many buyers
- Added `schemas/esp.json` defining all twelve ESP messages, so Section 9.5.3's requirement to validate every frame against "the expected JSON-RPC schema" now names a schema that exists; six delegation messages previously had no documented wire shape anywhere
- Encoded the Section 3.11 service-validity prose as machine-checkable `if`/`then` and `oneOf` constraints in `schemas/catalog.json`, added `capacity.waitlist` to `availability.json` so the `waitlist` slot state has the flag it is keyed off, added `delivery_address` to `paid_bookings.json` so UCP-Native checkouts can carry `at_buyer_location` addresses, and constrained `canceled_by` to an enum
- Added the four missing MCP feed-subscription methods to `openrpc/usp-mcp.json` and Section 9.2.1, establishing 31 REST to 31 MCP parity, and downgraded the A2A mapping to informative and partial with an explicit non-parity list, since it covers 12 of 31 operations and was presented as complete
- Added three flow test vectors under `tests/vectors/flow/` for hold expiry mid-checkout, a concurrent-hold race, and DST-spanning slots. Each records the plausible wrong answers and what they cost, because a spec can say "atomic" and "use instants" and be read as agreement by two implementations that behave differently
- Added a `coherence` subcommand to `tools/usp_check.py` and wired it into CI. It catches the three drifts that read as healthy prose: a field table naming a field its schema dropped, an operation added to one binding only, and a binding emitting an error code the matrix never defined
- Fixed the MCP business-outcome path to `result.structuredContent.messages[]` in all three places it was wrong, and corrected the UCP checkout example to `order: { id }` rather than a root-level `order_id`, which agents would otherwise read as a real UCP field.
- Dropped the Section 3.6.3 claim that `start_interval` restates `booking_window.slot_interval`, because the ruler tick is per bitmap entry and can differ from the live-slot policy, so consumers that substituted the policy decoded the wrong starts - Stated that `coverage`, `density`, and `soonness` are comparable only within one vertical and within one entry's grid, extending the existing "not comparable across registries, requests, snapshots, or scoring instants" rule, because density is a fraction of that entry's own `slot_count` and mixed-vertical comparison ranked class and course calendars against appointment grids - Mirrored both rules in `site-docs/specification/service-catalog.md`, `site-docs/specification/discovery-registry.md`, `schemas/catalog.json`, and `schemas/registry.json` `RankSignals`, so the published site and the canonical schemas do not keep the old equivalence or the old comparability bound - Extended `tools/usp_check.py` availability contract fragments so a later edit cannot restore the restatement sentence or drop the vertical and grid comparability language
# Conflicts: # CHANGE_LOG.md
- Rewrote the Section 7.5 cancel-checkout requirement as a mechanism-agnostic invariant on the USP booking resource observed through `GET /bookings/{booking_id}`, so a business must not leave that booking in a state from which Section 5.1.1 requires accepting `confirm`, without prescribing how the internal record is stored
- Clarified that derivation rule 2 constrains only the checkout-scoped `BookingContext.booking_status` summary, resolving the ambiguity that previously cited that rule while naming the booking record
- Added `cancellation.reason_code` (open vocabulary, well-known value `checkout_abandoned`) and required `reason_code: checkout_abandoned` with `canceled_by: system` when a booking is terminalized because its checkout was canceled and never reached `confirmed`, so platforms can distinguish abandonment from a confirmed-appointment cancellation on the agent-facing wire
- Required `canceled_at` stability across reads so derive-and-stamp-now cannot report a different cancellation instant on every `GET`
- Made buyer-facing cancellation-notice suppression normative for the never-confirmed case while keeping the `booking.canceled` webhook a SHOULD
- Forbade `booking_status: pending` on a canceled checkout and permitted omitting the `booking` object on the cancel response
- Documented the silent-abandonment terminal-path gap in Section 5.2 when `expires_at` is omitted and no explicit `cancel_checkout` runs
- Added flow vector `105-cancel-checkout-abandoned-booking` and mirrored the cancel rules in `site-docs/deployment-modes/ucp-native.md` and `site-docs/specification/booking.md`
- Corrected the Section 7.5 cancel-checkout invariant to say Section 5.1.1 "requires or permits" accepting `confirm`, `reschedule`, or `update`, because `reschedule` from `pending` is `SHOULD` rather than `Yes` and the previous wording claimed a requirement the cited table does not make; mirrored in `site-docs/deployment-modes/ucp-native.md` - Added a wrong answer to flow vector `105-cancel-checkout-abandoned-booking` for keying the terminal state on USP `pending` instead of the specific backing state the abandoned checkout left behind, because a status mapping that folds several backing states into `pending` would also match a paid manual-confirmation booking awaiting merchant approval, which derivation rule 1 makes `pending` and which must never be reported canceled
A hosted agent's address must not be sent as the buyer's IP.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.