How to Connect Opayo to Twilio for Voice & IVR Payments

By Shuttle Team, June 27, 2026

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, with tones suppressed so agents never hear them.

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. As Twilio's official payment partner, 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 ``

  1. Caller reaches payment step. Your Twilio call flow (IVR, Studio, or custom TwiML) triggers the <Pay> verb.

  2. Card details captured via DTMF. The caller enters their card number, expiry, and CVV on the keypad. Tones are suppressed from the agent audio and call recordings.

  3. Shuttle receives card data. The data passes from Twilio's PCI-compliant environment directly to Shuttle's connector. It never touches your servers.

  4. Shuttle charges the card via Opayo. The connector creates an Opayo transaction, processes it through your Opayo vendor account, and handles the response.

  5. 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 entire flow happens in seconds. The caller stays on the line. For merchants used to reading card numbers back for confirmation, it's a step change: faster, quieter, and out of PCI scope.


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, you pay per transaction)

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 or Twilio Studio flow:

``xml <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 to shuttle-pay-connector

  • chargeAmount: the amount to charge

  • currency: ISO currency code

  • action: 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:

``json { "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: route UK transactions to Opayo and other regions to a local acquirer

  • **Serve enterprise customers** who mandate a specific PSP (Stripe, Worldpay, Checkout.com, etc.)

  • Need failover: if one gateway is unavailable, automatically route to a backup

  • Expand to new markets where a different acquirer gives better authorisation rates

You configure routing rules in Shuttle's dashboard. Your Twilio call flow doesn't change. The <Pay> verb always points to shuttle-pay-connector, and Shuttle handles which gateway processes the transaction.

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 keeps you completely out of PCI scope:

Layer

PCI handled by

DTMF capture & suppression

Twilio

Card data processing

Shuttle (PCI DSS Level 1)

Payment processing

Opayo / Elavon

Your systems

No card data (SAQ-A)

Card data flows from Twilio to Shuttle to Opayo. Your application only receives redacted data (last 4 digits, card brand, transaction reference). You qualify for SAQ-A, the lightest PCI self-assessment.

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, PCI-certified connector that handles this.

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.

Does this work with Twilio Studio? Yes. Twilio Studio supports the <Pay> widget. Configure it with shuttle-pay-connector as the connector and the payment flow works within your Studio flow.

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 $0.20 per successful transaction. Opayo's standard fees apply on top. No Shuttle setup fees or monthly minimums.

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.


Related Reading


*Connect Opayo to Twilio in minutes with Shuttle's Pay Connector: PCI DSS Level 1, $0.20/transaction, no setup fees. Install on Twilio or book a discovery call.*

Talk to us

See how Shuttle can power payments for your platform — multi-PSP, multi-channel, white-label.

Book a Demo