fix(issuing): map mid_limit and complete card control and card create responses

[armando-rodriguez-cko]

Summary
Fixes and completes the issuing card control and card create responses against the API reference. mid_limit was never read (the property was mapped to velocity_limit), card create responses carrying controls failed to deserialize, and several properties were missing.

Changes

• MidCardControlResponse: adds MidLimit mapped to mid_limit
• VelocityLimit: adds AmountRemaining (long?), null on requests and never sent
• Control response classes and VelocityLimit, MccLimit, MidLimit, VelocityWindow: doc comments completed
• ControlsSerializationTest (new): each subtype from the API reference example, roundtrip, list response, _links on create, deprecated alias, amount_remaining absent on requests

Also fixed while here

• AbstractCardControlResponse now extends Resource, like the rest of the SDK's responses, so the create control response exposes _links
• CardControlsResponseConverter read the subtype from type, but card create controls carry control_type; any card create response with controls threw NotImplementedException. It now reads control_type and falls back to type
• MidCardControlsResponse (card create controls): adds MidLimit mapped to mid_limit, same bug as above
• AbstractCardCreateResponse: adds Scheme; doc comments on the card create response classes and Credentials rewritten with the API reference constraints
• CardCreateResponseSerializationTest (new): virtual and physical card create examples, full roundtrips, controls with all three types

Deprecated

• MidCardControlResponse.VelocityLimit and MidCardControlsResponse.VelocityLimit: use MidLimit. They now forward to MidLimit, so existing callers start getting the value
• AbstractCardControlsResponse.TargetId, CreatedDate, LastModifiedDate: not returned by the API in the card create response
  All of them will be removed in the next major version.

API Reference

• PUT /issuing/controls/{controlId}, GET /issuing/controls/{controlId}, GET /issuing/controls, POST /issuing/controls
• POST /issuing/cards (add-card-response, add-virtual-card-response, add-physical-card-response)

Breaking changes
None. Deprecated members keep working until the next major version.

README
No change needed.

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:src/CheckoutSdk/Issuing/Cards/Responses/Create/Credentials.cs

Operational gates

• ✅ jira_ticket (INT-1704)
• ✅ independent_review

Files analysed: 19

---

_{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
security_sensitive_path — src/CheckoutSdk/Issuing/Cards/Responses/Create/Credentials.cs	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

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.

This PR fixes the mid_limit mapping bug in both control response hierarchies, adds amount_remaining to VelocityLimit, fixes the CardControlsResponseConverter discriminator to read control_type first, promotes AbstractCardControlResponse to extend Resource, and adds Scheme to AbstractCardCreateResponse — all with new roundtrip serialization tests covering each subtype. The changes are internally consistent and match the stated intent.

What I checked

• The deprecated VelocityLimit properties on MidCardControlResponse and MidCardControlsResponse correctly forward to MidLimit via getter/setter and are marked [JsonIgnore], so existing callers get the correct value and serialization emits mid_limit only once.
• CardControlsResponseConverter now reads control_type first and falls back to type, which is the correct fix for the NotImplementedException on card create responses with controls.
• VelocityLimit.AmountRemaining is a nullable long with no [JsonProperty] attributes visible in the diff; the test ShouldNotSendAmountRemainingOnVelocityCardControlUpdate implicitly verifies null values are not serialized, which depends on the SDK's global NullValueHandling setting — this is consistent with how other optional nullable fields work in the SDK.
• AbstractCardControlResponse now extends Resource instead of HttpMetadata; this is a behavioral change (Links property added) but is non-breaking since Resource extends HttpMetadata.
• The test file is truncated in the diff but the visible portions cover all three control subtypes and both card create response types with full roundtrips, which is appropriate coverage for the changes made.

⚠️ The diff was too large to read in full, so this review covers only part of the change.

---

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

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:src/CheckoutSdk/Issuing/Cards/Responses/Create/Credentials.cs

Operational gates

• ✅ jira_ticket (INT-1704)
• ✅ independent_review

Files analysed: 19

---

_{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
security_sensitive_path — src/CheckoutSdk/Issuing/Cards/Responses/Create/Credentials.cs	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

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 failed

Failed conditions
B Maintainability Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE