Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Accepting payments is getting harder

medium.com

Post reply on HN
Print view View original

101–110 of 125 posts

Re: Accepting payments is getting harder

#101

Post by akshatpradhan »

tomjen3 wrote: post #95
akshatpradhan wrote: post #40

Earlier quoted context omitted.

I think my tool can actually help you. You document all your procedures in an organized structure using Github flavored markdown. http://cc-stg2.herokuapp.com/compliancechimp/documents/softw... We're becoming the true Turbo Tax for compliance.

You probably have a good tool, but I am not even going to take a look at it when it doesn't have its own url. herokuapp just screams weekend project.

I do have a real tool. Its on ComplianceChimp.com. But its down right now because my TLS Certs expired a couple days ago and I never recorded my Key rotation procedures. I did think about temporarily disabling SSL, specifically for this HN post, but thought against it. We want to do compliance right.

We're fixing the certs now and updating our Key rotation procedures for you all to see in our publicly viewable compliance workbook.

Re: Accepting payments is getting harder

#102

Post by sumedh »

nmridul wrote: post #56
cm2187 wrote: post #52

We should have moved a long time ago to vendor specific credit card numbers (ecommerce isn't exactly a new activity). Say I get from my bank a token which I provide to this vendor, and the first time the vendor uses it to accept a payment, the token locks in to that vendor, i.e. my bank will not allow any payment with this token to another vendor (i.e. to another bank account). Then it doesn't matter if it's stolen,…

This is similar to how bank payment is working in India. When I make payment on seller website, it redirects me to the bank website. I enter my credentials (including phone based or device based OTP) to confirm the payment and its done. And there is also option to make easy subscriptions.

Subscription based payments dont work in India though, which sucks.

Re: Accepting payments is getting harder

#103

Post by jamiesonbecker »

benmanns wrote: post #98
mcdougle wrote: post #97

What service might I use if I needed to fulfill the following requirements: 1) Say I already have a customer -- he already paid a signup fee and we charge him monthly, so he's already put in his credit card information. At a later date, we need to charge him for something other than his monthly subscription fee. This is something he can do himself by logging in, but also something the site administrator needs to be a…

For 2), it looks like Balanced payments accepts ACH debits. https://www.balancedpayments.com/ach-debits

Apparently not any more. Balanced shutting down (RIP)

https://www.balancedpayments.com/stripe/faq

Re: Accepting payments is getting harder

#104

Post by benmanns »

jamiesonbecker wrote: post #103
benmanns wrote: post #98

Earlier quoted context omitted.

For 2), it looks like Balanced payments accepts ACH debits. https://www.balancedpayments.com/ach-debits

Apparently not any more. Balanced shutting down (RIP) https://www.balancedpayments.com/stripe/faq

Oh yikes, thanks. Listen to this guy.

Re: Accepting payments is getting harder

#105

Post by ceequof »

akshatpradhan wrote: post #101
tomjen3 wrote: post #95

Earlier quoted context omitted.

You probably have a good tool, but I am not even going to take a look at it when it doesn't have its own url. herokuapp just screams weekend project.

I do have a real tool. Its on ComplianceChimp.com. But its down right now because my TLS Certs expired a couple days ago and I never recorded my Key rotation procedures. I did think about temporarily disabling SSL, specifically for this HN post, but thought against it. We want to do compliance right. We're fixing the certs now and updating our Key rotation procedures for you all to see in our publicly viewable compli…

Not to kick someone while they're down... but a security company screwing up their key rotation is not exactly a good sign.

Re: Accepting payments is getting harder

#106

Post by jtdowney »

matthewarkin wrote: post #60
chinathrow wrote: post #55

Earlier quoted context omitted.

So where's the news then? Malicious JS is known to be bad. Would the next step be to turn of JS at all? Or go back to hosted cc forms only?

Historically, the thought has been that the iframe and a redirect could both be treated as SAQ A (the easiest form of compliance), was because if you changed the iframe that was displayed or the page the customer was linked to it would be extremely difficult to steal customer information in a silent way. So if a merchant links to paypal.com/merchant, and I inject js to change it to paypal.com/matthewarkin. The mercha…

At Braintree, we have been working on the approach you mentioned. We’ll soon update our iframe products to allow a merchant to opt-in to only ever receiving cardholder data via the Braintree iframe. With this change, we could actively block malicious JavaScript from rewriting the merchant form by rejecting data not from the Braintree iframe. Things like this aren't a panacea though which is why it’s important for merchants to use technologies like Content Security Policy and leverage as much of the browser security model as possible.

Re: Accepting payments is getting harder

#107

Post by juliangregorian »

Animats wrote: post #37
reviseddamage wrote: post #28

Earlier quoted context omitted.

Braintree too, Feb28, 2015 edit: actually I'm seeing Google there Jan 31, 2015 , so I wouldn't pay too much attention to this. Likely they fix up before anyways.

Visa's put Google on red status. Wow. Wonder what Google's problem is.

I used Google Checkout as a merchant once years ago and it was a horrible experience. Customer service was appalling. They ultimately ended up revoking our account and keeping the balance (it was low enough to not be worth fighting them over).

Re: Accepting payments is getting harder

#108

Post by akshatpradhan »

ceequof wrote: post #105
akshatpradhan wrote: post #101

Earlier quoted context omitted.

I do have a real tool. Its on ComplianceChimp.com. But its down right now because my TLS Certs expired a couple days ago and I never recorded my Key rotation procedures. I did think about temporarily disabling SSL, specifically for this HN post, but thought against it. We want to do compliance right. We're fixing the certs now and updating our Key rotation procedures for you all to see in our publicly viewable compli…

Not to kick someone while they're down... but a security company screwing up their key rotation is not exactly a good sign.

There's only so much I can get done with my dwindling runway =(.

But you're right, that getting Key Rotation Procedures documented is the 1st thing I should have done.

This is good feedback actually because now I know that after scoping the assets in my turbo tax-like tool, the very next thing a person should do is write down their key rotation procedures. Its also easier to write out as a procedure because its such a common yet forgetful practice.

We're putting cycles into this right absolutely now.

Re: Accepting payments is getting harder

#110

Post by dlubarov »

nothrabannosir wrote: post #68
BlackFly wrote: post #53

Earlier quoted context omitted.

The real solution to the problem is use of an integrated circuit card, usually through EMV. If a web merchant uses 3D secure or Verified By Visa or SafeKey (from MC, Visa and AmEx respectively), the issuing bank can implement the same level of security in a web transaction that occurs in a card present chip transaction. Proof that the transaction was originated by someone who has control over the card, proof that the…

This solution is already implemented in large parts of the world and good to go! But the incentives are sometimes not right. Ultimately, I want IC payments to be cheaper, as a merchant. I want my incoming IC payments to be in a separate bookkeeping from the non-IC: increase in fees on the latter, I'd like to keep my rates for the former. Ultimately, I can then pass these savings on to the customers. But as long as th…

My understanding is that

- The liability shift will pressure merchants just to use EMV-capable terminals. As long as they're using one they won't be penalized for swiping.

- However, the networks require certified EMV terminals to reject swipes from chip cards. (They can tell from the service code in the card's track data.) Unless dipping fails a certain number of times, in which case the terminal can allow swiping as a fallback.

So merchants are incentivized to get an EMV-capable terminal, issuers are incentivized to replace magstripe cards with ICCs, and terminal requirements (mostly) prevent swiping ICCs.

Post reply on HN