Release 5.5.0 - Airline and accommodation sub-tree model alignment

[david-ruiz-cko]

This release updates the documentation and test cases for airline and accommodation data objects across multiple payment API endpoints, clarifying the differences in their accepted shapes, especially regarding the passenger field and address formats. The changes also improve test data to match the updated API field names and expected structures.

API Documentation and Behavior Clarifications:

• Added detailed documentation for airline_data and accommodation_data fields in all payment-related endpoints (Payments, HostedPayments, PaymentLinks, PaymentSessions, PaymentContexts), specifying the required and optional fields, and clarifying which endpoints accept a single passenger object vs. an array. This includes a summary table of endpoint behaviors and advice for defensive coding when reading responses. [1] [2] [3] [4] [5] [6] [7] [8] [9]

• For PaymentContexts, explicitly documented that the stop_over_code field in flight_leg_details should not be sent, as it is rejected by the API, and clarified the difference in the AccommodationData schema compared to other endpoints.

Test Case Updates:

• Updated test data in payment-setups-unit.js to use the correct field names (address_line1 instead of address_line_1), to use ISO country codes, and to match the updated array/object structures for airline and accommodation data. [1] [2] [3] [4] [5] [6]

Schema and Field Description Improvements:

• Improved inline documentation for flight_leg_details in PaymentSetups to clarify field names, expected formats, and historical inconsistencies in SDKs.

These changes ensure developers are aware of endpoint-specific requirements and quirks, reducing integration errors and making the codebase more maintainable.

[agent-wall-e]

🟢 Risk Classification: LOW

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

Classification reasons

• 2.2.7_dependency_upgrade

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 1

---

_{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
2.2.7_dependency_upgrade	classifying	§2.2.7	All files are manifest + lockfile, and no security-sensitive package was touched.

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:

• 2.2.7_dependency_upgrade

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