Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Sage Pay and PCI


John_SagePay

Recommended Posts

I thought I would put a post up about the new certified Sage Pay modules and how the PCI DSS requirements affects you as a merchant.

 

PCI DSS or Payment Card Industy Data Security Standard is a set of comprehensive requirements for enhancing payment account data security. All merchants need to prove to their merchant acquirers that the way in which they operate their business conforms to the PCI DSS standards. The PCI standards surround the aspects of Storing, Processing and/or Transmitting sensitive card data.

 

Sage Pay is audited on a yearly basis by our Qualifed Security Assessor, Trustwave. We are a Level 1 compliant Payment Service Provider and are also active members of the PCI Security Council which means we able to comment on drafts of all revisions to the DSS specification, and on any new specifications, prior to public release. This gives us the distinct advantage of being able to maintain our systems to the latest PCI specifications on an ongoing basis.

 

The level of PCI Compliance that a merchant needs to adhere to all depends on which Sage Pay module they choose to process transactions with.

 

Sage Pay Form:

 

With Sage Pay Form, the buying customer is redirected away from the merchants website and onto a Sage Pay hosted payment page. Sensitive credit card information is entered into the Sage Pay hosted page and the response that Sage Pay provide the merchant on completion of a transaction does not contain any sensitive information. The Storing, Processing and Transmission of credit card information is contained on the Sage Pay Level 1 servers. Therefore an online merchant using Sage Pay Form will need to complete a PCI Self Assessment Questionnaire (SAQ).

 

Sage Pay Server:

 

With Sage Pay Server, the buying customer can be redirected away from the merchants website and onto a Sage Pay hosted payment page very much like Sage Pay Form. There is now also the iframe option which enables a merchant to effectively keep the buying customer on their own website for the entering of credit card data. In reality, the buying customer is entering their credit card info into a Sage Pay hosted payment page which can be fully customised to look and feel like the overall payment page. This gives the buying customer a seamless checkout experience without being redirected away from the merchants website. With both Sage Pay Server methods, sensitive credit card information is entered into the Sage Pay hosted page and the response that Sage Pay provide the merchant on completion of a transaction does not contain any sensitive information. The Storing, Processing and Transmission of credit card information is contained on the Sage Pay Level 1 servers. Therefore an online merchant using Sage Pay Form will need to complete a PCI Self Assessment Questionnaire (SAQ).

 

Sage Pay Direct:

 

With Sage Pay Direct, the merchant provides the forms and logic to capture the credit card data to post to the Sage Pay servers. The buying customer stays on the merchants website and inputs their credit card data into the forms provided. With the Sage Pay Direct certified module, there is no Storing or Processing, however, there is an element of Transmission. Because of this, there will be a level of PCI that the merchant will need to undertake, this level can only be determined by a Qualifed Security Assessor like Trustwave.

 

Payment solutions where buying customers stay on the merchants website have always been viewed as more "professional", so the introduction of the Sage Pay Server iframe gives the merchant the ability to offer this "professional" solution without the PCI implications that Sage Pay Direct may bring. As mentioned, the iframe templates can be completely customised to look like it belongs to the overall website.

 

I hope this helps and if anyone has any further questions please feel free to ask.

 

Many thanks,

 

John.

Link to comment
Share on other sites

  • 1 year later...

I thought I would put a post up about the new certified Sage Pay modules and how the PCI DSS requirements affects you as a merchant.

 

PCI DSS or Payment Card Industy Data Security Standard is a set of comprehensive requirements for enhancing payment account data security. All merchants need to prove to their merchant acquirers that the way in which they operate their business conforms to the PCI DSS standards. The PCI standards surround the aspects of Storing, Processing and/or Transmitting sensitive card data.

 

Sage Pay is audited on a yearly basis by our Qualifed Security Assessor, Trustwave. We are a Level 1 compliant Payment Service Provider and are also active members of the PCI Security Council which means we able to comment on drafts of all revisions to the DSS specification, and on any new specifications, prior to public release. This gives us the distinct advantage of being able to maintain our systems to the latest PCI specifications on an ongoing basis.

 

The level of PCI Compliance that a merchant needs to adhere to all depends on which Sage Pay module they choose to process transactions with.

 

Sage Pay Form:

 

With Sage Pay Form, the buying customer is redirected away from the merchants website and onto a Sage Pay hosted payment page. Sensitive credit card information is entered into the Sage Pay hosted page and the response that Sage Pay provide the merchant on completion of a transaction does not contain any sensitive information. The Storing, Processing and Transmission of credit card information is contained on the Sage Pay Level 1 servers. Therefore an online merchant using Sage Pay Form will need to complete a PCI Self Assessment Questionnaire (SAQ).

 

Sage Pay Server:

 

With Sage Pay Server, the buying customer can be redirected away from the merchants website and onto a Sage Pay hosted payment page very much like Sage Pay Form. There is now also the iframe option which enables a merchant to effectively keep the buying customer on their own website for the entering of credit card data. In reality, the buying customer is entering their credit card info into a Sage Pay hosted payment page which can be fully customised to look and feel like the overall payment page. This gives the buying customer a seamless checkout experience without being redirected away from the merchants website. With both Sage Pay Server methods, sensitive credit card information is entered into the Sage Pay hosted page and the response that Sage Pay provide the merchant on completion of a transaction does not contain any sensitive information. The Storing, Processing and Transmission of credit card information is contained on the Sage Pay Level 1 servers. Therefore an online merchant using Sage Pay Form will need to complete a PCI Self Assessment Questionnaire (SAQ).

 

Sage Pay Direct:

 

With Sage Pay Direct, the merchant provides the forms and logic to capture the credit card data to post to the Sage Pay servers. The buying customer stays on the merchants website and inputs their credit card data into the forms provided. With the Sage Pay Direct certified module, there is no Storing or Processing, however, there is an element of Transmission. Because of this, there will be a level of PCI that the merchant will need to undertake, this level can only be determined by a Qualifed Security Assessor like Trustwave.

 

Payment solutions where buying customers stay on the merchants website have always been viewed as more "professional", so the introduction of the Sage Pay Server iframe gives the merchant the ability to offer this "professional" solution without the PCI implications that Sage Pay Direct may bring. As mentioned, the iframe templates can be completely customised to look like it belongs to the overall website.

 

I hope this helps and if anyone has any further questions please feel free to ask.

 

Many thanks,

 

John.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...