Release 4.4.0 - Add verification attempt-assets endpoints and card scheduled_activation_date

[david-ruiz-cko]

⚠️ Breaking changes (see at the bottom)

This release introduces several enhancements and documentation improvements to the identity verification, address document verification, and face authentication modules. The main focus is on adding detailed docstrings for data models, supporting pagination for attempt and asset listing endpoints, and expanding the data model to include additional applicant details.

Pagination and API Enhancements

• Added AttemptsQueryFilter and improved AttemptAssetsQueryFilter classes in checkout_sdk/identities/entities.py to support pagination for attempt and asset listing endpoints.
• Updated client methods in identityverification_client.py, iddocumentverification_client.py, addressdocumentverification_client.py, and faceauthentication_client.py to accept pagination filters and return paginated results for attempts and attempt assets. [1] [2] [3] [4] [5] [6]

Data Model and Documentation Improvements

• Added detailed docstrings and field-level documentation to all request and data classes in identityverification.py, iddocumentverification.py, addressdocumentverification.py, and faceauthentication.py, clarifying expected shapes, field requirements, and examples. [1] [2] [3] [4]
• Expanded the DeclaredData and related classes to include additional fields such as phone_number, email, and address for identity verification, and improved the structure for address and phone number data. [1] [2]

Code Imports and Structure

• Updated imports in client files to include the new pagination filter classes where required. [1] [2] [3] [4]
• Added missing __ASSETS_PATH constants to relevant client classes to support the new asset listing endpoints. [1] [2]

Minor Improvements

• Added missing import for Dict in checkout_sdk/issuing/cards.py.

These changes improve the SDK's usability, make the API contracts clearer, and provide more flexibility when listing and retrieving verification attempts and their assets.

⚠️ Breaking changes

Kind	Change
removed	activation_date -> scheduled_activation_date on CardRequest and UpdateCardRequest

Note: attributes are assigned dynamically, so setting the old name raises nothing and the field is silently dropped from the request. Worth calling out to integrators. Nothing else is breaking: the new query and headers parameters both default to None.

[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 4.3.0 to 4.4.0; none of the substantive changes described in the PR body are visible, so the reviewer must verify the full changeset manually before approving.

For you to decide

• The provided diff contains only the version increment in checkout_sdk/properties.py — all claimed changes to entities, clients, docstrings, and the breaking activation_date → scheduled_activation_date rename are not present in the diff shown.
• A human reviewer must confirm the breaking rename on CardRequest/UpdateCardRequest in checkout_sdk/issuing/cards.py is implemented and that tests cover the new field name.
• The PR description acknowledges the silent-drop footgun (old attribute name raises nothing but is silently dropped) — a reviewer should decide if this is acceptable or if a deprecation warning or explicit error is needed.

---

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