Bring your own carrier

If your calls are not already on Twilio, you do not have to move them. Keep your numbers, routing and call logic where they are, and hand the caller over to Twilio <Pay> and Shuttle for the payment segment only. Cards and ACH bank debit are both supported.

This works with any carrier, SIP trunk, PBX or contact centre platform that can transfer a call to an external SIP address.

On Telnyx? You do not need this. Telnyx’s own <Pay> verb connects directly to Shuttle — see the Telnyx IVR integration guide.

How the handover works

You create a SIP Domain in your own Twilio account and point it at a TwiML endpoint you control. When payment is due, your platform sends the caller to that SIP address. Twilio asks your endpoint what to do, you return a <Pay> verb, and Twilio captures the card by DTMF and passes it to Shuttle. The caller then returns to your flow.

There are two ways to send the caller across, and the choice is a compliance decision rather than a technical preference:

• Bridge — your platform keeps its leg and the caller comes back automatically when Twilio hangs up. Works with any carrier. The DTMF crosses your equipment, and a running call recording will capture it unless you stop it.
• Handoff — a SIP REFER moves the call off your platform entirely, so neither your equipment nor your recording is in the card data path. Requires your upstream carrier to honour REFER, and Twilio has to dial the caller back.

The guide below works through that decision before any configuration, because it determines what you have to build and what falls inside your PCI DSS scope. If you are adopting DTMF capture in order to reduce that scope, read it before you start.

Get started

• Other platforms — the capability checklist, the questions to put to your vendor, and the pattern step by step

Shuttle does not provide technical support for Twilio or for your carrier. Obtain official technical support from the vendor concerned. Shuttle supports the Shuttle Pay connector and the payment itself.