Paypal vs PaypalUk in Magento

Magento 里有两个有关 Paypal 支付的模块:Paypal and PaypalUk。我尚未查到文档有关它们的区别,只知道 PaypalUK 依赖于 Paypal,在同时启用 Paypal and PaypalUk 时,后台可以看到

Configuration Paypal section when PaypalUk is enabled
Configuration Paypal section when PaypalUk is enabled

Configuration Payment Methods section when PaypalUk is enabled
Configuration Payment Methods section when PaypalUk is enabled

若不启用 PaypalUk 模块,后台变成:

Configuration Paypal section when PaypalUk is disabled
Configuration Paypal section when PaypalUk is disabled

Configuration Payment Methods section when PaypalUk is disabled
Configuration Payment Methods section when PaypalUk is disabled

对比可见后台多了 Payflow Edition,估计 PaypalUk 是面向开发者的称呼,Payflow 是面向普通用户的称呼。更多区别还有待摸索。

We can not argue with PayPal

我用 PayPal 多年,但还是得不时应付意想不到的新情况。

因为 PayPal 不是我公司的主 PSP,我也不是 PayPal 帐户的日常管理者,所以当我注意到7月底一笔交易被标注上 Reversal 时已经是8月底了。当时忙,没去理会。这笔交易虽然被 reversed,但没有通知我们有 dispute,在 Resolution Centre 也找不到这条记录,直接就被 reversed。可能当时 PayPal 有发邮件,但我不是 PayPal 邮件的接收者,大概那信跟一般的到款扣款通知太相似,我同事收到也没警觉(PayPal 的大部分信我们都不看)。9月底我有空了,想起这桩事,打电话给 PayPal 问原因。

我以前知道 PayPal 独创了 eCheque,顾客在 PayPal 余款不够时仍可以下单,款项由 PayPal 从顾客的银行帐户里划,PayPal 划款成功后再转给我们,通常需要5到7个工作日。我们的 bookkeeper 恨死了 eCheque,因为它给帐目处理带来了极大的麻烦——这时题外话。

eCheque 虽然麻烦,但还是安全的。可我以前不知道,顾客在 PayPal 余款不够时还有另一种付款办法,就是 instant payment。仍是由 PayPal 从顾客的银行帐户里划,但 PayPal 即时就划款给我们,如同顾客用 PayPal 余款付款。如果日后 PayPal 从顾客的银行帐户里划款失败,PayPal 就把钱从卖家帐上 reverse 过去。必须是 bank account verified 的顾客才能用 instant payment。如果卖家对 reversal 有异议,必须在 reversal 之日起7日提出。

一切都是 PayPal 定的规矩,不给人 argue 的余地。我是一个喜欢规矩的人,没有规矩不成方圆嘛,尤其欣赏美妙的规矩,比如数学的定理、Magento 的框架——又扯远了。PayPal 定的规矩,大部分是合理的,否则 PayPal 也不会做大。但这次被它的规矩套进去,我总有点不是滋味(虽然不是我的钱),只能敬告我自己:PayPal 邮件要封封读,或者帐户要日日看。

PayPal Spoof

PayPal Looks Like Phishing
An email from PayPal: looks like phishing

I had an email from PayPal a while ago. I believe it was sent by some careless staff of PayPal.

PayPal always remind people aware of phishing emails. At the bottom of the email, it says – How do I know this is not a spoof email? Spoof or ‘phishing’ emails tend to have generic greetings such as “Dear PayPal member”. Email from PayPal will always address you by your first and last name.

However, this particular email address me “Dear First Name Last Name”.

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 money to bank account,不一定是全额入帐。

PayPal 和 WorldPay settlement 都是全额入帐(小金额除外),Protx 就不是,中途还要扣掉按笔次数或金额百分比交易费。因为 settlement fees 不是 Protx 赚去,所以也不能说 Protx 有 hidden fees。PayPal 和 WorldPay 都是要收 transaction fees 的,Protx 不收 transaction fees 并不意味着它就是最便宜的 PSP。当初我初识 Protx 时觉得它异常便宜,一直想不通 Protx how to cover credit card fees charged by credit card companies,如今想通了,该交的是逃不掉的。

I can’t find a way to group releted transactions in PayPal history download

I have tried all formats of PayPal Download History, and found “Comma Delimited – All Activity” is the most comprehensive one. I send it as an attachment for your review. My problem with this history is – every transaction has a different Transaction ID, it is not give me enough information to group related transactions. Basically, it is missing a column Parent Transation ID (or call it Related Transaction ID, whatever).

Some virtual terminal transactions have an update transaction, some don’t (depends on whether AVS matches). I can’t use any ID number to trace a update transaction back to its parent transaction ID, so I might calculate one transaction twice.

PayPal should improve its data download format. At least, it should provide an extra column of “Parent Transaction ID” (indicate its parent transaction if any), or “Unique Tranaction ID” (all related transactions have a unique transaction ID) for me to group related transactions.

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一次非正常登录记录,当时我以为我记忆出错(现在看来我记性还是不错的),不过我没上心主要是认为英国人不会为这点小钱犯出性质严重的错误(这个帐号受清算公司监管,所以这个事件不再是公司内部事务)。现在还不知道这事会怎么处理。

PayPal问题多多

在使用paypal越来越深入时,我和同事们发现了paypal存在着很多问题,有些问题还算是低级错误,所以给我们的感觉是paypal对business用户(特别是美国以外的business用户)照顾得不周到。可能paypal名声在外,原来在我心目中是一个非常好用的payment solution,期望值高了,失望也大。平心而论,这些问题还不是nightmaire,如果发生在其他的payment service provider,我也不会有那么大感慨。

目前我碰到的最大的问题是:paypal download history下载来的交易记录不能直接拿来做帐用,我专门写了个转化程序,用于正规化交易记录。从paypal download history中,可以下载到好几种交易记录,我主要关心两种:all activities和balance affecting payment。前者确实包含了所有的交易活动,但后者包含了一些不影响余额的交易。

说到余额,记录中balance那一栏只能参考,很多时候它并不是真正的余额,搞得bookkeeper很头痛,这也是我写转化程序的直接动机。迄今为止,我遇到14种交易类型(type):

  1. eBay Payment Sent
  2. Payment Received  (仅用于money request)
  3. Pre-approved Payment Sent (paypal月费)
  4. Refund
  5. Shopping Cart Item (paypal cart模式,excluding VAT)
  6. Shopping Cart Payment Received (paypal cart模式,including VAT)
  7. Temporary Hold (dispute时,paypal暂扣款)
  8. Update to eCheque Received
  9. Update to Payment Received (虚拟终端模式,accept transaction)
  10. Update to Reversal (dispute结束后,paypal释放暂扣款)
  11. Virtual Terminal Transaction
  12. Web Accept Payment Received
  13. Web Accept Payment Sent
  14. Withdraw Funds to a Bank Account

通过对比all activities交易记录和balance affecting payment交易记录,以下三种记录包含在all activities里,但被balance affecting payment剔除:

  1. Virtual Terminal Transaction with Status “Pending”
  2. Virtual Terminal Transaction with Status “Refused” (若accept transaction,会有两条记录,type分别为Virtual Terminal Transaction 和 Update to Payment Received;若refuse transaction, 只有一条记录,type仍是Virtual Terminal Transaction,只是Status为Refused)
  3. Web Accept Payment Received if payment by eCheque (upon being paid, not cleared)

但实际上,仅剔除以上三种记录远远不够。比如:

Shopping Cart Item 是 Shopping Cart Payment Received 同笔交易,excluding VAT的记录不应该和including VAT的记录同时进入数据表;

Virtual Terminal Transaction 如果有accept transaction,就会有Update to Payment Received,同笔交易决不该有两条记录affacting balance。

正因为paypal 对balance affecting 逻辑不清,balance那一栏的数据就很乱套。光看paypal net 和 balance那两栏,很多人会认为上一条记录的balance 加当前记录的net 应该等于当前的balance,但paypal balance不是这么算的,谁也不知道paypal的逻辑,搞得bookkeeper说paypal有时会就一笔交易重复收费。

事实上,说paypal重复收费也冤枉了paypal。我转化程序的验证balance和paypal的最终余额还是完全吻合的。只能怪paypal提供的原始记录没有逻辑。

I am finally in Paypal Developer Central

It was very hard to join Paypal Developer Central. I registered for access long time ago. After registration, it said it would send me an email to activate my account. But I did not receive this email. I requested a resend but nothing happened either. I asked for Paypal Technical Support to look into this matter but they only suggested me look at my spam folder.

Today by chance I requested a resend of activation, and I got it. So, it was likely that Paypal had a Email System problem for a certain period.

电话收款的完美方案

客户电话订货,他把信用卡信息告诉我们,我们通过虚拟终端收款;我们的软硬件都不够安全等级,不适宜保存客户信用卡资料;客户再次订货时,我们通常又得问一遍信用卡信息。这很烦人,客户有时也觉得烦,大大咧咧的客户更觉得我们保存信用卡资料比每次问要好。我觉得以现有的软硬件设施来保存客户信用卡资料是不合法的,但我们不能做的事情,我们的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里找。