Skip to content

feat: Add Payment Terms with Well-Defined Schedules#602

Draft
raginpirate wants to merge 2 commits into
mainfrom
raginpirate/payment-terms
Draft

feat: Add Payment Terms with Well-Defined Schedules#602
raginpirate wants to merge 2 commits into
mainfrom
raginpirate/payment-terms

Conversation

@raginpirate

Copy link
Copy Markdown
Contributor

Description

Introduces dev.ucp.shopping.payment_terms, an extension for expressing checkout-wide payment terms composed of immediate, deferred, or finite recurring payment schedules.

Businesses advertise complete terms through payment.available_terms[], including schedule timing and totals. Buyers select and fund a term directly through payment.instruments[].term_refs, which can target the whole term or individual schedules. This naturally composes with Split Payments—for example, using a gift card for an immediate deposit and a card for a deferred balance.

The resulting Order snapshots the complete accepted term under order.payment.terms[]. The model is designed to compose with the read-only Order payment instruments proposed in #584, preserving schedule assignments without carrying checkout-time credentials or handler details.

The structured schedule model gives platforms and businesses a shared way to determine:

  • Exactly how much is due for each payment occurrence, empowering interesting SDK usage like Apple Pay's recurring line items.
  • What terms should be bound into an AP2 mandate for ingestion as verifiable proof of a recurring term.

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

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.
  • New and existing unit tests pass locally with my changes.
  • (For Core/Capability) I have included/updated the relevant JSON schemas.
  • I have regenerated Python Pydantic models by running generate_models.sh under python_sdk.

Screenshots / Logs (if applicable)

…entages with totals, improve documentation

Assisted-By: devx/cda4fcd3-f600-4f4b-9e5e-884732556852
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant