Comment by midnightmonster | Hacker News Reader

Comment by midnightmonster | Hacker News Reader

Parent Full thread

midnightmonster

Ahhhhhh... Someone is wrong on the Internet!

The card thing is really No Big Deal. It's actually a pretty smart integration with one shortcoming.

Whatever gateway they're using has some support for you maintaining control of the checkout experience while not actually receiving or transmitting card data--a great thing for PCI compliance. So the form is on an HTTPS page on the merchant's site, but instead of posting to the merchant's app, it posts directly to the gateway. The gateway communicates status with the merchant via a synchronous HTTP request or signed data in a redirect URL, and the merchant's software processes the transaction without ever seeing card data.

As the OP says, "they're using HTTPS"--yes, this makes all the difference. The only reason the info appears to be clear text to him is that he's using Tamper Data, a browser extension that lets you play with your own POST data before you send it over HTTP(S).

This is the Right Way to do it for a site that doesn't get some compelling advantage out of building the infrastructure necessary to be PCI compliant. Done this way, PCI compliance requires just the trivial SAQ A. The only problem with this is that either the gateway does not support (sadly, the most common case) or the developer did not implement signing the transaction details on the merchant side.

I meant not so big a deal as transmitting the card data in the clear, and not that hard to fix, and possibly not even indicative of developer incompetence if they knew about this issue (which may be a limitation of the gateway the merchant insisted they use) and apprised their client.

Yes, it's bad for people to be able to change the prices on what they're buying, and potentially it's a very big deal if there's no reasonably attentive humans involved anywhere else in your process. (If I got a $10,000 order, I'd double check that everything was golden in my gateway before I popped the cork on my champagne.)

The worst case for this is someone with a stolen credit card purchasing big ticket items for a small enough amount that it doesn't trip any alarms. You'd be a fool to do this with your own card.

Hmm, from what I gather the customer is able to reset the dollar amount. Something that can be caught for sure, but sounds like pretty bad design to me.

It's No Big Deal until someone orders $10,000 worth of merchandise, pays $1 for it, and it gets shipped to an empty house in a subdivision before someone notices.

Then it's a Really Big Fucking Deal Oh God How Will We Pay Rent.

So admittedly I've only ever dealt with Paypal as a third party taking payment (as opposed to a few other systems where my server talked directly to the payment gateway).

One thing I noticed that the OP did not mention was whether or not the website's own 'transaction ID' was part of the transaction details being sent and / or whether or not the third party site returns a transaction ID themselves. At least with Paypal, the client makes the payment then they are returned to the original site with a 'receipt' transaction ID and it is then up to the original site to take that receipt number and do their own look up, back to Paypal, to ensure that the amount paid was actually the amount it wanted to be paid...

If that is happening with the OP's site, then I don't think there's anything stupid going on (or, at least, it's relatively simple to resolve).

I used a lot of systems. AFAIK, they all give some way for you to set your own transaction ID, and they all provide you with a gateway transaction ID, too. A good system will have a backend process to reconcile records based on one of these and would of course flag anything where the dollars don't match. This is the (inadequately explained) basis of my contention that the price editing is not a big deal. Of course, it could be a big deal if they botched a lot of other things, but by itself it doesn't mean there's an actual serious problem.

I don't think this is what you meant by signing, but it seems the easy fix for this is to have the merchant server post the transaction details to the processor, get a purchase order number, and redirect the customer to that. Why do processors rely on the customer to provide the details?

Actual approaches I've seen:

* Trust the submitted data. Sadly, very popular. Of things I've seen lately, Authorize.Net's new Direct Post Method does this, as does the Prolific gateway.

* Have the merchant optionally crypto-sign all the interesting-to-manipulate parts and submit the signature along with. Braintree's old API worked this way, not sure about the current. USAePay does this, but they don't let you sign all the important fields.

* Stripe has your form submit to you, but they use JavaScript to submit the card details to them first and replace them in your form with a customer ID which you charge as you like.

* PayPal Express Checkout (but not any of their other checkout methods) uses the method you suggest. Although of course with them you leave the merchant's site to complete your payment. I suspect the reason it's not used more is that it requires the gateway to maintain some state that they wouldn't otherwise have to, and it involves an extra server round trip versus signing the submission.

Reply on news.ycombinator.com