Phishing: Fake emails or chats requesting wire transfer
We are aware of phishing attempts via fake emails and live chats, which request the receiver to t...
We are aware of phishing attempts via fake emails and live chats, which request the receiver to transfer an amount to an Italian or a German bank account. The communications appear to be coming from an eBay seller and are requesting a payment through "Adyen Escrow". These emails or online requests are a form of phishing. The sender is requesting to wire funds to a bank account that is not related to Adyen.
The subject of the phishing email is: "Your Adyen purchase request is ready."
The email or communication mentions the following:
eBay seller has requested the payment through Adyen Escrow and we offered to cover all the risks for you and the seller.
It is our responsibility to inform Buyers about our Sellers. You are dealing with a verified Adyen seller, protected by our Adyen services such as insurance and dispute resolution, and you may buy and sell with confidence in all eBay transactions with this seller.
The email is sent from firstname.lastname@example.org, email@example.com, or a similar address.
The mentioned bank account IBAN is IT45O0760101400001042352987, DE49100110012625550603, or a similar variant.
The email address and the IBAN are both not related to Adyen.
In case you receive other phishing attempts, please forward the details to firstname.lastname@example.org.
Internet Explorer Error “This page can’t be displayed”
When trying to access the Adyen Customer Area Internet Explorer displays the error message “This ...
When trying to access the Adyen Customer Area Internet Explorer displays the error message “This page can’t be displayed”.
To access to the Customer Area please switch on TLS 1.2 encryption in Internet Explorer settings
- Open Settings -> Internet Options -> Advanced -> Security.
- Set the option “Use TLS 1.2” to on.
- Close the dialog by clicking “Apply” and then “OK”.
- Reload the Adyen Customer Area.
TLS 1.2 encryption is required for access to the customer area to safeguard payment and customer data.
How can I safely make use of third-party services on my payments page?
There are safer ways to provide these facilities, which your security team should evaluate before and after any implementation:
• Embedding external content (such as chat tools or even limited functionality page analytics) in iFrames
• Embedding localized payments pages that contain static content in your HPP skin or in your CSE or Checkout page environment
To track shoppers through the flow (for example using Google Analytics) without embedding web analytics code in your HPP skin, use the merchantReturnData field.
Any third-party hosted service or resource that is not securely embedded in an iFrame, or not entirely stored in the HPP skin, must be from a listed PCI DSS Level 1 or 2 Service Provider, and this provider must be listed in your current SAQ.
If you must embed third-party resources in your payments page, you can also move to a Checkout SDK or Checkout API integration with secure fields. This uses sensitive fields in iFrames to protect payment data.
Can I use third-party resources on my payments page?
Externally hosted resources can be compromised or even be designed to be hostile to your business. If they are included on your payments page, attackers can compromise shopper information including cardholder data. Adyen notes that there are a number of high profile cases in the news, impacting millions of shoppers in some cases.
Using external resources without the right compliance documentation means that your PCI DSS scope reduction is no longer applicable for HPP, CSE or certain Checkout integrations. PCI DSS does not allow third-party services to be used in the payment process unless they are a certified PCI DSS Level 1 or 2 Service Provider. Adyen also requires all third-party service providers to be reported in your SAQ and to be registered with Visa.
Things to look out for on your payments page:
• Analytics tools
• Automatic translation services
• Chat tools
• Tag managers
• Fonts provided from other systems or third parties
You can use these services elsewhere on your site and shopping cart, but not on your payments page due to the risks to cardholder data.
There are some safer ways to provide some of these facilities. Read more on that here.
The responsibility of maintaining compliance and security of your payments page remains with you.
How do I report a possible security issue to Adyen?
We welcome reports of possible vulnerabilities or issues as part of our responsible disclosure pr...
We welcome reports of possible vulnerabilities or issues as part of our responsible disclosure program. At this point in time we do not run a bug bounty program.
To report a security issue, contact Support.
If the nature of the security issue is sensitive, please provide the following:
- Describe the issue to help us determine priority.
- Provide your PGP public key.
- Request contact from the Adyen security team.
The security team will communicate directly with you using PGP encrypted emails.
What version(s) of TLS does Adyen support?
All merchant integrations with Adyen must use TLS 1.2. The PCI Security Standards Council (PCI SS...
All merchant integrations with Adyen must use TLS 1.2.
The PCI Security Standards Council (PCI SSC) no longer accepts early TLS (TLS 1.0) as a secure communication protocol for transmitting payment card data, and we have therefore disabled older versions of TLS on our platform.
Note: Integrations such as Java 7 or .NET 4.0 don’t support TLS 1.2 using default configurations. Integrations using Java 6 and below, .NET 3.5 and below, Python 2.7.8 and below, Ruby 1.9.3 and below, OpenSSL 1.0.0 and below will all be difficult or impossible to configure to use TLS 1.2, and significant migration effort may be required by the merchant. Additionally, shoppers using old browsers (IE8 and IE9 as well as Android versions 4.4 and below) that only support early TLS in combination with Hosted Payment Pages (HPP) and Client Side Encryption (CSE) will not be able to connect to these services.
TLS 1.0 must not be used to protect payments data or payments pages after June 30th 2018.
Do merchants need to phase out early TLS on their shopper-facing websites too?
Yes. Use of TLS 1.0 to protect payments data or payments pages is not PCI DSS compliant after Jun...
Yes. Use of TLS 1.0 to protect payments data or payments pages is not PCI DSS compliant after June 30th 2018.
What can I do to encourage upgrades of shopper browsers in order to support TLS?
What can I do to encourage upgrades of shopper browsers in order to support modern TLS? Merchants...
What can I do to encourage upgrades of shopper browsers in order to support modern TLS?
Merchants are encouraged to check their shoppers’ browsers during the shopper interactions with their shopping cart, and suggest to shoppers to upgrade their browsers if the browsers are out-dated.