feature/INT-1699 - Date serialization issues, APIShortDate solution with format yyyy-MM-dd

[david-ruiz-cko]

This pull request improves the handling and serialization of date and datetime fields in the SDK, ensuring that fields specified as format: date (yyyy-MM-dd) are correctly annotated as str and serialized as date-only strings, rather than full timestamps. It also updates the JsonSerializer to properly distinguish between date and datetime objects, preventing serialization errors and ensuring compliance with API specifications. Comprehensive tests are added to verify correct serialization behavior and type annotations.

Serializer improvements:

• Updated JsonSerializer in checkout_sdk/json_serializer.py to distinguish between date and datetime objects, ensuring that date fields serialize as yyyy-MM-dd strings and not as full timestamps. This also fixes a previous bug where serializing a date could raise a TypeError. [1] [2] [3]

SDK model annotation updates:

• Changed type annotations for all SDK model fields representing format: date (e.g., issue_date, date_of_birth, departure_date, registration_date, etc.) from datetime to str, with inline comments specifying the expected format. This ensures correct serialization and API compatibility. [1] [2] [3] [4] [5] [6] [7]

Test coverage:

• Added comprehensive unit tests in tests/json_serializer_test.py to verify correct serialization of date, datetime, and subclasses, as well as nested and list scenarios. These tests ensure that only date fields are serialized as yyyy-MM-dd, and that the serializer's object reflection and key transformation logic remain unaffected.
• Added tests in tests/payments/contexts/payment_contexts_serialization_test.py and tests/payments/setups/payment_setups_serialization_test.py to confirm that relevant fields are annotated as str, serialize correctly, and do not include unset date fields in the output. Tests also document the behavior when a datetime is mistakenly assigned to a date-only field. [1] [2] [3]

[agent-wall-e]

🟢 Risk Classification: LOW

Approval route: AI Auto-Approval
Rollback controls: Automated Instant Rollback + feature flags

Classification reasons

• no_low_class_matched
• prod_source_modified
• 2.2.6_logical_extension:All changes are non-destructive type annotation updates and a serializer bug fix that reuse existing code paths, introduce no new endpoints, auth, persisted data, or external integrations, and are a natural extension of the existing serialization abstraction.

Operational gates

• ✅ jira_ticket (INT-1699)
• ✅ independent_review

Files analysed: 6

---

_{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.
2.2.6_logical_extension — All changes are non-destructive type annotation updates and a serializer bug fix that reuse existing code paths, introduce no new endpoints, auth, persisted data, or external integrations, and are a natural extension of the existing serialization abstraction.	classifying	§2.2.6	Sonnet 4.6 evaluator promoted minor → low: the change reuses existing code paths and does not cross a trust boundary.

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]

✅ Auto-approved — this PR meets all Low-risk criteria.

All checks passed, no unresolved comments, and the change classification is:

• no_low_class_matched
• prod_source_modified
• 2.2.6_logical_extension:All changes are non-destructive type annotation updates from datetime to str for date-only fields and a serializer bug fix within the existing JsonSerializer class, reusing existing code paths without adding new endpoints, external integrations, persisted data, or auth changes.

_{wall-e 2026.06.19-02 · policy 376219bc71e6…}

[agent-wall-e]

🟢 Risk Classification: LOW

Approval route: AI Auto-Approval
Rollback controls: Automated Instant Rollback + feature flags

Classification reasons

• no_low_class_matched
• prod_source_modified
• 2.2.6_logical_extension:All changes are non-destructive type annotation corrections (datetime→str) on existing model fields and a serializer bug-fix that improves existing date handling without adding new endpoints, persisted data, auth changes, or external integrations.

Operational gates

• ✅ jira_ticket (INT-1699)
• ✅ independent_review

Files analysed: 6

---

_{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.
2.2.6_logical_extension — All changes are non-destructive type annotation corrections (datetime→str) on existing model fields and a serializer bug-fix that improves existing date handling without adding new endpoints, persisted data, auth changes, or external integrations.	classifying	§2.2.6	Sonnet 4.6 evaluator promoted minor → low: the change reuses existing code paths and does not cross a trust boundary.

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]

🟢 Risk Classification: LOW

Approval route: AI Auto-Approval
Rollback controls: Automated Instant Rollback + feature flags

Classification reasons

• no_low_class_matched
• prod_source_modified
• 2.2.6_logical_extension:All changes are non-destructive refactors of existing serializer logic and type annotations within existing models, reusing existing code paths without new endpoints, external integrations, persisted data, auth changes, or background processes.

Operational gates

• ✅ jira_ticket (INT-1699)
• ✅ independent_review

Files analysed: 6

---

_{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.
2.2.6_logical_extension — All changes are non-destructive refactors of existing serializer logic and type annotations within existing models, reusing existing code paths without new endpoints, external integrations, persisted data, auth changes, or background processes.	classifying	§2.2.6	Sonnet 4.6 evaluator promoted minor → low: the change reuses existing code paths and does not cross a trust boundary.

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