Does this API actually exists?

Hi Robert,

I'm sorry about the confusion and hopefully I can clear this up for you.  There is in fact only one Reporting & Admin API for everyone to use and not just partners however, this API is being updated.  The current version of the API, which is live and available to use now, was the first release and previously known as "Access".  The lastest update has just gone into beta testing and is currently only on the test server. The API formerly known as "Access" isn't being withdrawn, our customer services team have been advised to stop releasing the technical protocol guides.  One of the main reason for this is the latest version, now known as the Reporting & Admin API, is not backwards compatible and to avoid any serious impact on our vendors wishing to use this, we are discussing this through with everyone on an individual basis.

I'm sorry if your original email has not been responded to, this is a popular feature which a lot of out vendors are interested in and there is a small backlog of emails.  I'm part of the team responsible for the API and I will pick this up immediately and respond back to you.

I hope this has cleared up the confusion and I apologise for the mis-communication you received.

Cheers

Moe

Sage Pay

Thank you very much Moe. This is more like it! Thank you for your e-mail also. We're not working to a deadline as such but it would be useful for us to know what the API can do and as we're currently switching from Direct to Server due to PCI compliance it may influence the way we write some of our systems. Hopefully I'll get the API info by the end of the day and can start having a look.

Hi Robert,

As another developer, im interested in knowing why your having to move from Direct to Server for PCI complience?

I've simply removed the storeage of any card data from our system.

The end result is that if there's a payment issue, the customer has to re-enter all the information again..

Doing that our company passed (only Requirement 4: Encrypt transmission of cardholder data across open, public networks: needed looking at, and a vaid SSL cert sorts that out too.)

----- PCI DSS ----

Build and Maintain a Secure Network

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update anti-virus software
Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8: Assign a unique ID to each person with computer access
Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security

I am also migrating from Direct to Server.

With Direct even though the card details are not stored on the server, they do pass through the servers memory, which means if the site was compromised code could skimmed without the customer knowing.

By moving to Server you don't have this problem, and should reduce the SAQ that you need to do. I have seen this advice several times on the old forums.

Steve

The amount of $_POST data going through our servers memory (and a simple unset($_POST) clears it away) any hackers skimming data out of the servers memory is going to have to be totally on the ball to catch it, they would be better off catching your servers traffic, monitoring where SagePay posts the information back, and getting stock from you that they have not paid for.

Secure for the customer, but letting your stock holding take a dive.

Script kiddies can do this in a few hours, i've seen them in action on PayPal transactions.

The main reason behind PCI is the same as chip and pin (already hacked), it's to cover you in the event that a customers card information is stolen (from whoever), you will not be held liable to cover the cost. I know it's rough on the customers (of which we are all) but it's an arse covering job. As long as you have done everything that is practically posible and monitor/update, theres nowt else you can do.

Saying to your insurance company "we've lost £100,000 of stock, can we make a claim?" is going to get them asking questions like "why did you change to a less secure method?", using PCI as an excuse wont cut the mustard, as ALL are PCI complient.

The most common way of getting card data, is from the USER (something like 80%), i.e. Install a keyboard capture routine, or a backdoor etc. If the customer has been hacked, and they use your site, there's nothing you can do to help them. They will still see it as your fault, thus PCI comes into play and you prove you have done everything in your powers to stop it.

Using the logic of changing due to 'server skimming' are you also going to check the users PC ?

Are you offering advise about what virus guard they use before buying from you?

Check that if they are using WiFi that they have it set-up with full security? (WEP has been hacked)

I still don't see the reason to re-program all your system, unless your upgrading to 2.23 (but that's a 5 minute job)

Our SAQ (already done) took 15 minutes, asked where our credit card data was stored (we don't), if we used SSL/TLS (yes we do), if the main database was protected by a firewall (yes, and it's on a intranet that the internet users can't access, unless they breach the server) and if we use PCI passwords etc and so on...

Moving from Direct to Server won't reduce any questions from your SAQ UNLESS your storing the card details, or moving from REQUEST type payments, (those where you AUTH the transaction and then request the payment in batch mode or take payment in part)

We were going on the advice from someone on the old forum. There are loads of posts about it: https://support.sagepay.com/forum/Topic8784-35-1.aspx

We are also moving from 2.22 to 2.23, so needed to do something.

We have a physical terminal, plus multiple virtual terminals, so we have the full SAQ to be compliant. Moving from Direct to Server seemed like a good opportunity to get up to date and be secure.

Hi Steve,

Well, we have three terminals from HSBC (they have stated they are complient) and the HSBC informed us to use 'Security Metrics' who are a PCI partnet to them.

Security Metrics simply asked what terminals we had, and where we got them, put in HSBC and the termnal models (passed, next stage)

Do we 'STORE' card details (NO, removed all the pages to do with that)

Do we transmit card details (YES)

What ISP do we use (entered the ISP, PASSED, already acredited)

Do we use SSL/TSL (YES, who supplies the cert, entered our provider, PASSED, already acredited)

(wow, this is easy)

Do we allow access to card details in our organisation (NO, PASSED)

Do we use PCI complient passwords (YES, Windows Server 2008, PASSED, Already acredited)

Who processes your online card payments? (SagePay, PASSED, Already acredited)

and so it went on..!

The SAQ from 'Security Metrics' is built as you answer the ONLINE questions, stored by them and they do security checks (price???), they pass all the info to the HSBC directly, so there was nothing else for me to do, except place the logo on the payments page.

Your asking yourself, how much (HSBC deal £80), more if you don't bank with the HSBC...

For you SAQ, a simple phonecall to your bank could save your company HUNDREDS of pounds and days of reading. Get advise from THEM first..!

Get a FREE quote from them -> https://www.securitymetrics.com/

If you use Terminals, then you'll still need to do SAQ D.

Also interestingly, if you use Server, you MAY still need to do SAQ D, if you store the AUTH number (apart of the credit card information) etc...

Having had a thought about the OP's question, without this API, the Server route could damage your business.

As with this API, you could check that SagePay did take the funds, and thus, you know you've not simply had a payment  injected into your site (by sending spoofed details, that the downloadable document details, to your payment page)

It's totally dependant on how your checking the details returned, and what information your using as a key, and wether that key can be hijacked (but that route is easier than hijacking a servers memory, scanning it, decoding the details and pulling out the card details)

An easier route for hackers, is via SQL and/or CODE injection. Code injection being a nasty one, as theres a php shell routine that was written by a Russian that allows FULL root access to a server, allowing the hacker to change your code without you even knowing (unless you've got it encoded or do a SHA check on it)

We spoke with our merchant bank and were told WE had to work out which SAQ to do, they refused to tell us. It is indeed SAQ-D that we are doing.

We have also been told by Sage Pay that there is a difference between Server and Direct when it comes to compliance. Direct isn't covered under their Certificate, Server is.

We are using Hacker Guardian from Comodo, and our sites code has passed all the scans. I am confident we are safe and secure.

From reading the forums I decided to be safe and move to Server. I can't see it affecting sales for our site. There are lots of opinions on the forum, and on the net in general, I just went with what I feel safe with.

They where really helpful then, sounds like your account manager needs re-training in 'customer service'.

Direct isn't covered as it uses your code to send/receive data, and thus you need to get complience.

As your doing your own SAQ D, if your code gets passed, and you use a valid SSL/TLS cert, your cert will cover it.

Looking at Hacker Guardian, I can't see an option for code validation, there tests are the standard IP/Port tests, checking that the server doesn't have an open port that has a known issue/checking that the software used doesn't.

Code issues can be as simple (in php) as having register_globals=on in the php.ini and using include($path.'file.php'); as a hacker can send the $path via the URL and have your script load an external file and process it through the api.

SQL injections are even worse, having $username = $_POST['username'] and then doing a SQL line "SELECT * FROM users WHERE username='$username'; would allow someone to inject SQL into your database and gain full access to the DB simply by putting '; OR '' into the username box.

The above depends on if your using a PCI complient software package, or like us, you have a skilled programmer in house then you need to go through every line of code until your happy you have no holes :( (just finished totally re-writing our system as it was written by a company that no longer trades)