Tarsnap now takes credit cards (switching from Paypal to Stripe) | Hacker News Reader

Tarsnap now takes credit cards (switching from Paypal to Stripe)

daemonology.net

152 pointscperciva34 comments

I love your implementation of the payment iframe!

I've wanted to implement stripe on a project of mine for a while, but I've had the same objection -- I don't want to allow any foreign-loaded Javascript that's not in an iframe.

Will you be releasing the iframe-generator by any chance?

Not that I don't trust you, but I'd feel more comfortable running it on my own HW... For instance, if you went evil, you could replace the iframes generated, rather than really delivering the Stripe code. Alternatively, you might decide that the payment iframe isn't worthwhile, and shut it down, leaving me and my users out of luck.

I think you wanted to post this over here --> http://news.ycombinator.com/item?id=4376192

But while I'm replying, I might as well answer the question... I didn't think anyone would want the frame-generator code, since (a) you'd need to host it yourself and set up your own new domain to do it in, and (b) you wouldn't need the flexibility of specifying a target URL and API key at run-time.

But if people want the code I'm happy to provide it -- send me an email to remind me to put it up somewhere.

Sorry, didn't see you posted that separately, I found it linked through this post.

I'll send you an email -- It'd be useful for for piece of mind for me, anyway. Throwing an additional Linode up isn't that bad, and it lets me know that the stack isn't going to change.

Thanks again for writing this, I'm consistently amazed at the quality of work you do! ;)

I feared you might have removed Paypal, because Paypal allows using local payment methods (like direct debit).

Fortunately it seems like both Stripe and Paypal are supported now. Phew!

Yes, when it comes time to make a payment you can click on either the "Make credit card payment" button (which loads the payment iframe) or the "Send payment via paypal" button (which sends you off to Paypal).

There's a lot of people outside of North America who don't have credit cards, and I certainly don't want to exclude them from using Tarsnap.

Thank goodness. I was considering Tarsnap a few months ago, but I had to reconsider it because of the Paypal requirement. Stripe is a welcomed alternative, though any non-PayPal method would work as well, and I'm likely going to finish my account setup this week.

I've always been curious about comments similar to yours with regard to avoiding a service that uses Paypal. Is that because of not wanting to use Paypal at all? Or is that because you think using Paypal means not being able to pay with credit card(they do and a Paypal account is not required)? Thanks.

I believe you can specify the amount you're depositing into your account, though someone correct me if I'm wrong. My issue is with just not trusting PayPal. I do use them every now and then when I absolutely must, but I just don't store credit cards or bank accounts with them any longer.

Sorry if I'm not clear. I mean you can make a purchase using Paypal and a credit card without having an account. This is separate than having a Paypal account, funding it and then purchasing via transfer("purchase") to another Paypal account.

Usually true, but not always -- for people in "high risk" countries Paypal sometimes refuses to accept a credit card unless you create a Paypal account first.

Got it. Thank you. But isn't this a separate issue and more to card issuance by Visa/Mastercard/Diner's etc? Won't Stripe likely have the same restrictions to cover themselves...or in time after they've been burned enough as well?

Stripe doesn't need to "cover themselves" as much as Paypal, since they have more information about their merchants and hold on to money for a week.

While true, there is an annoying edge case: If you have (at some point) linked your credit card to a PayPal, then PayPal forces you to log in to pay. You simply can't use the non-login path if the card has a PayPal account.

Some reasons why this is annoying, that I can think of: (1) It makes the process more complex. Some people just close their window when forced to log into something. (2) It makes writing tutorials/documentation harder. 'Just fill in your credit card details' becomes a long sentence listing the different things that can happen. (3) I have had some customers who complained that they had forgotten about their PayPal account and had to go through the "forgot password" sequence in order to pay. I imagine that the percentage of people who didn't complain but simply closed the tab is higher.

> If you have (at some point) linked your credit card to a PayPal, then PayPal forces you to log in to pay.

This is not true. I have a long unused PayPal account that hasn't been canceled, and on the occasion that I do end up buying something from someplace that only accepts PayPal, upon entering my information they ask if I would like to sign in and pay with a large "YES" button, or a very small "No, continue without signing in" link which acts the same as not having an account with them at all.

Edit: see Colin's child remark to the parent comment of yours. this may only happen in non-high-risk countries that allow payment without accounts.

Thanks. It is entirely possible that my information is out of date.

If you know of a site where I can trivially test this (ie., small amount, no signup or shipping required), I would be happy to test. I am not in a position to test my own stuff as it is currently all based on recurring payments (which requires a PayPal account).

Colin,

With the iframe implementation, is the burden of PCI compliance back on you(or someone who implements a similar function on their own hardware)?

I totally understand the need for safety with regard to external javascript but I thought one of the selling points for Stripe was less PCI headaches since they handle the "sensitive" parts for you?

The PCI rules only apply to systems which touch credit card data -- not to a system which serves up a credit card form.

Sorry if I misunderstand. Aren't you(paymentiframe) processing the form which is touching the data and then passing the data onto Stripe via their API?

The iframe uses Stripe's javascript to send the card details directly to Stripe's servers -- the only thing which hits the tarsnap server is a token which Stripe returns (and nothing at all goes back to the server hosting the iframe).

This approach of Stripe's has always seemed like a bit of a shell game to me, but I can only assume it's been deemed PCI compliant.

As I point out in my blog post, what the networks care the most about is ensuring that there aren't months or years worth of cards stored anywhere which might leak out. Having a site get compromised and a few days of cards stolen is orders of magnitude less important.

I think the point was frustration over the disconnect between PCI rules and reality, that there's no difference in security between self-hosting the form action (over ssl, sending the cc info to the payment processor, and getting a confirm that way), compared to hosting an iframe and "not touching" credit card data. A compromised webserver means the iframe can be compromised so that the card details do hit your server.

There is a difference: If the data never touches your server at all, it is impossible for you to inadvertently record it.

If the iframe that you host is compromised, you have no idea where that info is being recorded. The fact that it doesn't touch your server doesn't ensure that your site isn't leaking numbers.

Certainly. But it does ensure that access to your server does not entail access to historical numbers.

Unless the compromise is a long-term one.

Part of what PCI attempts to address is limiting legitimate access to servers, as well as preventative measures against compromise.

I personally think that Stripe may be within the letter of the law, but not necessarily the spirit.

I loved how you wrote that! Whenever people talked about stripe I always thought: Stop, wait! What if your server is compromised? You can do any change to stripe.js you like using malicious injected code. Many people would just handwave that away, but you write it perfectly clear and give the reason why what stripe does still helps: It basically just avoids the PCI checks without being secure ;-) No, you wrote that it avoids having you inadvertently store the data.

More people should write about obvious security holes so clearly and logically correct like you do

That's not universally true. Unfortunately, the PCI DSS is somewhat subjective and enforced inconsistently, so it's difficult to definitively answer what's required for PCI compliance for a certain type of payments integration.

Even for merchants that use third-party hosted payment forms, it's still common to need to complete SAQ A (a short self-assessment questionnaire) and have quarterly network scans. For example, with PayPal[1]: "Our hosted solution takes a lot of the work out of meeting these standards. The only remaining requirements are a Security Self-Assessment Questionnaire (SAQ) and Quarterly Security Scans."

According to MasterCard[2]: "All merchants that store, process, or transmit cardholder data must be PCI compliant." It's subjective whether using Stripe.js could be considered transmitting cardholder data.

Visa[3] holds Acquirers responsible for ensuring their merchants are PCI compliant. Requirements vary depending on processing volume: "In addition to adhering to the PCI DSS, compliance validation is required for Level 1, Level 2, and Level 3 merchants, and may be required for Level 4 merchants." Notice that for Level 4 merchants, validation only may be required, although those merchants should still be adhering to the PCI DSS.

Stripe has several PCI requirements in their terms of service[4], and their FAQ does seem to indicate[5] that merchants have some responsibility for PCI compliance. According to the TOS "It is your responsibility to comply with these standards." and according to the FAQ: "Most Qualified Security Assesors (QSAs) will want to talk through many of the implementation details before giving an opinion"

Disclosure: I work for Braintree.

Disclaimer: This response is my opinion; I'm not speaking for Braintree.

[1] https://merchant.paypal.com/us/cgi-bin/?cmd=_render-content&...

[2] http://www.mastercard.com/us/company/en/whatwedo/determine_m...

[3] http://usa.visa.com/merchants/risk_management/cisp_merchants...

[4] https://stripe.com/terms/US

[5] https://answers.stripe.com/questions/what-exactly-do-i-need-...

Colin, are automatic renewal payments coming?

Yes. I needed to get credit card processing working first before I can start to work on storing cards to charge later.

The Stripe API for this was marvelously simple to work with. All told, I had around 20-25 lines of code for dealing with subscriptions.

Yes, the work needed is on Tarsnap's side, not the Stripe-interfacing bits. I need to attach Stripe IDs to accounts, find out when and how much people want their accounts to be automatically recharged (and store those parameters), write code which checks each account to see if it needs to be recharged, etc.

This is welcome news. I like tarsnap but really don't like the possibility of losing all my tarsnap backups because I am not around to recharge it within the small window. I might be out on an mountaineering trip and be away from the email alert or something else like that.

This means Stripe is coming to Canada very soon. I'm ecstatic!

Reply on news.ycombinator.com