Hosted payment gateway VS API integration

knowj

Up until now every store system integration I have done has been with a hosted payment gateway solution involving the user entering their card details on the payment gateways website (e.g. worldpay, protex) However a project I am working on at the moment is going to involve integrating with paypoint via their API using XML-RPC.

As this is my first API integration with a payment system i'm slightly worried and the documentation as with every other payment system i've seen is pretty pathetic and unclear.

First off are there any GOTCHAS I should be aware of?
Is there anything I should look into before i touch any code?

I like the idea of an api integration BUT I can see quite a few negatives.

Firstly if anyone ever hacks the server it would be easy silently to farm card details as normal functionality of the site resumes.
Second if any of the card providers decide to change security the developer is responsible for updating the system to accommodate for these changes. I think Maestro/Mastercard are making 3D secure pay mandatory.
If a new card is supported all the validation needs to be updated to support the new cards format.
There are a whole host of responses that are received with the xml response depending on authorization, transaction success and security checks that passed/failed etc...such as address match/missmatch/partmatch.

I know it looks nice and it's a comfort for a user that sees they are still entering their details on what they see as a "secure" and "trusted" site but this doesn't seems to outweigh my worries with this implementation.

etully

First off are there any GOTCHAS I should be aware of?

Here's a few off the top of my head.

Don't store the CC number in a DB ever. Maybe store the last 4 digits but only if you really need to.

Make sure that both the forms page and the processing page are SSL. Don't just have the forms page point to an HTTPS page. Put PHP code in each of those pages that checks the port number and redirects to SSL if they aren't already.

You shouldn't email order details to the site's owner. Make an SSL secured reports page that shows all the order details. It's ok to email the site's owner with a notice "Order #123 came in for $300 for a new pair of skis" but don't send the customer's name or address - or CC# 🙂

It's not a bad idea to install an intrusion detection system that gets MD5 scores of all the files on both the web site and the operating system. And if you do this, TEST IT. See what happens if you actually modify one of the critical files.

See if you can disable FTP. Use SSH and SCP if you can. If you have any code where users can upload their own files, triple check it for security holes.

Have a programmer (who is not you) check your site over for SQL injection weaknesses.

Think about whether or not there is any code on your site that you didn't write. This is a prime vector for attack. Are there any bulletin boards? Email forms scripts? If so, consider them a risk.

Second if any of the card providers decide to change security the developer is responsible for updating the system to accommodate for these changes.

Not if you write the contract carefully. 🙂 Make sure that you get to bill for future work. Changes to the protocol don't mean that you made a mistake. You are not responsible for the update because you aren't fixing something that you left broken.

Realistically speaking, In 12 years of integrating with payment gateways, I've never had one change protocols.

In my experience, when the site owner decides to accept a new card, this usually requires little more than adding it as an option to your HTML form.

Regarding the large list of possible responses from the gateway, I have found that most companies provide sample code that shows how to parse through the possible responses so it's less work than you expect. Treat the response you hear from the gateway as INPUT just as you would INPUT from a user. That is, assume the response is from a hacker and only trust input that matches the format you expect. For example, I once used ereg to scan the response for "ACCEPTED" to see if the credit card was accepted until I realized that the user could claim that their last name is "ACCEPTED" and the failed credit card transaction would mistakenly be considered good.

knowj

Thanks for the response greatly appreciated.

I am integrating a store system I personally built and that will be the only code that will be running on that domain will be written by me.

The Payment gateway is paypoint and unfortunately the documentation is pretty poor and spread around in some cases. My class is currently 500 lines in with very little validation but I am able to send data with test_status enabled and get the desired responses and handle them.

However recently Maestro/Master card announced that 3D secure is going to be compulsory so I am going through 41 pages of documentation trying to figure out what I have to do now. It doesn't seems to be a complete nightmare though.

I really like how the request and response can be handled at the same time which hugely reduces the chance injecting POST/GET variables.

Quick question when you send a request and get error responses do you handle/display a single error at a time or provide all errors to the user?

e.g. I currently use this:

case 'P:A':
	$this->error = 'Pre-bank checks. Amount not supplied or invalid';
	break;
case 'P:X':
	$this->error = 'Pre-bank checks. Not all mandatory parameters supplied';
	break;
case 'P:P':
	$this->error = 'Pre-bank checks. Same payment presented twice';
	break;
case 'P:S':
	$this->error = 'Pre-bank checks. Start date invalid';
	break;
case 'P:E':
	$this->error = 'Pre-bank checks. Expiry date invalid';

the response however can send multiple errors in the format of
'P:ES" -> Pre-bank checks. Expiry date invalid, -> Pre-bank checks. Start date invalid

Would it be worth stripping down the response string to provide users with multiple errors if required or let them handle one thing at a time (as one error could trigger multiple)

etully

First off, you can validate some of the data before you send it. For example, if the gateway has to tell you that the AMOUNT was not supplied or the zip code was blank, then... you're doing it wrong. As much as you can, you should know that what you are sending to the gateway is sane.

Second, I do not report every single Credit Card failure error to the user. I usually just tell them, Accepted / Failed. I rarely tell them much of what the gateway told me.

I don't know how your shopping cart works (and I don't know how experienced you are) but I can tell you this: Do all price calculations on the server... and do them INSIDE the script that actually validates the transaction. For example, if the user wants to buy two widgets and a gadget, your page flow should go like:

user shops around the site, puts items in basket, sees cost on screen as needed
user clicks "checkout" and goes to the checkout page
you present a page that asks for the name, address, CC#, etc.
That page posts to checkout2.php which does this:

Validate data as much as you can. (Do name, address, city, state, zip, CC#, CC exp all have values? Are there one or more items in the basket?) If there's a problem, display a message like, "You left the zip code field blank", and then STOP. Don't bother going on to step 2 or 3.
loop through all items in the basket, tally total cost
open connection to paypoint and pass the cost that YOU, YOURSELF, calculated in step 2, to paypoint for authentication.

A true beginner mistake is to embed the cost of the order as a hidden variable in the checkout page which gets passed to the the authentication script... and that script blindly trusts that number.

Lastly, on a different topic, I set up a system about 6-7 years ago that accepted CC orders. I found that hackers were using the very last page (the authentication page) to test stolen CC numbers to see if they were good. They wrote an automated script and were testing about 100 cards a minute for a very low transaction amount ($15-20) just to see if the card was good - I guess to see if they should use it on some other web site for a big ticket item. I ended up writing a little code that set a session variable in the the store, I updated the variable in the first checkout page, and then the authentication page checked to see if that session variable was at least 45 seconds old and if they spent at least 20 seconds on the previous checkout page. While this system isn't perfect, it was enough to make the hackers go away for now.

knowj

I handle everything I can do within the script. Address etc... is also dealt with internally as the user registered and the data is validated/sanitized.

The error codes i showed there are just listing our ALL the standard errors that paypoint can pass through to the system whilst I am building the class to handle everything.

I validate everything that cannot be changed by the payment provider but some things such as pattern matching the credit card number can change and could cause issues at a later date.

I spent most of yesterday reading through the 3D secure integration documentation doesn't seem to be too much of a task. Just adds another step with an external party that the user has to complete.

A true beginner mistake is to embed the cost of the order as a hidden variable in the checkout page which gets passed to the the authentication script... and that script blindly trusts that number.

I have never trusted anything a user enters even if it is within the site admin controls. The only time I have done this is when a MD5 hash of amount:orderid and a shared key is also sent and compared with the same data at serverside but this has only been required on payment gateways such as worldpay etc...

again thanks for the input.