礼品卡/借记卡激活
一般问题
零售机构如何限制礼品卡或预付费电话/借记卡的激活？
他们必须有一个系统，只能阻止您打电话激活未通过收银机扫描的卡，而且我认为零售 ERP/会计系统中必须内置一个标准解决方案。它可能涉及 Web 服务或 EDI。
具体问题
我问这一切是因为我的一位客户希望我开发一种产品，您可以通过在零售店购买一张 30 美元的卡来使用它。该卡上有一个唯一的号码。一旦您购买了卡并通过网站激活了它，餐馆的优惠券等就会定期通过电子邮件发送给您。
然而，如果有人偷了一堆卡片或弄清楚了编号顺序，我们不希望这些卡片发挥作用。
据推测，这是一个已解决的问题，因为零售商正在使用上述产品（预付费电话卡等）来做到这一点。
我可以想出很多方法来解决这个问题，但是我需要提供零售商期望的“标准”解决方案，以便产品能够以正常方式融入他们的基础设施。
多谢！
General Problem
How do retail establishments constrain activation for gift cards, or those pre-paid phone/debit cards?
They must have a system in place that only keeps you from calling in to activate cards that haven't scanned through the register, and I assume there must be a standard solution built into the retail ERP/accounting systems. It probably involves web services or EDI.
Specific Problem
I ask all this because one of my clients wants me to develop a product that you get into by purchasing a $30 card at a retail store. The card has a unique number on it. Once you've purchased a card and activated it via a web site, coupons for restaurants and so on are emailed to you periodically.
However, if someone were to steal a bunch of cards or figure out the numbering sequence, we don't want the cards to work.
Presumably, this is a solved problem because retailers are doing this with the products above (pre-paid phone cards, etc).
I can think of a number of ways to solve this problem, however I need to provide the "standard" solution that the retailers expect, so that the product will snap into their infrastructure in the normal way.
Thanks a lot!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我曾研究过一些此类系统，它们基本上都以相同的方式工作。该卡的磁条中编码有#（也可能是条形码）。这通常就是卡本身的全部内容。然后卡将在购买时激活。
基本流程如下：
客户进来并购买卡：
所以基本上，这张卡在激活之前毫无价值。那时它就变得“活跃”并且有与之相关的金钱。也就是说，在某个服务器上的某个地方有一个数据库，其中包含这张卡的#、激活的时间/地点、金额等。
通常有一些功能可以生成“日终”交易报告，以帮助您核对您的数字（您的系统所说的与他们记录的内容）。
由于卡是集中管理的，如果卡被盗，他们可以很容易地标记卡（这并不重要，因为在激活之前它们的价值为 0 美元）。
I've worked on a few of these types of systems and they all basically work the same way. The card has a # encoded into the magnetic strip (it could also be a barcode). That's usually all that's on the card itself. Cards are then activated at time of purchase.
Here's the basic flow:
Customer comes in and purchases a card:
So basically, the card is worthless until it's activated. At that point it becomes "live" and has money associated with it. That is, back on some server somewhere is a database that has this card #, when/where it was activated, amounts, etc.
There is usually some functionality to generate an "end of day" transaction report to help you reconcile your numbers (what your system says vs what they have recorded).
Since cards are centrally managed it becomes easy for them to flag cards if they were stolen (not that it matters since they have $0 value until they have been activated).
我通过其他来源发现大约有八种卡处理服务与各个零售地点集成。
每个零售点都使用一个。当卡扫描收银机时，零售商会通知卡处理服务（解锁 PIN 以便激活），然后卡处理服务可能会通过 API 调用通知我们。
然后，当客户去激活他们的卡时，我们可以知道哪些卡已通过收银机扫描（因为它们已解锁）。通过这种方式，我们可以解决有关卡被盗或密码被猜测的问题。
其中一些网络的名称是：
I found out through other sources that there are about eight card processing services that integrate with the various retail locations.
Each retail location uses one. When a card scans through the register, the retailer notifies the card processing service (unlocking the PIN so that it can be activated), and then presumably the card processing service notifies us via an API call.
Then, when the customer goes to activate their card, we can tell which ones have scanned through the register (because they are unlocked). In this way, we get around problems surrounding stolen cards or guessed pin numbers.
The names of a few of these networks are:
我很高兴在大学毕业后就参与其中一个系统的工作。根据他们处理处理的方式，日终批次或每周报告可能会导致很多问题。我看到的一件事是，如果持有该卡的人，无论合法与否，如果他们设法进行了一系列购买，这些购买的金额将小于 100 美元。当日开始余额但到当日结束时 >大于所有采购将进行的起始余额。当公司每天要为每个用户支付 100 美元以上时，这不是很有趣。
在安全方面，让与您接触的公司对采购负责。这是我所见过的处理这个问题的最好方法，因为这就是他们存在的目的。希望能以某种迂回的方式有所帮助。
I had the joy of working on one of these systems right out of college. Depending on the way they handle their processing whether end of day batch or weekly report could cause quite a lot of problems. One of the things I saw was that if the person whom had the card, whether legit or not, if they managed to make a bunch of purchases that were < the day's starting balance but by the end of the day > greater than starting balance all the purchases would go through. Not very fun when the company had to swallow upwards of 100 dollars per user a day.
In terms of security, make the company that you interface with be held responsible for purchases. That is the best way of handling this in what I have seen, because that is what they are there for. Hope that helps in some roundabout way.
你必须小心，我在零售商中见过这种情况……收银员会询问你面前的顾客是否有会员卡。顾客说不，但他们背后的顾客提供了他们的卡，卡被刷了，因此为他们没有购买的东西收集了积分……
因此，以牺牲顾客没有购买卡为代价获得积分，从而扭曲/扭曲了结果客户（拥有会员卡的人）的个人购物体验以及他们没有购买的商品......在适当的系统数据库中
简而言之，除了要求进行视网膜扫描或识别顾客身份的指纹。有些顾客在加入俱乐部时会出于隐私考虑而谨慎...这是另一件事要记住...并非所有人都会有会员卡...
希望这会有所帮助，
此致，
汤姆.
You have to be careful, I have seen this played out in retailers..a customer in front of you is asked if they have a loyalty card by the cashier. The customer says no, but the customer behind them offers their card and it gets swiped hence collecting points for something that they did not buy...
Thus gets points at the expense of the customer in not having it thus skewing/distorting the results of the customer (the one who has a loyalty card)'s personal shopping experience and what they did not buy...on the appropriate system's database
In short, there is no foolproof way of getting around that other than asking for a retina scan or finger print that identifies the customer. Some customers would be cautious in joining a club in regards to their privacy...that is another thing to be kept in mind...not all of them would have a loyalty card...
Hope this helps,
Best regards,
Tom.
我认为最安全的解决方案是拥有一个生成和打印（或导出）卡号的服务器。当顾客有兴趣购买礼品卡时，收银机会对其进行扫描，收银机会通知服务器该卡已获得批准（可能带有收银员的凭据）。
然后，当在您的网站上输入时，网站会检查卡服务器以查看卡号是否有效并获得批准。
那么，被盗的卡将不会被批准。如果有人弄清楚了编号方案，那么您可能会被搞砸，因此建议数字是随机的，并且有足够的数字，以使猜测数字变得不合理（可能使用类似于 CV2 代码的东西）。
这类似于借记卡的工作方式：卡号/生成的 CV2（“服务器”）->运送给客户->客户通过电话激活（“注册”，“凭证”是他们的 SSN 或类似信息）->然后客户在商店使用，商店联系卡公司的服务器
我知道 Intuit Quickbooks 销售点提供这样的服务（配有 API），您可以查找它们。
I believe that the most secure solution possible is to have a server that generates and prints (or exports) the card numbers. When a customer is interested in purchasing a gift card, it is scanned at the register and the register notifies the server that the card has been approved (probably with the credentials of the cashier).
Then when input on your website, the website checks with the card server to see if the card number is valid and approved.
Then, stolen cards are not approved. If someone figures out the numbering scheme, then you may be screwed so it is recommended that the numbers be random with enough digits to make guessing numbers unreasonable (perhaps with something similar to a CV2 code).
This is similar to how debit cards work: card number/CV2 generated ("server") -> shipped to customer -> customer activates via phone ("register", with the "credentials" being their SSN or similar) -> customer then uses at a store and the store contacts the card company's server
I know that Intuit Quickbooks Point of Sale offers a service like this (complete with an API), you could look them up.
我喜欢 HalfBrain 的解决方案。我还想象他们考虑到了某些安全问题，例如单个 IP 地址（或其他一些标准），超过一定数量的失败激活尝试会被标记为明显试图探测系统。
I like HalfBrain's solution. I'd also imagine they have certain pieces of security in mind, like a single IP address (or some other criterion) with more than some number of failed activation attempts getting flagged for apparently attempting to probe the system.