pyproject.toml pins ucp-sdk==0.4.4, and the commit that set it says why: "matching the UCP 2026-04-08 specification".
python-sdk released v2026-08-25 on 2026-08-27, declaring version = "0.5.0". The suite's newest commit fdbdafd is dated 2026-08-18 — a week before the 2026-08-25 specification was published.
The ucp_version plumbing is version-agnostic, so setting 2026-08-25 in conformance_input.json is accepted and threaded into request envelopes. What is a version behind are the Pydantic models the assertions build responses with (checkout.Checkout(**response_json) and friends). So the suite can accept the new version as a value while being unable to assert its shapes.
It is a small port, not a blocker
We measured it rather than assumed. Bumping the pin alone fails at import; the full change is:
Six import paths that moved from shopping to common/types in 0.5.0:
| Was |
Now |
shopping.payment_create_request |
common.types.payment_create_request |
shopping.payment_update_request |
common.types.payment_update_request |
shopping.payment |
common.types.payment |
shopping.types.postal_address |
common.types.postal_address |
shopping.types.total |
common.types.total |
shopping.types.reverse_domain_name |
common.types.reverse_domain_name |
One field. ShippingDestination now requires type: Literal["shipping_address"] — the tagged discriminator 2026-08-25 introduced — and the suite constructs destinations without it at two sites (integration_test_utils.py, checkout_lifecycle_test.py). Before adding it, 47 of 48 failures were that single field.
Patch
0004-adopt-ucp-sdk-0.5.0.patch — ~250 lines, mostly imports.
Verified: applied on top of the fixes in #101, #102 and #103, the suite runs on 0.5.0 and reports 58 passed / 6 failed / 13 skipped against an independent merchant, reproducibly from a clean clone. Happy to send this as a PR instead.
pyproject.tomlpinsucp-sdk==0.4.4, and the commit that set it says why: "matching the UCP 2026-04-08 specification".python-sdkreleasedv2026-08-25on 2026-08-27, declaringversion = "0.5.0". The suite's newest commitfdbdafdis dated 2026-08-18 — a week before the2026-08-25specification was published.The
ucp_versionplumbing is version-agnostic, so setting2026-08-25inconformance_input.jsonis accepted and threaded into request envelopes. What is a version behind are the Pydantic models the assertions build responses with (checkout.Checkout(**response_json)and friends). So the suite can accept the new version as a value while being unable to assert its shapes.It is a small port, not a blocker
We measured it rather than assumed. Bumping the pin alone fails at import; the full change is:
Six import paths that moved from
shoppingtocommon/typesin 0.5.0:shopping.payment_create_requestcommon.types.payment_create_requestshopping.payment_update_requestcommon.types.payment_update_requestshopping.paymentcommon.types.paymentshopping.types.postal_addresscommon.types.postal_addressshopping.types.totalcommon.types.totalshopping.types.reverse_domain_namecommon.types.reverse_domain_nameOne field.
ShippingDestinationnow requirestype: Literal["shipping_address"]— the tagged discriminator2026-08-25introduced — and the suite constructs destinations without it at two sites (integration_test_utils.py,checkout_lifecycle_test.py). Before adding it, 47 of 48 failures were that single field.Patch
0004-adopt-ucp-sdk-0.5.0.patch— ~250 lines, mostly imports.Verified: applied on top of the fixes in #101, #102 and #103, the suite runs on 0.5.0 and reports 58 passed / 6 failed / 13 skipped against an independent merchant, reproducibly from a clean clone. Happy to send this as a PR instead.