Release 2.5.0 - Airline and accommodation sub-tree model alignment

[david-ruiz-cko]

This release introduces several new payment-related data models and improves the documentation and type annotations for existing models in the CheckoutSdk::Payments module. The changes enhance clarity, ensure better alignment with the payment API specification, and add support for new payment attributes such as accommodation and aggregator data. The most important changes are grouped below:

New Payment Data Models

• Added AccommodationData and related classes (AccommodationAddress, AccommodationGuest, AccommodationRoom, AccommodationPhone) to represent accommodation booking information in payments.
• Introduced Aggregator class to capture payment aggregator details.
• Added PartnerCustomerRiskData class for merchant-specific key-value risk data.

New Enumerations and Types

• Added PanProcessedType, ProcessingCardType, and AchServiceType enums to specify PAN preference, card processing type, and ACH service type, respectively. [1] [2] [3]

Improvements to Airline Data Models

• Enhanced AirlineData documentation to clarify the usage and cardinality of the passenger attribute, and updated type annotations for its attributes.
• Improved Passenger and PassengerAddress documentation, specifying required formats and adding examples. [1] [2]
• Updated FlightLegDetails to provide detailed attribute documentation and align property names and types with the API specification (e.g., class_of_travelling, stop_over_code).

Type Annotation and Documentation Improvements

• Standardized array type annotations in ProcessingData (e.g., Array(String) instead of Array<String>), and improved documentation for accommodation and airline data attributes. [1] [2] [3]

Dependency Management

• Updated payments.rb to require the newly added files and remove an obsolete require statement for sender/ticket. [1] [2]

[agent-wall-e]

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

• no_low_class_matched
• prod_source_modified

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
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.

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}

[agent-wall-e]

🔵 Advisory review: Sound, but needs your judgement

This PR needs a human approval. The code itself reads as correct; whether it should land depends on context I don't have.

The diff shown only contains the version bump from 2.4.0 to 2.5.0; all substantive changes described in the PR body (new models, enums, documentation, require updates) are not visible in this diff, so correctness of the full release cannot be verified here.

For you to decide

• The diff is partial — only version.rb is shown, so none of the claimed new files (AccommodationData, Aggregator, PartnerCustomerRiskData, new enums) or modifications to AirlineData, FlightLegDetails, ProcessingData, or payments.rb can be reviewed.
• A human reviewer must verify that the new require statements in payments.rb actually load all new files, and that no old require (e.g., sender/ticket) is removed incorrectly.
• The version increment to 2.5.0 implies a minor release with new public API surface; a human should confirm that semantic versioning intent matches the actual scope of changes and that no breaking changes are hidden in the unseen diff.
• If this is a gem release, the reviewer should confirm that the gemspec or Gemfile.lock (if relevant) and changelog/CHANGELOG entry are also updated consistently with 2.5.0.

---

_{This is not an approval. wall-e cannot auto-approve this PR — it is an opinion to help whoever does. Advisory review · us.anthropic.claude-sonnet-4-6 · wall-e 2026.06.19-02}

[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