Skip to content

feat: require the subdomain option or an explicit useLegacyDomain opt-out - #448

Open
armando-rodriguez-cko wants to merge 6 commits into
masterfrom
feat/INT-1688-mandatory-subdomain
Open

feat: require the subdomain option or an explicit useLegacyDomain opt-out#448
armando-rodriguez-cko wants to merge 6 commits into
masterfrom
feat/INT-1688-mandatory-subdomain

Conversation

@armando-rodriguez-cko

@armando-rodriguez-cko armando-rodriguez-cko commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

Summary

Makes the merchant-specific subdomain (MSSD) mandatory. Initializing without a subdomain already emitted a deprecation warning, so this finishes the job: it now throws a ValueError. Callers must either set subdomain, or explicitly opt out with useLegacyDomain: true, which ships @deprecated in the type definitions. Both, or neither, throws.

Changes

  • src/auth-builder.js — new validateDomainOptions() replaces the two deprecation warnings; the EnvironmentSubdomain is only built once the options are known valid; new isPreviousPlatform()
  • src/config.js — new PREVIOUS_SECRET_KEY_REGEX
  • types/dist/Checkout.d.ts — documents subdomain as required and adds useLegacyDomain, marked @deprecated so editors and tsc flag it
  • test/config/config.js, test/environment-subdomain/environment-subdomain-integration.js — the cases that asserted invalid subdomains being silently dropped now assert the throw; added coverage for the legacy opt-out and for both-set
  • test/transfers, test/hosted-payments, test/payments-links — the clients there now pass the subdomain their own nock host already expected

Two exemptions

A custom host replaces the base URL outright, so the merchant has already said where requests go. Previous (ABC) keys predate merchant-specific subdomains.

Fixed along the way

The Previous exemption needed a new regex: MBC_LIVE_SECRET_KEY_REGEX only matches live keys, so sandbox Previous keys (sk_test_<uuid>) were not recognised as that platform.

Verification

884 tests passing, 0 failing, 79 pending. The one eslint error (prefer-const in src/api/balances/balances.js) is pre-existing on master and untouched here.

API Reference

Breaking changes

Yes, two. This needs a major release, classified and versioned when the release is cut.

  1. The merchant-specific subdomain is mandatory for the Default and DefaultOAuth platforms. Code that omitted it and relied on the implicit fallback to api.checkout.com / access.checkout.com now fails at client construction. Migration: set the subdomain, or use the legacy-domain opt-out as a temporary measure. The Previous (ABC) platform is unaffected.
  2. An invalid subdomain now fails instead of being silently ignored. Callers passing a malformed value keep working against the shared host today; after this change they fail fast. This one is easy to miss because it is not what the ticket asked for, so it needs its own line in the release notes.

README

Updated in this PR: a "Subdomain value" section above the Default example, the subdomain added to the configuration samples, and a "Legacy domain (emergency use only)" section at the bottom.

Notes

The suite routes every client it builds through a single helper that uses the shared hosts. Applying the merchant-specific subdomain there looked better, since it is the path merchants are being moved to, but the sandbox OAuth clients are not provisioned for it: .NET CI failed 224 integration tests with invalid_client when the token request went to {subdomain}.access.sandbox.checkout.com. Binding those OAuth clients to the subdomain is a platform task and should land before merchants are told the subdomain is mandatory.

Reference implementation: checkout-sdk-net#590. Tracked as INT-1688.

No version bump here: that happens on master when the release is cut, per the release workflow.

…-out

Initializing without a subdomain already emitted a deprecation warning, so this
finishes the job: it now throws a ValueError. Callers must either set
`subdomain`, or opt out explicitly with `useLegacyDomain: true`, which ships
deprecated in the type definitions. Both, or neither, throws.

An invalid subdomain also throws now instead of being silently dropped back to
the shared host, which is a second breaking change: a malformed value currently
works and the caller never finds out.

Two exemptions. A custom `host` replaces the base URL outright, so the merchant
has already said where requests go. Previous (ABC) keys predate merchant-specific
subdomains, matched by the new PREVIOUS_SECRET_KEY_REGEX, which covers both live
and sandbox key shapes (MBC_LIVE_SECRET_KEY_REGEX only matched live).

Mirrors checkout-sdk-net#590. Refs INT-1688.
@agent-wall-e

agent-wall-e Bot commented Aug 10, 2026

Copy link
Copy Markdown

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

  • exceeds_bounded_scope:827>200

Operational gates

  • ✅ jira_ticket (INT-1688)
  • ✅ independent_review

Files analysed: 11


wall-e 2026.06.19-02 · policy 376219bc71e6…

@agent-wall-e

agent-wall-e Bot commented Aug 10, 2026

Copy link
Copy Markdown
🔬 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
exceeds_bounded_scope827>200 classifying §2.1 M8 More than 200 non-test, non-doc, non-lockfile lines changed.

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

…is unset

CI failed at module load with "subdomain is required". Twenty-four test files
read the subdomain from CHECKOUT_MERCHANT_SUBDOMAIN, but no workflow exports it,
so the option arrived undefined. That used to be harmless, it just meant no
subdomain; now it throws.

They all spread domainOptions() instead, which uses the subdomain when the
variable is set and the legacy hosts otherwise. Exporting the variable in CI
would not be enough on its own: the sandbox OAuth clients are not provisioned for
the subdomain, so the token request would come back invalid_client.

This only reproduced in CI because the variable happens to be set locally.
@agent-wall-e

agent-wall-e Bot commented Aug 11, 2026

Copy link
Copy Markdown

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

  • exceeds_bounded_scope:827>200

Operational gates

  • ✅ jira_ticket (INT-1688)
  • ✅ independent_review

Files analysed: 36


wall-e 2026.06.19-02 · policy 376219bc71e6…

@agent-wall-e

agent-wall-e Bot commented Aug 11, 2026

Copy link
Copy Markdown
🔬 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
exceeds_bounded_scope827>200 classifying §2.1 M8 More than 200 non-test, non-doc, non-lockfile lines changed.

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

agent-wall-e Bot commented Aug 11, 2026

Copy link
Copy Markdown

🔵 Advisory review: Sound, but needs your judgement

This PR needs a human approval. The code itself reads as correct; whether it should land depends on context I don't have.

The PR correctly implements the stated breaking change — replacing deprecation warnings with thrown ValueErrors, requiring either subdomain or useLegacyDomain: true, with exemptions for custom host and Previous-platform keys. The logic reads as sound and tests are updated to match, but the decision to mass-swap all integration-test clients to useLegacyDomain: true (rather than waiting for the sandbox OAuth provisioning to be completed first) is a product/release-sequencing call a human should consciously own.

For you to decide

  • The isPreviousPlatform implementation is truncated in the diff — the body ends mid-function — so its correctness (including the new PREVIOUS_SECRET_KEY_REGEX that fixes sandbox Previous keys) cannot be fully verified here.
  • All integration test clients (20+ files) have been switched from subdomain: process.env.CHECKOUT_MERCHANT_SUBDOMAIN to useLegacyDomain: true with a comment explaining sandbox OAuth isn't provisioned for subdomain yet; this means the integration suite is now permanently opted into the deprecated path until the platform work lands, which a human should decide is acceptable.
  • In test/transfers/transfers.js and a few unit-level tests, subdomain: '123456789' is hardcoded as 9 characters — the README says the subdomain is always 8 characters; this should be checked against EnvironmentSubdomain.isValidSubdomain to confirm whether 9-char values are accepted by the regex or whether these tests would spuriously pass/fail.
  • The hosted-payments-it.js integration test uses useLegacyDomain: true but the comment mentions 'OAuth clients' — that file uses a static secret key (CHECKOUT_DEFAULT_SECRET_KEY), so the OAuth provisioning concern doesn't apply there; the actual reason for the opt-out in that specific file is unclear.
  • The type definition marks subdomain as optional (subdomain?: string) with a JSDoc comment saying it's required unless useLegacyDomain is set — the runtime enforces this but the TypeScript types do not, so tsc will not catch the missing-subdomain case at compile time.
  • README states ValueError is thrown but the error class name visible in the diff is imported from services/errors.js as ValueError — whether that class name surfaces meaningfully in error messages/stack traces for end users is worth confirming (minor but affects DX for a breaking change).

⚠️ 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

Flagged in review. A custom host is exempt from *requiring* a subdomain, since it
replaces the base URL outright, but a subdomain passed alongside one was neither
validated nor used: it was quietly dropped. Now the format check applies whenever
a subdomain is present, wherever the base URL comes from.
@agent-wall-e

agent-wall-e Bot commented Aug 11, 2026

Copy link
Copy Markdown

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

  • exceeds_bounded_scope:840>200

Operational gates

  • ✅ jira_ticket (INT-1688)
  • ✅ independent_review

Files analysed: 36


wall-e 2026.06.19-02 · policy 376219bc71e6…

@agent-wall-e

agent-wall-e Bot commented Aug 11, 2026

Copy link
Copy Markdown
🔬 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
exceeds_bounded_scope840>200 classifying §2.1 M8 More than 200 non-test, non-doc, non-lockfile lines changed.

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

The suite could only run against the shared hosts, so the subdomain path this PR
makes mandatory had no integration coverage. Reviewers flagged that on every SDK,
and it is the right thing to flag.

The domain helper now has two modes. Default is unchanged, the shared hosts,
because the sandbox OAuth clients are not provisioned for the subdomain and the
token request returns invalid_client. Set CHECKOUT_TEST_USE_SUBDOMAIN=true and the
suite runs against CHECKOUT_MERCHANT_SUBDOMAIN instead, so once sandbox is
provisioned like production it is a one-line change in the workflows, already
wired and documented, rather than a rewrite of every fixture.

The switch is deliberately separate from CHECKOUT_MERCHANT_SUBDOMAIN, which CI
already exports: provisioning should drive the behaviour, not the presence of a
secret.
@agent-wall-e

agent-wall-e Bot commented Aug 11, 2026

Copy link
Copy Markdown

🔴 Risk Classification: MAJOR

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

Classification reasons

  • security_sensitive_path:.github/workflows/build-master.yml
  • security_sensitive_path:.github/workflows/build-pull-request.yml
  • security_sensitive_path:.github/workflows/build-release.yml

Operational gates

  • ✅ jira_ticket (INT-1688)
  • ✅ independent_review

Files analysed: 39


wall-e 2026.06.19-02 · policy 376219bc71e6…

@agent-wall-e

agent-wall-e Bot commented Aug 11, 2026

Copy link
Copy Markdown
🔬 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.github/workflows/build-master.yml classifying §2.1 M4/M5 Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path.github/workflows/build-pull-request.yml classifying §2.1 M4/M5 Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path.github/workflows/build-release.yml 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

Versions are bumped on master during the release, not in a feature branch, per
the release workflow. This branch should carry only the change itself; the major
bump is classified and applied when the release is cut.
@agent-wall-e

agent-wall-e Bot commented Aug 12, 2026

Copy link
Copy Markdown

🔴 Risk Classification: MAJOR

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

Classification reasons

  • security_sensitive_path:.github/workflows/build-master.yml
  • security_sensitive_path:.github/workflows/build-pull-request.yml
  • security_sensitive_path:.github/workflows/build-release.yml

Operational gates

  • ✅ jira_ticket (INT-1688)
  • ✅ independent_review

Files analysed: 38


wall-e 2026.06.19-02 · policy 376219bc71e6…

@agent-wall-e

agent-wall-e Bot commented Aug 12, 2026

Copy link
Copy Markdown
🔬 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.github/workflows/build-master.yml classifying §2.1 M4/M5 Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path.github/workflows/build-pull-request.yml classifying §2.1 M4/M5 Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path.github/workflows/build-release.yml 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

Two problems with the previous approach. It needed a new variable in 21 workflow
files, which is not viable without access to create secrets. And it wrapped the
builder chain in a configureDomain helper that is not part of the public API, so
the tests stopped looking like the code a merchant would actually write.

Every fixture now calls the real opt-out inline, in the chain, with a comment
saying why: the sandbox OAuth clients are not provisioned for the merchant-specific
subdomain, so the token request comes back invalid_client. When sandbox is
provisioned, those calls become the subdomain setter.

The unit tests covering all four combinations are untouched: they already used the
public API directly.
@agent-wall-e

agent-wall-e Bot commented Aug 12, 2026

Copy link
Copy Markdown

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

  • exceeds_bounded_scope:840>200

Operational gates

  • ✅ jira_ticket (INT-1688)
  • ✅ independent_review

Files analysed: 34


wall-e 2026.06.19-02 · policy 376219bc71e6…

@agent-wall-e

agent-wall-e Bot commented Aug 12, 2026

Copy link
Copy Markdown
🔬 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
exceeds_bounded_scope840>200 classifying §2.1 M8 More than 200 non-test, non-doc, non-lockfile lines changed.

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

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant