Release 8.6.0 - Representative documents alignment

[david-ruiz-cko]

This release significantly improves the documentation and clarity of the Accounts API SDK by adding detailed JavaDoc comments to many classes, enums, and fields. It also introduces new document types and classes to support additional onboarding and verification requirements. The changes enhance maintainability and make the codebase much easier to understand for developers integrating with the API.

The most important changes are:

Documentation and Clarity Improvements:

• Added comprehensive JavaDoc comments to most classes, enums, and fields in the com.checkout.accounts package, explaining their purpose, usage, and field requirements. This includes details on required fields, expected formats, and API variant differences. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

API Surface and Document Type Expansions:

• Added new document types and enums to support additional onboarding requirements, such as CertifiedAuthorisedSignatory, CertifiedAuthorisedSignatoryType, and new values in AccountsFilePurpose (e.g., ADDITIONAL_DOCUMENT, ARTICLES_OF_ASSOCIATION, etc.). [1] [2] [3]
• Enhanced enums with JavaDoc comments to clarify their purpose and usage, including distinctions between similar document types (e.g., FinancialStatementsType vs. FinancialVerificationType). [1] [2] [3] [4] [5]

API Method Documentation:

• Added detailed JavaDoc comments to the AccountsClient interface methods (both async and sync), describing the purpose, parameters, and return values for file upload and retrieval operations. [1] [2]

Field and Requirement Clarifications:

• Clarified field requirements, formats, and validation rules (e.g., regex for file IDs, phone numbers, and national ID numbers) in class-level and field-level documentation. [1] [2] [3] [4] [5]

Deprecation Notices:

• Added deprecation notice to the document field in Identification, indicating it is not read by the API and will be removed in a future major version.

[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 only shows a version bump from 8.5.0 to 8.6.0, but the PR description claims significant additions of new classes, enums, JavaDoc, and API surface changes — none of which are visible in the provided diff.

For you to decide

• The diff is partial or incomplete: all substantive changes described (new CertifiedAuthorisedSignatory class, new AccountsFilePurpose enum values, JavaDoc additions, deprecation of Identification.document field) are absent from the diff, so their correctness cannot be verified.
• A human reviewer must confirm that all the claimed source changes are actually present in the full PR and have been reviewed, since the version bump alone is insufficient evidence that the release is correct.
• The version increment from 8.5.0 to 8.6.0 follows semver minor conventions, which is appropriate if the changes are purely additive (new classes, new enum values, JavaDoc, deprecations without removal) — but this must be confirmed against the actual changes.
• The deprecation of Identification.document described in the PR body should be verified to not be a breaking change for existing callers before the reviewer approves.

---

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