Home – New Forums Selling online Is this PCI compliant?

  • This topic is empty.
Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
    Posts
  • #986727
    geegee
    Member
    • Total posts: 89
    Up
    0
    ::

    Say a website with SSL accepts credit card payments and the middle 8 digits are emailed to them and the front and back four digits are stored in the database with the customer’s order. They then enter the CR details as a MOTO in a terminal and then delete the email and reference to the rest of the CR card from the database. Is this PCI compliant?

    #1159342
    eWAY
    Member
    • Total posts: 524
    Up
    0
    ::
    geegee, post: 183822 wrote:
    Say a website with SSL accepts credit card payments and the middle 8 digits are emailed to them and the front and back four digits are stored in the database with the customer’s order. They then enter the CR details as a MOTO in a terminal and then delete the email and reference to the rest of the CR card from the database. Is this PCI compliant?

    To answer your question, anything is PCI DSS compliant as long as it’s properly documented, approved and enforced.

    However, for the majority of places I don’t believe the method you’ve described would be approved as you’re giving staff access to an unmasked PAN.

    Although you’re only storing the masked number in the database. By emailing the rest of the numbers you’re still storing them, just separately.

    Best off talking to your bank though.

    Maclean

    #1159343
    geegee
    Member
    • Total posts: 89
    Up
    0
    ::
    eWAY, post: 183844 wrote:
    To answer your question, anything is PCI DSS compliant as long as it’s properly documented, approved and enforced.

    However, for the majority of places I don’t believe the method you’ve described would be approved as you’re giving staff access to an unmasked PAN.

    Although you’re only storing the masked number in the database. By emailing the rest of the numbers you’re still storing them, just separately.

    Best off talking to your bank though.

    Maclean

    It was an available add-on for my website. I thought it did not sound PCI compliant. Thought I would check here. Thanks for your response.

    #1159344
    ExplorePayments
    Member
    • Total posts: 11
    Up
    0
    ::
    geegee, post: 183822 wrote:
    Say a website with SSL accepts credit card payments and the middle 8 digits are emailed to them and the front and back four digits are stored in the database with the customer’s order. They then enter the CR details as a MOTO in a terminal and then delete the email and reference to the rest of the CR card from the database. Is this PCI compliant?

    Hi Geegee,

    In my opinion the best way to stay PCI compliant is not to have any exposure to card details whatsoever. If you are planning on saving some cash by keying in card details (using a virtual terminal) rather than using a fully hosted payment payment by a payment gateway then this might work out a lot more expensive than you think.
    Should card holder details get compromised from the process you have explained then this could prove to be an expensive problem to fix. Not only does an acquiring bank pass visa and master card fees to their merchants should this hit the media this will have a negative impact on reputation and will affect your sales. Sorry to sound so gloomy but you should consider what happens if things go wrong.

    Compromises on card holder data are becoming much more frequent with Target being a recent victim and liable for billions in fines.
    http://techcrunch.com/2013/12/23/target-may-be-liable-for-up-to-3-6-billion-from-credit-card-data-breach/

    I recently wrote about both PCI and data breaches on my blog so it may be of interest to you

    http://explorepayments.com/2013/11/24/the-biggest-threat-for-2014-data-breach/

    http://explorepayments.com/2014/02/08/pci-dss-understanding-the-key-focus-areas/

    Hope that helps
    Cheers
    Ian

    #1159345
    John Debrincat
    Member
    • Total posts: 963
    Up
    0
    ::
    ExplorePayments, post: 184046 wrote:
    Hi Geegee,

    In my opinion the best way to stay PCI compliant is not to have any exposure to card details whatsoever. If you are planning on saving some cash by keying in card details (using a virtual terminal) rather than using a fully hosted payment payment by a payment gateway then this might work out a lot more expensive than you think.

    Compromises on card holder data are becoming much more frequent with Target being a recent victim and liable for billions in fines.
    http://techcrunch.com/2013/12/23/target-may-be-liable-for-up-to-3-6-billion-from-credit-card-data-breach/

    Hello Ian,

    Your blog posts are spot on and, in general, I agree with your advice regarding PCI DSS compliance and not manually processing card not present transactions.

    On the issue of the Target USA attack (and other USA mainstream retailers) before Christmas you should note that this was not an online compromise. The situation was caused by hackers embedding a malicious software virus in the systems that interfaced with the in-store EFTPOS systems. When the consumer swiped their card the the information on the magnetic strip was scraped and sent to the hackers. This was a very sophisticated attack that occurred at multiple companies and locations. Target got the most media exposure.

    I was asked about for a news article that was published in Connected.com.

    The USA have not implemented Chip and PIN cards and that was the main reason this attack could occur and was successful. It is far less likely to happen in Australia where we have been implementing Chip and PIN as well as Tap and Go type technology.

    Selling online in Australia and buying online in Australia are remarkably safe and secure. Recording card details anywhere is not good practice unless you have implemented the technology to protect that information and that technology is not cheap or easy.

    So go with a reputable payment service provider for any online credit card processing and check that your hosting company and your online store provider are PCI DSS Compliant.

    John

    #1159346
    ExplorePayments
    Member
    • Total posts: 11
    Up
    0
    ::
    John Debrincat, post: 184049 wrote:
    Hello Geegee,

    Your blog posts are spot on and, in general, I agree with your advice regarding PCI DSS compliance and not manually processing card not present transactions.

    On the issue of the Target USA attack (and other USA mainstream retailers) before Christmas you should note that this was not an online compromise. The situation was caused by hackers embedding a malicious software virus in the systems that interfaced with the in-store EFTPOS systems. When the consumer swiped their card the the information on the magnetic strip was scraped and sent to the hackers. This was a very sophisticated attack that occurred at multiple companies and locations. Target got the most media exposure.

    I was asked about for a news article that was published in Connected.com.

    The USA have not implemented Chip and PIN cards and that was the main reason this attack could occur and was successful. It is far less likely to happen in Australia where we have been implementing Chip and PIN as well as Tap and Go type technology.

    Selling online in Australia and buying online in Australia are remarkably safe and secure. Recording card details anywhere is not good practice unless you have implemented the technology to protect that information and that technology is not cheap or easy.

    So go with a reputable payment service provider for any online credit card processing and check that your hosting company and your online store provider are PCI DSS Compliant.

    John

    Hi John,

    In reference to the target data breach my intention was to highlight the cost rather than anything else.

    Great article btw

    Cheers
    Ian

    #1159347
    John Debrincat
    Member
    • Total posts: 963
    Up
    0
    ::
    ExplorePayments, post: 184056 wrote:
    Hi John,

    In reference to the target data breach my intention was to highlight the cost rather than anything else.

    Great article btw

    Cheers
    Ian

    Oops sorry Ian wrong name on that post fixed now.

    John

Viewing 7 posts - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.