Release 6.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 structural improvements to the identity verification and face authentication modules. The main updates include adding support for pagination when listing verification attempts, introducing new fields and types for richer applicant data, and enabling retrieval of document/image assets for verification attempts. The changes also improve type annotations and documentation for better clarity and extensibility.

Pagination and Asset Retrieval Enhancements:

• Added support for optional pagination (skip and limit) when listing verification attempts in the get...Attempts methods for identity, ID document, address document, and face authentication clients, using the new AttemptsQueryFilter class. These methods now use the new query method in ApiClient to handle query parameters. [1] [2] [3] [4] [5] [6]
• Introduced new API methods to retrieve uploaded document/image assets for specific verification attempts in the ID document and address document verification clients, supporting optional pagination. [1] [2]

Applicant Data Model Improvements:

• Added new entity classes: PhoneNumber, IdvAddress, IdentityDeclaredData, and IdentityVerificationClientInformation to capture richer applicant details, including phone, email, address, document issuing country, and document type. [1] [2] [3] [4]
• Updated request objects for verification attempts to support the new applicant data fields and types, and improved property annotations for clarity and validation. [1] [2] [3]

Type and Documentation Improvements:

• Improved type annotations and documentation for fields in ClientInformation, DeclaredData, and related request/response objects, specifying formats, examples, and optionality for better developer experience and validation. [1] [2]

Dependency and Import Updates:

• Added necessary imports for new classes in client and request files to support the new features and types. [1] [2] [3] [4]

These updates make the API more flexible, extensible, and user-friendly, especially for clients needing to paginate results or capture additional applicant information.

⚠️ Breaking changes

Kind	Change
removed	$activation_date -> $scheduled_activation_date on CardRequest and UpdateCardRequest

Note: nothing else is breaking. The new getXAttempts($id, ?AttemptsQueryFilter $query = null) and updateCardDetails($cardId, $request, ?CardUpdateHeaders $headers = null) parameters default to null, and ApiClient::query() was widened to accept a nullable filter. Properties are untyped, so the IdentityDeclaredData and IdentityVerificationClientInformation subclasses are a docblock change only.

[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: 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
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: Looks good to me

This PR still needs a human approval — wall-e cannot auto-approve it. For what it's worth, I read the diff and found nothing I'd block on.

The visible diff bumps the version to 6.4.0 and fixes a test that was using GBP (rejected by the API's currency scope) to use USD; the substantive feature changes described in the PR body are not present in the provided diff. Based on what is shown, the changes are correct and internally consistent.

What I checked

• Version bump from 6.3.0 to 6.4.0 is consistent across both CheckoutUtils.php and version.json.
• The currency change in AccountsIntegrationTest.php from Currency::$GBP to Currency::$USD is explained clearly in the updated comment and fixes an API rejection (processing_details_currency_invalid_for_currency_scope), which looks like a legitimate bug fix.
• The diff provided is clearly partial — the PR description claims new entity classes, new client methods, pagination support, and a breaking rename of activation_date to scheduled_activation_date, none of which appear in the diff; the human reviewer should ensure they are reviewing the full changeset.

---

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

• no_low_class_matched
• prod_source_modified

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 3

---

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

[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