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

```text
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`