Re: Payment Providers
BODY { font-family:Arial, Helvetica, sans-serif;font-size:12px; }
5. Established, tested cpan modules for dealing with them
I only know of Business::PayPal::API in CPAN which seems to work
ok. The downside is that its PayPal :)
My initial inclinations were the big guns like Datacash and
Paypoint,
but of some concern was datacash's website being hosted on IIS, and
the fact that neither of them have modules on cpan (and frankly, the
perl examples for datacash were more than a little embarrassing for
them).
So, recommendations? Horror Stories? Legal guidance?
--James
I've not seen a good implementation/example in perl from any
payment provider. And yes, the datacash examples are awful.
Anywhere I've worked we've rolled our own. Since most providers use
SOAP or key values via HTTPS it is not that much work to do a perl
implementation.
As for which provider I'd use I have no idea, I guess the one that
gives you the best deal. Technically they all seem to have their good
and bad points.
Paul.
Re: Payment Providers
On Thu, Oct 01, 2009 at 09:02:07PM +0100, James Laver wrote: I'm looking for a card processing service to take payments with. Essential features: 1. No javascript required to make a payment (that means you, NetBanx). The new Unified Payment Pages now work just fine without JavaScript. If we have documentation saying otherwise, could you point it out so that I can ask for it to be corrected? 2. No insistence on 3dsecure (because really, it's horrifically insecure). And badly implemented by quite a few providers. (There's XML, and a DTD. If the XML validates against the DTD, that means that it's *VALID*, dammit, so don't reject it) However, one can't take payments from Maestro unless one has 3D insecure. (And it seems that even easyJet are no longer large enough to wiggle out of that one) 3. I don't have to store any credit card details at all. 4. They deal with as many of the legal issues as possible so I don't have to. Particularly PCI DSS. Point 4 would imply point 3 is met. You don't say, whether you have a merchant account with a bank, or whether you want the payment service provider to deal with that part. Point 4 implies that you'd like them to deal with it, and just make money appear in my account. Doing this might restrict your options on 3D insecure/ Phished by Visa. 5. Established, tested cpan modules for dealing with them I don't know about that for *any* providers. My initial inclinations were the big guns like Datacash and Paypoint, but of some concern was datacash's website being hosted on IIS, and the fact that neither of them have modules on cpan (and frankly, the perl examples for datacash were more than a little embarrassing for them). Paypal probably meets most of your criteria too :-) Nicholas Clark
Re: Payment Providers
2009/10/1 James Laver james.la...@gmail.com: I'm looking for a card processing service to take payments with. Essential features: 1. No javascript required to make a payment (that means you, NetBanx). 2. No insistence on 3dsecure (because really, it's horrifically insecure). 3. I don't have to store any credit card details at all. 4. They deal with as many of the legal issues as possible so I don't have to. Particularly PCI DSS. 5. Established, tested cpan modules for dealing with them My initial inclinations were the big guns like Datacash and Paypoint, but of some concern was datacash's website being hosted on IIS, and the fact that neither of them have modules on cpan (and frankly, the perl examples for datacash were more than a little embarrassing for them). So, recommendations? Horror Stories? Legal guidance? Okay, I've been quiet on this so far, and I admit I can't actually address most of your points. Also, the disclaimer here is going to be *very* obvious. At my $employer , the CEO is also running another company, whose primary business is handling credit card transactions. I'm moderately sure that they don't have a CPAN module, but they are a perl shop, so it shouldn't be outside their skills to make one. In the interests of not spamming the whole list I'll not mention them directly here - just say that they've got their office on one of the main canals in Amsterdam, and leave it to James to email me offlist if he wants details. Disclaimer: I'm not actually employed by said company, but as far as I know they may well be providing the profit that the boss is using to keep us afloat (if we need that, I'm not exposed to the numbers that much) -- Better to remain silent and be thought a fool than to speak out and remove all doubt. -- Abraham Lincoln
Re: Payment Providers
On Fri, Oct 02, 2009 at 10:26:06AM +0100, Nicholas Clark wrote: However, one can't take payments from Maestro unless one has 3D insecure. (And it seems that even easyJet are no longer large enough to wiggle out of that one) Nor are Google: http://econsultancy.com/blog/4356-why-has-google-checkout-dropped-maestro Paypal probably meets most of your criteria too :-) They meet all of them. Tom
Re: Payment Providers
On Fri, Oct 2, 2009 at 10:49 AM, Tom Hukins t...@eborcom.com wrote: Nor are Google: http://econsultancy.com/blog/4356-why-has-google-checkout-dropped-maestro Paypal probably meets most of your criteria too :-) They meet all of them. What do you all think of Google Checkout? https://checkout.google.com/seller/developers.html?hl=engl=GB James has just saved me asking this question for myself. -d. -- Damon Allen Davison http://allolex.net http://musicindustryrules.com http://thegannet.net
Re: Payment Providers
--- On Fri, 2/10/09, Nicholas Clark n...@ccl4.org wrote: From: Nicholas Clark n...@ccl4.org 2. No insistence on 3dsecure (because really, it's horrifically insecure). And badly implemented by quite a few providers. (There's XML, and a DTD. If the XML validates against the DTD, that means that it's *VALID*, dammit, so don't reject it) However, one can't take payments from Maestro unless one has 3D insecure. (And it seems that even easyJet are no longer large enough to wiggle out of that one) OK, I give. That's two references to how insecure 3D secure is. Given that I know nothing about it other than the annoying fact that I've forgotten my password for it, could someone explain why its broken? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Payment Providers
Ovid wrote: OK, I give. That's two references to how insecure 3D secure is. Given that I know nothing about it other than the annoying fact that I've forgotten my password for it, could someone explain why its broken? Well firstly you, I and *everyone* forgets their password. And then it just lets you generate a new one. Which makes it meaningless even if 90% of users didn't end up using PAZZWORD anyway. Secondly - who's providing that 3d-secure form? How do you know it's your bank and not someone collecting PAZZWORDs? -- Richard Huxton Archonet Ltd
Re: Payment Providers
On Fri, Oct 02, 2009 at 10:49:04AM +0100, Tom Hukins wrote: On Fri, Oct 02, 2009 at 10:26:06AM +0100, Nicholas Clark wrote: However, one can't take payments from Maestro unless one has 3D insecure. (And it seems that even easyJet are no longer large enough to wiggle out of that one) Nor are Google: http://econsultancy.com/blog/4356-why-has-google-checkout-dropped-maestro Then again, Maestro screwed up and is screwed. Switch was if you see a Switch logo, you can use your Switch card Maestro is, well, printed A4 sheets in shop windows with Austrian Maestro Only It's one logo applied to 15 or so different debit card schemes, without guaranteeing any sort of interoperability. Which destroys any sort of brand value it might have had. There's a technical term for this, but apparently I'm not supposed to use it in front of small children*. Maestro is being replaced by Mastercard Debit, which is not tainted with this incompetence. In the UK, at least HSBC and RBS are replacing Maestro. With *Visa* Debit. Oh yes, and Switch was screwed because not all Switch cards pass the Luhn check. Card length limit is 19 digits, and HSBC used to issue Switch cards that were $BIN . $sort_code . $account_number, which used up all 19 digits, so they had no ability to make the card meet the spec about the checksum. Various *merchant acquirers* seem not to know this, as they reject them rather than trying to auth. Then again, a certain large UK bank not owned by the government will happily auth *anything*, then refuse to settle it, and then complain that one is sending it bogus data. *You* bloody *authed* it. Oh well, if we can't get through to the issuing bank in time, we just auth it anyway Yeah right. And nearly all of them have test auth systems that differ from their live systems. Some of which you can DOS by accident, some with data files that meet the specs. Nicholas Clark * even if she throws up on me.
Re: Payment Providers
On Fri, Oct 02, 2009 at 03:13:35AM -0700, Ovid wrote: --- On Fri, 2/10/09, Nicholas Clark n...@ccl4.org wrote: From: Nicholas Clark n...@ccl4.org 2. No insistence on 3dsecure (because really, it's horrifically insecure). And badly implemented by quite a few providers. (There's XML, and a DTD. If the XML validates against the DTD, that means that it's *VALID*, dammit, so don't reject it) However, one can't take payments from Maestro unless one has 3D insecure. (And it seems that even easyJet are no longer large enough to wiggle out of that one) OK, I give. That's two references to how insecure 3D secure is. Given that I know nothing about it other than the annoying fact that I've forgotten my password for it, could someone explain why its broken? There's a description about how little it takes to reset the password in the link Tom gave: http://econsultancy.com/blog/4356-why-has-google-checkout-dropped-maestro Ben Laurie explains it here: http://www.links.org/?p=591 It's indistinguishable from a phising scam. Even better, which Ben doesn't cover, is that some banks have implemented it by outsourcing it to a third party, which then serves the pages from *its* domain. (Rather than having DNS delegated, so that 3dinsecure.rbs.gov.uk is a CNAME pointing to an IP owned and hosted by the outsourcer) So you get a popup saying I'm from your bank; tell me your secrets popping up in new window (believe it or not, originally with branding guidelines that were don't show a URL bar etc), served from a domain which is nothing to do with your bank. And often this is the first time that you, the card holder, have encountered the thing. Because your bank didn't bother to tell you about it in a communication from them that you trust is from them. It's almost like some enterprising chap in Nigeria wrote the specs for the banks, to save the the costs of having to do it themselves. Nicholas Clark
Re: Payment Providers
On Fri, Oct 02, 2009 at 11:34:15AM +0100, Nicholas Clark wrote: (Rather than having DNS delegated, so that 3dinsecure.rbs.gov.uk is a CNAME pointing to an IP owned and hosted by the outsourcer) Oh yes. If anyone knows anyone who might know someone at the registrar who might cause rbs.gov.uk to come into existence, and then have it so that everything served by it over HTTP is a 302 to rbs.co.uk, that would appeal to my sense of irony. (And annoyance, as a UK taxpayer, at all the various stupidities involved, that I'm paying for, because of incompetence from people who are not just still employ*able*, but employ*ed*) Nicholas Clark
Re: Payment Providers
2009/10/2 Nicholas Clark n...@ccl4.org: (And annoyance, as a UK taxpayer, at all the various stupidities involved, that I'm paying for, because of incompetence from people who are not just still employ*able*, but employ*ed*) Direct also your ire to the employees of the DWP, because most of those staff members in the JobCentre are just as institutionalized as their customers. Dominic
Re: Payment Providers
On Friday 02 October 2009 11:13:35 Ovid wrote: OK, I give. That's two references to how insecure 3D secure is. Given that I know nothing about it other than the annoying fact that I've forgotten my password for it, could someone explain why its broken? Well, there's the fact that, for years, we've been trying to educate Internet users not to enter details into untrusted websites, and now all of a sudden they're expected to trust some random page that appears in a popup/iframe from some domain entirely unrelated to the one they're in the middle of trying to give their card details to? Like, for instance, securesuite.co.uk - would you trust that random domain? (Incidentally, that's the domain that RSA forgot to renew at one point...!) See, for instance, http://ambrand.com/2006/09/06/is-securesuitecouk-a-phishing-scam It's a poor attempt towards three-factor authentication, but relying upon entering a password - which will be picked up by the same keylogging/sniffing techniques they'd use to grab the rest of your details if you're entering them on a compromised machine. However, now, the bank has shifted liability to the customer, claiming that since the transaction was authorised with their secret password, they have no right to repudiate the transaction. Cheers Dave P
Re: Payment Providers
On 2 Oct 2009, at 12:07, David Precious wrote: It's a poor attempt towards three-factor authentication, but relying upon entering a password - which will be picked up by the same keylogging/ sniffing techniques they'd use to grab the rest of your details if you're entering them on a compromised machine. However, now, the bank has shifted liability to the customer, claiming that since the transaction was authorised with their secret password, they have no right to repudiate the transaction. Yes, those lovely three factors: - Something you know - Something you know - Something you know Clever, huh. Firstly, they shift liability to the bank, which is why retailers like it. Unfortunately the bank shifts liability to the customer with the defence but noone else knows your 3dsecure password, it was you, there was no fraud. HSBC revealed to me that they've had 'zero fraud' since the introduction of the scheme, which means they're pinning this, exactly like they've all been pinning chip and pin fraud on the bank customer, because of the same defence (and they got away with that one in court, somehow). Because of this, banks are loathe to let you opt out. I've been unable to do so with HSBC. I've been writing a paper about attacks on the 3dinsecure system and it's all remarkably easy: 1. I steal your card (or memorise your details while you're paying with it), you haven't registered yet, I register for you, thus choosing the password I want 2. I steal your card (or memorise your details while you're paying with it) and go through a simple reset procedure, which generally only requires information I could extract from you during an hour at the pub without you realising 3. I set up a fake page that looks like a 3dsecure page on my site and cream off the details before submitting them myself so the payment goes through. Since it's all handled by third parties, you'd never know what's legitimate and what isn't. And many, many more, wait for the paper to be released :) It doesn't take an evil genius to see gigantic holes in the system, it's shaped like a swiss cheese. --James
Re: Payment Providers
On 2 Oct 2009, at 10:26, Nicholas Clark wrote: The new Unified Payment Pages now work just fine without JavaScript. If we have documentation saying otherwise, could you point it out so that I can ask for it to be corrected? Ah no, my experience was as a customer of the companies house website, where it ships in an iframe laden with javascript. And badly implemented by quite a few providers. (There's XML, and a DTD. If the XML validates against the DTD, that means that it's *VALID*, dammit, so don't reject it) The spec is ridiculous, but nothing is more ridiculous than programmers reading a spec and getting it wrong. However, one can't take payments from Maestro unless one has 3D insecure. (And it seems that even easyJet are no longer large enough to wiggle out of that one) If the card company mandates it, not a lot I can do about that, so be it. Point 4 would imply point 3 is met. You don't say, whether you have a merchant account with a bank, or whether you want the payment service provider to deal with that part. Point 4 implies that you'd like them to deal with it, and just make money appear in my account. Doing this might restrict your options on 3D insecure/ Phished by Visa. This was part of my concern. I know paypal just do CVC checking and to hell with 3dsecure (very sensible). I don't have an account with a merchant bank, I'd like all of that taken care of.1 Paypal probably meets most of your criteria too :-) I'd thought about paypal, but no. It would be nice to have it as an option though (which Datacash offer for example). Cheers, --James
Re: Payment Providers
On Fri, Oct 02, 2009 at 01:11:36PM +0100, James Laver wrote: On 2 Oct 2009, at 10:26, Nicholas Clark wrote: The new Unified Payment Pages now work just fine without JavaScript. If we have documentation saying otherwise, could you point it out so that I can ask for it to be corrected? Ah no, my experience was as a customer of the companies house website, where it ships in an iframe laden with javascript. Yes, that's the old stuff. That's, um, not exactly something to be proud of/ not exactly a good advertisement of what we now can do. However, one can't take payments from Maestro unless one has 3D insecure. (And it seems that even easyJet are no longer large enough to wiggle out of that one) If the card company mandates it, not a lot I can do about that, so be it. We had a chat at lunch, and (IIRC) Tom said that he thinks that Amazon are now not taking Maestro. We're inferring that Amazon have said We don't do 3D. We aren't prepared to loose 6% of our business from it, Mastercard have said But to take Maestro, you must do 3D, and Amazon said OK, we won't take Maestro then* If enough big sites take this attitude, then it will get the fate it deserves, whatever the banks think or want, because customers won't use those cards any more, because they aren't useful. Nicholas Clark * Well, really I'm hoping that they said Screw you hippy
Re: Payment Providers
On Fri, Oct 02, 2009 at 01:40:55PM +0100, Nicholas Clark wrote: We had a chat at lunch, and (IIRC) Tom said that he thinks that Amazon are now not taking Maestro. You remember correctly, but I'm wrong. I managed to end up looking at the list of card types accepted on amazon.com and somehow convinced myself I was on the UK site. I probably need a holiday. Tom
Re: Payment Providers
On 2 Oct 2009, at 13:40, Nicholas Clark wrote: Yes, that's the old stuff. That's, um, not exactly something to be proud of/ not exactly a good advertisement of what we now can do. Ah, well at least that's changed :) We had a chat at lunch, and (IIRC) Tom said that he thinks that Amazon are now not taking Maestro. We're inferring that Amazon have said We don't do 3D. We aren't prepared to loose 6% of our business from it, Mastercard have said But to take Maestro, you must do 3D, and Amazon said OK, we won't take Maestro then* 6%? I know of sites with much larger dropouts than that. And one day some of them will finally realise it's stupid and stop taking 3dsecure at all. If enough big sites take this attitude, then it will get the fate it deserves, whatever the banks think or want, because customers won't use those cards any more, because they aren't useful. I'm hoping that'll happen too. HSBC ditched maestro in favour of visa debit a few months ago. I've found maestro to be shocking actually. Like the DVLA take Solo (which noone takes) but not Maestro (what's with that?). My natwest maestro card needed replacing about once a month because the chip kept rubbing off too (though I don't know if they have some centralised manufacture or what). But then again, it's all about the liability shift. Smaller retailers rightfully look at the risk and say 'fuck it', not realising that the liability ends up with the customers (and probably not caring). Chip and pin did the same and the only bank I know of that instantly refunds you with a crime reference number is Barclays (in fact I had a rather long discussion with a Barclays manager about it after HSBC wouldn't let me take out cash in branch with my chip and signature card that they issued to me). I hope 3dinsecure goes to hell. --James
Re: Payment Providers
On Fri, 2 Oct 2009, James Laver wrote: 6%? I know of sites with much larger dropouts than that. And one day some of them will finally realise it's stupid and stop taking 3dsecure at all. In my experience sites are forced to by their bank. -- bob walker buses should be purple and bendy
Re: Payment Providers
On 2 Oct 2009, at 14:18, Bob Walker wrote: In my experience sites are forced to by their bank. That's unusual. Banks usually don't care, but they will give liability to the retailer in case of fraud on non-3ds transactions. --James
Re: Payment Providers
On Fri, 2 Oct 2009, James Laver wrote: Banks usually don't care, but they will give liability to the retailer in case of fraud on non-3ds transactions. Like I said forcing them. -- bob walker buses should be purple and bendy
Re: Payment Providers
On 2 Oct 2009, at 16:28, Bob Walker wrote: On Fri, 2 Oct 2009, James Laver wrote: Banks usually don't care, but they will give liability to the retailer in case of fraud on non-3ds transactions. Like I said forcing them. It's not *quite* so clear-cut. The costs due to fraud might be less than the costs of losing sales due to VBV/3DSecure, in which case the retailer might be happy to risk the fraud, especially if they have other fraud-avoidance mechanisms in place.
Re: Payment Providers
- Original Message From: Peter Corlett ab...@cabal.org.uk It's not *quite* so clear-cut. The costs due to fraud might be less than the costs of losing sales due to VBV/3DSecure, in which case the retailer might be happy to risk the fraud, especially if they have other fraud-avoidance mechanisms in place. This has to be one of the most important comments about all of this. When I originally went to uni to be an economist, I was amazed to discover in research how much in-house accounting dealt with which costs us less rather than which is right. It's rather sad. Cheers, Ovid (the hippie) -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Payment Providers
On 2 Oct 2009, at 22:16, Ovid wrote: - Original Message From: Peter Corlett ab...@cabal.org.uk It's not *quite* so clear-cut. The costs due to fraud might be less than the costs of losing sales due to VBV/3DSecure, in which case the retailer might be happy to risk the fraud, especially if they have other fraud-avoidance mechanisms in place. This has to be one of the most important comments about all of this. When I originally went to uni to be an economist, I was amazed to discover in research how much in-house accounting dealt with which costs us less rather than which is right. It's rather sad. Yes, but you have to balance both viewpoints here. Personally, I'm on the side of people not being forced to use 3dsecure (I want to be fully opted out). I don't want to be lumbered with the costs of fraud because I know how to take care of my end and if my details get out, it's not me that did it. I don't think it's reasonable I get charged because the bank or retailer messes up. On the other hand, the retailer wants to not be liable when there's any fraud because they shouldn't have to lose out on the goods. They don't think it's reasonable they lose out on the goods because the bank or customer messes up. Which side wins? Well, the retailer gets to choose. And it'll come down to a strict profit sum, whether costs of lost revenue is greater than costs of potential fraud. If you don't like it, there are other retailers waiting to take your money. --James
Re: Payment Providers
2009/10/1 James Laver james.la...@gmail.com I'm looking for a card processing service to take payments with. Essential features: 1. No javascript required to make a payment (that means you, NetBanx). 2. No insistence on 3dsecure (because really, it's horrifically insecure). 3. I don't have to store any credit card details at all. 4. They deal with as many of the legal issues as possible so I don't have to. Particularly PCI DSS. 5. Established, tested cpan modules for dealing with them My initial inclinations were the big guns like Datacash and Paypoint, but of some concern was datacash's website being hosted on IIS, and the fact that neither of them have modules on cpan (and frankly, the perl examples for datacash were more than a little embarrassing for them). We've used RealEx payment systems. They have a few integration options (sans javascript), provided (relatively shocking) reference perl code, have 3dsecure as optional, and helpful if not always on the ball support. Just a datapoint.
Re: Payment Providers
On Thu, 1 Oct 2009, James Laver wrote: So, recommendations? Horror Stories? Legal guidance? 3d secure is normally optional until your bank tells you otherwise. SecureTrading seem fine. Dont know about perl interfaces but all you have to do is pass xml to a java app. So really shouldnt be that hard. there are two i wouldnt recommend but they are stories best kept for the pub. -- bob walker buses should be purple and bendy
