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

[david-ruiz-cko]

This pull request 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: MINOR

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

Classification reasons

• exceeds_bounded_scope:1228>250

Operational gates

• ✅ jira_ticket (INT-1702)
• ✅ independent_review

Files analysed: 8

---

_{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 — 1228>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: 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.

This PR is a documentation-and-test-only change that records discovered API quirks (passenger object vs. array per endpoint, field name corrections, stop_over_code rejection on payment-contexts) and fixes the test data to match. The functional code is unchanged; the question is whether the documented workarounds accurately reflect the live API and should become the canonical SDK guidance.

For you to decide

• The integration test file payments-airline-it.js reads from process.env.CHECKOUT_DEFAULT_SECRET_KEY but registers a global afterEach outside any describe block, which will affect every other test suite in a shared test run — a reviewer should confirm this is intentional or acceptable in the project's test setup.
• The unit test file getPaymentAirlineData.js uses a hardcoded public-looking SK (sk_test_0b9b5db6-f223-49d0-b68f-f6643dd4f808) but the tests are nock-mocked, so no live credential is needed; the value is cosmetically a real key format and a reviewer should confirm it is a known dummy value used elsewhere in the project.
• The test data in payment-setups-unit.js changes airline_data: {} (object) to airline: [] (array) and accommodation_data: [] to accommodation: [] — this is a field-name change on the industry sub-object, not just a formatting fix, and a reviewer should verify these match the actual PaymentSetups API schema rather than other endpoint schemas.
• The JSDoc for hosted-payments and payment-links states that an empty array and explicit null for passenger are both rejected with 422, yet payment-sessions accepts both object and array — a reviewer should confirm these findings are reproducible and correctly attributed to the right endpoints, since the claim directly contradicts the shared PaymentInterfacesProcessing schema.
• The stop_over_code advisory in payment-contexts JSDoc says the field is rejected with 422 for every value including the spec's own example "x", while the integration test fixture in payments-airline-it.js sends stop_over_code: "x" to POST /payments (not payment-contexts) — a reviewer should confirm the scope of the rejection is correctly limited to payment-contexts only.
• The accommodation address in the new test fixtures drops address_line_2 from both the unit test and integration test; the JSDoc does not mention whether this field is accepted, rejected, or simply optional — a reviewer may want to clarify this in the docs to avoid a follow-up question.
• The accommodation_data fixture in both new test files sets country: "USA" (three-letter) while the PR description and JSDoc elsewhere specify ISO 3166-1 alpha-2 — a reviewer should confirm the API actually accepts three-letter codes here, since this is inconsistent with the alpha-2 guidance given for address.country.

⚠️ 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:1228>250

Operational gates

• ✅ jira_ticket (INT-1702)
• ✅ independent_review

Files analysed: 9

---

_{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 — 1228>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
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