Release 5.3.0 - Address Document Verification endpoints + ChallengeIndicator/SessionChallengeIndicator alignment

[david-ruiz-cko]

This release introduces several improvements and clarifications to the 3DS challenge indicator and related enums used in session and payment APIs. The main focus is on separating the values specific to session requests from those used in payment flows, improving documentation, and ensuring backwards compatibility. Additionally, related enums are updated for clarity and consistency, and comprehensive tests are added to verify correct serialization and deprecation handling.

Key changes:

3DS Challenge Indicator Improvements

• Introduced a new SessionChallengeIndicatorType class with clear documentation and nine explicit values, including exemption values, for use only with session requests (POST /sessions). This separates session-specific values from those used in payments.
• Updated ChallengeIndicatorType in Checkout\Common to clarify that five exemption values are deprecated and only accepted by sessions, not by payments or hosted payments. Documentation is improved and deprecation tags are added for these values.
• Updated SessionRequest to use SessionChallengeIndicatorType for the challenge_indicator property, with improved docblocks and default value assignment. [1] [2] [3]

Related Enum and Property Updates

• Updated Category, SessionScheme, and TransactionType enums with improved documentation, consistent naming, and added or corrected values (e.g., non_payment, quasi_card_transaction, new schemes like discover and upi). [1] [2] [3]

Test Improvements

• Added a comprehensive test class, ChallengeIndicatorSerializationTest, to verify that all challenge indicator values are exposed, correctly serialized, and properly marked as deprecated where appropriate.
• Updated integration tests to use the new SessionChallengeIndicatorType for session requests. [1] [2] [3] [4] [5]

These changes clarify the intended usage of challenge indicator values, improve maintainability, and ensure that the SDK aligns with API expectations and best practices.

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

[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