Payment card number

A standardized issuer-assigned account or funding identifier encoded as decimal digits with industry, issuer, account, and check-digit structure under payment-network rules.

Version

v1 · 2026-09-08 · History

Domain-specific #

6016

Origin domain

payment systems

Subdomain

payment systems

Core Idea

A PAN identifies the payment account relationship presented in card transactions and is governed by ISO/IEC 7812 length and numbering ranges, issuer allocation, tokenization, masking, storage, and security controls. Prefix ranges route to industry and issuer, an account identifier distinguishes the record, and a check digit detects common entry errors while authorization occurs through separate credentials and network messages. The abstraction is therefore identified by a declared carrier, a transformation or constraint over that carrier, and an invariant that tells an analyst whether the named structure is genuinely present.

Scope of Application

Payment card number belongs to payment systems and is useful where the analyst can specify the typed payment systems carrier, defining objects and relations, parameters, conventions, evidence, boundary cases, and comparison targets, then evaluate identifier length and format, issuer range, account mapping, check-digit convention, token-versus-PAN status, display and storage controls, and governing standard are explicit. The scope is broad within that domain but bounded by the need for identifier length and format, issuer range, account mapping, check-digit convention, token-versus-PAN status, display and storage controls, and governing standard are explicit. Descriptive payment-standard identity only; no real card data, credential generation, validation bypass, fraud, or authorization procedure is provided.

Clarity

The abstraction clarifies a crowded vocabulary by making identifier length and format, issuer range, account mapping, check-digit convention, token-versus-PAN status, display and storage controls, and governing standard are explicit the center of the account. A claim should name the carrier, the governing operation or relation, the applicable assumptions, and the recognition test. A bare label is insufficient because the name Payment card number can be used for a formal identity, an implementation, or a neighboring result unless carrier and convention are stated.

Manages Complexity

Without the abstraction, an analyst must reason directly over many local details: the carrier roles, admissibility assumptions, competing conventions, derived invariants, boundary cases, and proof or validation obligations specific to Payment card number. Payment card number compresses them into the roles in the structural signature. That compression permits comparison across instances without erasing the variables that determine validity. It also exposes which details may be varied safely and which are constitutive.

Abstract Reasoning

1. Identify the carrier. State what the elements, states, objects, or observations are: the typed payment systems carrier, defining objects and relations, parameters, conventions, evidence, boundary cases, and comparison targets. Reject examples whose alleged carrier belongs to a different problem. 2. Lock the constitutive rule. Express identifier length and format, issuer range, account mapping, check-digit convention, token-versus-PAN status, display and storage controls, and governing standard are explicit independently of one notation or implementation.

Knowledge Transfer

Knowledge transfers strongly among subfields of payment systems because they reuse the typed payment systems carrier, defining objects and relations, parameters, conventions, evidence, boundary cases, and comparison targets, Prefix ranges route to industry and issuer, an account identifier distinguishes the record, and a check digit detects common entry errors while authorization occurs through separate credentials and network messages., and type the carrier, state every parameter and convention in the definition, test that identifier length and format, issuer range, account mapping, check-digit convention, token-versus-PAN status, display and storage controls, and governing standard are explicit, compare the nearest accepted identity, and report counterexamples, uncertainty, and limiting cases.

Relationships to Other Abstractions

Current abstraction Payment card number Domain-specific

Parents (1) — more general patterns this builds on

• Payment card number is a kind of Identification Prime

  The proposed strict upward parent is prime:identification.

Hierarchy paths (3) — routes to 3 parentless roots

• Payment card number → Identification → Social Identity Theory → Classification

Show alternative paths (2)

Neighborhood in Abstraction Space

Payment card number sits in a moderately populated region (44^th percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — South Asian Numeration & Identification (6 abstractions)

Nearest neighbors

• Double-spending — 0.93
• Cheque — 0.92
• Automatic identification and data capture — 0.89
• Data store — 0.88
• Debt-to-income ratio — 0.88

Computed from structural-signature embeddings · 2026-09-08