fix: add merchant_id to the Google Pay enrollment response

[armando-rodriguez-cko]

What

Adds merchant_id to the Google Pay enrollment response.

Reported internally on behalf of a merchant. merchant_id is what the caller needs to initialise Google Pay on the client, so without it the enrollment response is not usable for its purpose.

The root cause is the spec, not this SDK

GooglePayEnrollmentResponse in the spec declares only tosAcceptedTime and state, both required, omits merchant_id, and sets additionalProperties: false.

The real 201 from POST /googlepay/enrollments returns:

{
  "merchant_id": "12345678901234567890",
  "tos_accepted_time": "2026-08-13T09:12:41Z",
  "state": "ACTIVE"
}

The model was generated faithfully from a wrong schema. The spec fix is being raised separately and is the actual fix: until it lands, the next regeneration reintroduces this.

Tests

They deserialize the real sandbox body, not the swagger example, because the swagger example is the thing that was wrong. One test asserts merchant_id survives on its own, since losing it is the entire defect, and another asserts an absent merchant_id comes back null rather than blank, so a caller can tell "not returned" from "returned empty".

Not breaking

Purely additive on a response model.

Refs INT-1690.

Note on the timestamp

tosAcceptedTime already worked here: GsonSerializer applies FieldNamingPolicy.LOWER_CASE_WITH_UNDERSCORES, so the field matches tos_accepted_time on the wire without a @SerializedName. Only the missing field needed fixing.

Four new tests, the whole Google Pay serialization suite green.

[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:This is a purely additive change to an existing response model class, adding a single missing field to deserialize data already returned by the existing API endpoint, with no new endpoints, persistence, auth changes, or external integrations.

Operational gates

• ✅ jira_ticket (INT-1690)
• ✅ 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.
2.2.6_logical_extension — This is a purely additive change to an existing response model class, adding a single missing field to deserialize data already returned by the existing API endpoint, with no new endpoints, persistence, 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}

[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

[armando-rodriguez-cko]

Update: the spec fix is merged, so this SDK change is now aligned with the spec rather than ahead of it.

cko-web/checkout-api-reference#2084, merged 2026-08-18, changes GooglePayEnrollmentResponse to:

• add merchant_id (string, optional)
• rename tosAcceptedTime to tos_accepted_time, including in required

That matches this PR exactly, and it removes the regeneration risk noted above: the schema no longer reintroduces the problem.

One caveat for whoever reviews this: the fix is merged in the spec repo but not yet published to the live spec at api-reference.checkout.com, which still serves the old tosAcceptedTime shape. The live API has always returned merchant_id and tos_accepted_time, so this PR is correct either way, but a schema diff run before publication will still show the old names.

[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:This is a purely additive field addition to an existing response model class, reusing existing serialization infrastructure, with no new endpoints, auth changes, persisted data, or external integrations.

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