docs(payments): document connector object in payment-method responses (#156527)

[gergesfikry-ottu]

What

Documents the additive connector: { identifier, processor } object added to every payment-method entry in core PR #218 — Redmine #156527 (child of #156526).

{
  "code": "kpay-prod",
  "connector": { "identifier": "kpay", "processor": "knet" }
}

Changes

Area	File	Change
Concept	docs/developers/payments/payment-methods.md	New Connector section: identifier vs processor, the KNET/KPay & CyberSource/CSUC shared-processor examples, and a "match on connector, not code" tip.
Hand-written example	docs/developers/payments/wallet/index.mdx	connector added to the payment_methods example + cross-link to the concept.
SDK	docs/developers/payments/checkout-sdk/index.md	Cross-reference for developers building custom selection UIs.
Spec	static/Ottu_API.yaml	New Connector schema component referenced from PGPaymentMethods and PaymentMethodsForRedirect.
Auto-generated	docs/developers/apis/* (16 files)	Regenerated via npm run gen-api — connector-only diff (get-payment-methods + the 4 checkout-transaction endpoints + StatusCodes; create-invoice also embeds payment_methods).

Notes / decisions

• Enrichment overlays can't add fields — the engine only overrides existing property descriptions, so connector had to go into the raw Ottu_API.yaml. A baseline gen-api on the unmodified spec produced a zero-line diff, so the regenerated output is a clean, minimal, connector-only diff.
• Bridge until #156526 lands: the hand-add to Ottu_API.yaml will be overwritten cleanly on the next npm run fetch-api once the backend export includes connector.
• Four platform SDK guides (web/android/ios/flutter) intentionally left unchanged — they document the payment-result callback and pass setupPreload opaquely, so they contain no hand-written payment-method object. SDK consumers see connector via the Checkout response schema in the regenerated reference. (Corrects an over-specification in the ticket.)
• pg field not introduced — it isn't part of these response schemas, so documenting it here would invent a field readers can't find.

Verification

• npm run typecheck ✅
• npm run build ✅ — no new broken links/anchors (the #connector anchor and all new cross-links resolve).

🤖 Generated with Claude Code

https://claude.ai/code/session_01SJjww6AtJZPYDm6xvym3oU

[jab3z]

@claude review

[claude]

Claude finished @jab3z's task in 3m 52s —— View job

---

Review complete ✅

• Gather context (PR diff, changed files)
• Review concept doc changes (payment-methods.md)
• Review hand-written example changes (wallet/index.mdx, checkout-sdk/index.md)
• Review spec change (static/Ottu_API.yaml)
• Spot-check auto-generated diff is connector-only
• Post final review

Solid, well-scoped PR. The core mechanics all check out:

Verified correct:

• static/Ottu_API.yaml: new Connector schema (identifier, processor, both readOnly + required) is referenced consistently via allOf from both PGPaymentMethods and PaymentMethodsForRedirect, and connector was added to both schemas' required lists.
• Deep-link {{apiBaseUrl}}/payments/payment-methods/#connector in the new schema descriptions resolves correctly (apiBaseUrl = /developers per static/api-enrichments/_variables.yaml), and I confirmed it renders correctly in the regenerated get-payment-methods.StatusCodes.json.
• Anchor {#connector} on the new ### Connector heading in docs/developers/payments/payment-methods.md:73 matches all the cross-links pointing to it from wallet/index.mdx and checkout-sdk/index.md.
• The 16 auto-generated files structurally diff clean — I parsed old vs. new JSON for several of them (get-payment-methods.StatusCodes.json, others) and the only change is the additive connector property + its required entry, matching the PR's "connector-only diff" claim.
• Sidebar (sidebars.ts) correctly left untouched — payment-methods.md uses the anchor-submenu pattern keyed to ## headings only, and ### Connector is (correctly) a sub-heading under ## Guide, so it shouldn't get its own sidebar entry per the documented convention.
• wallet/index.mdx example JSON is valid and the added connector block matches the schema shape.

Two things worth a look, neither blocking:

1. Missing glossary entries. connector and processor are new domain terms with no entry in src/data/glossary-terms.ts (only Payment Gateway exists today). Root CLAUDE.md ("no jargon without definition — first use... links to the glossary") and docs/developers/CLAUDE.md's cross-referencing table ("Domain terms... → Glossary (first use per page)") both call for this. The new section is thorough and self-contained, so it's not a functional gap, just a convention gap.
   Fix this →

2. H3 subsection outside the canonical set. docs/developers/CLAUDE.md specifies that ## Guide should only contain ### Workflow, ### Live Demo, ### Step-by-Step, and ### Use Cases. The new ### Connector (payment-methods.md:73) is a fifth, non-canonical subsection sitting between Step-by-Step and Use Cases. The content itself is genuinely conceptual/reference material (not a workflow step), so it may not fit cleanly into any of the four canonical buckets as-is — worth a deliberate call on whether to fold it into an existing subsection or treat this as an intentional exception to the template.

Bridge-to-core-PR approach (hand-adding connector to static/Ottu_API.yaml ahead of the backend export) is clearly called out in the PR description as temporary and will be cleanly overwritten by the next fetch-api, which is a reasonable tradeoff given the enrichment engine can't add new fields.