Tag: payment service providers

Magento user be warned: eav_entity_store has realtime sales data

最近在一个 Magento 网站上大幅调整了 catalog structure。我先在测试服务器上调整产品属性、目录属性等，然后把测试服务器数据库里所有 catalog 和 eav 开头的表导入到生产服务器。因为生产站点的销售没有中断，我不能简单地从测试服务器往生产服务器导入整个 magento 数据库。 这次升级初看很成功，随后就发现百密中有一疏。我装有 protx standard (for SagePay Form integration)，顾客在重定向到 SagePay 付款时，表单预填的数据是别人的。原因是测试服务器的跟销售有关数据是生产服务器若干天前的，eav_entity_store 表里保存有 increment_last_id，我从测试服务器往生产服务器导入所有 catalog 和 eav 开头的表，导致 magento 再次分配几天已分配过的 order ID 给新订单。如果顾客在重定向到 SagePay 后点击 cancel，会导致同订单号的老订单 status change to cancelled。 ID 重复是一个很低级的错误，我不应该去导入 eav_entity_store 表。我是知道这张表的作用的，这个错误应该归咎于我考虑不周到。 Protx standard 这个模块也不够周到，我用的版本比较老，不知新版是否在这方面有改进。

AmazonPayments is removed from Magento 1.4

最近留意到一件奇怪的事：Magento 1.3 里还在的 AmazonPayments module 整个儿从 1.4 版拿掉了。 虽然 AmazonPayments 跟大部分英国公司没关系，但它还是造成一点小麻烦。因为它在 Magento 1.3 出现过，所以数据库里 system config 里留有 AmazonPayments 的一些配置信息；但是 Magento 1.3 升级到 1.4 时，为了减少麻烦，我把整个 1.3 源码目录删掉后再替换入 1.4 源码（而不是通常的 merge and replace），这样一来的现状是：数据库里有 AmazonPayments config data，但源码里没有 AmazonPayment module。这时，如果要新建一条基于 payment method 的 promotion rule （比如想鼓励大家使用 GoogleCheckout，给 GoogleCheckout 用户额外 10% 折扣），一点选择 payment method 就出错。 定位了一下出错的语句，原来是 getAllMethods() 不妥，因为它会根据 config data… Continue reading AmazonPayments is removed from Magento 1.4

Paypal vs PaypalUk in Magento

Magento 里有两个有关 Paypal 支付的模块：Paypal and PaypalUk。我尚未查到文档有关它们的区别，只知道 PaypalUK 依赖于 Paypal，在同时启用 Paypal and PaypalUk 时，后台可以看到 若不启用 PaypalUk 模块，后台变成： 对比可见后台多了 Payflow Edition，估计 PaypalUk 是面向开发者的称呼，Payflow 是面向普通用户的称呼。更多区别还有待摸索。

PSP hidden fees

我们公司用着 PayPal。PayPal 问题很多，但我认为它仍不失为最好的 PSP (或者说最适合的)。 我老板不这么认为，他认为 PayPal 给顾客付款带来很多障碍（主要是限制已注册信用卡单独付款）。我认为这种限制是必要的，PayPal 不只是 PSP 产品，它要做 Express Checkout，它要给 seller protection (同时也给buyer protection)，它必须改变常规信用卡付款的逻辑过程。 很多顾客不认可这种逻辑，也有顾客根本就反感 PayPal (总有些人在 PayPal 或 ebay 上有过失望或绝望的体验)，导致我们最终决定换一个 PSP。如果当初走上 PayPal 算是我积极推荐的话，这次选择新的 PSP 我不想过多参与了。 最后选了个 Protx，因为它的收费太诱人了，每季度1000笔交易以下月费£20，以上10p每笔（似乎Protx的定价模型有问题，交易越多单笔交易反而更贵？不过我不去深究 Protx）。网上对 Protx 的评论都是正面的，我主要关心是否有 hidden fees，没见 Protx 负面报导。 于是老板着手落实。很快他就发现还有一个 IMA (internet merchant account) 费用没在 Protx 计算在内。这是一个灰色地带，因为我了解的 PSP 除了 PayPal 就是 WorldPay，它们都不牵涉 IMA（或者说它们本身就是 IMA），所以我是第一次听说从 PSP withdraw… Continue reading PSP hidden fees

A dishonest colleague

经济危机袭来，俺老板玩了个金蝉脱壳。公司改头换面，解雇了几个同事，缩小规模继续经营。原公司有一个paypal帐号，原来不是main payment service provider，也不经常用，里面剩有小量余额。 我的一个原同事负责日常操作这些payment service providers，被解雇后他以为没人留意这个paypal帐号，观察了2个月后终于动手把余额转到他的个人账户里去了，并把这个paypal帐号给关闭了。 其实，这并不是一个被遗忘的角落，只是新老公司交替，大家杂务缠身，没及时去处理若干小事。今天，我正准备把这点余额移交给清算公司，发现paypal帐号无法登录了，折腾了好久终于跟paypal的客户服务通上话。（BTW，paypal的电话客服系统很糟糕，它首先假设用户都是不会使用internet的新手，各道语音菜单总是提示用户去上www.paypal.co.uk。我和另一个同事挂了不下10通电话才和电话那头的活人通上话。） 当了解到原同事竟然私转余额后，我对英国人的诚信度又有了新的认识。大概老板对此也会有新的认识，以前人事交替从来没有更改系统密码的要求，不知以后在这方面得到加强。 我也该检讨一下，前段时间我注意到这个paypal一次非正常登录记录，当时我以为我记忆出错（现在看来我记性还是不错的），不过我没上心主要是认为英国人不会为这点小钱犯出性质严重的错误（这个帐号受清算公司监管，所以这个事件不再是公司内部事务）。现在还不知道这事会怎么处理。

电话收款的完美方案

客户电话订货，他把信用卡信息告诉我们，我们通过虚拟终端收款；我们的软硬件都不够安全等级，不适宜保存客户信用卡资料；客户再次订货时，我们通常又得问一遍信用卡信息。这很烦人，客户有时也觉得烦，大大咧咧的客户更觉得我们保存信用卡资料比每次问要好。我觉得以现有的软硬件设施来保存客户信用卡资料是不合法的，但我们不能做的事情，我们的Payment Service Provider可以替我们做到啊。 这个问题我已经想了很久了：客户能把信用卡资料告诉我们一次，也能把信用卡资料告诉我们两次；我们能从客户卡上划出一镑钱，也能从他卡上划出两镑钱。这个前提是客户给与我们充分的信任。如果我们是诚信经营的，那么客户把信用卡资料告诉我们一千次也无妨，反之，哪怕一次也是祸害。 从理论上讲，Payment Service Provider是支付网关，当它的虚拟终端被我们使用一次以后，它就保存有客户的信用卡资料，以后同个客户再来付款，它就没必要让我们再从客户嘴里套问一遍信用卡资料。 但事实就是这么残酷。对于老客户的电话订单，一直以来我们总是反复问同一个客户几个同样的问题：持卡人姓名、账单地址、邮编、卡号、到期日、安全码… 直到本周我们新换了PayPal做我们的Payment Services Provider，我的牛劲上来了，追着PayPal Support问：能不能有一种结合Virtual Terminal（能电话收款）和Recurring Payments（能定期收款）两个产品特点的新产品，能在客人每次下电话订单的时候收款，但不用每次套问信用卡资料？说实话，我本以为PayPal不会有一个现成的方案，我只是想建议他们推出这么个新产品，可以方便广大商家。 不知道是PayPal Support笨，还是我表达得不够清楚，抑或是PayPal根本不想推广这个方案，我跟PayPal Support一来一去足足有四个来回才知道他们有现成的方案（藏这么好干吗？），前三个来回都是答非所问。 现成方案就叫“New Reference Payment” ，就在每笔Virtual Terminal Payment的Details里找。

An Ideal Way to Take Repeat Payments for Phone and Mail Orders

We have lots of regular customers place orders over the phone. I am looking for a solution which can satisfy: 1. We would not like ask credit card details every time; 2. We can not store credit card details; 3. It looks like a combination of Virtual Terminal and Recurring Payments, but these recurring payments… Continue reading An Ideal Way to Take Repeat Payments for Phone and Mail Orders

cardholder authentication是吃素的

我还没来英国的时候，就听说这里信用卡付款时不需要密码即可完成网上支付，当时我已经用中国的银行卡在中国的网上消费过几次，我觉得中国的银行卡的网上消费方案还是安全的，所以一对比英国的网上消费，我觉得很不可思议，在金融、网络技术领域都走在中国前面的英国，信用卡消费竟然不需要密码？！这个漏洞太大了，太可怕了。 来英国久了以后，我也渐渐接受了这个事实：所有信用卡消费都不需密码，全凭几个security questions保证持卡人的安全（这大概也是英国人和西方国家很看重隐私的一个原因）。 又过了一段时间，Master推出了MasterSecurity，Visa推出了VerifiedByVisa，很多payment service providers开始实施cardholder authentication，顾客在付款时回答完常规的security questions之后还要回答从authentication password里随机挑选的三个字母。如果所有的payment service providers都实施了cardholder authentication，付款不需密码的漏洞在我看来算是堵上了。 最近，paymenet service providers的大哥大之一worldpay宣布实施cardholder authentication，我很高兴，可随即我发现worldpay实施cardholder authentication不够彻底——在顾客在付款时回答完常规的security questions之后，worldpay会给顾客一个选择，也就是说顾客可以option in or out cardholder authentication。这样还不是老方一贴？安全性增强在哪里？不过我猜测worldpay给顾客选择是过渡期的方案，让顾客熟悉之后，最终cardholder authentication全面实施，不会把选择权留给顾客的。 今天，我又发现一件更离奇的事情，我收到了ebuyer一份“订单也被受理”的通知，事情的起因得从上周三我为公司订购一块usb wireless ethernet card说起。我先在ebuyer上选了一款，付款进行到最后一步碰到cardholder authentication，我使用的是公司信用卡，cardholder authentication security password不是我设的，我一看ebuyer的payment service provider要cardholder authentication，我只好终止了付款转而向boardbandbuyers买了一块usb wireless ethernet card。boardbandbuyers的payment service provider不需要cardholder authentication，所以订单一下子就通过了，第二天货也收到了。 如果说worldpay还在过渡期，cardholder authentication可以被option out还情有可原，但ebuyer的cardholder authentication岂不更是形同虚设？明明没有完成全部付款过程，ebuyer仍可以借记cardholder，这个安全漏洞更大。 作为商家，cardholder authentication的实施给顾客付款制造了一点障碍，似乎对商家不利（比如我的订单从ebuyer逃到了broadbandbuyers），但cardholder authentication的anti-fraud也是为了保护商家。我在这里倒不想进行cardholder authentication的利弊分析，只是觉得cardholder authentication作为一项安全屏障，一旦实施，就应该把它落实到实处。