[armando-rodriguez-cko]

Summary
With the default fetch client every PATCH request failed with 400. The method was passed to fetch in lowercase, and fetch only normalises DELETE, GET, HEAD, OPTIONS, POST and PUT, so patch reached the API as-is. The axios client was not affected. Every verb is now sent in uppercase on both clients.

Changes

• src/services/http.js: httpRequest uppercases the method once before choosing the client; the OAuth token request uses POST
• test/http/httpMethod.js: new tests that read the method on a local HTTP server for GET, POST, PATCH, PUT and DELETE with both the fetch and axios clients (nock matches the method case-insensitively, so it could not catch this)

Verified against the sandbox with the default client: updating a customer returned 400 before the change and succeeds after it.

API Reference
Every PATCH operation the SDK exposes, for example:

• PATCH /customers/{identifier}: https://api-reference.checkout.com/tag/customers/PATCH/customers/%7Bidentifier%7D

Breaking changes
None.

README
No change needed.

[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:The change is a non-destructive, function-preserving bug fix that uppercases the HTTP method string within an existing code path, introduces no new endpoints, data, auth, or external integrations, and is strictly limited in scope.

Operational gates

• ✅ jira_ticket (INT-1745)
• ✅ 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.
2.2.6_logical_extension — The change is a non-destructive, function-preserving bug fix that uppercases the HTTP method string within an existing code path, introduces no new endpoints, data, auth, or external integrations, and is strictly limited in scope.	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

[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:The change is a pure bug fix that uppercases the HTTP method string in an existing code path, touching no auth logic, no data persistence, no new endpoints or integrations, and no external boundaries.

_{wall-e 2026.06.19-02 · policy 6b4ce2b3b45a…}