Generic SPT payment handler

[armsteadj1]

Description

Proposes a UCP-governed Shared Payment Token (SPT) payment-handler specification.

This adds a first-class payment-handler specification for dev.ucp.payment.shared_payment_token, describing how a UCP business can advertise support for an opaque, short-lived, merchant-usable payment credential that is redeemed through a configured processor, wallet, network, or credential provider.

The goal is to provide a provider-neutral payment-handler shape for agentic-commerce flows where agents need to present scoped payment credentials without receiving or exposing raw PAN, CVC, network-token cryptograms, bank credentials, wallet secrets, or PSP secrets.

This PR adds:

• a new docs/specification/shared-payment-token-payment-handler.md specification page
• navigation under the UCP Payment Handlers section
• handler naming and registration guidance for dev.ucp.payment.shared_payment_token
• request/response examples for advertising and invoking the handler
• security guidance for binding, replay protection, expiry, single-use credentials, and processor routing

This is intentionally proposed as a payment-handler specification, not as a core UCP protocol change. It does not modify core transport behavior, checkout state machines, JSON schemas, SDKs, or generated models.

Category (Required)

Please select one or more categories that apply to this change.

• Core Protocol: Changes to the base communication layer, global context, or breaking refactors. (Requires Technical Council approval)
• Governance/Contributing: Updates to GOVERNANCE.md, CONTRIBUTING.md, or CODEOWNERS. (Requires Governance Council approval)
• Capability: New schemas (Discovery, Cart, etc.) or extensions. (Requires Maintainer approval)
• Documentation: Updates to README, or documentations regarding schema or capabilities. (Requires Maintainer approval)
• Infrastructure: CI/CD, Linters, or build scripts. (Requires DevOps Maintainer approval)
• Maintenance: Version bumps, lockfile updates, or minor bug fixes. (Requires DevOps Maintainer approval)
• SDK: Language-specific SDK updates and releases. (Requires DevOps Maintainer approval)
• Samples / Conformance: Maintaining samples and the conformance suite. (Requires Maintainer approval)
• UCP Schema: Changes to the ucp-schema tool (resolver, linter, validator). (Requires Maintainer approval)
• Community Health (.github): Updates to templates, workflows, or org-level configs. (Requires DevOps Maintainer approval)

Related Issues

None yet. Opening this PR to start review and discussion on whether Shared Payment Token support should be standardized as a UCP payment-handler specification.

Checklist

• I have followed the Contributing Guide (including Conventional Commits title requirements and ! for breaking changes).
• I have updated the documentation (if applicable).
• My changes pass all local linting and formatting checks.
• I have added tests that prove my fix is effective or that my feature works. N/A — documentation/specification-only change; no runtime behavior changed.
• New and existing unit tests pass locally with my changes. N/A — no SDK, schema, or runtime code changed.
• (For Core/Capability) I have included/updated the relevant JSON schemas. N/A — proposed payment-handler specification only; no core UCP JSON schemas changed.
• I have regenerated Python Pydantic models by running generate_models.sh under python_sdk. N/A — no Python SDK or schema model changes.

Screenshots / Logs (if applicable)

Local validation performed:

git diff --check main...HEAD
uv run mkdocs build --site-dir /tmp/ucp-spt-spec-build

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[dkoch74]

Providing a specific payment handler implementation for SPT is not a good fit here IMO - the spec is reserved for broad description and explanation of the protocol itself.

I suggest considering necessary revisions to the Tokenization doc instead which covers the related work, and/or creating an issue describing the knowledge gap/need for this change. Thanks.