feat(payments): add scheme_transaction_link_id to ProcessingData

[armando-rodriguez-cko]

Summary

Adds processing.scheme_transaction_link_id (the Mastercard Transaction Link Identifier) to the response-side ProcessingData model. The field was already exposed on the request side (ProcessingSettings) but not on the response, so merchants could send it and never read it back (INT-1686, Mastercard mandate deadline 2026-10-23).

With this the Ruby model covers the swagger ProcessingData schema in full.

Changes

• lib/checkout_sdk/payments/processing_data.rb — added the scheme_transaction_link_id accessor; replaced the summary comment with per-attribute YARD documentation for all 29 attributes, carrying the swagger descriptions and constraints (locale pattern and length, partner_code pattern, preferred_scheme and pan_type_processed enum values)
• spec/checkout_sdk/payments/processing_data_spec.rb — new spec: covers every attribute of the schema, the accommodation and airline collections, and the all-nil default state

API Reference

• GET /payments/{id} — PaymentDetails.processing (ProcessingData schema)

Breaking changes

None. One new optional response attribute plus documentation.

README

No impact. The README does not document individual response fields.

[agent-wall-e]

🟢 Risk Classification: LOW

Approval route: AI Auto-Approval
Rollback controls: Automated Instant Rollback + feature flags

Classification reasons

• no_low_class_matched
• prod_source_modified
• 2.2.6_logical_extension:The change only adds a new optional accessor to an existing response model and corresponding tests, reusing existing abstractions without new endpoints, persistence, auth changes, or external integrations.

Operational gates

• ✅ jira_ticket (INT-1686)
• ✅ independent_review

Files analysed: 2

---

_{wall-e 2026.06.19-02 · policy 376219bc71e6…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
no_low_class_matched	informational	§2.2 (fall-through)	None of the deterministic Low classes (§2.2.3, §2.2.4, §2.2.7, docs-only) applied; classifier fell through to LLM evaluation.
prod_source_modified	informational	§2.1 M7 (informational)	At least one file is non-doc, non-test, non-IaC — i.e. application source code was modified.
2.2.6_logical_extension — The change only adds a new optional accessor to an existing response model and corresponding tests, reusing existing abstractions without new endpoints, persistence, auth changes, or external integrations.	classifying	§2.2.6	Sonnet 4.6 evaluator promoted minor → low: the change reuses existing code paths and does not cross a trust boundary.

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[agent-wall-e]

✅ Auto-approved — this PR meets all Low-risk criteria.

All checks passed, no unresolved comments, and the change classification is:

• no_low_class_matched
• prod_source_modified
• 2.2.6_logical_extension:The change only adds a new optional accessor to an existing response model and corresponding specs, reusing existing abstractions without new endpoints, persistence, auth changes, or external integrations.

_{wall-e 2026.06.19-02 · policy 376219bc71e6…}