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

Transcription

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 Understand practical security measures you can take to protect your data

2 Best Practice Guide > Contents Contents 1 Introduction Who is this guide for? Skills and knowledge More help? Legal 4 2 Worldpay DTD More information 6 3 Valid XML More information 7 4 Order notifications and inquiries More information 8 5 Order modifications More information 9 6 Support for iframes Hosted Payment Pages More information Standard payment pages More information 11 7 MasterCard and Maestro authorisations Authorisations defined by MasterCard or Maestro as final authorisations The final authorisations classification Authorisations defined by MasterCard or Maestro as pre-authorisations The pre-authorisations classification Changes to Worldpay systems Recommendation 13 8 Pay as Order More information 14 9 HTTP timeout interval More information SSL certificates More information 16

3 Best Practice Guide > Contents 11 Firewalls More information Send messages to fully qualified domains More information Cookies More information Browser and device testing More information Software versions More information Worldpay domain More information Avoiding a 401 Security Violation Error More information VISA and MCC 6012 customers More information Information security Keeping systems up to date Malware Securing wireless networks Information and password security Managing access Social engineering How to avoid becoming a victim of social engineering Incident and escalation Summary 29 Appendix A: Changes to the guide 30

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 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 at Talk to your Relationship Manager For our integration and other technical guides see To contact Corporate Support: 1.3 Legal corporatesupport@worldpay.com Phone: +44 (0) Worldpay 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: / FCA No: ), Worldpay Limited (Company No: / FCA No: ), Worldpay AP Limited (Company No: / FCA No: ). 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 companies.

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: An example copy - not the full version - of the Worldpay DTD is available from

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: 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 iframe Lightbox The Hosted Payment Pages are displayed full page in a browser. The Hosted Payment Pages are displayed in an iframe within your website. 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. All other Hosted Payment Page content is displayed full page in the browser. All Hosted Payment Page content, including 3D Secure content, is displayed in an iframe within 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 More information For more information, see the Hosted Payment Pages Guide on our support site: 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 1 st party cookies to maintain payment sessions. However, some browsers treat our 1 st party cookies as 3 rd party 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 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: 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 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 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 preauthorisations 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 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 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 the XML Direct Integration Guide or the XML 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 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 More information To update your root certificate, and to find out more about digital certificates in general, see the Verisign website at: 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 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: /23 (the range of IP addresses from to ) 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 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: Use addresses like this: 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 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 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 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 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) 40" - -

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:

22 Best Practice Guide > 15 Software versions 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 More information For the latest version of Java, see For the latest Apache software, see IETF and the W3C coordinate the development of HTTP. For more information, see: The IETF website at The W3C website at

23 Best Practice Guide > 16 Worldpay domain 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 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 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 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 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 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 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 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: 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 systems responsibly. Try to only visit sites that are appropriate for your business. Don t open any 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 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 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: Make your password memorable for you but hard for someone else to guess. Use a password that contains eight or more characters. Make your password complex by using uppercase, lowercase, numbers and special characters. Change your password on a regular basis. Don t share your password with anyone, not even your manager or IT Support. Don t write down your password. Don t use easily guessed passwords for example, password, username or dictionary words. Don t use 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. The following sites provide good guidance on password strengths:

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 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 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 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 and don t respond to unexpected and unrecognised solicitations for this information. This includes opening attachments or following links sent in s. 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 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 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 against individuals trying to obtain personal or sensitive information, either face-to-face or by phone or . Think carefully about what you post on social media. Be cautious of suspicious s. Do not open attachments or click any links. Delete the s without opening them. Do not forward them on. Make sure you use a strong password and always keep it secret. Limit access to no more than that needed to do the job. Be aware of ways that malware could be installed, such as plugging in unknown USB devices or downloading programs from websites. Ensure your 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 November October September January November October 2014 Added section about MasterCard and Maestro pre-authorisation and final authorisation. Expanded information about support for iframes. Transferred to Madcap Flare. Added information about security guidance. Expanded Support for iframes on page 10 to include information about the use of iframes with different types of payment pages. Added Order modifications on page 9 and HTTP timeout interval on page 15 Updated contact information. First release of this guide.

31 Best Practice Guide > Contact us 31 To find out more, get in touch with your Relationship Manager or: Worldpay All rights reserved. Worldpay, the logo and any associated brand names are all trademarks of the Worldpay group of companies.