对于电子商务应用程序，我需要使用信用卡并使用真实卡传递到支付网关，但我需要存储并返回给交易发起者，这是一个保留格式的代理。具体来说，这意味着：
1）代理中的位数与真实卡号（PAN）相同。2) 卡的发行人类型部分——初始 1,2 或 4 位数字在代理中与原始 PAN 中保持相同。3) 代理人的最后 4 位数字保持不变（出于客户服务目的。） 4) 代理人通过 Luhn mod10 检查以获取语法上有效的信用卡。
我可以轻松处理要求 1-3，但 #4 让我完全难住了！最终实现将是 t-sql 或 c#。
有任何想法吗？
@neo 有正确的答案（给你+1），但我只是想指出，如果我理解你在做什么正确，这似乎是一个“坏主意”。发行者标识符号(IIN) 是 PAN 的前六位数字。如果您想存储前六位和后四位数字，我认为您不会有问题（PCI 规则规定您可以以明文形式存储这些数字），但是通过模拟中间六位（或更多）位，并确保它们通过luhn 检查它完全有可能你会复制一个真实的卡号。此外，如果您试图向审计员证明您没有存储真实的卡号，您会感到非常头疼。
可能是最好的重新考虑恕我直言。从您的问题中不清楚为什么您需要一个通过 luhn 检查并且看起来像一张真正的卡的数字，但实际上并非如此。
编辑：
根据您答案中的评论，您可以通过获取真实卡的前六位和后四位数字并将所有其他数字替换为 0 来生成您的代理。然后通过 luhn 检查运行它。如果它无效，则将最后一个零更改为 1，然后重试。继续增加那个数字，直到你得到一个有效的数字。您最多需要这样做 9 次。它很粗糙，可以优化，但它会起作用。
使用未通过 Luhn 算法测试的代理编号的问题在于，当您在任意数量的主机应用程序之一中用代理替换真实 PAN 时，这些应用程序本身具有一些可能接受/拒绝代理的逻辑或根据代理中的属性触发行为。
例如，如果初始数字不代表适当的卡类型（4=visa、37=AMEX、6011=Discover 等），许多电子商务和计费系统也会使用 Luhn 算法进行快速语义验证。如果我交给他们一个未通过此测试的代理人，那么它可能会被拒绝。最后，虽然出于 PCI DSS 的原因，他们不想存储原始 PAN，但出于客户服务的原因，他们通常确实需要最后 4 位数字。
我会根据您的想法考虑；理想情况下，我更愿意创建不通过 MOD 10 测试的代理，因为这更容易防御，但我必须了解客户供应商的需求。
关于 Luhn 算法本身，我查看了算法的细节以及 Graham Mitchell 生成 Luhn 传递“假”数字的算法。然而，他的算法是不受约束的——它不是从第一个数字开始，最后 4 个数字是固定的，特别是因为最后一个数字本身就是校验和数字。