Release 2.6.0 - Representative documents alignment

[david-ruiz-cko]

This release makes significant improvements to the checkout_sdk Accounts module, focusing on enhancing documentation, clarifying API usage, and adding support for new document types. The changes improve code maintainability and make the SDK easier to use and understand, especially regarding file uploads and document handling for onboarding and verification.

Documentation and API Clarity Improvements:

• Added detailed YARD documentation to many models (e.g., Company, ContactDetails, Document, BankVerification), specifying required fields, formats, and variant-specific requirements. This makes the SDK much easier to use and reduces ambiguity for integrators. [1] [2] [3] [4] [5] [6] [7] [8]
• Deprecated several fields and classes that are not part of the Accounts API schemas, and clearly marked them as such in the documentation (e.g., AdditionalInfo, EntityDocument, Company#document, EntityFinancialDetails#documents). [1] [2] [3] [4]

File Upload and Document Handling Enhancements:

• Improved file upload methods in AccountsClient, clarifying parameters, return values, and the multipart nature of requests for both general and entity-scoped file uploads. [1] [2] [3]
• Added new document types and models for certified authorised signatory, proof of residential address, and proof of registration, with corresponding enums and documentation. [1] [2] [3]

Model and Enum Additions:

• Introduced new models and enums for document types, including CertifiedAuthorisedSignatory, CertifiedAuthorisedSignatoryType, ProofOfResidentialAddress, ProofOfResidentialAddressType, ProofOfRegistration, ProofOfRegistrationType, RepresentativeDocuments, and FilePurpose. [1] [2] [3]

General Improvements:

• Improved consistency and accuracy of model attribute documentation, including regular expressions for file IDs and clearer type annotations. [1] [2] [3]

These changes collectively make the Accounts SDK more robust, self-explanatory, and easier to integrate with the Checkout.com onboarding API.

[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 provided diff only shows a version bump from 2.5.0 to 2.6.0, but the PR description claims substantial changes to models, enums, documentation, and the AccountsClient — none of which are visible in the diff. A human reviewer must verify the actual substance of the change.

For you to decide

• Only the version file is present in the diff; all referenced changes to AccountsClient, new document models (CertifiedAuthorisedSignatory, ProofOfResidentialAddress, etc.), and deprecation annotations are not visible and cannot be reviewed.
• The reviewer should confirm that all new models, enums, and deprecations described in the PR body are actually present and correct in the full changeset before approving.
• The reviewer should verify that deprecated fields/classes (AdditionalInfo, EntityDocument, Company#document, EntityFinancialDetails#documents) are handled safely and existing integrators are not silently broken.
• The reviewer should confirm that any new file upload or multipart request handling in AccountsClient does not introduce unhandled error paths or behavioral regressions.

---

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