Stripe Integration for Twilio Pay | Hacker News Reader

Stripe Integration for Twilio Pay

stripe.com

207 pointsdsr1229 comments

I don't completely understand how they do this without exposing the DTMF tones / digits pressed to the carriers.

For example, when I key in my card number, my phone carrier will know it, the routing carriers know it before it reaches Twilio. How is my card information safe? I guess I'm missing something here.

PCI doesn't currently consider telephones to be public networks. That's why they are okay with fax machines sending CC details, provided they are in a secure area and a few other non tech requirements. Not sure I agree with the practice, but it is what it is.

Never knew that. I assumed VoIP based telephony comes under PCI view.

DTMF is being pulled out of band by Twilio (or more likely the underlying CLECs they partner with), thus the agent should not hear it. This is very common for most VOIP carriers, DTMF is carried in the signaling messages rather than in-band in the audio stream. The only person being protected from having access to your card data is the agent who asked you to key in your card.

I know they do pull it out to a separate band but many VoIP providers log the DTMF sent as digits to debug things - most evident in IVR use cases.

So, if attackers wants to get card details, they need not attack the business or Twilio (because it might redact these when they see <Pay>, but they can simply access logs of the middlemen for DTMFs. Concatenate all those per call, and there we should have all card numbers, expiry dates and CVC/4DBC.

Not sure how Twilio is doing it though. Unless they use some awesome encryption method to encrypt all these numbers so no one in middle can see them.

Not really sure how these things work so this is an honest question:

Why would they be receiving the tones once the connection is made? Isn't it the same as me just whistling at particular frequencies? I didn't think it was sent in a different manner.

Or do you mean it goes through the carrier just like if you spoke your card number over the phone to someone?

AFAIK, there are two ways in which the tones can be sent.

1. In the regular audio stream (AKA in-band) so anyone who can listen to the phone call, can also listen to these tones. These tones can be mapped to the digits pressed.

2. In a separate RTP payload (AKA out-of-band) so not everyone can read / listen to this stream of signals / tones. RFC 4733 (earlier it was RFC 2833) specifies the format of this RTP payload. This is what the payment via phone systems might be using.

There is a secure RTP with encryption support, but I am not sure if it can be implemented end-to-end to avoid anyone in middle (not a man-in-middle attacker, but a genuine carrier / network) to see these DTMFs. Just unable to imagine how this works :)

It’s not 100% clear from the documentation but it appears the card details have to be keyed in and there’s no voice recognition mode.

It would be great to hear a demo of what <Pay> sounds like, particularly the error handling.

I absolutely get the benefit of insulating your agents from the billing data. Not so keen on an abrupt switch to touch-tone inputs during a call though.

From the linked post: "when it’s time to collect the payment, the agent activates Twilio <Pay> to let the customer enter payment info using their keypad—agents can follow the customer’s progress, but won’t see or hear the card details."

Yes, this is pretty standard.

I recently pay my home insurance's renewal that way (Europe).

However, these days many systems use voice recognition rather than having to key in numbers. I'm guessing that this is on Twilio's roadmap.

They demo'd it a few hours ago. Essentially you key in the card info and press pound once your done for each piece of info. The agent on the line can't hear the tones. The agent see's the data filled in (sensitive data hidden). It didn't work a few times and there was a delay so they have a little work to do.

Does Stripe have payment links like Razorpay [1] ?

[1] https://razorpay.com/payment-links/

They don't, although you can create invoices in the dashboard if you know who your customer is.

Alternatively, I built https://checkoutpage.co to create hosted payment pages for Stripe that are accessible by url, similar to Razorpay's payment links.

Might as well jump in here - founder of Trolley [1] which lets you put a payment button on any website, which triggers a Stripe-powered shopping popup.

[1] - https://trolley.link

This looks pretty cool. I keep coming up with Twilio-based side projects I want to build, but the abuse potential keeps me from actually releasing anything useful. With this, maybe I can charge users $.0X per call minute, or $X/month to recoup my Twilio costs.

> the abuse potential

It's kinda hard to abuse recently. You can do heavy geo locking in order to not get fucked over by abuse to other countries.

Do you have to do it yourself or Twilio takes care of that?

Geo-locks are enabled for everything minus US and UK.

If you don't buy UK numbers, I think UK is locked down as well.

I worked on a very similar product a few years ago. There were a few companies battling over patent rights for similar implementations of DTMF tone suppression in the payment space.

Not sure what happened with that but looks like essentially the same idea here. Always thought it was pretty niche now everyone has a browser in their pocket.

Interestingly, this might be in response to the new PCI requirements.

In the past, if you iframe'd a payment processor site, you didn't need to be PCI compliant while the new spec requires everyone who is involved in the process to be compliant.

I wonder if this will be the future of payment processing, just outsourcing to Twilio and Stripe.

TIL, they should be geared up to take advantage then. We had PCI compliancy but like you mention the big players will take most of the pie.

Which new requirements are you referring to?

I've heard rumors about new PCI requirements for service providers mandating end to end encryption of phone calls with credit card data. This would certainly be an off the shelf solution

There's still a lot of places doing faxes with CC details, especially in B2B. Guess they'll have to finally ditch that.

This is very cool. One problem I see though is that most phone payment transactions happen over a regular phone call vs a dedicated session started over some IVR system. It would be very cool for businesses to be able to, say, have a payment bot join the call and then leave once the transaction is done.

Sounds like they addressed this.

" For a more personalized experience, employees can also walk customers through an order over the phone: when it’s time to collect the payment, the agent activates Twilio <Pay>"

Of course, larger places have their own non-Twilio Voice PBX and lines, so I'm not sure if this approach only works if the call originally came in via Twilio.

If you're interested in seeing a demo on this, I'd love to talk.

I understand the part where an agent/operator won't be able to see my details but when I digit my credit card details into my phone, who's handling them? Are they going to Stripe directly or is Twilio forwarding the "tones" to Stripe? Kinda confused?!

The card information is passing through Twilio to Stripe, and they've built a version of/path through their systems that's PCI compliant for this purpose. Tutorial shows that you have to turn on PCI Mode in your account in order to use this.

https://www.twilio.com/docs/voice/tutorials/how-capture-your...

Reply on news.ycombinator.com