There is no reason to think that an e-commerce site payment page that directly handles the payment transaction, rather than redirecting to a third party payment processor such as PayPal's site is less secure. In fact, many e-commerce sites that *do* use third party PSPs are less secure than those that directly implement their payment page, because they incorrectly assume that using a third party PSP means that they can ignore PCI DSS, which is not true -- even when completely outsourcing the entire payment page, the code that redirects to / iframe's the PSP page, and the server(s) it emanates from are still in scope for PCI DSS, since modifications could affect the security of cardholder data.
All entities that store, process or transmit card account data, including merchants like (ISC)2, or who can affect the security of card account data, or a cardholder data environment, are required to be continuously compliant with all applicable PCI-DSS requirements. For e-commerce sites, that includes, at minimum, passing quarterly vulnerability scans by a PCI Authorized Scanning Vendor (ASV).
Assessment and reporting requirements for a merchant are determined by their acquirer. They don't include reporting to customers.
At the end of the day, the trustability of an e-commerce site with your card account data is based on whether you can trust the operators of that site in the first place, which I would think is not of question with (ISC)2. 🙂
While the "scanning attestation certificate" graphics that some web sites display (and are offered by some ASV Companies) are a "feel good" item, they actually have no real meaning, and in my opinion, are off-site content that could provide another route for an attacker to insert malicious code. I personally advise consumers to verify that the page that they are typing their card account data into is properly using strong encryption (by checking the URL for https; clicking the "lock" icon in the browser, confirming that a valid digital certificate that chains to a trusted root certificate; making sure that the whole page is indicated to be using TLS v1.2 or higher with a strong cipher, etc.
Finally, I wanted to point out that it is acceptable for a merchant to store sensitive authentication data, such as the card verification code/values (CVC2,CVV2,CID etc.) prior to authorization, but they may not be retained once authorization has taken place.
That being said, there is usually no mechanism for the cardholder to tell whether a merchant has *authorized* a transaction (a few issuers do report authorizations via mobile apps nowadays, but most do not -- and authorizations do not appear on your account statement.) This is because there are several steps to the payment card transaction process, and the entire process may take days (or even longer) to take place, especially with MOTO (mail order/telephone order) or e-commerce transactions, since consumer protection laws prohibit a merchant from completing a payment card transaction until the order is fulfilled. Here are the steps:
1. Consumer completes the order transaction on the merchant's site, entering card data & clicking the pay button.
2. E-commerce site submits an "Authorize" transaction to their processor/acquirer. The transaction includes the Primary Account Number (PAN), expiry date, card verification code/value and transaction amount.
3. Processor (if used) routes transaction to the merchant's acquirer. The acquirer sends the transaction to the card's issuer (based on the bank identification number (BIN), which is the first 6 digits of the PAN) via the payment brand's network.
4. Issuer receives the "Authorize" transaction, checks the cardholder's account, and responds either with a "Decline", or "Approved" response.
a) If "Approved", the Issuer places a "hold" on the cardholder's account for the amount of the transaction to make sure the account doesn’t exceed its limits. Holds are held for a specific amount of time.
b) The response message will include a transaction identifier ("authorization code").
5. Issuer sends response to Acquirer over the payment brand network; Acquirer sends to Processor (if used); Processor sends to Merchant system.
6. Merchant's system saves the transaction data, typically including the PAN, expiry date, and transaction ID. Card validation codes/values are not saved, as they are no longer needed. Payment page informs consumer that transaction was successful.
7. When merchant is ready to fulfill order, they update the status in their system, which causes a "Completion" transaction to be sent to the Acquirer. The "Completion" message contains the finalized amount of the transaction, the PAN, expiry date and usually the transaction ID/authorization code.
8. The Acquirer then sends the finalized purchase information to the payment brand network, which sends it to the Issuer. The issuer prepares data for the cardholder's statement, and sends back reconciliation information to the Acquirer. This process is called "Clearing". This is the point at which the transaction will appear on the cardholder's account.
9. In the last step of the payment process, the Issuer pays the Acquirer for the transaction amount, and the Acquirer pays the merchant. This process is called "Settlement".
When you buy stuff in a store face to face, usually the Authorization and Completion messages will take place simultaneously if the merchant's terminals are continuously online, although some merchants still do what they call "batch settlement", but which really is a separation of the Authorization (happens at time of sale) and Completion (a batch of them get sent all at once) messages. Usually that decision has more to do with the cost of processing, so you'll see this kind of thing happen a lot, for example, if you go to a merchant at a weekend street fair. They'll often run the Authorization in real time on a payment terminal that uses mobile data connection, but they'll wait and submit the Completions in a batch once they get home to reduce the # of cell calls, so there might be a week's worth of transactions from Saturday the 18th that don't start clearing until Monday the 27th.
Clearing is also a back-end batch process that involves sending files between acquirers and issuers, not a realtime process, so it typically takes 2-3 days for domestic transactions.
Jim Scardelis, M.S., CISSP, CISA, CEH, PCI Secure Software, Secure SLC, P2PE, P2PE Application & 3DS Assessor, PCIP, CIPP/US, CIPP/C, CIPP/E, CIPT, CTT+
Any views or opinions contained in this communication are solely those of the author.
