Feature/INT-1702 - Airline and accommodation sub-tree model alignment

[david-ruiz-cko]

This pull request introduces several important improvements and corrections to the payment industry data models, focusing on better alignment with the API specification, increased robustness in JSON (de)serialization, and enhanced documentation. The most significant changes include improved handling of polymorphic array/object fields, migration of several properties to more flexible types, and extensive JavaDoc updates for clarity and maintainability.

Improvements to JSON (de)serialization and data model flexibility:

• Added a custom deserializer in GsonSerializer to handle fields that may be either a single object or an array (notably for airline passenger data), ensuring consistent internal representation as a list and always serializing as an array. This prevents data loss and aligns with the API's flexible input. [1] [2]
• Updated Industry and related classes to map airline and accommodation properties as lists (List<AirlineData>, List<AccommodationData>) instead of single objects, matching the API specification and fixing previous serialization issues.

Data type corrections and deprecations:

• Changed several fields from enum types (e.g., CountryCode) to plain String to accommodate the API's use of both two- and three-letter country codes, increasing compatibility. [1] [2]
• Deprecated and documented old or duplicate classes and fields (e.g., PaymentContextsAccommodationData, serviceClass in FlightLegDetails, hubModelOriginationCountry in ProcessingSettings) to guide developers toward the preferred usage and maintain backward compatibility. [1] [2] [3]

Documentation and JavaDoc enhancements:

• Added or improved JavaDoc comments across all affected classes and fields, providing clear descriptions, usage notes, and references to the API specification. This improves maintainability and developer understanding. [1] [2] [3] [4] [5] [6] [7] [8] [9]

New features and classes:

• Introduced PartnerCustomerRiskData to represent merchant-specific key-value pairs for transaction risk data, supporting new API features and aligning with the latest specification. [1] [2]

Property and field corrections:

• Updated property names and types for consistency with the specification (e.g., classOfTravelling, departureDate as LocalDate, numberOfNightsAtRoomRate as String), and clarified optionality and expected formats. [1] [2] [3]

These changes collectively improve the SDK's correctness, flexibility, and developer usability when handling payment industry-specific data.

[agent-wall-e]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:433>250

Operational gates

• ✅ jira_ticket (INT-1702)
• ✅ independent_review

Files analysed: 27

---

_{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
exceeds_bounded_scope — 433>250	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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: Concerns worth a look

This PR needs a human approval. Before you give it, these are the things I'd want resolved.

This PR fixes real bugs (wrong field names, wrong cardinalities, enum vs. string mismatches) and adds solid test coverage, but there are several concrete problems a reviewer must resolve before merging.

Concerns

• Breaking API change: Industry.airlineData (single object) is renamed to airline (list) and Industry.accommodationData is renamed to accommodation. Any caller already constructing Industry with the old field names will get a compile error; the PR does not show whether all callers have been updated.
• Breaking API change: FlightLegDetails.serviceClass is replaced by classOfTravelling, stopoverCode is replaced by stopOverCode, departureDate changes from String to LocalDate, and flightNumber changes from Long to String. These are source-incompatible; callers that set those fields must be updated and the diff does not show that they are.
• Breaking API change: ProcessingSettings.taxAmount, discountAmount, dutyAmount, shippingAmount, shippingTaxAmount, originalOrderAmount all change from Long to Double. While the IT tests are updated, any caller passing integer literals (e.g. taxAmount(500L)) will fail at compile time; the diff only shows partial coverage of callers.
• Breaking API change: PaymentContextsAccommodationData.state changes from CountryCode to String and country changes from CountryCode to String, and PaymentContextsAccommodationRoom.numberOfNightsAtRoomRate changes from Integer to String. Existing callers passing CountryCode or Integer values will break.
• Breaking API change: PaymentContextsProcessing.accommodationData changes from List<PaymentContextsAccommodationData> to List<AccommodationData>. Any caller constructing that list with the old type will break.
• The double-Javadoc block on singleOrArrayDeserializer in GsonSerializer.java (one Javadoc for the deserializer, then immediately another for the factory) suggests the first block is orphaned — the actual method it should document is cut off in the truncated diff. If singleOrArrayDeserializer has no Javadoc because the patch is missing it, that's cosmetic; but if the first block is attached to nothing, it's a documentation error.
• The singleOrArrayPassengerFactory writes a single object when passenger has exactly one element and an array when it has more, based on a sandbox test dated 2026-09-25 (a future date). For AirlineData (used by POST /payments), the API accepts both shapes, but the truncated diff does not confirm the write-path logic is correct for all covered surfaces (hosted-payments, payment-links). The comment says one object is accepted everywhere but an array breaks hosted-payments/payment-links — the write logic must be verified to be correct for both the single- and multi-passenger cases.
• Missing newline at end of Industry.java (the diff shows no trailing newline), which will cause a warning in some build tools; minor but visible.
• The ProcessingData.taxAmount field is changed from Long to Double in the response object — if response JSON contains integer values like 3000, Gson will parse them as 3000.0, which is fine, but if any existing code compares taxAmount using Long.equals or casts it, those will break silently at runtime.

⚠️ The diff was too large to read in full, so this review covers only part of the change.

---

_{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}

[agent-wall-e]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:514>250

Operational gates

• ✅ jira_ticket (INT-1702)
• ✅ independent_review

Files analysed: 27

---

_{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
exceeds_bounded_scope — 514>250	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:525>250

Operational gates

• ✅ jira_ticket (INT-1702)
• ✅ independent_review

Files analysed: 27

---

_{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
exceeds_bounded_scope — 525>250	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:551>250

Operational gates

• ✅ jira_ticket (INT-1702)
• ✅ independent_review

Files analysed: 29

---

_{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
exceeds_bounded_scope — 551>250	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:551>250

Operational gates

• ✅ jira_ticket (INT-1702)
• ✅ independent_review

Files analysed: 30

---

_{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
exceeds_bounded_scope — 551>250	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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
3 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud