4 ms·

If the Primary Account Number (PAN) and CVV go directly to the merchant and bypass your servers, then you can drastically reduce your PCI scope. Most solutions

If the Primary Account Number (PAN) and CVV go directly to the merchant and bypass your servers, then you can drastically reduce your PCI scope. Most solutions have a merchant server that allows a cross-origin POST or uses an iframe. In either of these methods you exchange the payment information for a low value token that you then send to your server. Your server can exchange that low value token for a high value token and use that to charge people's cards. This is better for everyone involved because there is less of a chance that the PAN or CVV will be exposed.

decentralised 9y ago
I think there's a bit of a confusion in terminology here, but I haven't finished my morning coffee yet so apologies if I misread your comment. Merchant = yourShop.com Merchant Bank = Big Commercial Bank for yourShop.com PSP = paymentGateway.com Card Network = Visa Issuing Bank = JoeBlogsBank.com PAN (Personal Account Number) = 16 (can be different in some card schemes) digit card number, CVV, expiry date Customer = Joe Blogs The hosted payment interface is provided by the PSP so that the merchant doesn't need to have a PCI-DSS compliant system at all. As you say, this means that no PAN data needs to be captured or retained by the merchant systems and instead only an auth code and status message are used as proof of payment, or capture if we're exclusively discussing credit cards.
- miahi 9y ago
  In the 3DSecure context, there is another level added, with a password handled by the Issuing Bank. From what I saw, the web form for entering this password is not implemented by the PSP but by the issuing bank - the PSP redirects you to the bank's website for entering the password, then you are redirected back to the PSP and merchant. This is mostly implemented by smaller PSPs and stores (probably because of lower fees when using it, as the card holder will have a hard time to dispute a 3DSecure transaction). From what I saw, most of the US-based and large payment gateways bypass 3DSecure.
  - decentralised 9y ago
    You are correct. 3DSecure add a new layer of protection provided by the card network (visa, mastercard, etc) IIRC, so not the issuing bank itself. US based e-commerce follows a different set of rules and I would rather not go into that. I was an architect at a major PSP for 6 years.. I've actually forgot most of it by now :-)
  - user5994461 9y ago
    3D secure shifts the burden of proof. Without 3D secure, the merchant is charged back by the bank in the event of a fraudulent transaction. With 3D Secure, the bank takes the loss.
    - zaroth 9y ago
      Wow - no chargebacks? Do people buy crypto coins this way? This is a huge benefit to the merchant if it's true. There's no direct benefit to the customer, so you have to overcome that somehow.
      - sitepodmatt 9y ago
        Not 100%. This removes chargebacks due to theft (or I didnt make that transaction) I believe, but people can still chargeback for many reasons - disputing quality of product/service being the biggest headache, product not being delivered (or supposedly) another..
zaroth 9y ago
That's what's funny about PCI scope. The JS is controlled by the server, so that the server doesn't presently see the card number, should be irrelevant. I assume exposure is equal to passing the card to a merchant gateway on the backend as it is for passing the card to a merchant gateway on the frontend. It's nonsensical to assume the threat profile on the two are any different. Certainly it matters if the backend is storing the card number in any way. Or if the backend is transmitting the card number in any way beyond the established TLS channel. The card number be encrypted as quickly as possible and shoved off. I always find the best place to do it is on the backend. If you can afford it, you get the PCI audit anyway, because not having it is just an excuse to be sued, right?

decentralised 9y ago

I think there's a bit of a confusion in terminology here, but I haven't finished my morning coffee yet so apologies if I misread your comment. Merchant = yourShop.com Merchant Bank = Big Commercial Bank for yourShop.com PSP = paymentGateway.com Card Network = Visa Issuing Bank = JoeBlogsBank.com PAN (Personal Account Number) = 16 (can be different in some card schemes) digit card number, CVV, expiry date Customer = Joe Blogs The hosted payment interface is provided by the PSP so that the merchant doesn't need to have a PCI-DSS compliant system at all. As you say, this means that no PAN data needs to be captured or retained by the merchant systems and instead only an auth code and status message are used as proof of payment, or capture if we're exclusively discussing credit cards.

miahi 9y ago
In the 3DSecure context, there is another level added, with a password handled by the Issuing Bank. From what I saw, the web form for entering this password is not implemented by the PSP but by the issuing bank - the PSP redirects you to the bank's website for entering the password, then you are redirected back to the PSP and merchant. This is mostly implemented by smaller PSPs and stores (probably because of lower fees when using it, as the card holder will have a hard time to dispute a 3DSecure transaction). From what I saw, most of the US-based and large payment gateways bypass 3DSecure.
- decentralised 9y ago
  You are correct. 3DSecure add a new layer of protection provided by the card network (visa, mastercard, etc) IIRC, so not the issuing bank itself. US based e-commerce follows a different set of rules and I would rather not go into that. I was an architect at a major PSP for 6 years.. I've actually forgot most of it by now :-)
- user5994461 9y ago
  3D secure shifts the burden of proof. Without 3D secure, the merchant is charged back by the bank in the event of a fraudulent transaction. With 3D Secure, the bank takes the loss.
  - zaroth 9y ago
    Wow - no chargebacks? Do people buy crypto coins this way? This is a huge benefit to the merchant if it's true. There's no direct benefit to the customer, so you have to overcome that somehow.
    - sitepodmatt 9y ago
      Not 100%. This removes chargebacks due to theft (or I didnt make that transaction) I believe, but people can still chargeback for many reasons - disputing quality of product/service being the biggest headache, product not being delivered (or supposedly) another..

zaroth 9y ago

That's what's funny about PCI scope. The JS is controlled by the server, so that the server doesn't presently see the card number, should be irrelevant. I assume exposure is equal to passing the card to a merchant gateway on the backend as it is for passing the card to a merchant gateway on the frontend. It's nonsensical to assume the threat profile on the two are any different. Certainly it matters if the backend is storing the card number in any way. Or if the backend is transmitting the card number in any way beyond the established TLS channel. The card number be encrypted as quickly as possible and shoved off. I always find the best place to do it is on the backend. If you can afford it, you get the PCI audit anyway, because not having it is just an excuse to be sued, right?