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]](https://github.com/checkout/checkout-sdk-node/pull/465/files#diff-76578f44aeabef26fcd3c9e30dd28b350638ccfd14e2f8e027903d4543dc103bR81-R126) [[2]](https://github.com/checkout/checkout-sdk-node/pull/465/files#diff-76578f44aeabef26fcd3c9e30dd28b350638ccfd14e2f8e027903d4543dc103bR168-R172) [[3]](https://github.com/checkout/checkout-sdk-node/pull/465/files#diff-76578f44aeabef26fcd3c9e30dd28b350638ccfd14e2f8e027903d4543dc103bR208-R228) [[4]](https://github.com/checkout/checkout-sdk-node/pull/465/files#diff-85bd78abffa389dbea5f6766f8828567611980703de2f9612cff55e545639e5dR31-R48) [[5]](https://github.com/checkout/checkout-sdk-node/pull/465/files#diff-4a03b92adc23934e550253d4e4f0462248d9229860dd84b42cf71d576b563857R32-R49) [[6]](https://github.com/checkout/checkout-sdk-node/pull/465/files#diff-2b4d77715704a0b6567e52f52d77a970cb22da3119595db73cb218a99ef42aa1R35-R51) [[7]](https://github.com/checkout/checkout-sdk-node/pull/465/files#diff-2b4d77715704a0b6567e52f52d77a970cb22da3119595db73cb218a99ef42aa1R121-R127) [[8]](https://github.com/checkout/checkout-sdk-node/pull/465/files#diff-1805c66253fb18216ac51ceef961007303a3338e76e7e987860351d65ef40f7dR22-R44) [[9]](https://github.com/checkout/checkout-sdk-node/pull/465/files#diff-1805c66253fb18216ac51ceef961007303a3338e76e7e987860351d65ef40f7dR74-R85)

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]](https://github.com/checkout/checkout-sdk-node/pull/465/files#diff-ddab7c1168be8fa8283ceb4fda260cbec9c09656f8b53953f5d5e75796362dd2L467-R467) [[2]](https://github.com/checkout/checkout-sdk-node/pull/465/files#diff-ddab7c1168be8fa8283ceb4fda260cbec9c09656f8b53953f5d5e75796362dd2L484-R485) [[3]](https://github.com/checkout/checkout-sdk-node/pull/465/files#diff-ddab7c1168be8fa8283ceb4fda260cbec9c09656f8b53953f5d5e75796362dd2L516-R529) [[4]](https://github.com/checkout/checkout-sdk-node/pull/465/files#diff-ddab7c1168be8fa8283ceb4fda260cbec9c09656f8b53953f5d5e75796362dd2L655-R656) [[5]](https://github.com/checkout/checkout-sdk-node/pull/465/files#diff-ddab7c1168be8fa8283ceb4fda260cbec9c09656f8b53953f5d5e75796362dd2L672-R674) [[6]](https://github.com/checkout/checkout-sdk-node/pull/465/files#diff-ddab7c1168be8fa8283ceb4fda260cbec9c09656f8b53953f5d5e75796362dd2L704-R718)

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}

[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…}

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:.github/workflows/build-release.yml

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 2

---

_{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
security_sensitive_path — .github/workflows/build-release.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

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 bumps the version to 5.5.0, upgrades CI to Node 22/npm 11.21.0, and switches to OIDC-based trusted publishing on npm — plus documentation and test fixes described in the body. The CI and publishing changes are consequential and need a human to confirm the npm trusted publisher environment is already configured correctly before merging.

For you to decide

• The workflow now targets environment: production with OIDC (id-token: write) for npm trusted publishing — this only works if the npm package has a configured trusted publisher pointing to this repo/workflow/environment; if that setup is absent or mismatched, the publish step will fail silently or error.
• npm is pinned to 11.21.0 (npm install -g npm@11.21.0) — this is a very recent version and the rationale (trusted publishing needs >=11.5.1) is plausible, but the specific pin should be verified as intentional rather than arbitrarily high.
• actions/create-release@v1 is still used in the workflow; this action is unmaintained/archived and may produce warnings or failures independent of this PR's changes, which could block the release.
• The NODE_AUTH_TOKEN secret is removed and replaced by OIDC — a reviewer should confirm the secret is no longer needed and that no other workflow step depends on it.
• The diff does not show any of the documentation or test changes described at length in the PR body; the diff shown only covers build-release.yml and package.json, so the documentation/test claims cannot be verified from what is visible here.
• Node engine requirement in package.json remains >=18 while the CI now builds with Node 22 — this is fine for compatibility but worth confirming the SDK is actually tested on Node 18 somewhere if that's a supported target.

---

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