On This Page
On This Page

As a partner platform to WePay, follow this Security Certification to protect your users and their data. We’ll cover best practices to help protect your platform, in addition to laying out what is required to meet various levels of PCI complaince depending on what product you implement.

Definitions

 

Abbreviation Full Form Definition
HTTPS HTTP Over SSL or Hypertext Transfer Protocol Secure A variant of the standard web transfer protocol (HTTP) that adds a layer of security on the data in transit through a secure socket layer (SSL) or transport layer security (TLS) protocol connection.
HSTS HTTP Strict Transport Security A web security feature that helps to protect websites against protocol downgrade attacks and cookie hijacking.
OWASP Open Web Application Security Project An open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted.
DMARC Domain-based Message Authentication, Reporting & Conformance An email authentication, policy, and reporting protocol.
PCI Payment Card Industry The full spectrum of commerce which accepts debit, credit, or any other form of payment card during transactions.
PCI SSC Payment Card Industry Security Standards Council The regulatory body which maintains and enforces PCI security standards.
PCI DSS Payment Card Industry Data Security Standard A set of security standards designed to ensure that ALL parties which accept, process, store, or transmit credit card information maintain a secure environment.
SAQ Self-Assessment Questionnaire Validation tools intended to assist merchants and service providers report the results of their PCI DSS self-assessment.
QSA Qualified Security Assessor Independent security organizations that have been qualified by the PCI SSC to validate an entity’s adherence to PCI DSS.

Security Best Practices

 

By integrating with the WePay API, you’re reducing the scope of security and compliance requirements that your application must adhere to. That said, as an application that handles sensitive and private data, you must take extra care to ensure the privacy and security of your application, your users, and your users’ data. Read our recommendations below to help architect your integration with WePay.

The following list applies to most card-not-present integrations, but you should expand and customize these requirements based on the specifics of your application.

Authenticate users and protect their credentials

If your application provides access to sensitive financial information (e.g. payment history), you must authenticate users to make sure that sensitive information is not accessed by a third party. Your authentication system must be robust:

  • Require long passwords (at least 8 characters) with a mix of alpha-numeric characters to prevent password guessing attacks
  • Never store plain text passwords in your database
  • Use one-way hash functions (e.g. bcrypt) to protect passwords
  • Make sure that only a limited number of employees have access to the database that stores users’ credentials (i.e. passwords, WePay access tokens, etc.)

Use HTTPS and HSTS

The “plain” HTTP protocol is vulnerable to:

  • Session hijacking by listening to the traffic and extracting the session cookie (e.g. by a person sitting next to your user in the coffee-shop).
  • Man-in-the-middle attacks. For example, an attacker with access to your ISP can inject malicious content into your website and run rogue JavaScript code from your domain.

By using HTTPS and HSTS you can ensure that the network connections between your users and your servers are encrypted and protected. For this reason, more sophisticated users tend to trust HTTPS protected sites more than non-HTTPS sites.

Protect your production systems

  • Require strong passwords and 2-factor authentication to access your production system.
  • Change any default passwords on any internal or external services used by your application.
  • Install a firewall and limit the open ports to the ones required by your application.
  • If you’re hosting in a shared environment, you must consider the protection of data on the network. Encrypting data in transit using strong version of TLS on internal shared environment provides protection against Man-In-The-Middle type attacks. Install the latest patches and updates to ensure that all known vulnerabilities in the system software are patched.
  • Install the latest patches and updates to ensure that all known vulnerabilities in the system software are patched.
  • Install extensive logging and perform regular automated and manual audits to detect any suspicious activities.

Protect API Secrets

An access_token is a unique string of letters and numbers that you pass with every API call so WePay knows that you have the authorization to make that call.

Access_tokens are private and should neither be passed in the URL as part of HTTP Get Request nor revealed to any third-party. Remember, WePay Support will never ask you to provide your access token.

Setup a secure development process

A secure development process is critical to ensuring your application security:

  • Code reviews
  • Extensive testing
  • Utilizing well known frameworks
  • Training your developers

You can learn more about these and other ways to protect your application by visiting The Open Web Application Security Project (OWASP) website.

Configure automated vulnerability scans

Consider configuring at least weekly automated vulnerability scans from a PCI-certified vendor. While automated scans are limited in the vulnerabilities they can detect, they can still catch bugs that slipped past other protection barriers.

Email Security

DMARC is an email security standard that provides the receiver a mechanism to verify the source of an email.

Define and document your security policies and procedures

Your system security is only as strong as its weakest link. To get a complete view of your systems and processes, internally define and document your security policies and procedures, and make sure that you adhere to them. As your application and business change, you should update these procedures. Carefully consider each change and its impact on your system security and compliance.

 

WePay takes security very seriously. We’re happy to answer questions or discuss any security concerns you may have. Contact our security team at security@wepay.com.

PCI DSS Requirements

 

All WePay platforms need to be compliant with PCI DSS. The PCI DSS that are applicable depend on how a platform integrates with WePay. These requirements supplement the ongoing work that WePay does on our systems everyday to maintain the highest possible level of PCI compliance as your payments service provider.

  • Every partner needs to be PCI compliant, even if you are using iFrame/embedded or hosted checkouts.
  • In most cases, being PCI compliant means filling out an SAQ.
  • Partners using iFrame checkout will generally qualify for the simpler SAQ-A.
  • Partners using custom checkout (tokenization) will generally need to fill out the new SAQ-A-EP and perform quarterly scans.
  • WePay will continue to look for compliant ways to offer the benefits of tokenization without requiring partners to complete the SAQ-A-EP.

Who Must Be PCI Compliant

Compliance requirements are determined by your transaction level and the nature of your integration with WePay.

Transaction Level: Number of transactions processed every year. These levels are set by the PCI SSC.
Integration: How you interact with Wepay (and thus card data) determines the specific SAQ that you must complete.

Steps To PCI Compliance

1. Identify Your Transaction Level.


PCI has four levels of compliance. The level you need will depend on the number of transactions that are processed each year. The table below is a simplified set of requirements.

Note

The transactions/year counts are for Visa OR Mastercard, not the two combined

Level Transactions/year Requirements
Level 1 More than 6M, regardless of acceptance channel
Level 2 1M-6M, regardless of acceptance channel
Level 3 20K-1M eCommerce transactions
Level 4 Less than 20K eCommerce transactions; and/or up to 1M transactions regardless of acceptance channel

If you need help identifying your transaction level, please reach out to your relationship executive or WePay Support.

2. Identify the appropriate SAQ based on your integration with WePay.


Integration Requirements Notes
Checkout or Preapproval Iframes In these integrations, all of the credit card data is managed on WePay-served pages via the iframes.
Custom Checkout via WePay Tokenization library In this integration, credit card data is collected on a webpage that you serve, and then use WePay’s javascript library to send the values directly to WePay.

Quarterly network scans are required even if you are only level 4.
Custom Checkout via server to server calls
  • SAQ-D
    • Quarterly network scans
    • Annual penetration testing
 A small number of platforms collect credit card information directly and then passing it on to WePay in a web call rather than through the JS (e.g. via /credit_card/create).

This integration requires certification from WePay.

If you need help identifying your integration components, please reach out to your Technical Account Manager or api@wepay.com.

Why the extra work for tokenization?


The PCI council believes that the risk of attack is higher for a custom UX checkout than for an iFrame checkout. They specifically highlight that attacks on custom UX integrations can be much harder for users to notice, and thus impact many more people, than a compromise involving iFrames.

3. Keep your documentation current and ready to provide at WePay’s request.


Keep all PCI DSS certification documents on file, such as SAQs, quarterly network scans, etc. Provide documents to WePay upon request, which may be as often as once a year, or upon expiration.

Last Updated: July 19, 2019