Virtual payments are becoming more and more prevalent outside of the insurance industry as companies realize the convenience of paying virtually. As a result, more business-to-business (B2B) purchases are being paid for via virtual payments. It also became obvious at our latest PCI Dream Team session that virtual payments need to be better explained to people so that they understand how they work and their responsibilities for security.
Definition
Technically virtual credit cards have existed for a while. Businesses have had “virtual” credit cards for making airline and hotel reservations, purchasing office supplies and paying for other business expenses for decades. The cards do not physically exist (originally they did exist, but this was seen as a security risk), but the business’ accounts payable department had a virtual card with a PAN, card verification code and expiration date issued by Visa, MasterCard or American Express for paying merchants for goods or services.
A virtual payment (or virtual credit card) is essentially the same as a regular, physical credit card with the following exceptions.
- The primary account number (PAN) can only be used once to make a payment. If you mess up either of the next two criteria, that does not count as a ‘use’. That said, even if everything is correct and the payment is declined you will have to contact the organization that generated the virtual payment to get a new virtual payment created. Also, be careful with a virtual card PAN as some processors may generate a PAN that will not Luhn check.
- Only the merchant defined on the virtual payment can use the payment. For example, if the merchant on the virtual payment is defined as ‘ABC Company’, only ABC Company can submit the transaction for payment.
- The payment must total exactly to the total authorized on the virtual payment. For example, if the virtual payment is for $1,252.98 USD, then the merchant can only submit a charge for $1,252.98 USD for payment.
- Virtual payments are flagged as being virtual. So, if someone were to copy the information and put it on a physical card to use physically at a retail outlet, the card would be declined.
How Do Virtual Payments Work?
Virtual payments are typically created by transaction processors such as Chase Paymentech, Elavon or Worldpay. Although there are a number of independent sales organizations (ISO) and others that have affiliated themselves with processors to also generate such payments.
A lot of accounts payable software solutions now provide connections to transaction processors’ APIs for the generation of virtual payments to pay bills. You will have to check with the application vendors to determine whose virtual payment solutions their applications support. But the original way of using a Web browser to access the processor’s virtual payment application is also available.
An organization must sign up for virtual payment services, so it is not something that you can just access. In addition, it is the responsibility of the organization to manage the users that have the ability to generate virtual payments as well as establish the minimum/maximum transaction amounts, time payments are valid (typically 30 to 90 days) and other payment criteria. In addition, the solution may also specify the merchants that can be paid through the virtual payment solution. Once set up, an organization can then generate virtual payments to pay their bills.
One very important step before you start generating virtual payments is that you need to ensure that the organizations you are paying will accept virtual payments or payment cards. While an organization may have retail outlets that accept payment cards for payment, does not mean that their commercial operations also accept payment cards. As such, you need to contact the accounts receivable department at the organizations you intend to pay with a virtual payment to ensure that they will process the virtual payments as some organizations cannot or will not. Also use this as an opportunity to confirm you have the correct name of the organization (as it appears when they process card payments), the correct facsimile number, correct email address (I recommend you get both just in case) and the preferred method of sending the virtual payment (i.e., facsimile or email). Keep in mind it is not your problem to worry about the payee’s PCI compliance in how they handle your payment. That is their problem, not yours.
When a virtual payment is generated, it is typically sent to the payee via facsimile. However, I have also heard that some processors that can send the information via secure email services such as Proofpoint or MimeCast.
If you are accepting virtual payments, you need to be aware of the PCI compliance issues with facsimile. The problem with using facsimile is that a lot of organizations have implemented facsimile services such as HelloFax, MyFax or eFax and any facsimile messages are automatically delivered to users via corporate email. Such a solution as eFax brings an organization’s email system into scope for PCI compliance. As a result, it is important that if your organization will accept virtual payments that those facsimile transmissions are sent to a secure physical facsimile machine located in the area where those payments will be processed. I have some clients that use secure printing solutions for printing their facsimiles where the user has to use their building HID card to securely print output on any printer.
Secure email solutions will hold the message for the payee to obtain from the secure email Web site interface via a browser. The secure email solution will send you a notification that you have received a secure message along with a link to that message. Once you get into the secure email solution, it is up to your organization to ensure you maintain the security of the message and the SAD sent to you. So, no forwarding the message to your own email system. No storing message attachments (likely the SAD) to a PC or network drive. Print out the message and/or attachments to a physical printer and process the payment from those printouts.
SAD Is SAD – CHD Is CHD
As I said earlier, virtual payment messages contain SAD in the form of card verification value in addition to the PAN, expiration date and cardholder name which are cardholder data (CHD). Just because we are talking about virtual payments and they can be used only once does not mean they can be treated any differently than the same information from a physical payment card.
That said, Visa and MasterCard have their own view of virtual payment information security. As David Mundhenk reminded everyone on our latest Dream Team session, the card brands also have their own rules in addition to the PCI standards. So, it is important for everyone to look at the card brands’ rules as well as the PCI standards when dealing with SAD/CHD. That means not only their security programs, but also their respective Merchant Agreements and asking them questions when you cannot find the answers in any of their official documents.
In the case of virtual payments, Visa and MasterCard differ on security of virtual payment information. Unfortunately, you would not know that fact if you had not asked each of the brands about this subject because their security programs and merchant agreements do not address the subject. For the record, American Express and JCB do not have an opinion on the subject. Obviously SAD is SAD before it is used to process the payment, where the difference comes is after the payment is processed.
Visa wants the information protected even after the payment is processed. They demand that it be securely destroyed after the payment is processed even though the information is single use. I kid you not, MasterCard said on a call that if my client wanted to post the printed facsimile on a utility pole out in public, that was okay with them because the information could not ever be used again. Talk about two polar opposite approaches. As a result, I recommend following Visa’s recommendation and securely destroy the original message or attachment. If for whatever reason you need to keep the payment document, securely redact the information, take a copy of the redacted original for your records and then destroy the redacted original.
That is what you need to know about virtual payments.
PCI Guru 
Thank you, Jeff, for this further and more detailed guidance following the PCI Dream Team webinar that also addressed this topic.
I would add that a method for delivery of payment instructions that requires the AR staff to click on a link in an email is problematic due to prevalence of “phishing”, false messages with links to malware. (Rule of thumb for business email: Never click a link.)
Your elaboration of an acceptable procedure using secure fax is very helpful.
I am also seeking providers of VCN payment services that can send a generic email indicating that a payment is available and that the AR should log in to their account on the site to see their account info and select the payment(s) to view, from the server of the VCN provider, with the payment data that can then be entered into the AR’s “card not present” payment card processing system. I.e. No written record of the PAN in the the recipient’s AR, server or facility at any time. The processed payment record can serve as the receipt.
Again, much appreciation for your post on this important topic that until now has not yet been well documented re scope nor re guidance on compliance.
Another example of the council being completely out of touch with reality. One-time virtual payment numbers are no more *Card Holder* Data than is a receipt number or reference number generated after the transaction.
Visa would highly disagree with you. Their rationale is that PANs get reused and therefore it is always CHD.
“Embezzlement” is one of the ways that such VCN payment data could be misused.
Better to consider that “a PAN is a PAN is a PAN” than to try to parse out when a PAN may not be a PAN.
Embezzlement is also impossible since the payment goes only into the merchant of record’s bank account.
Not “impossible”. I have experience with an enterprise where the CFO and another manager conspired to embezzle over $1 million. In the case of VCN payments, to change the receiving bank account number when such embezzlement transactions are to occur would not be difficult to perform. (… A good reason for changes to such sensitive fields in a business system to have audit records placed on them, or better e-signature.)
IMO it is preferable to have an incrementally broader requirement to assure security than to have a diminished requirement that may make policies and procedures easier to practice but may be less robust in secure performance.
Well, when someone changes the account, what did you expect? I’m talking about fraud from a standpoint that the brands have made it possible because of a flaw on their part. Once it’s out of the brands’ control, anyone can do whatever to defraud their employer. That is up to the payee to have the proper controls in place to minimize the possibility of fraud.
Noticed you mentioned Vantiv, but they change name when they bought/merged with WorldPay and is nowadays named WorldPay.
Forgot that. Thanks. I have updated the post.
To me, that difference sounds like Mastercard has strong controls in place to ensure it is actually single use and Visa does not.
To me that sounds like an incorrect assumption.
It truly is single use until the PAN is reused which is a good period of time. Also, the card verification value changes with each use which would trip any fraudster up. In addition, the fact that it cannot be used other than card not present is also an issue.