identity-canon/research/commercial-identity/payment-credential-pci-boundary.md

Payment Credential Boundary — PCI and Commercial Commitment

Source Type

Standards and product synthesis. PCI DSS tokenization guidance, Stripe Payment Methods / SetupIntents, and identity-canon Credential vs. Commercial Commitment separation.

Domain

Payment instruments on billing customers — what belongs in canonical identity model vs. PCI-scoped downstream vaults, and how charge authorization relates to Commercial Commitment.

Why This Source Matters

Stripe Customer objects carry payment methods, and canon Credential already covers secrets and proof material. Collapsing them causes two failures:

1. PCI scope bleed — modeling PAN, CVV, or vault secrets in identity canon implies they belong in general identity stores.
2. Semantic collision — login passkeys and payment mandates both "authorize something" but authorize authentication vs. commercial debit.

Payment methods are commercially binding (tier 3 assurance) when they encode mandate to charge — but the binding artifact is the authorization/commitment, not the token reference.

Key Concepts

PCI DSS data categories

• CHD (cardholder data): PAN, cardholder name, expiration, service code.
• Sensitive authentication data (SAD): CVV/CVC, full track data, PIN — never stored after authorization per PCI.
• Token: surrogate value replacing PAN; if properly implemented, token in merchant environment is out of PCI CHD scope (PCI tokenization guidelines).
• Scope principle: systems that store, process, or transmit CHD fall under PCI; token references (pm_xxx) in app DBs are not CHD when only the token exists.

Stripe payment object model

• PaymentMethod (pm_xxx): reusable payment details attached to Customer; contains type-specific non-transaction data (last4, fingerprint, billing details).
• SetupIntent: establishes future off-session payment — creates mandate to charge.
• PaymentIntent: one-time or reusable charge attempt.
• Customer: billing container; payment methods attach here, not to login User.
• Mandates (SEPA, Bacs, etc.): explicit customer authorization for debits.

Authentication vs. payment authorization

Dimension	Authentication credential	Payment authorization
Proves	Identity / session control	Right to debit funds
Scope	IdP, app login, federation	Payment network / acquirer
Regulation	NIST 800-63, OIDC	PCI DSS, PSD2 SCA, Nacha
Canon home	Credential	Payment Mandate (Commercial Commitment)
Secret handling	Passkey, password hash	CHD in vault only; token ref in app

Modeling Assumptions

• Canon is implementation-neutral but must not encourage CHD in identity layers.
• Payment provider owns payment truth; app holds references and commitment state.
• Reusable payment method implies Commercial Commitment (payment mandate) when customer consented to future charges (SetupIntent succeeded, card on file).
• Single-use payment methods may exist only for one PaymentIntent — weaker commitment, often no reusable mandate.
• Subscription is separate Commercial Commitment (recurring service obligation); payment mandate is enabling commitment for collection.
• Webhook events (setup_intent.succeeded, payment_method.attached) are Evidence Source for mandate lifecycle.

Identity-Canon Implications

Resolved: do not map payment methods to Credential

Credential in canon covers authentication, federation, and entitlement proof (passkey, password, certificate, VC). Payment methods are not Credentials.

Raw CHD and SAD are out of canon entirely — downstream PCI vault / payment provider only.

Payment Instrument Reference

Add Payment Instrument Reference — Reference layer value scoped to a payment provider (Stripe pm_xxx, fingerprint, display last4, mandate ID). Links to Commercial Record, not to login Account.

Properties:

• provider_scope — Stripe account, Adyen merchant, etc.
• instrument_type — card, sepa_debit, us_bank_account, etc.
• reference_id — provider token (not PAN).
• reusable — boolean.
• lifecycle_state — attached, detached, expired, revoked.

This is a Scoped Identifier specialization, not a Credential.

Payment Mandate as Commercial Commitment

When a customer authorizes future charges (SetupIntent success, SEPA mandate signed, card saved with explicit consent), model Payment Mandate as a Commercial Commitment subtype:

• commitment_type: payment_mandate
• lifecycle_state: proposed → active → revoked → expired
• Parties: customer actor (via Commercial Record) and vendor/payment facilitator
• Evidence Source: SetupIntent result, mandate document, SCA proof metadata
• assurance_tier: committed on Counterparty Assurance Gradient

Subscription remains commitment_type: subscription — distinct but often co-created at checkout.

Commercial Record role

Commercial Record (Stripe Customer) references payment instrument refs and hosts links to Payment Mandate commitments. Do not embed CHD attributes in Commercial Record canon fields — only provider references and lifecycle flags (delinquent, default payment method ref).

Layer diagram

Login Account          → Credential (passkey, password)
Commercial Record      → Payment Instrument Reference (pm_xxx)
Commercial Commitment  → Payment Mandate + Subscription
PCI Vault / Stripe     → CHD (downstream only, not canon)
Evidence Source        → webhooks, mandate PDF, SCA audit

Terminology Conflicts

• Payment method (Stripe) vs. Credential (canon): both grant "permission" but different permission domains.
• Payment credential (informal) vs. Credential (glossary): avoid informal phrase in canonical definitions; use Payment Instrument Reference + Payment Mandate.
• Saved card vs. payment mandate: saved token may exist before explicit off-session mandate — lifecycle proposed until SetupIntent completes.
• customer_account (Stripe) vs. Account (login): reinforces commercial split.

Candidate Canonical Mappings

Source artifact	Canonical mapping
PAN / CVV	Out of canon (PCI downstream)
PaymentMethod pm_xxx	Payment Instrument Reference
SetupIntent succeeded	Payment Mandate Commercial Commitment + Evidence
Subscription object	Commercial Commitment (subscription)
Default payment method	Reference on Commercial Record
Payment webhook	Evidence Source
3DS / SCA step-up	Evidence Source on mandate (not Credential)
Passkey for login	Credential (unchanged)

Open Questions

(none — settled in commercial-identity-nuance-settlement.md)

Settled

• Network tokens → Payment Instrument Reference instrument_type: network_token.
• Shared methods → multi Commercial Record link within payment org Scope.
• Wallet balance → Commercial Record provider_ledger_balance attribute.

References

• PCI SSC, Tokenization Guidelines — https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf
• Stripe Payment Methods — https://docs.stripe.com/payments/payment-methods
• Stripe Customer object — https://docs.stripe.com/api/customers/object
• Stripe SetupIntent — https://docs.stripe.com/api/setup_intents
• Internal: ../commercial-subscription/stripe-customer-billing.md, reputation-assurance-gradient.md, commercial-identity-synthesis.md