Opayo doesn't natively connect to Twilio for voice payments. If you want to process Opayo transactions during a phone call (via IVR, agent-assisted, or AI voice agent), you need a Twilio Pay Connector that bridges the two platforms.
Shuttle's Pay Connector does exactly this. It connects Opayo (and 30+ other gateways) to Twilio's <Pay> verb, so you can accept PCI-compliant card payments during any voice interaction.
This matters more for Opayo merchants than most. Opayo, formerly Sage Pay and now part of Elavon (a U.S. Bank company), is one of the UK's longest-established gateways, and a large share of its merchant base has always taken payments by phone: MOTO orders, invoice settlement, deposits, bookings. If your agents currently key card numbers into a virtual terminal while the customer reads them out, every agent, headset, and call recording sits inside PCI scope. Connecting Opayo to Twilio replaces that with automated DTMF capture, so card data never reaches your people or systems.
This guide walks through how the integration works, how to set it up, and what to watch for.
Why Opayo + Twilio Don't Connect Directly
Opayo is built for card-not-present commerce: online checkout, invoice payments, and telephone (MOTO) orders. It has served UK and Irish merchants for over two decades, first as Sage Pay, and since Elavon's acquisition, as Opayo.
Twilio is built for voice and messaging. Its <Pay> verb captures card details during phone calls via DTMF keypad input, so the digits never reach the agent or the call recording.
The problem: Twilio's <Pay> needs a Pay Connector to route captured card data to a payment gateway. Opayo isn't one of Twilio's built-in connectors, so there's no native way to send <Pay> transactions to your Opayo account.
This is where Shuttle comes in. Shuttle provides a Pay Connector that accepts card data from Twilio's <Pay> verb and routes it to Opayo's API for processing. One integration connects the two platforms.
How It Works
Caller → Twilio (DTMF capture) → Shuttle (Pay Connector) → Opayo (processing) → Result
Caller reaches payment step. Your Twilio call flow (IVR or custom TwiML) triggers the
<Pay>verb.Card details captured via DTMF. The caller enters their card number, expiry, and CVV on the keypad. The digits never reach the agent or the call recording.
Shuttle receives card data. The data passes from Twilio's PCI-compliant environment directly to Shuttle's connector. It never touches your servers.
Shuttle charges the card via Opayo. The connector creates an Opayo transaction, processes it through your Opayo vendor account, and handles the response.
Result returned to your call flow. Your webhook receives the Opayo transaction reference, last four digits, card brand, and transaction status. The call continues.
The caller stays on the line. For merchants used to reading card numbers back for confirmation, it's a step change: faster, quieter, and with the card data out of your systems.
Step-by-Step Setup
Prerequisites
A Twilio account with voice capability
An Opayo account with API credentials (vendor name, integration key, and integration password)
A Shuttle account (free to create; see pricing)
Step 1: Install Shuttle's Pay Connector
Go to the Twilio Marketplace and install the Shuttle Pay Connector. This adds Shuttle as an available connector in your Twilio account's Pay configuration.
Step 2: Add Opayo Credentials to Shuttle
Generate API credentials in the MyOpayo portal if you haven't already (note: Opayo issues a single set of API credentials per account, and the integration password is shown only once, so store it securely). Then log into the Shuttle dashboard, navigate to Payment Profiles, and create a new profile:
Gateway: Opayo
Vendor name: Your Opayo vendor name
Integration key: From MyOpayo
Integration password: From MyOpayo
Currency: Set your default (GBP, EUR, etc.)
Environment: Live or Test
Save the profile. Shuttle now has a live connection to your Opayo account.
Step 3: Configure Your Twilio Call Flow
Add the <Pay> verb to your TwiML:
<Response>
<Say>Please enter your card number followed by the hash key.</Say>
<Pay paymentConnector="shuttle-pay-connector"
chargeAmount="49.99"
currency="GBP"
description="Invoice payment"
action="/payment-complete">
</Pay>
</Response>Key parameters:
paymentConnector: set toshuttle-pay-connectorchargeAmount: the amount to chargecurrency: ISO currency codeaction: your webhook endpoint for the payment result
Step 4: Handle the Payment Result
Twilio sends a POST to your action URL with the payment result:
{
"Result": "success",
"PaymentCardNumber": "xxxx-xxxx-xxxx-1234",
"PaymentCardType": "visa",
"PaymentConfirmationCode": "OPAYO-TX-REF-123...",
"ProfileId": "your-shuttle-profile-id"
}Use the PaymentConfirmationCode to look up the transaction in MyOpayo if needed. Update your order, confirm to the caller, and continue the flow.
Step 5: Test
Opayo's test environment is a copy of the live system without the banks attached, so you can run the full flow end-to-end with no money moving. Point your Shuttle payment profile at the test environment, use the test card numbers from Elavon's Opayo developer documentation, and verify the complete call flow before switching to live credentials.
What You Can Do With Opayo + Twilio
Charge Immediately
Standard payment transaction. The caller pays, Opayo processes, done. This is the direct replacement for agents keying MOTO transactions into a virtual terminal.
Tokenise for Future Use
Capture card details once over the phone. Shuttle tokenises the card with Opayo and returns a reusable token, which you can use for future payments across any channel: web, mobile, voice, or payment links. For merchants taking recurring or repeat telephone orders, this means the customer reads out (or keys in) their card exactly once. The card data is never stored in your systems.
Send a Payment Link Instead
Not every caller wants to key digits. From the same Shuttle account, an agent can send a payment link by SMS or email mid-call, backed by the same Opayo profile. One gateway connection, multiple collection channels.
Multi-PSP: Beyond Opayo
One of the key advantages of using Shuttle rather than a single-gateway connector is flexibility. Your Twilio integration stays the same even if you:
Add a second gateway: serve your UK merchants with Opayo, and other regions with a local acquirer
Serve enterprise customers who mandate a specific PSP (Stripe, Worldpay, Checkout.com, etc.)
Want a backup gateway: if one gateway is unavailable, you can move the affected payment types to another connected gateway. There is no automatic failover, and saved cards stay with the gateway that stored them, so repeat payments on stored cards will not run through the second one
Expand to new markets, with each merchant or entity there on its own gateway
You choose which connected provider handles each payment type in Shuttle’s dashboard. Your Twilio call flow doesn't change. The <Pay> verb always points to shuttle-pay-connector, and Shuttle sends the payment to the provider you configured.
This is particularly important for BPOs and outsourced contact centres that serve multiple merchants. One client might be on Opayo, another on Stripe; each merchant's transactions go through their own gateway account via the same Twilio integration.
PCI Compliance
The Opayo + Twilio integration via Shuttle limits your PCI scope:
Layer | PCI handled by |
|---|---|
DTMF capture | Twilio |
Card data processing | Shuttle (PCI DSS Level 1) |
Payment processing | Opayo / Elavon |
Your systems | Merchants: SAQ-A. Platforms: SAQ-D. |
Card data flows from Twilio to Shuttle to Opayo. Your application only receives redacted data (last 4 digits, card brand, transaction reference). Merchants complete SAQ-A, the lightest PCI self-assessment; platforms complete SAQ-D. Everyone taking card payments has to be PCI compliant, and your acquirer confirms which form applies to you.
Contrast that with the traditional MOTO setup, where the agent hears the card number and types it into a terminal: the agent, their workstation, the call recording platform, and often the whole contact centre are in scope. For the full picture, see Twilio PCI Compliance: Payments Without Handling Card Data.
FAQ
Can I connect Opayo to Twilio without Shuttle? Twilio doesn't have a built-in Opayo Pay Connector. You'd need to build a custom connector using Twilio's Generic Pay Connector framework, which means handling PCI compliance for card data processing yourself. Shuttle provides a pre-built connector that is PCI DSS Level 1 certified.
I still know it as Sage Pay. Is this the same thing? Yes. Sage Pay was acquired by Elavon (a subsidiary of U.S. Bank) in 2019 and rebranded as Opayo. Your vendor account, credentials, and integrations carry the Opayo name, but it's the same UK gateway. Everything in this guide applies whether you signed up as Sage Pay or Opayo.
Where do I find my Opayo API credentials? In the MyOpayo portal, under the Administrator settings. You need three values: vendor name, integration key, and integration password. Opayo issues one set of API credentials per account, and the password is displayed only once at creation, so if you already integrate with Opayo elsewhere, reuse your existing keys.
What about Opayo's test environment? Fully supported. Opayo's test server mirrors the live system without banks attached. Use your test credentials in Shuttle and run the full Twilio flow before going live.
What does it cost? Shuttle charges $49 per live instance per month, plus from $0.20 per transaction, falling with volume, billed through your Twilio account. Opayo's standard fees apply on top.
Can I switch from Opayo to another gateway later? Yes. Change the gateway in your Shuttle payment profile. Your Twilio call flow stays exactly the same, with no code changes needed. Saved cards stay with the gateway that stored them, so repeat payments on stored cards will not move to the new gateway.
Related Reading
Twilio Pay Connectors: How to Connect Any Compatible Payment Gateway: the complete guide to Twilio Pay Connectors and multi-PSP routing
Twilio PCI Compliance: Payments Without Handling Card Data: how to keep your PCI scope limited
How to Connect Stripe to Twilio for Voice Payments: step-by-step Stripe + Twilio setup
How to Connect Adyen to Twilio for Voice & IVR Payments: step-by-step Adyen + Twilio setup
Payment Collection for BPOs: multi-client payment routing for outsourced contact centres
Opayo on Shuttle: supported channels and setup
Twilio Pay: Connect Any Compatible Payment Gateway to Twilio: all supported gateways, pricing, and setup
Connect Opayo to Twilio with Shuttle's Pay Connector: PCI DSS Level 1, $49 per live instance per month, plus from $0.20 per transaction, falling with volume, billed through your Twilio account. Install on Twilio or book a discovery call.