Release 6.5.0 - Airline and accommodation sub-tree model alignment

[david-ruiz-cko]

This release introduces comprehensive improvements to the PHP SDK's payment and processing data models, focusing on documentation clarity, alignment with API specifications, and enhanced support for accommodation and airline payment features. The changes include detailed docblocks for classes and properties, deprecation notices for outdated fields, and new or updated models for handling accommodation and airline data across different payment flows.

Documentation and Specification Alignment

• Added or improved docblocks for nearly all major payment-related classes (e.g., AccommodationData, AccommodationGuest, AccommodationRoom, Passenger, FlightLegDetails, airline data classes) to clarify their purpose and usage. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]
• Updated property annotations to use correct array/object types, added [Optional] markers, and provided detailed notes on API quirks, expected types, and backward compatibility. [1] [2] [3] [4] [5] [6]

Accommodation and Airline Data Enhancements

• Added new properties to AccommodationData (e.g., property_phone, customer_service_phone) and introduced the AccommodationPhone model to support richer accommodation contact details. [1] [2]
• Refined airline and accommodation data handling in processing and payment context classes, ensuring correct property names and types per API requirements (e.g., plan instead of billing_plan, ticket/passenger as objects not arrays, use of shared models). [1] [2] [3]

Deprecations and Backwards Compatibility

• Added deprecation notices for properties and classes no longer supported by the API (e.g., service_class in FlightLegDetails, PaymentContextsPartnerCustomerRiskData), with guidance on preferred alternatives. [1] [2]
• Clarified which properties are retained for backwards compatibility and which are ignored by the gateway. [1] [2]

Schema and Model Corrections

• Updated several models to use the correct local versions (e.g., PaymentSetupAccommodationAddress, PaymentSetupAccommodationRoom) where the schema differs from the main payment models. [1] [2]
• Improved handling and documentation of airline and accommodation arrays in processing settings, payment contexts, and main payment requests. [1] [2] [3]

New Models

• Introduced AccommodationPhone to encapsulate property and customer service phone details for accommodations.

These changes significantly improve the maintainability, correctness, and clarity of the SDK's payment data models, making integration with the Checkout API more predictable and robust.

[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 diff only increments the SDK version constant string, which is a non-destructive, function-preserving change with no auth, data persistence, new endpoints, or new integrations.

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 2

---

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}

[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 diff only increments the SDK version constant string, which is a non-destructive, function-preserving change with no auth, data persistence, new endpoints, or new 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 diff only bumps the SDK version constant string, which is a non-destructive, function-preserving change with no new integrations, auth changes, persisted data, or logic modifications.

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}