[sswaminathan-godaddy]

Checkout payment labels returned by the API were discarded by the generated client, leaving JSON without descriptions and human output showing "Saved payment method". Preserve rich_text_description in the Shopping schema normalization and vendored client schema so checkout create/get/update display the API-provided label. No additional card or expiry fields are exposed.

The human completion summary now reads the completion API response's payment.instruments array and uses the first entry whose selected field is true. Its rich_text_description supplies the label and its id identifies the instrument. For example:

{
  "payment": {
    "instruments": [
      {
        "id": "payment-1",
        "selected": true,
        "rich_text_description": "CREDIT_CARD/VISA 4242"
      }
    ]
  }
}

This produces Selected payment: CREDIT_CARD/VISA 4242 (ID: payment-1) in human completion output. If the selected instrument has no description, the label falls back to Saved payment method. If the response has no instrument marked selected, the completion summary omits the payment line. It does not infer which method was charged from the earlier checkout. JSON output retains the API's nested payment.instruments[].rich_text_description; the human summary's selected_payment field does not change the JSON response shape.

In common.rs, the rebuilt payment instrument uses defaults for the new description field so display text is not echoed into checkout update requests. Instrument ID, selection, billing address, handler ID, and type continue to be preserved. The existing request test now verifies that an API-supplied description is omitted from the update body.

Validation:

• cargo check --workspace
• cargo clippy --workspace -- -D warnings
• cargo test --workspace (passed after allowing localhost mock sockets)
• cargo fmt --check
• ./rust/scripts/check-module-size.sh
• cargo run -- --help
• Regression coverage decodes all four generated checkout response types, verifies descriptions in JSON/human output, and confirms expiry fields remain omitted.
• Live test CLI human checkout create/get displayed payment labels; an explicitly authorized purchase completed and shopping order get --wait returned the order with its item processing.

Known limitation: the live completion output did not include the selected payment. This change renders it only when payment.instruments[] in the completion response contains an entry with selected: true.

[Copilot]

🟢 Approval recommended

The focused changes match the documented behavior, include relevant regression coverage, and have no unresolved findings.

No open issues 🎉

What changed in this PR

Preserves API-provided payment descriptions in the Shopping client so checkout JSON and human output retain saved-payment labels without exposing additional card or expiry fields.

Changes:

• Adds rich_text_description to schema normalization and the vendored payment-instrument schema.
• Shows the selected payment in human completion output only when the completion response explicitly marks an instrument as selected.
• Keeps descriptions out of checkout update requests and adds regression coverage for preservation, rendering, and omission behavior.

File	Description
rust/​tools/​generate-api-catalog/​src/​shopping_spec.rs	Preserves payment descriptions during schema normalization and tests the schema fields.
rust/​src/​shopping/​human.rs	Renders selected completion payments and tests typed responses and fallback behavior.
rust/​src/​shopping/​common.rs	Excludes display descriptions from rebuilt payment update bodies and verifies omission.
rust/​shopping-client/​openapi/​shopping.oas3.json	Adds the payment description field to the vendored schema.

_{Review effort: Balanced}

[jpage-godaddy]

Approved if rich_text_description isn't actually some encoded "rich text" format and it's actually something we can legitimately serve up from the CLI.

[jpage-godaddy]

Sounds like we have some non-user-friendly display for the credit card; that can be fixed at the API level.