传统银行卡最让人不放心的地方，是卡号、有效期和卡片验证码长期不变。一张信用卡就像带着固定门牌的「物理金库」：信用卡 PAN 常见为 15 位或 16 位，其中 16 位更常见。这些信息一旦泄露，攻击者就可能反复尝试线上交易。发卡行风控、3DS 等机制还能继续拦截风险，但静态支付凭证的暴露范围很难主动收窄。
虚拟信用卡（Virtual Credit Card，VCC）把这组长期凭证变成「随用随开、随时能撕」的临时纸条。例如，可以临时创建一张只许刷 100 元、限定商户或用一次就关闭的卡。持卡人也可以在 App 或 API 中暂停、关闭或替换卡片。凭证泄露仍可能产生未授权交易、退款和争议，但可撤销的卡号与消费规则能缩小影响范围。
这项技术从 1999 年前后的线上支付安全工具起步，先以银行网站或本地应用生成替代卡号，后来进入发卡处理器、卡网络服务和 API。到了 BaaS 时代，虚拟卡又与实时授权、JIT Funding 和企业费控结合，成为可编程支付基础设施的一部分。
一、源起与变革：1999 年的信任危机与 Orbiscom
1. 时代痛点：不敢在网上刷卡
1999 年前后，互联网泡沫处于高点，Amazon、eBay 等电子商务平台快速增长，消费者却不愿把长期使用的主卡号交给陌生网站。TLS 已经出现，可以保护浏览器与服务器之间的传输数据，但网站部署、商户数据安全和消费者信任仍不成熟。一旦商户数据库泄露，同一组卡号、有效期和卡片验证码还可能在其他地方被尝试。
这里的卡号是 PAN（Primary Account Number，主账号），也就是日常所说的银行卡号。消费者已经会网购，阻碍他们的是把一组长期有效的支付凭证填进陌生网站。
2. 颠覆性解法：OAC / CPN 受控支付号码
Graham O'Donnell 与 Ian Flitcroft 共同创办的 Orbiscom 提出了一条直接的思路：不要把日常使用的主卡号交给商户，网购时临时生成另一组号码。其专利技术称为 Controlled Payment Number（CPN，受控支付号码）；OAC（Online Account Numbers）可以理解为这类线上替代号码的产品称呼，不是统一的行业标准术语。
这组替代号码仍符合卡网络接受的 PAN 格式，但发卡侧可以给它附加金额、商户、周期或使用次数等规则。Mastercard 后来的收购公告也把 CPN 描述为 Orbiscom 的专利技术。
以一张限额 $30 的受控卡号为例，早期思路可以概括为：
「用完即销毁」只是可选规则。受控卡号也可以按商户、金额或周期重复使用，具体行为由发卡产品决定。
3. Orbiscom 的技术巧思与商业演进
发卡端侧挂：不改商户，先改发卡侧
这类方案的巧思在于兼容。虚拟卡号仍是符合卡网络规则的 PAN，包含有效的 IIN/BIN 前缀和校验位，商户与收单机构可以把它当作普通卡号处理。银行与卡网络里有大量长期演进、包含 COBOL 的主机系统，整体替换成本很高；把 Orbiscom 引擎作为 Issuer-side Proxy 部署在发卡侧，便可以在一次授权的时间窗口内完成号码关联和规则匹配，不要求每个商户、收单机构或 POS 系统升级。
第一块试验田：AIB transactonline
爱尔兰联合银行 AIB 在 2000 年 2 月公布与 Orbiscom 合作，计划以 transactonline 品牌向 Visa 信用卡客户提供受控号码。用户可以在银行网站上生成 O-Control 号码，设置单次使用和最高金额，商户则继续按普通信用卡交易处理。AIB 当时预计首 12 个月至少覆盖 50,000 张 Visa 卡，并预计到 2002 年这些持卡人的线上年消费额超过 1 亿爱尔兰镑。发布材料把降低盗刷顾虑、提升网购意愿和兼容现有受理网络作为产品目标，但没有提供运行数据证明这些效果。同期资料还把 AIB 列为 Orbiscom 股东，但没有足够依据确认原先流传的 5% 持股比例。
进入美国并扩展到更多机构
同年，MBNA 宣布采用 Orbiscom 技术。持卡人可以下载 O-power 应用，为每笔交易生成唯一号码并设置金额上限，服务后来以 ShopSafe 为产品名。Bank of America 于 2006 年完成与 MBNA 的合并，Bank of America 也出现在 Orbiscom 后来的客户名单中；现有资料不足以确认 ShopSafe 后续版本是否完整继承了早期 O-power 的实现。American Express 当时也推出了自研的一次性卡号产品，但不能把它算作 Orbiscom 客户。
Orbiscom 后来的客户和合作机构还包括 Citi、Bank of America、Wells Fargo、PayPal、Swedbank 和 Banque Populaire。早期产品需要下载本地应用，随后逐渐进入银行网站、App 和 API。不同机构采用的产品名、规则和映射位置并不相同，不能把所有虚拟卡服务视为同一套实现。
Discover、American Express Private Payments、法国 e-Carte Bleue 和 DBS 也属于同期虚拟卡或线上安全支付产品。它们说明一次性号码和线上安全支付已经形成更广的市场方向，但现有资料不足以证明这些产品全部采用 Orbiscom，不能把整张名单直接写成 Orbiscom 客户。
Mastercard inControl 与收购
2008 年 9 月，Orbiscom 公布其技术用于创建 Mastercard inControl 平台。2009 年 1 月，Mastercard 以约 $100 million 收购 Orbiscom；同期商业报道换算为约 EUR 73.1 million。inControl 已经覆盖授权控制、交易路由、提醒、消费限额和 limited-use number 等能力，Orbiscom 团队与产品也进入 Mastercard 体系。
这笔收购可以解释 CPN 与 inControl 的产品延续，却不能单凭收购公告断言 Orbiscom 团队就是 Mastercard Labs 的早期核心班底，或进一步推导它直接演进成 Apple Pay、Google Pay 的 Tokenization 标准。受控卡号与 EMV Payment Token 都会减少原 PAN 的暴露，但两者的对象、角色和处理方式并不相同。
二、VCC 底层架构、授权机制与技术演进
1. 核心本质：带规则的支付凭证
对于与主账户关联的 VCC，可以把它理解成「带规则的路由凭证」：商户提交虚拟卡号，控制服务检查规则，再找到对应的资金账户。这个模型解释了很多企业虚拟卡，但不是所有 VCC 的统一实现。有些产品直接发行一张独立虚拟 PAN，有些产品使用共享信用额度，还有些产品连接独立预付账户。
1.1 资金解耦：钱、卡号和额度分开管理
多数虚拟卡不会在卡片本身「保存」资金。在一种常见模型中，承载真实资金或总额度的账户称为主资金池（Master Pool），虚拟卡与主账户之间的关联称为映射指针（Pointer）。实际资金与额度可能记录在发卡账本、企业资金账户、信用额度或预付账户中，虚拟卡则提供一组可用于交易的支付凭证。不同产品的资金模型并不相同：
共享资金或信用额度： 多张虚拟卡共同使用企业账户、主账户或授信额度，每张卡再配置自己的消费限制。
独立预付账户： 资金先进入与卡片关联的预付账户，授权时检查该账户余额。
按交易入资： 账户平时无需预存余额，授权发生时再通过 JIT Funding 决定是否入资。
界面上显示的「可用金额」也不一定是已经划入卡内的余额。它可能来自主账户可用资金、信用额度、预付余额和 Spend Limit 的共同计算。只看到 $100 可用，不能判断底层采用了哪种资金模型。
同样，虚拟卡也不一定是原 PAN 的「映射指针」。有些产品生成与主账户关联的替代卡号，有些产品则直接发行一张独立的虚拟 PAN。把所有 VCC 都称为 Token，会与 EMV Payment Token 混淆。
1.2 风险隔离：替身卡号可以随时作废
虚拟卡可以隐藏日常使用的主卡号。某张虚拟卡泄露后，持卡人通常可以在 App 或 API 中关闭、销毁（Burn）或替换它，无需补发实体卡。这样能切断后续授权路径，但已经发生的授权、清算、退款和争议仍要继续处理，资金账户也不会因此与风险完全隔绝。
1.3 规则引擎：给每张卡加上使用边界
规则引擎可以继续收窄这张卡的使用范围：
商户锁定（Merchant Lock）： 卡片首次在 AWS 等指定商户使用后，只允许同一商户继续扣款。是否支持 Merchant ID 级控制取决于发卡平台。
单次使用（Burner / Single-use）： 完成一次符合条件的授权后关闭卡片，可用于一次性采购、单笔供应商付款或需要提交支付凭证的正规试用。卡片作废不能替代取消订阅，也不能消除已经形成的付款义务。
消费上限（Spend Limit）： 设置单笔
$50，或者每月$20等周期限额，控制订阅超扣和自动续费。类别限制（MCC Filter）： 只允许餐饮、交通等指定 Merchant Category Code，用于企业采购和差旅费控。
规则不是事后报表。以 Stripe Issuing 为例，类别、国家、Card Presence 和金额限制会在 real-time authorization 之前执行；不满足限制的交易可以在进入业务方实时决策前被拒绝。不同服务商支持的控制维度和执行位置并不一致。
2. 密码学屏障与号段资源管理
2.1 Virtual BIN 与 8 位 IIN 升级
BIN 是行业常用说法，ISO 标准使用 IIN（Issuer Identification Number，发卡机构识别号）。发卡项目可以为虚拟卡使用独立 IIN 或 Account Range，也可以在同一 IIN 下划分产品区间。独立号段便于识别和配置，但不是所有 VCC 的必要条件，也不能据此断言虚拟卡与实体卡一定「物理隔离」。
例如，可以把 4800 99 视为虚拟卡号段、4111 22 视为实体卡号段来理解产品划分。这两个前缀只用于说明结构，不代表真实可用的发卡配置。
ISO 为缓解 IIN 资源不足，把新分配的 IIN 从 6 位扩展为 8 位；卡组织在 2022 年 4 月前后进入 8 位 IIN/BIN 的迁移节点。一个既有的 6 位 IIN 可以转换为 100 个 8 位 IIN，因此前缀划分粒度扩大到原来的 100 倍。
把所有数字前缀直接枚举出来，6 位共有 10^6 = 1,000,000 种组合，8 位共有 10^8 = 100,000,000 种组合，也就是从 100 万种数学组合增加到 1 亿种。它们不是实际可分配的 IIN 数量；真实分配还受注册规则、保留范围和卡组织管理约束。
在 16 位 PAN、最后 1 位为 Luhn 校验位的前提下，IIN 变长也会压缩单个号段的账户编号空间：
| IIN 长度 | 账户编号可用位数 | 理论组合数 |
| 6 位 | 16 - 6 - 1 = 9 位 | 10^9，即 10 亿 |
| 8 位 | 16 - 8 - 1 = 7 位 | 10^7，即 1000 万 |
这些数字只解释编号空间，不代表发卡机构可以实际发满所有组合。更完整的 IIN、Account Range 和最长前缀匹配说明，可继续阅读卡 BIN 全解：银行卡的「身份证号」如何影响支付。
2.2 动态回收与隔离期
16 位 PAN 使用 8 位 IIN 和 1 位校验位时，中间有 7 位账户编号。虚拟卡量大、生命周期短，发卡项目可能回收已关闭的号码，但不能在关闭后立即分给下一位持卡人。
原交易之后还可能出现退款、授权撤销、迟到清算和 Chargeback。一个项目可以把隔离期设为 180 天到 2 年，用来覆盖这些迟到事件；这只是产品设计范围示例，不是行业统一期限。隔离期要覆盖哪些事件、持续多久，以及号码能否重新分配，仍由卡组织、发卡行、处理器和具体项目规则决定。
号码重新使用时，发卡系统会分配新的有效期，并在受 HSM 保护的密码学环境中生成或验证相应的卡片验证码。旧交易是否被拒绝，不能只归因于 CVC 校验，还取决于卡片状态、有效期、商户发起方式、Credential-on-File 关系和授权规则。
2.3 Luhn、CVC 与动态安全码
以 16 位 PAN 为例，最后 1 位通常是 Luhn 校验位，由前 15 位数字按模 10 算法计算。它可以在不联网的情况下发现一部分输入错误，但不是加密或反欺诈机制；通过 Luhn 校验只能说明数字格式自洽。
CVC/CVV 主要用于 Card-not-present 授权。发卡系统可以在受控密码学环境中使用 Card Verification Key 生成或验证这类数值，HSM 是常见的密钥保护与运算边界。以 CVV/CVC 的常见模型为例，输入会涉及 PAN、有效期和服务代码；具体算法、字段组合和结果长度取决于支付品牌与实现，不能把它简化成所有卡都使用同一条公开公式。
PCI DSS 禁止商户或服务商在交易授权后保存卡片验证码，即使持卡人同意也不能改变这项要求；具备合法发卡业务需要的 Issuer 或 Issuing Service 另有适用边界。因此，不能把「任何银行数据库都严禁存储 CVV」当成完整规则。
部分虚拟卡产品会提供动态卡片验证码（dCVV），按时间窗口或产品规则轮换页面展示的验证码，但这不是所有 VCC 的共同能力。Apple Pay 等电子钱包采用的 EMV Payment Token 和一次性支付密码也不是「屏幕上的 CVV 每隔几分钟变化」。Apple 的安全说明显示，交易会携带设备卡号和根据交易计数器、密钥等数据计算的一次性安全码，用于支付网络或发卡机构验证。
3. 交易授权闭环与卡组、银行双重校验
虚拟卡平台先建立卡片、持卡人、资金来源和规则之间的关系。交易发生后，商户再把虚拟 PAN 送入现有卡网络，由负责该发卡项目的系统执行规则和账户检查。整个过程分为「生成 VCN」与「刷卡授权」两个阶段，但映射存储和规则引擎不一定都位于卡网络。
这张图描述的是授权，不是完整清算。商户后续请款、网络清分、机构间结算、退款和争议仍会继续发生，授权通过不等于资金已经完成最终结算。
3.1 从发卡侧软件到托管控制服务
Orbiscom 早期方案把额外能力部署在发卡侧，卡网络继续路由普通格式的授权报文。授权到达银行时，Issuer-side Proxy 检查卡片规则，把替代卡号关联到对应账户或 PAN，再交给核心账务完成账户检查。把 2008 年前后作为理解转折点，可以看出产品从发卡侧软件扩展到 Mastercard inControl 一类托管服务；此后，发卡处理器和卡网络可以在授权路径中执行 limited-use number、消费限额、交易路由和提醒等控制。
这不是一条所有机构都在 2008 年同时完成的统一迁移。现代项目仍可能采用发卡行自建、处理器托管、卡网络服务或多层组合。授权在哪一层被拒绝、账户映射由谁保存，应以具体卡项目的协议与报文路径为准。
3.2 两阶段数据流：生成 VCN，再完成授权
生成 VCN 时，数据流通常包含四步：
用户在银行 App 或发卡平台申请虚拟卡，并设置
$100等消费规则。平台调用发卡处理器、卡网络托管服务或银行自建控制系统。
控制系统创建 VCN，并保存它与主账户、虚拟 PAN 或资金来源的关联。若项目采用 Network Tokenization，这类关联可能进入 Token Vault；普通 VCN 项目则可能保存在发卡行或 Processor。
VCN 返回给银行和用户，商户只看到可用于支付的那组凭证。
刷卡授权时，数据流再反向走一遍：
商户经收单机构和卡网络提交 VCN。
负责该卡项目的控制服务查找账户关联和消费规则。
规则不通过时，托管服务可以直接返回 Decline；规则通过时，再按项目架构路由 VCN，或把映射后的 PAN 送往发卡银行。
发卡银行检查余额、信用额度、挂失状态和反欺诈模型，并保留最终拒绝交易的能力。
授权结果沿卡网络返回商户，之后再进入请款、清算和争议处理。
3.3 EMVCo Tokenization 是相邻但不同的标准
卡网络入口把 Payment Token 查找并关联到 PAN 的过程通常称为 Token Conversion 或 De-tokenization。Visa Token Service、Mastercard Digital Enablement Service、UnionPay Token Service，以及 American Express、Discover、JCB 等支付网络或其服务方，都可以在各自方案中承担 Token Service Provider（TSP）相关能力。
EMVCo 在 2013 至 2014 年间推动并发布首版 EMV Payment Tokenisation Technical Framework，为 Payment Token、Token Requestor、TSP、Token Vault、使用域和生命周期提供共同框架。EMVCo 将 EMV Payment Token 定义为 PAN 的替代值，并允许把使用范围限制到特定商户、设备或支付场景，但框架不会规定每个 VCC 项目都由卡网络保存映射。
VCC 解决的是卡片发行形态和消费控制问题；EMV Payment Token 解决的是在钱包、电商和其他数字支付场景中替换 PAN、限制 Token 使用域的问题。一张虚拟卡可以添加到 Apple Pay 等钱包，随后再生成用于该设备或场景的 Payment Token。此时虚拟 PAN 和 Payment Token 是两层凭证，不是同一个号码换了两个名称。
3.4 双门安检与映射权归属
当控制服务和发卡银行都执行检查时，可以把授权理解成「双门安检」：
第一道门是卡片规则： 卡组托管服务、Processor 或发卡侧控制系统检查一次性卡号是否已使用、金额是否超限、MCC 或商户是否匹配。规则不通过时，这一层可以直接 Decline。
第二道门是账户规则： 发卡银行检查账户余额、信用额度、主卡状态、挂失状态和反欺诈模型。即使第一道门找到映射并放行，银行仍可以一票否决。
映射权取决于卡号由谁发行和托管：
卡网络或 TSP 托管型： Token Vault 保存 Payment Token 与 PAN 的关联，网络控制服务再执行 Token Domain 或其他授权规则。
银行或 Processor 自建型： 卡网络把 VCN 当作普通 PAN 路由，账户关联和规则保存在发卡侧。
多层组合型： 卡网络、Processor 和发卡银行分别执行不同规则，报文中的 PAN、Token 或账户引用也可能在不同阶段变化。
没有公开统计支持「托管型占 90%+」这一比例，不能用它判断具体项目。哪怕前一层映射成功，只要发卡银行发现主账户已关闭、额度不足或命中风控，交易仍会被拒绝。
4. BaaS 时代：JIT Funding 与可编程控卡
4.1 JIT Funding：刷卡时再决定是否入资
BaaS 与现代发卡平台把虚拟卡进一步变成可编程的企业付款工具。Marqeta 将 Just-in-Time Funding（JIT Funding）定义为在交易处理中实时为账户入资：账户无需提前保有余额，平台可以按交易信息自动决策，也可以把 Funding Request 发给企业自己的系统判断。
以一笔 $15.50 的消费为例：
授权窗口由服务商决定，并不存在统一的 200 ms 时限。例如，Stripe Issuing 的 real-time authorization 要求业务方通过同步 webhook 返回批准或拒绝；当前文档给出的响应窗口是 2 秒，超时后按账户配置的策略处理。Marqeta 的 Gateway JIT Funding 也要求业务端响应每个 Funding Request，具体时限应以项目配置和服务协议为准。
「资金零占用、盗刷风险归零、账实 100% 对齐」会夸大 JIT Funding 的能力。三个说法分别对应一种真实收益，也各有边界：
「资金零占用」对应减少预先入资： 不必为成千上万张卡逐一维持过高余额，资金可以更多地留在企业主账户，用于集中流动性管理；能否获得利息取决于账户产品。企业仍需准备可用资金，并承担结算与流动性要求。
「盗刷风险归零」对应缩小暴露窗口： 未通过业务规则的 Funding Request 不会获得本次入资，但系统故障、错误规则、账户接管、后续清算和争议风险仍然存在。
「账实 100% 对齐」对应保留逐笔决策依据： 订单、金额、商户、规则版本和批准结果可以进入对账与审计记录，但小费追加、退款、撤销、清算差异和 Chargeback 仍需处理。
4.2 精细化代码控制仍受授权数据限制
业务系统可以在实时决策中叠加更细的规则：
MCC 限制： 只允许加油站
MCC 5541或酒店MCC 7011等指定商户类别。地理围栏： 如果业务 App 在用户授权下取得可信定位，可以在 Funding Decision 中设置「距离指定门店不超过 500 米」等条件。GPS 不是标准卡授权报文的必备字段，还要处理定位伪造、权限缺失和隐私要求。
用后关闭（Burn-after-use）： 为一笔供应商付款、首单或正规免费试用生成单次使用卡，授权完成后关闭，避免凭证继续被扣款。卡片作废不能替代取消订阅，退款、撤销和迟到请款也仍要保留可追溯的原交易关系。
