feat(payments): add PaymentSetup accommodation/airline fields

[armando-rodriguez-cko]

Summary

Adds the new PaymentSetupAccommodation and PaymentSetupAirline fields from the 2026-09-08 spec update to POST/GET/PUT /payments/setups and POST /payments/setups/{id}/confirm/{payment_method_name}. Also fixes industry.airline/industry.accommodation, which serialized under the wrong keys because of a missing @SerializedName, so the fields never reached the API correctly.

Changes

• AccommodationData.java (new), AccommodationGuest.java (new), AccommodationHost.java (new), AccommodationRoom.java (new) — full PaymentSetupAccommodation model, including the new totalNumberOfGuests, refundable, deliveryRecipient, host fields
• AirlineData.java — added totalNumberOfPassengers, travelType, tripType, refundable, deliveryRecipient, ancillaries, insurance
• AirlineInsurance.java (new), AirlineInsurancePrice.java (new) — nested insurance model
• Industry.java — fixed @SerializedName on accommodationData/airlineData so they serialize as accommodation/airline; split accommodation modelling out of the shared PaymentContextsAccommodationData type used by an unrelated /payments contexts domain
• PaymentSetupsIndustrySerializationTest.java (new) — roundtrip coverage for both schemas plus a regression test for the JSON-key fix

API Reference

• POST /payments/setups
• PUT /payments/setups/{id}
• GET /payments/setups/{id}
• POST /payments/setups/{id}/confirm/{payment_method_name}

Breaking changes

None for the new fields (additive). The industry.airline/industry.accommodation key fix changes wire format, but the old shape never matched the API contract, so nothing that worked before is affected.

README

No README changes needed.

[agent-wall-e]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:312>200

Operational gates

• ✅ jira_ticket (INT-1696)
• ✅ independent_review

Files analysed: 9

---

_{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
exceeds_bounded_scope — 312>200	classifying	§2.1 M8	More than 200 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.

Adds new PaymentSetup accommodation/airline fields and fixes the @SerializedName bug on Industry.java. The core changes look correct, but there are a few concrete issues worth resolving before approval.

Concerns

• AccommodationData.java: the field room is typed as List<AccommodationRoom> but named room (singular) — if the API contract uses a plural key like rooms, this will silently serialize under the wrong name and no @SerializedName is present to enforce the correct key.
• AirlineData.java: ancillaries is modelled as a plain String (e.g. "extra_baggage"), but the field description says 'add-ons purchased', suggesting it may be a list of values at the API level; a single string would be wrong if the API accepts an array.
• Industry.java: accommodationData is typed as List<AccommodationData> (plural/array), while airlineData is a single object — if the API spec has accommodation as a single object too, this is a type mismatch that would cause serialization/deserialization failures.
• AccommodationRoom.java: rate uses Double (floating point) for a monetary value — this is consistent with AirlineInsurancePrice.amount also using Double, but monetary amounts are typically represented as integer minor units or BigDecimal in payment APIs; both should be verified against the spec.
• PaymentSetupsIndustrySerializationTest.java: the key-fix regression test asserts assertTrue(!json.contains("airline_data")) — GsonSerializer uses camelCase-to-snake-case conversion, so without a @SerializedName the field would serialize as airline_data not airlineData; the test is valid but it would also be worth asserting the old wrong keys are absent to fully confirm the regression is fixed (only the positive assertion for "airline" / "accommodation" is there).
• AirlineData.java: no @SerializedName annotations are added to the new fields (totalNumberOfPassengers, travelType, tripType, deliveryRecipient, ancillaries) — the existing fields in AirlineData also lack them, so this is presumably relying on Gson's camelCase-to-snake-case conversion; this is consistent with the rest of the class but should be confirmed as the intended pattern (the test does verify the snake_case output).

---

_{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
9.4% Duplication on New Code

See analysis details on SonarQube Cloud