Latest News: (loading..)

John_SagePay

Partner
  • Content count

    11
  • Joined

  • Last visited

  • Days Won

    1

John_SagePay last won the day on October 7 2009

John_SagePay had the most liked content!

2 Followers

About John_SagePay

Profile Information

  • Real Name
    John Fitchett
  • Gender
    Male
  1. Hi Narfi, Templates are now up on the test server. Please could you test and let me know. Many thanks, John.
  2. Hi Nafri, PM me your vendor name and I will get the guys to check your custom template. Many thanks, John.
  3. Hi, Please see this post: - http://forums.oscommerce.com/topic/346355-sage-pay-and-pci/ Many thanks, John.
  4. 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.
  5. Hi Sage Pay payment modules can be found here: - http://addons.oscommerce.com/service/sage_pay Many thanks, John.
  6. Hi Ken, I will put a dedicated post on PCI and Sage Pay shortly but put simply, with Form or Server, the merchant will be using the Sage Pay level 1 compliant hosted payment pages. As no sensitive credit card data is ever Stored, Processed or Transmitted from the merchants website, website with Form or Server, the merchant is reduced down to having to complete the PCI DSS Self Assessment Questionnaire which costs around £70 per annum. With the Direct solution, the merchant is providing the forms and logic to capture the sensitive card data on their website and transmit this off to Sage Pay to process. You are correct in saying that a dedicated server is required for this solution to become fully 100% PCI Compliant and the cost of this with Sage Pay Direct can only be assessed by a Qualifed Security Assesser. The Direct integration has always seemed the more "professional" approach to accepting credit cards online and this is why we have developed our Server integration to have the iframe option in order to give the look and feel of a Direct integration whilst reducing the merchants PCI Compliance requirements. Many thanks, John.
  7. Hi Ken, Sage Pay provide 3 methods of integration: - 1. Form 2. Server 3. Direct Regardless of which integration method chosen, the Sage Pay pricing remains the same: - 1. £20 per month for up to 1,000 transactions per quarter 2. 10p per transaction for over 1,000 transactions per quarter. You may be referring to the cost implications of the development times required for a Server/Direct integration and you would be right in saying that it is a more time consuming effort in comparison to Form. This the reason Sage Pay have partnered with osCommerce to provide modules certified to the osCommerce code base enabling the merchant to "enabling" the module rather having to go through a development. I hope this helps. John.
  8. Hi Claire. Just to futher update you on this, the first transaction I looked at did show the vendor email being sent. However on looking at this I presume this was a transaction from a previous module that you had running. When you completed another test transaction yesterday and sent across the TxID, I can confirm that the vendor email was not being sent hence you not receiving an email from Sage Pay. I have since spoken with Harald and we have updated the module to include the various optional fields that will enable you to start receiving these emails. Just awaiting now Harald to release the updated module. Just out of interest would you not want to update your module to Sage Pay server and benefit from the iframe option? It will give a more seamless checkout flow whilst still maintaining the use of the hosted payment page. From a customer conversion point of view this may be a better option than redirecting your paying customers to another site to complete the transaction. Let me know what you think. I appreciate all comments on these modules and we will continue to ensure that the feedback is taken on board and that the osCommerce users benefit from these modules which we will fully support and keep updated. Many thanks, John.
  9. Hi, Could you message me your vendorname and I will check your account at point 1. Many thanks, John.
  10. Hi Ross, Point 2 in your original post has now been amended with the custom template packs. Many thanks, John.
  11. Hi Ross, Could you message me your vendorname and I will get your custom template added as priority to test this. Many thanks, John.