• No results found

Best Practice Guide. Corporate Gateway. V2.4 December Use this guide to:

N/A
N/A
Protected

Academic year: 2021

Share "Best Practice Guide. Corporate Gateway. V2.4 December Use this guide to:"

Copied!
31
0
0

Loading.... (view fulltext now)

Full text

(1)

Corporate Gateway

Best Practice Guide

V2.4 December 2015

Use this guide to:

Integrate with Worldpay as quickly and smoothly as possible Get the best performance you can from our payment systems

(2)

Best Practice Guide >Contents

Contents

1 Introduction

4

1.1 Who is this guide for?

4

1.1.1 Skills and knowledge

4

1.2 More help?

4

1.3 Legal

4

2 Worldpay DTD

6

2.1 More information

6

3 Valid XML

7

3.1 More information

7

4 Order notifications and inquiries

8

4.1 More information

8

5 Order modifications

9

5.1 More information

9

6 Support for iframes

10

6.1 Hosted Payment Pages

10

6.1.1 More information

10

6.2 Standard payment pages

10

6.2.1 More information

11

7 MasterCard and Maestro authorisations

12

7.1 Authorisations defined by MasterCard or Maestro as ‘final authorisations’

12

7.1.1 The ‘final authorisations’ classification

12

7.2 Authorisations defined by MasterCard or Maestro as ‘pre-authorisations’

12

7.2.1 The ‘pre-authorisations’ classification

12

7.2.2 Changes to Worldpay systems

13

7.3 Recommendation

13

8 Pay as Order

14

8.1 More information

14

9 HTTP timeout interval

15

9.1 More information

15

10 SSL certificates

16

10.1 More information

16

(3)

Best Practice Guide >Contents

11 Firewalls

17

11.1 More information

17

12 Send messages to fully qualified domains

18

12.1 More information

18

13 Cookies

19

13.1 More information

19

14 Browser and device testing

20

14.1 More information

20

15 Software versions

22

15.1 More information

22

16 Worldpay domain

23

16.1 More information

23

17 Avoiding a 401 Security Violation Error

24

17.1 More information

24

18 VISA and MCC 6012 customers

25

18.1 More information

25

19 Information security

26

19.1 Keeping systems up to date

26

19.2 Malware

26

19.3 Securing wireless networks

27

19.4 Information and password security

27

19.5 Managing access

28

19.6 Social engineering

28

19.6.1 How to avoid becoming a victim of social engineering

28

19.7 Incident and escalation

29

19.8 Summary

29

(4)

Best Practice Guide >1  Introduction 4

1 Introduction

We’ve created this Best Practice Guide to help you integrate with Worldpay as smoothly and as quickly as possible.

Check this guide for high-level technical guidance on everything from XML parsing to firewalls before building, testing or upgrading your integration. You should use this guide alongside our XML integration guides and other technical guides.

1.1 Who is this guide for?

This is a technical guide, aimed at:

System integrators and testers

Other technical roles, including managers, who are helping you with your integration

1.1.1 Skills and knowledge

To carry out the tasks described in this guide, you will need: XML programming skills

A knowledge of HTTPS

Some knowledge of how our payment services work

1.2 More help?

For more information about our products and services, including payment methods: See our website athttp://www.worldpay.com

Talk to your Relationship Manager

For our integration and other technical guides seehttp://www.worldpay.com/support/gg/

To contact Corporate Support:

Email:corporatesupport@worldpay.com

Phone: +44 (0)208 185 0600

1.3 Legal

©Worldpay 2015. All rights reserved.

This document and its content are proprietary to Worldpay and may not be reproduced, published or resold. The information is provided on an “AS IS” basis for information purposes only and Worldpay makes no warranties of any kind including in relation to the content or suitability. Terms and Conditions apply to all our services.

Worldpay (UK) Limited (Company No: 07316500/ FCA No: 530923), Worldpay Limited (Company No: 03424752 / FCA No: 504504), Worldpay AP Limited (Company No: 5593466 / FCA No: 502597). Registered

(5)

Best Practice Guide >1  Introduction 5

Office: The Walbrook Building, 25 Walbrook, London EC4N 8AF and authorised by the Financial Conduct Authority under the Payment Service Regulations 2009 for the provision of payment services. Worldpay (UK) Limited is authorised and regulated by the Financial Conduct Authority for consumer credit activities. Worldpay, the logo and any associated brand names are all trade marks of the Worldpay group of

(6)

Best Practice Guide >2  Worldpay DTD 6

2 Worldpay DTD

The Worldpay DTD gives you all the XML elements you need for communicating with our payment service and third party processors.

You should store the DTD on your own systems rather than calling up the DTD from Worldpay. Storing the DTD locally reduces network traffic, and speeds up the transaction process.

Make sure you update your copy of the DTD regularly too, as we do make changes to the elements from time to time.

2.1 More information

To get the latest version of the DTD contact the Corporate Support Manager.

To find out more about the Worldpay DTD, see either the XML Direct Integration Guide or the XML Redirect Integration Guide on our support site:

http://support.worldpay.com/support/gg/index.php?c=WW

(7)

Best Practice Guide >3  Valid XML 7

3 Valid XML

If there’s a problem with your XML, our system won’t accept your messages. Check that the XML your system creates is valid. Your messages can’t be larger than 4k and must conform to the Worldpay DTD. To avoid errors, make sure you use industry-standard tools to test the validity of your XML.

Broadly speaking, your XML is valid if:

Every start tag ( <exampletag> ) has a matching end tag ( </exampletag> ) Elements don’t overlap

There’s only one root element ( <paymentService> )

You’ve presented any attribute values within quotes ( exampleattribute value=”23” ) Elements don’t have two attributes with the same name.

There are no comments or processing instructions within your XML tags.

You don’t have any unescaped  <  or  & signs in the element or attribute’s character data It references the Worldpay DTD

3.1 More information

For more detailed information about creating valid XML messages - including example code - see either the XML Direct Integration Guide or the XML Redirect Integration Guide on our support site:

http://support.worldpay.com/support/gg/index.php?c=WW

There are a number of tools you can use to check and validate XML. For example, see

(8)

Best Practice Guide >4  Order notifications and inquiries 8

4 Order notifications and inquiries

We recommend that you use order notifications instead of inquiries to find out about changes to your transactions.

If you’re set up for notifications, we do all the work - notifications are sent to you automatically when the status of a transaction changes. If you use inquiries, you have to ask us about the status of a particular transaction.

If you still want to use inquires you could see a negative response for an order that actually exists during busy periods. A good rule - although not guaranteed - is to wait five minutes to allow data to reach our central system before sending an inquiry. 

This is down to slight replication delays, as our shopper cells replicate your inquiry request to our central cell.

4.1 More information

To learn more about the advantages of notifications over inquiries, contact your Relationship Manager. To find out more about notifications, and how they work, see the Order Notifications – Reporting Payment Statuses Guide on our support site.

For more information about inquiries, see the Order Modifications and Order Inquiries Guide. You can find our support site at:

(9)

Best Practice Guide >5  Order modifications 9

5 Order modifications

We recommend that you use order modifications to capture, cancel or refund orders. Trying to perform these tasks manually through the Merchant Interface can take time – particularly if there are a large number of orders you want to modify.

Using order modifications in conjunction with notifications or inquiries allows you to respond more rapidly to information about your orders. You can even cancel batch orders – which may contain hundreds of orders – with a batch modification message.

5.1 More information

To learn more about order modifications, see the Order Modifications and Order Inquiries Guide. You can find the guide on our support site at:

(10)

Best Practice Guide >6  Support for iframes 10

6 Support for iframes

For the XML Redirect model, we provide different levels of support for iframes depending on the type of payment pages you use.

We offer two types of payment pages: Hosted Payment Pages Standard payment pages

6.1 Hosted Payment Pages

The Hosted Payment Pages enable your customers to make payments from a variety of devices including smartphones, tablets and desktops. The Hosted Payment Pages automatically optimise payment page content to fit the device used.

We provide three ways to integrate the Hosted Payment Pages. If you choose an iframe integration, you can display the Hosted Payment Pages in an iframe within your website.

The following table shows the ways you can integrate the Hosted Payment Pages and the corresponding iframe support.

Integration type

Description

iframe support

Full-page redirect The Hosted Payment Pages are displayed full page in a browser.

We use an iframe to display 3D Secure. All other Hosted Payment Page content is displayed full page in the browser.

iframe The Hosted Payment Pages are

displayed in an iframe within your website.

All Hosted Payment Page content, including 3D Secure content, is displayed in an iframe within your website.

Lightbox The Hosted Payment Pages are

shown in a lightbox that is displayed over a page in your website.

We use an iframe to display 3D Secure within the lightbox. All other Hosted Payment Page content is displayed in the lightbox.

Currently, the iframe and lightbox versions of the Hosted Payment Pages support card payments only. Alternative payment methods are not supported.

The iframe and lightbox versions require a more advanced integration.

6.1.1 More information

For more information, see the Hosted Payment Pages Guide on our support site:

http://support.worldpay.com/support/gg/index.php?c=WW

6.2 Standard payment pages

We don’t support the use of iframes for our standard payment pages. The standard payment pages are typically displayed full page in a desktop browser. For best results, we recommend that you use the embedded Hosted Payment Pages instead.

(11)

Best Practice Guide >6  Support for iframes 11

We understand that some customers may want to use iframes with the standard payment pages anyway. We use 1stparty cookies to maintain payment sessions. However, some browsers treat our 1stparty cookies as 3rdparty cookies when they’re presented in an iframe, which can lead to failed payments.

If you do decide to use an iframe to host our payment pages then the security liability is yours. Your hosting page must not interfere with any of the contents or events that take place on our payment pages.

You should also tell our Corporate Support team if you want to use iframes.

6.2.1 More information

To tell us that you’re going to use iframes with the standard payment pages, contact

corporatesupport@worldpay.com

You should also talk to your Relationship Manager.

For a brief overview of PCI DSS compliance, and your responsibilities in keeping your site secure, see the XML Redirect Integration Guide on the support site:

http://support.worldpay.com/support/gg/index.php?c=WW

For detailed information about PCI DSS compliance, see the official PCI website at:

(12)

Best Practice Guide >7  MasterCard and Maestro authorisations 12

7 MasterCard and Maestro authorisations

In an effort to improve the management of open to buy limits on their cards, MasterCard and Maestro have introduced the ability to flag non-zero value authorisations as either a ‘pre-authorisation’ (pre-auth) or a final authorisation.

To align with this change, MasterCard and Maestro have introduced a new fee structure for pre- and final authorisations which applies to merchants in the European region. Worldpay have absorbed any additional fees your authorisations have generated to date and will only start to pass on fees incurred from January 2016.

7.1 Authorisations defined by MasterCard or Maestro as ‘final

authorisations’

An authorisation should be coded 'final' if the goods or services can be dispatched and cleared within four working days of the original authorisation request, for the full amount.

7.1.1 The ‘final authorisations’ classification

The ‘final authorisations’ classification should meet all of the following criteria:

An authorisation on a transaction (greater than zero) for the final or known amount.

The transaction may no longer be cancelled after the authorisation is requested other than by performing a refund. This excludes any technical failures before the transaction completes. The transaction must be cleared (sent to the card processor) within four days of the authorisation date.

7.2 Authorisations defined by MasterCard or Maestro as

‘pre-authorisations’

Pre-authorisations are widely used by industries in the travel and entertainment sector such as hotels, car rental and travel agents. An authorisation should be coded as a 'pre-authorisation' any time that you are holding funds in a cardholder's account for longer than four days, or where you are estimating the final amount of the transaction.

7.2.1 The ‘pre-authorisations’ classification

The ‘pre-authorisations’ classification should meet all of the following criteria: An authorisation for an 'estimated' amount (greater than zero).

Where a transaction isn't cleared within four working days of the original authorisation date. Where a payment guarantee period is required for up to 30 days.

Where the cardholder will be offered the option to pay by an alternate means at completion. Pre-authorisations have to be reversed within 24 hours of a transaction cancellation.

(13)

Best Practice Guide >7  MasterCard and Maestro authorisations 13

7.2.2 Changes to Worldpay systems

We have enhanced our systems, so that any authorisation you submit to us which has no finality coding (final or pre-authorisation), will be flagged by us as a final authorisation when submitted to MasterCard or Maestro. If, however, your authorisations meet the pre-authorisation criteria, they should be coded accordingly by your own business logic. Please refer to the relevant technical documentation for guidance on how this is achieved. Alternatively if you cannot make the change to your XML submission requests, you can arrange for all authorisations to be flagged as 'pre' at Merchant Code level by us through your

Relationship Manager.

Authorisations not coded correctly (either 'final' or 'pre') will incur a financial penalty, as a result of integrity fees introduced by MasterCard. Please contact your acquirer for further detail on the fee structure that applies.

7.3 Recommendation

In light of these changes, Worldpay recommends that you review your processing model and how these requirements will impact your business practices.

For code examples of XML authorisation requests incorporating these changes, see either theXML Direct Integration Guideor theXML Redirect Integration Guide.

(14)

Best Practice Guide >8  Pay as Order 14

8 Pay as Order

Pay as Order is a PCI compliant, XML based service for taking recurring payments, such as monthly subscriptions. You can also use Pay as Order to create a fast checkout for returning shoppers, and to take pre-orders for goods that aren’t yet available.

Some customers like to authenticate the identity of potential subscribers first, through their card details, before going on to take their first Pay as Order payment.

However, if you immediately follow an initial ‘auth’ transaction – one in which no money is taken – with a Pay as Order payment, processing delays can occur. To avoid any problems, you should wait for up to twenty minutes after the ‘auth’ transaction has been processed before taking the first payment.

8.1 More information

For more information about ‘auth’ transactions and Pay as Order payments talk to your Corporate Support Manager.

For detailed information about our Pay as Order recurring payments service, see the Recurring Payments (Pay as Order) Guide on the support site:

(15)

Best Practice Guide >9  HTTP timeout interval 15

9 HTTP timeout interval

The HTTP timeout interval is the length of time you choose to keep the HTTP connection open with us, while waiting for a response to an order.

There’s no set answer here - you’ll need to think about the timeout interval that’s right for your business. Our merchants tend to go for a timeout interval between 10 and 60 seconds.

If the interval is quite short – less than 5 seconds say – then you could see an increase in the number of orders that get timed out from time to time. This can happen if our systems are very busy or the issuer response is slow. To help mitigate the effect of timeouts, we suggest showing a pending page to the shopper, and using our order notifications service to identify the payment outcome more quickly.

9.1 More information

For more advice on the HTTP timeout interval that’s right for you, talk to your Implementation Manager. To find out more about notifications, and how they work, see the Order Notifications – Reporting Payment Statuses Guide on our support site at:

(16)

Best Practice Guide >10  SSL certificates 16

10 SSL certificates

You should only store the root SSL certificate, which you can get from the Verisign website. Always follow the trusted chain of certificates – from the root to the intermediate to the client certificate – rather than store the intermediate certificates, as it’s possible for these certificates to change, breaking the chain. You should also avoid any other non-standard practices, such as parsing certificates for specific text. While we’ll endeavour to tell you when you need to update the root certificate, you should follow Verisign’s guidance about keeping the root certificate up to date.

10.1 More information

To update your root certificate, and to find out more about digital certificates in general, see the Verisign website at: https://www.verisign.co.uk/

For more information about connecting to us with HTTPS, see the XML Direct Integration Guide and the XML Redirect Integration Guide on our support site:

(17)

Best Practice Guide >11  Firewalls 17

11 Firewalls

We don’t recommend putting firewall restrictions around our communications with you. However, if your security policy means you need to use a firewall, make sure that you let through our full range of IP addresses, rather than specific IP addresses.

Letting some IP addresses through and not others can lead to interruptions in communication, as we sometimes move to other IP addresses in our range to communicate with you.

Your firewall needs to let through the following IP address range:

195.35.90.0/23 (the range of IP addresses from 195.35.90.0 to 195.35.91.255)

11.1 More information

To find out more about how firewalls can affect our IP communications with you, talk to your Relationship Manager.

For more information about connecting to us with HTTPS, see the XML Direct Integration Guide and the XML Redirect Integration Guide. If you want to know more about registering and managing IP address ranges, see the Merchant Interface Guide. All three guides are available from our support site:

(18)

Best Practice Guide >12  Send messages to fully qualified domains 18

12 Send messages to fully qualified domains

When you send messages, always use fully qualified domain names instead of IP addresses.

Don’t send messages to specific IP addresses, as these can change, leading to a break in communications – sometimes we need to move to different IP addresses in our range to communicate with you.

Avoid using addresses like this:http://1.2.3.4/path

Use addresses like this:http://somedomain.com/path

12.1 More information

To find out more about why you should use URLs rather than IP addresses in your messages to us, talk to your Relationship Manager.

For more information about creating and submitting XML messages, see the XML Direct Integration Guide and the XML Redirect Integration Guide on our support site:

(19)

Best Practice Guide >13  Cookies 19

13 Cookies

We use cookies to handle the status of transactions and for some of our security features.

You need to fully process all of the cookie names and values that we present to you, in line with standard cookie management practices. If you don’t, your integration with us may not work reliably, if at all. You should never hard code any aspect of cookie management – for example, limiting handling to specific cookie names. Don’t make any assumptions about the format of a cookie value, as our use of cookies may change from time to time to support new features or enhance security.

13.1 More information

If you have any questions or concerns about cookie handling, talk to your Corporate Support Manager. For specific guidance on standard cookie management practices, see HTTP State Management Mechanism, a document produced by the IETF. You can find this document on the IETF website at:

(20)

Best Practice Guide >14  Browser and device testing 20

14 Browser and device testing

We recommend testing your integration with a range of browsers, devices and operating systems. You may also want to consider re-testing your integration on a regular basis, as new browsers and devices come onto the market.

We test our web pages on Internet Explorer 7 and above, and the last two versions of Chrome, Safari, Firefox and Opera. To reflect the continuously evolving way in which shoppers access the internet, we test tablets, smartphones and games consoles, operating a variety of OS – including Windows, Android and iOS -as well -as desktop PCs and laptops.

14.1 More information

To find out more about how we test browsers and devices, talk to your Corporate Support Manager. When testing devices, you need to consider the format of the device, the model and the OS it’s using. The following test matrix is an example only, and shouldn’t be taken as definitive guidance on what devices to test (especially as devices and OS change so frequently):

Format

Model

OS

Tablet (7") Nexus 7 (2012 edition) Android 4.2 (Jelly

Bean)

Tablet (10") Samsung Galaxy Tab 3 Android 4.2 (Jelly

Bean)

Tablet iPad version 4 iOS 7

Tablet Surface RT Windows 8

Tablet Amazon Kindle Fire Android (non-stock)

Smartphone iPhone 5 iOS 7

Smartphone Android (large screen > 700 pixels high – for example, a Nexus 5)

-Smartphone Nokia Lumia 820 Windows 8

Games console Sony PS3

-Games console Sony PS4

-Games console XBox One

-Desktop/laptop <Any windows> Windows 7

Desktop/laptop Apple Mac iOS 7

Screen x 2 (HDMI capable)

(21)

-Best Practice Guide >14  Browser and device testing 21

There are a number of websites that can give you statistical data on the popularity of different browsers. For example:

http://www.w3schools.com/browsers/browsers_stats.asp

(22)

Best Practice Guide >15  Software versions 22

15 Software versions

We keep our systems up to date with the latest versions of HTTP, Apache and Java, and we recommend that you do the same.

To avoid service issues, remember to test your integration regularly against the latest software versions.

15.1 More information

For the latest version of Java, seehttps://java.com/en/download/index.jsp

For the latest Apache software, seehttp://www.apache.org/

IETF and the W3C coordinate the development of HTTP. For more information, see: The IETF website athttp://www.ietf.org/

(23)

Best Practice Guide >16  Worldpay domain 23

16 Worldpay domain

You should only use the dtd.worldpay.com and secure.worldpay.com domains in your integration. If your integration still uses any of our older domains, you should make plans to migrate to dtd.worldpay.com and secure.worldpay.com as soon as you can.

Our older domains have entered a ‘sunset’ phase and will be phased out over time. These older domains include:

secure.edi.worldpay.com secure.ims.worldpay.com

16.1 More information

If you are planning to migrate to dtd.worldpay.com and secure.worldpay.com, or have any other questions about the use of domains in your integration, talk to your Corporate Support Manager.

You can find detailed information about Worldpay domains in the technical guides on our support site:

(24)

Best Practice Guide >17  Avoiding a 401 Security Violation Error 24

17 Avoiding a 401 Security Violation Error

If you’re getting ready to send your first test XML order request, remember to check that: You’ve set the XML Password in the Merchant Interface.

The IP address you’re sending your XML order from is registered in the Merchant Interface. If you don’t set the XML Password, or register the IP address, you’ll get a 401 Security Violation Error.

17.1 More information

To find out more about testing your integration, and avoiding errors, talk to your Corporate Support Manager.

The Merchant Interface Guide, the XML Direct Integration Guide and the XML Redirect Integration Guide are available from our support site:

(25)

Best Practice Guide >18  VISA and MCC 6012 customers 25

18 VISA and MCC 6012 customers

If you’re a customer with the MCC (Merchant Category Code) 6012, you’ll need to send us some extra information about domestic VISA payments processed in the United Kingdom.

You’ll still have to send us this information, even if you’re operating under other merchant codes as well as MCC6012. This VISA requirement came into force on 1 June 2014.

MCC 6012 covers a range of payments for financial services. Examples of this type of payment include paying off all or part of a balance on a credit card or loan, or the repayment of a mortgage.

If you’ve been assigned the code MCC 6012 you need to collect the following details about the primary recipient for each UK domestic VISA transaction:

The Account Number / Primary Account Number (PAN) The recipient’s last name (family name)

Their date of Birth (D.O.B) Their postcode

The primary recipient is the person – or organisation - that has a direct relationship with the financial institution. The primary recipient also needs to have agreed to the terms and conditions of that institution.

18.1 More information

If you have any questions or concerns about this VISA requirement, talk to your Relationship Manager. You can find more details about the extra information you need to send us in XML Direct Integration Guide and the XML Redirect Integration Guide on our support site:

(26)

Best Practice Guide >19  Information security 26

19 Information security

You can put secure practices in place to help reduce most threats to information security.

When customers interact with you, they put their trust in you to safeguard their information. It is a valuable asset which, if compromised, could seriously damage your reputation and impact you financially.

The risks and threats to your information are increasing as society becomes more and more dependent on information systems. Being aware of these threats and implementing secure practices can go a long way to mitigating most threats.

The sections in this chapter detail some of the more common threats as well as the practices that you can adopt to help protect against them.

19.1 Keeping systems up to date

Many security compromises occur through vulnerabilities in IT systems that have had patches provided by the supplier. Ensure you keep your systems up to date.

Regularly download and install patches for your operating systems and software. Many operating systems and software products can be configured to automatically update patches, so take advantage of this to lessen the workload.

Ensure you download patches from a trusted source, such as the manufacturer of the software. Many vendors, such as those of operating systems like Microsoft Windows, have built-in update functionality.

Where possible, test patches and updates on a test system to ensure your systems will operate as expected once they are installed.

Regularly check the Worldpay support portal for any updates or security advisories for the Worldpay gateway

19.2 Malware

Malware is malicious software that is specifically designed to disrupt or damage a computer system. Viruses, trojans and worms are examples of malware.

Malware can be used to:

Steal passwords and personal details.

Disclose information to unauthorised individuals, or release it into the public domain. Corrupt data by embedding incorrect information.

Stop you working – even a small problem can mean that your computer has to be cleaned or rebuilt. On a bigger scale, malware could disrupt the whole of your company network. Your devices can become infected in the following ways:

Email attachments, malicious websites and Internet downloads can all contain malware that will infect your PC.

USBs and external storage devices may contain malware and, once connected, can infect your PC and, potentially, the whole network.

If you download and install software, such as mobile apps on smartphones and tablets, from untrustworthy sources. They can often contain malware that will infect your systems and devices.

(27)

Best Practice Guide >19  Information security 27

Here are some tips to help you to avoid infection:

Use the Internet and email systems responsibly. Try to only visit sites that are appropriate for your business.

Don’t open any email attachments that you aren’t expecting or that come from unknown sources. Never download software or plug-ins without checking with your IT support partners or personnel. Ensure you run antivirus software on your systems and keep it up to date.

Free versions of antivirus software often have limited protection measures. As such, we recommend you install a commercial antivirus solution. Seek advice from your IT support partners or personnel for further guidance.

Keep your personal computer and mobile devices updated with the latest security patches. Don’t connect any untrusted USBs or DVDs to your computer.

19.3 Securing wireless networks

Wi-Fi networks are more prevalent than ever, with more businesses using wireless to enable seamless connectivity to their systems for employees and customers. However, poorly configured Wi-Fi can allow malicious attackers access into your networks and systems.

We recommend that if you run Wi-Fi:

Secure communications using WPA2 encryption.

Set a strong password for this encryption and keep this password secure so it is not disclosed to unauthorised parties.

Change the administrative password for logging into the Wi-Fi router from the default one provided.

Consult your wireless router documentation and supplier for advice, as necessary.

19.4 Information and password security

A strong password is one of the best ways to keep a system secure.

Ensure passwords are at least eight characters long and a complex mixture of uppercase, lowercase, numeric and special characters (e.g. !$@& ). Other tips include:

Makeyour password memorable for you but hard for someone else to guess.

Don’tshare your password with anyone, not even your manager or IT Support.

Usea password that contains eight or more characters.

Don’twrite down your password.

Makeyour password complex by using uppercase, lowercase, numbers and special characters.

Don’tuse easily guessed passwords – for example, password, username or dictionary words.

Changeyour password on a regular basis.

Don’tuse the same password for all of your accounts. If one is compromised, they could all be hacked.

Contact your IT support or administration teams if you suspect your password is known to others. They can change it for you.

(28)

Best Practice Guide >19  Information security 28

Microsoft Password Checker Microsoft Telepathwords

19.5 Managing access

It is important that access to payment systems is strictly controlled. A few key things to bear in mind are: Only grant access to those with a genuine business need.

Limit access rights to those who need to do the job. Don’t give more access than is needed. Only use privileged accounts (for example, system administration accounts) sparingly. Attacks (such as viruses) upon a privileged account will run with the same privileged access rights. Stop them in their tracks by using accounts with limited access for day-to-day tasks.

Remove access as soon as it’s no longer needed and regularly review access rights in case anything excessive is still in place.

19.6 Social engineering

Social engineering refers to the psychological manipulation of people to persuade them to perform specific actions or give out confidential information. Social engineering targets an individual and not the IT systems, making it a particularly worrying threat, as even the most robust security measures cannot guard against it. To gain your trust, social engineers may:

Act like they already know you, your colleagues or boss.

Use your business language so they seem to fit and sound legitimate. Seek access to your premises by being aggressive or authoritative. Use threats of authority to scare you into disclosing information. Request urgent assistance with a seemingly desperate situation. Pose as a 'friend' on social networks to get confidential information.

19.6.1 How to avoid becoming a victim of social engineering

To avoid becoming a victim of social engineering:

Be suspicious of unsolicited phone calls, visits or email messages from individuals asking about employees or other internal information. Try to verify his or her identity directly with the company.

Don’t provide company, customer or personal information unless you are certain of a person’s authority to have that information.

Don’t reveal personal or financial information in an email and don’t respond to unexpected and unrecognised email solicitations for this information. This includes opening attachments or following links sent in emails.

Don’t let anyone follow you into secure areas in your premises without ensuring they are authorised to do so – make sure you check the identity of anyone asking to be let in.

(29)

Best Practice Guide >19  Information security 29

19.7 Incident and escalation

It is important that you notify Worldpay immediately if you become aware of, or suspect, any security breach relating to transaction data.

While identifying and resolving the cause of a security breach quickly is of the utmost importance, it is important to do so in line with payment card scheme rules, including the procurement of forensic reports from PCI-certified third parties.

It is strongly recommended that you seek guidance from Worldpay. Failure to follow such rules may result in further expense in meeting scheme expectations at a later date.

19.8 Summary

You can go a long way to protecting your information by being aware of threats to it, and knowing which practices to adopt.

Remember:

Guard againstindividuals trying to obtain personal or sensitive information, either face-to-face or by phone or email. Think carefully about what you post on social media.

Be cautiousof suspicious emails. Do not open attachments or click any links. Delete the emails without opening them. Do not forward them on.

Make sureyou use a strong password and always keep it secret. Limit access to no more than that needed to do the job.

Be awareof ways that malware could be installed, such as plugging in unknown USB devices or downloading programs from websites.

Ensureyour computer’s security is up-to-date, including security patches and antivirus programs.

Report anything suspicious. If you do discover a security compromise, notify Worldpay. We can provide guidance on scheme rules.

(30)

Best Practice Guide >Appendix A: Changes to the guide 30

Appendix A: Changes to the guide

Revision

Release

date

Changes

2.4 December

2015

Added section about MasterCard and Maestro pre-authorisation and final authorisation.

2.3 November

2015

Expanded information about support for iframes. Transferred to Madcap Flare.

2.2 October

2015

Added information about security guidance.

2.1 September

2015

ExpandedSupport for iframeson page 10to include information about the use of iframes with different types of payment pages.

2.0 January

2015

AddedOrder modificationson page 9andHTTP timeout intervalon page 15

1.1 November

2014

Updated contact information.

1.0 October

2014

(31)

Best Practice Guide >Contact us 31

To find out more, get in touch with your Relationship Manager or: Emailcorporatesupport@worldpay.com

© Worldpay 2015. All rights reserved. 

References

Related documents

Thus, the social success of future primary school teachers in the teaching process of the University is a holistic system, content and semantic unity components such as

1500, and fix the provide broadcasting interval to 50 phases. We compare the energy balancing scheme when the remedy coverage requirement is 50% and 70% for all sensors, with the

The aims for this modified replication study were to: (a) investigate the effectiveness of the Music Attention Control Training (MACT) protocol on different types of

If you want to exclude certain operating system settings when the destination computer is running Windows Vista, you will need to create and modify a Config.xml

String, see Appendix F: NAB Transact Gateway Response Codes N, LEN = 3 Eg: “000” No &lt;statusDescription&gt; Description: Format type: Format constraints: Value:

ii) Would not result in increased negative impact on natural heritage, cultural heritage or recreational values of the conservation reserve, or on existing authorized land uses;.

(2016) undertook a qualitative study in New Zealand involving 14 people with intellectual disabilities with type 1 and 2 diabetes and n=17 support workers focusing on

Recall that in Section 3.2 we showed that using a crediting rate equal to the short rate plus a fixed margin gives a fixed valuation, independent of the yield curve or any other