Programmatically accept credit cards over the telephone with voice + telephony API (text-to-speech and speech-to-text) like Twilio?

Question

Has anyone created a system with Twilio, or another voice + telephony API, to accept credit cards programmatically over the telephone? The system obviously would rely on speech-to-text and text-to-speech to automate the process of accepting credit cards.

If so, how much were the CC fees, and which voice + telephony API did you use?

Thanks!

Answer 1

Yes I have done this, but it's technically non-trivial due to the PCI-DSS requirements associated with credit card payment processing. More than likely the transaction fee assessed will be higher than it could be because you simply cannot store the credit card CV2 value. Transactions completed with a valid CV2 value are often processed with a cheaper rate by the acquiring bank.

I would forget about transcribing user speech for this, Twilio doesn't yet support grammars that would allow straightforward voice input, and using the transcription service would be cumbersome for this use case. The only data you will want to capture are credit card number, expiry date, and optionally billing zip code (for AVS). All these data are numerical and can be captured using the <Gather> TwiML verb.

There is a competing service to Twilio called Tropo, and the support simple grammars for capturing voice input. I think that is the only thin Tropo has on Twilio though. Twilio has a nicer API, is cheaper, and is run by very nice, helpful people.

Finally you DO NOT want to store CC numbers! It's not worth the trouble! You will have to store the expiry and zip because the Gather verb captures one thing at a time and then submits to your app via POST or GET. Capture the credit card number itself last, and then submit to your gateway immediately for purchase, authorisation, or tokenisation.

Hope this helps.

Answer 2

Sorry but this is really bad advice.

PCI-DSS will not allow you to store the CV2 after the card has been processed and other details can only be stored with valid need for them.

Also, Twilio is not PCI-DSS Level One compliant so the fact that the calls pass over their network in the first place is flawed. They will be stored by Twilio.

Using a 3rd party ASR provider, they will no doubt store the response they give you from the recording too upon conversion.

All in all, it is not worth the hassle/risk, use a dedicated provider for this that is Level One certified by an independent QSA.

Answer 3

I don't think you'll find that's a very popular option. If someone's giving you a credit card number you want to make that as easy as possible -- and that means talking to a person.

But if you do decide to take cards through Twilio, use the key pad (like Steve said, use the Gather verb) (When I call my credit card company, they ask you to type it in rather than using voice recognition, which is a pretty good indicator which one works better)

Answer 4

Hosted solution like Twilio woudln't work for sure, but you can always consider to build a system inhouse. Today with Freeswitch + CMUSphinx you can easily build an IVR to recognize credit card numbers with very high accuracy.

Since you will host this system yourself, there will be no issue with the privacy.

Answer 5

Regardless of the "how":

1. If you process credit cards in any way, you need to be PCI certified
2. As part of the certification, you need to provide proof of the certification of you "suppliers", in this case Twilio 3: Twilio is not certified

Proof: https://www.twilio.com/help/faq/twilio-basics/what-can-i-do-to-keep-my-twilio-application-workflows-pci-compliant

Answer 6

So Twilio recently announced which does exactly what was spoken about in this question.

Currently only with Stripe but accepting requests for other gateways too: https://www.twilio.com/pay/request-connector

Details: https://www.twilio.com/docs/voice/twiml/pay