External capability activation

Purpose and boundary

This runbook governs the capabilities that are intentionally built as provider-neutral, disabled preparation. It is not an activation request, provider configuration guide, or authorization to transmit production payment data. Until a deferred capability clears every gate below, its public and internal entry points must return the documented unavailable-capability result and must not call an external client. ACH direct-processing eligibility is described in its own section below; the ACH_TENDER record is administrative/audit metadata, not a runtime gate.

The following deferred capabilities remain disabled by default:

Capability	Disabled product behavior	Activation authority
3DS / SCA	Keep the platform THREE_DS gate disabled by default and evidence-gated; reject wallet requests with explicit 3DS fields before provider dispatch. No dedicated challenge/provider session is created.	Separate approved activation change
ACH / eCheck	Direct processing remains subject to the credential-profile, ACH-route, provider-credential, and adapter achSale prerequisites; hosted-checkout ACH remains unavailable until its dedicated flow exists.	Administrative/audit record plus separate provider and rollout approval; this row is not a runtime kill switch.
Account updater	Keep neutral update records and fixtures only; do not enroll or fetch a live updater file/feed.	Separate approved activation change
Network token lifecycle	Keep neutral lifecycle state and fixtures only; do not request, provision, or decrypt a network token.	Separate approved activation change
Pre-dispute alerts	Accept no live partner webhook or submission; fixtures may populate reconciliation queues.	Separate approved activation change
Agentic checkout	Reject agentic confirmation as unavailable; do not mint a mandate, accept a cryptogram, or call an AP2/ACP/network partner.	Separate approved activation change

A product-build pull request may add models, authorization, state machines, read surfaces, fakes, and disabled-path tests. It must not set an enabled configuration, add a live endpoint, register a provider credential, claim certification, or make any outbound production call.

Required activation record

Create one access-controlled activation record per capability and production provider/sponsor combination. The repository and normal issue comments contain only the redacted evidence reference; they must never contain PAN, bank account numbers, cryptograms, provider credentials, signed payloads, webhook secrets, or raw provider responses.

The approval record is complete only when all fields below have concrete, reviewed values:

Field	Required evidence
Capability and scope	Exact capability, card brands/rails, merchant population, countries, and transaction types.
Provider or sponsor	Approved provider name and, where applicable, sponsor bank, ODFI/acquirer, scheme, or alert partner.
Commercial owner	Named accountable Gateway owner and executed commercial/onboarding status.
Environment	Separate non-production and production account identifiers, endpoint allowlists, and access-owner confirmation. No credential value is recorded here.
Contract or certification artifact	Executed agreement plus the applicable network, scheme, sponsor, processor, or certification approval reference and expiration/renewal date.
Test-data handling	Approved synthetic/sandbox data source, retention period, redaction procedure, and deletion owner. Live payment data is not test data.
Production kill switch	Server-owned default-off capability control, its owner, test of immediate disablement, and the request path that returns unavailable after disablement.
Evidence location	Access-controlled evidence URI and immutable release/change reference. The URI must not expose secrets through public links.
Rollback	Named operator, disablement procedure, expected customer/API response, reconciliation handling for in-flight work, and incident communication path.

No reviewer may infer a missing field from a chat message, vendor dashboard, or source-code stub. A missing or expired item blocks activation.

Capability-specific prerequisites

The shared record is necessary but not sufficient. Each capability also needs its listed prerequisites before its production control can move from disabled to enabled.

3DS / SCA

• Explicit 3DS wallet data is recognized when any of eciIndicator, secureCode, securityProtocol, ucafCollectionIndicator, or directoryServerTransactionID is present. These fields already travel through wallet DTO/command mappings at the processor boundary.
• Before provider dispatch, the processing boundary requires the platform THREE_DS capability and selected adapter support (threeDs=true). While THREE_DS is disabled, explicit-field wallet sale/auth requests return the unavailable result without a provider call.
• TransIT is currently the only adapter declaring threeDs=true because its existing mapping carries these fields. CardPointe and other uncertified adapters remain threeDs=false pending provider wire and certification evidence.
• A future change that adds a dedicated challenge/provider-session lifecycle must separately document its MPI/3DS-server, directory-server/ACS, connectivity, certification, and in-flight rollback requirements. This change adds no such lifecycle.

ACH / eCheck

• Approved sponsor/ODFI and ACH processor, merchant underwriting/onboarding, supported SEC codes, and commercial owner.
• Sandbox and production bank-rail environments are independently approved; no production routing identifier or account data appears in source, fixtures, logs, or evidence packages.
• Required NACHA, sponsor, processor, return/correction, dispute, and funds availability obligations are reviewed and recorded.
• Test data uses only approved sandbox or synthetic bank instruments; the evidence package records redaction and retention/deletion confirmation.
• Runtime eligibility is enforced by the active/rotating credential profile, location ACH route, resolved provider credentials, and selected adapter's achSale capability. ACH_TENDER remains administrative/audit metadata and does not reject an otherwise eligible direct-processing request. The explicit certification-runner ACH opt-in remains available to prevent accidental traffic; any rollout still requires provider and operational approval.

Account updater

• Approved network/processor updater enrollment, supported brands/regions, merchant consent model, and commercial owner.
• A non-production updater feed/interface and separate production enrollment have passed contract validation using synthetic fixtures.
• Scheme/processor enrollment approval and file/feed handling requirements are recorded, including provenance and retention controls for update results.
• The kill switch disables feed retrieval and application while retaining the append-only neutral result history. Rollback records how any applied update is traced, corrected, and communicated without reprocessing the feed.

Network token lifecycle

• Approved card-scheme/token-service-provider participation, acquirer/processor support, supported devices/regions, and commercial owner.
• Sandbox and production token-service environments are separately approved; token references, keys, and cryptograms remain outside outward DTOs, audit data, exports, and this runbook.
• Scheme, acquirer, processor, device-wallet, and cryptogram/lifecycle certification requirements are complete for each enabled lifecycle action.
• The kill switch blocks provisioning, lifecycle requests, and cryptogram use before any network call. Rollback revokes the capability, preserves neutral history, and specifies reconciliation for in-flight lifecycle events.

Pre-dispute alerts

• Approved alert/dispute partner or aggregator, participating brands/programs, merchant enrollment, and commercial owner.
• Non-production fixtures and production webhook/submission environments have distinct authentication and ingress/egress controls.
• Partner onboarding, program rules, response-time SLA, evidence-submission requirements, and data-processing obligations are approved.
• Fixtures and exported evidence are redacted and retention-bounded; raw provider payloads and payment data are not copied into issue comments, audit records, or reports.
• The kill switch rejects or quarantines live delivery before a provider call. Rollback records ownership of pending alerts, deadlines, reconciliation, and merchant communication.

Agentic checkout

• Approved AP2/ACP, delegated-mandate, and any network-agentic-token partner scope, merchant/category policy, and commercial owner.
• Separate non-production and production partner environments, attestation verification, key custody, and approved caller identities are recorded.
• Applicable partner, card-network, delegated-mandate, cryptogram, and merchant-policy approvals are complete for each enabled order flow.
• Synthetic mandates and test cryptograms are handled under the approved test-data procedure; mandate, token, and cryptogram material remain absent from client DTOs, audit data, exports, and evidence summaries.
• The kill switch rejects confirm_payment before mandate synthesis, cryptogram success, or partner invocation. Rollback includes revocation, treatment of pending orders, and reconciliation ownership.

Evidence and approval sequence

1. Build gate: Verify the capability remains disabled in all environments. The disabled-path test must assert the explicit unavailable result and no interactions with the corresponding external client.
2. Readiness review: Complete the shared activation record and the capability-specific prerequisites. Attach only redacted evidence references to the tracking issue.
3. Non-production validation: Run the approved sandbox/certification plan with synthetic data and preserve a redacted evidence package in the private evidence location.
4. Production approval: Obtain change approval from the commercial owner, security, operations, and the responsible payment/certification owner. Record the release reference, the exact population, monitoring, and a tested kill switch.
5. Controlled rollout: Enable only the approved population. Confirm health, reconciliation, outbound-call metrics, and unavailable behavior after exercising the kill switch.
6. Rollback readiness: Keep the kill switch owner and rollback procedure available for the entire rollout. Any unmet prerequisite or unexpected provider behavior requires disablement rather than fallback simulation.

Validation contract

ACH retains its production external-client boundary. Its disabled-path regression must return the explicit unavailable-capability result before route resolution, adapter construction, provider-specific validation, or payment attempt creation, and it must verify no router, adapter factory, payment adapter, or attempt repository interaction.

Explicit-field 3DS wallet requests have a separate pre-dispatch capability boundary. A request carrying any explicit 3DS field (eciIndicator, secureCode, securityProtocol, ucafCollectionIndicator, or directoryServerTransactionID) requires platform THREE_DS and selected adapter threeDs=true before provider dispatch. While THREE_DS is disabled, the request returns the unavailable result and makes no provider call; requests without explicit 3DS fields, including cryptogram-only requests, keep their existing behavior.

This change adds no dedicated challenge/provider-session lifecycle. A future lifecycle change must add an end-to-end disabled-path regression at that concrete boundary and carry its own provider/session evidence.

A passing happy-path fake is not activation evidence. Production activation is allowed only through a separate approved change after the applicable real boundary regression and activation record are satisfied.