I'm developing the entire backend using for an Over-the-phone Virtual Assistant service. Their clients are busy professionals who delegate their online purchasing and booking to this service, which employs essentially call centre agents to handle their request.

E.g. Client requests service to buy a book, Call Centre Agent answers and goes to BookDepository, AbeBooks, Amazon, literally any company with a website, and buys the book for them.

What solution can we use to record the Client's credit card details (except CVV) and then allow the Agents to retrieving all of it and then manually input it into another service's website? I've looked into PCI-DSS compliance and it is way too onerous to store and retrieve it. Most services like Stripe or Authorize.net allow the company to recurrently bill, but doesn't allow retrieval of the card details (for obvious reasons).

Or is it just too hard and Agents should request the credit card details at every purchase? But I feel that is even more problematic because the Client could be overheard, obviously not convenient, Agent might be tempted to write it down somewhere.


  • This may not be practical but could you just use your companies own credit cards and invoice your customers later? If you go this route do look at leveraging a partnership where you can provide your call center workers with temporary (one-time use) virtual credit cards. Some travel agencies do this to get around this problem. – Trey Blalock Apr 26 '17 at 8:44
  • Sounds like the business model is slightly off - if the agents made purchases using cards belonging to the VA service, and then invoiced the clients, you would never need to store the client's card details. There might be some issues with online shops which require the delivery and billing addresses to be the same, but otherwise you're probably putting clients at risk of their cards being terminated, based on common terms and conditions for credit cards... – Matthew Apr 26 '17 at 8:45
  • Thanks - so using the company's credit card I initially thought of but doesn't work financially because it costs 2-3% to charge a client's card and the business model works by charging a 5% purchase fee. So billing the entire amount would cost 40% of their revenue. Invoicing creates a problem with cashflow; with 1000 clients, the company would be potentially down for hundreds of thousands of dollars before they would be paid. This is also a problem with using company's credit card, it's not easily scalable... – Lauuu Apr 26 '17 at 8:59
  • From a security point of view, anything which requires you to store client's credit card details is going to be a no-no - it would make the server where they were stored into a high value target for attackers, and then allowing agents to view them gives additional risk. I suppose the other option would be to have a pre-pay type solution, where clients provide a balance which is then spent, using company cards, which avoids the cash flow issue... – Matthew Apr 26 '17 at 9:53
  • 1
    This space ("charge other people's cards on their behalf", usually correlated to things like travel agencies) is not well addressed by the DSS, especially when you consider the CVV problem. I suspect there are no DSS compliant solutions, and yet bad solutions keep flying by because the PCI enforcement mechanisms are geared around processing agreements - and the actors in this case don't need one. – gowenfawr Apr 26 '17 at 13:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.