Shuttle is sold in several shapes — Embedded Payments for Platforms, Payment Links for Platforms, Payment Links, Twilio Pay — but they are packagings of one platform for different audiences. This page is the platform itself: what it can actually do, in one place, so you do not have to read four product sections to find out whether it does the thing you need.
Each capability names where the detail is. Where a product does not expose a capability, that is a packaging decision rather than a limit of the platform, so ask if you need it.
| Capability | Notes | Where |
|---|
| Take a payment | Card, bank debit, wallet or a gateway-hosted page. One call, whatever the method. | Take a one-off payment |
| Authorise now, capture later | Reserve funds, then capture some or all of them, or release what you do not take. | Capture · Void |
| Refund | Full or partial, through the processor, or recorded as settled outside Shuttle where the merchant refunded another way. | Refund a payment |
| Save a payment method without charging it | Tokenise a card or bank account for later, with no money moving. | Save a payment method |
| Take a payment for the customer | A member of the merchant's staff takes a payment on someone's behalf, on the phone or against arrears. | Merchant View |
| Take card details over the phone safely | The customer keys the card into the call, or an agent drives the capture, without the number reaching the agent. | Twilio Pay |
| Correct the record | Mark a payment the processor never confirmed as approved or declined; attribute money that arrived without a home; reverse a refund recorded in error. | Business Rules |
| Capability | Notes | Where |
|---|
| Recurring | A charge per billing cycle, for a fixed number of collections or open-ended. | Payment Types |
| Scheduled one-time | A single payment agreed now and taken on a future date. | Payment Types |
| Instalment schedules | Every charge set out up front, each with its own amount and date. Irregular plans are fine. | Payment Types |
| Change an agreement | Amount, frequency, dates, the number of collections, the payment method — either in place or as a replacement. | Amend a contract · Amend instalments |
| Pause and restart | Suspend collection without losing what is owed, then resume. | Suspend · Resume |
| Handle arrears | Collect what is owed now, move the next attempt, or write a charge off so it stops being chased. | Collect arrears · Write off a charge |
| Retry failures automatically | On the merchant's schedule, with technical errors and declines treated differently. | Scheduler |
| Respect bank debit lead times | Methods needing advance notice are lodged early enough to settle on the due date. | Scheduler |
| End an agreement | Stop future charges, with or without writing off the balance, and with or without refusing to finalise over an in-flight payment. | Terminate a contract |
| Capability | Notes | Where |
|---|
| Accounts | A payer record holding details, saved payment methods and full history. Keyed by your own reference (crm_key) as well as ours. | Create an account |
| Saved payment methods | Several per account, each held as a token at the processor. Shuttle never holds the number. | Core Concepts |
| Search | Across accounts, contracts and transactions, with filters, from the screens or the API. | Merchant View |
| Notes and attachments | Free-text notes with files against an account, contract, payment or payment method. | Add or edit a note |
| Audit history | Who changed what, and when, on every record. | Sections on every screen |
| Capability | Notes | Where |
|---|
| More than 50 processors | One integration. OAuth where the processor supports it, API keys where it does not. | Processors |
| Several processors per merchant | Run new business through one while an old connection still holds saved cards and refunds old transactions. | Merchant Setup |
| Route by payment method | Send cards to one processor and a wallet to another. | Route a payment method |
| Restrict by currency or amount | Turn a method off for a currency, or above or below a threshold. | Amount rules |
| Fraud screening | Connect a third-party tool and screen payments on a route before they are taken. | Connect a fraud workflow |
| Wallets | Apple Pay and Google Pay, including the network tokenisation that goes with them. | Apple Pay & Google Pay |
| Buy now, pay later messaging | Provider messaging injected into your product and checkout pages. | BNPL Messaging |
| Several legal entities | One merchant collecting under more than one entity, with its own routing and currencies. | Business Rules |
| Capability | Notes | Where |
|---|
| Hosted checkout | Embedded in your page or opened on its own. Card data and PCI scope stay with Shuttle. | Checkout · Guide |
| Payment links | A checkout prepared in advance and shared as a URL. Reusable, or personalised per customer. | Payment Links |
| Merchant self-service setup | Merchants connect their own processor without your engineers or your support team. | Merchant Setup · Guide |
| A console for merchant staff | Search, take payments, refund, manage agreements and payment methods — embedded in your product. | Merchant View · Guide |
| Your branding, your wording | Fonts, colours and spacing on the components; the actual words a customer reads are editable per brand. | Merchant View - Admin |
| Switch any of it off | Every action a console exposes can be turned off per application or per embed. | Merchant View Options |
| Capability | Notes | Where |
|---|
| Multi-tenancy | One instance per merchant, provisioned by you through the API. Merchants need never know Shuttle exists. | Instances |
| Applications | Group instances by product line or region, each with its own credentials, webhook destination and defaults. | Applications |
| Roles and permissions | Four roles out of the box, or manage the underlying permissions yourself. | Roles and permissions |
| Webhooks | Real-time notification of payment, contract, charge and payment method events. | Webhooks |
| Sandbox and live | Separate credentials and configuration, so a change can be proved before it reaches production. | Testing |
| REST API for everything | Every operation a screen performs is available directly, following the same rules. | API reference |
A few things that are true of the platform and shape what you build:
- Shuttle is not the processor. The merchant's own processor account takes the money and holds the relationship. Shuttle connects to it, so a merchant keeps their rates and their existing account.
- Card data never reaches your platform. Everything that touches a card number does so inside a Shuttle-hosted iFrame or a processor's own page.
- One-off payments are simple; the machinery underneath is shared. A single purchase is a contract with one charge, which is why one set of rules and one set of webhooks serves a £5 payment and a three-year plan — but you read a single
payment object in the response and can ignore the rest. See Core Concepts.
- No receipt reaches the payer automatically. The checkout shows a receipt page and
success_email mails addresses you name, but sending the payer their own receipt is yours to do.
- A screen is sometimes stricter than the API. Where that is deliberate, the rule page says so, so you know what a direct call would still be allowed to do.
| Product | For | Start at |
|---|
| Embedded Payments for Platforms | SaaS platforms offering payments as a native, white-labelled feature. You provision merchants; they never deal with Shuttle. | Introduction |
| Payment Links for Platforms | Platforms whose merchants hold their own Shuttle account and connect it by OAuth. | Introduction |
| Payment Links | Merchants using Shuttle's hosted links directly, with no platform in between. | Payment Links |
| Twilio Pay Connector | Taking card details over the telephone, for merchants whose calls run on Twilio or who can hand the payment segment to it. | Twilio Pay |
How much you build is a separate decision from which product you use: see Platform Integration Approaches.
