Shuttle

Shuttle is a white-label payment orchestration platform that routes payments across gateways and processors. Agents create and capture payments, refund and void, run recurring contracts, generate hosted checkouts and payment links, and manage accounts, instances, and routing.

1 trigger 70 actions Basic auth available

Shuttle website Platform Documentation Capability data verified 2026-08-25

Declines climb sharply on one processor inside a short window

List Transactions pulls the failing rows and the gateway each was routed through

Get Gateway Connection Status separates broken processor credentials from badly formed requests

Agent confirms the pattern follows one gateway rather than one card type, currency, or amount band

Get Gateway Payment Method Count reports how many stored cards are tied to that gateway

The payments owner decides whether to move traffic, knowing exactly what a move would strand

What This Integration Enables

Shuttle sits between a business and its processors, routing payments across several gateways and legal entities from one interface. That is the vendor's own framing of the product, and it makes the connector unusual: what this API can actually do is not a property of the API but of what is connected behind it, which is why it publishes a capabilities read rather than expecting you to assume. FlowRunner agents take payments through it, capture and void and refund, run recurring contracts and their arrears, generate hosted checkouts, payment links, and deep links, and manage accounts, gateways, instances, and legal entities across a group.

Two facts shape how an agent should behave here. The vendor returns a successful response for a declined payment, stating plainly that the request succeeded and the payment carries a decline status, so any flow that reads response codes rather than payment status will count declines as revenue. And stored payment methods belong to the gateway that tokenized them, so a routing change is never only a routing change. FlowRunner agents can hold both of those facts every time. The decision that follows from the second one belongs to a person, and human-in-the-loop is where it lands.

Without FlowRunner

An outage and a decline look identical A failed payment reports an error without saying whether the connection to the processor is the thing that broke

Success read off the response A request that completed is treated as a payment that completed

Portability assumed Moving traffic to another processor is planned as a configuration change, and the stored cards are discovered afterwards

With FlowRunner

The two told apart in one call Connection status answers whether the credentials with the processor still work, before anyone debugs a request body

Success read off the payment status The status field decides, so a decline is never counted as a sale

Portability measured before it is used The count of cards tokenized with a gateway is on the table before any traffic moves off it

Use Case Scenarios

One route, four different commitments

Create Payment does four separate jobs depending on what you send: a one-off charge, a charge scheduled for a future date, a recurring contract with a frequency and an occurrence count, and an explicit list of dated charges. The agent chooses deliberately rather than inheriting a default, because the difference between a single payment and an open-ended contract is one field. It sends a nonce so a retried flow deduplicates within the vendor's window instead of charging twice, it reads the payment status rather than the response, and where the action was an authorization it schedules the capture, because an authorization left uncaptured releases and nobody pays.
Arrears that get chased before they age

On a schedule the agent searches charges by outstanding amount and due date, which is the arrears report, and searches contracts by retry count to find the ones actively failing. For each failing contract it calls Create Payment Method Update URL and sends the customer a hosted page where they replace the card themselves, with no card data touching your systems. Get Future Charges answers the other half of the question, what this customer is going to be billed and when, which the charge history cannot tell you. The summary reaches the revenue team in Slack and the aged detail lands in Google Sheets for the collections review.
Onboarding a merchant environment on a platform account

A new merchant signs. Using a platform credential, the agent calls Create Instance to provision their isolated environment and sets the webhook target on it at creation, since that target replaces the application-level one for this instance rather than adding to it. Get Instance Capabilities then reports what that environment can actually do given the gateways behind it, which the agent writes back to the account record in HubSpot so sales knows which methods and currencies this merchant can be sold. Nothing is promised to the merchant that the connected processors cannot deliver.

Human-in-Loop Highlight

Get Gateway Payment Method Count exists for one reason, and the vendor says so: tokens belong to the gateway that created them, so migrating away from a gateway strands every card tokenized with it and every contract relying on those cards. Update Gateway is the operation on the other side of that fact, and rotating credentials on it reaches every payment routed through the gateway, including charges already scheduled on live contracts.

So when the triage flow decides one processor is genuinely broken rather than one request being malformed, the agent does not repoint anything. It posts the whole picture: "Gateway ADYEN-EU has returned connection failures for 41 minutes. 1,284 payment methods are tokenized with it and 903 active contracts charge through it. Moving traffic to WORLDPAY-EU strands those tokens and those contracts will fail at their next charge. Continue routing new payments to WORLDPAY-EU and leave contracts where they are, move everything, or hold?" That count is the number nobody has to hand during an incident, and it is precisely the number that decides the answer. The agent produces it in seconds. The person decides what it means.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

70 actions

Payments

Create Payment Takes a payment routed to whichever gateway applies. One route covers a one-off charge, a scheduled charge, a recurring contract, and an explicit schedule, and the payment status rather than the response is what says whether money moved.
Get Payment Reads one payment with its status, amount, and gateway response.
Capture Payment Captures funds on a payment created as an authorization. An authorization left uncaptured releases, and nobody pays.
Void Payment Cancels an uncaptured authorization and releases the hold. A captured payment is refunded instead.
Refund Payment Refunds a captured payment in whole or in part, or records one given back offline. Partial refunds against one payment are not supported by every processor.
Get Refund Reads one refund with its status and the transaction it reversed.
Get Void Reads one void with its status and the authorization it canceled.
Get Capture Reads one capture with its amount and status.
Refund Capture Refunds a specific capture rather than the payment as a whole, which matters when an authorization was captured in parts.

Transactions

List Transactions Searches every payment, capture, refund, and void in one ledger using the vendor's own search string, with related objects inlined to save a request per row.
Get Transaction Reads one transaction, whichever kind it is.

Accounts

Create Account Creates the customer record payments belong to. A payment sent without an account identifier gets a brand new account, which is how duplicate customer records accumulate.
List Accounts Searches accounts by name, email, phone, company, your CRM key, channel, tags, and activity dates.
Get Account Reads one account. Addressing it by a CRM key that several accounts share returns the first one created with it, not necessarily the one you meant.
Update Account Updates account details, with the same caution about shared CRM keys.

Payment Methods

Create Payment Method Tokenizes and stores a card, a direct debit mandate, or a bank account. Sending raw card details puts the flow in scope for card security requirements, which the hosted checkout avoids entirely.
List Payment Methods Searches the stored payment methods.
Get Payment Method Reads one stored method with its masked digits, expiry, and status.
Update Payment Method Updates a stored method, typically its expiry or billing address. The card number itself cannot be changed.
Delete Payment Method Removes a stored method. Any contract still pointing at it fails at its next charge, so those move first or the recurring revenue stops silently.

Contracts

List Contracts Searches the recurring agreements behind repeat payments. Searching on the next payment date answers what is about to be charged, and on retry count finds the ones failing.
Get Contract Reads one contract by id or by your own key. A shared key returns the most recent contract carrying it, which is the opposite rule to accounts.
Update Contract Updates a contract's schedule, payment method, amount, or status. Changing the amount cancels and clones by default, so the id a flow is holding stops being the live one unless in-place modification is requested.
Cancel Contract Stops all future charges on a contract. It does not write off an outstanding balance, which can survive the cancellation.
Create Contract Payment Takes a payment against an existing contract off its schedule, for collecting arrears without disturbing the recurring plan.
Refund Contract Refunds money taken under a contract without needing to know which individual payments it came from.
List Contract Charges Lists the charges raised under one contract, paid and unpaid.
Get Future Charges Works out the charges a contract will raise before they exist, which is a forecast rather than a history.
Create Payment Method Update URL Returns a hosted URL where a customer replaces the card behind a contract themselves. This is the dunning fix that keeps card data out of your systems.

Charges

List Charges Searches charges across contracts. Filtering on outstanding amount and due date is the arrears report.
Get Charge Reads one charge with its due date, amount, and outstanding balance.
Update Charge Changes a charge's status, amount, or due date. A due date set in the past may take the payment immediately, which is not what changing a date usually implies.

Checkout

Create Checkout Creates a hosted checkout session, which is how a payment is taken without handling card data at all. The session is addressed afterwards by its nonce rather than an id.
Get Checkout Reads one checkout session with its status and any payment it produced.
Delete Checkout Cancels a checkout session so it can no longer be paid.
Create Checkout Monitor Session Opens a session that lets your own front end watch a checkout progress, which is what the vendor recommends while a customer is sitting in front of the screen.

Payment Links

Create Payment Link Creates a URL you send a customer with no integration on your side. The link's id doubles as its payment nonce, and the expiry must be a future date.
Get Payment Link Reads one link with its status and, once paid, the account, contract, payment, and transaction it produced.
Update Payment Link Updates a link. The update mode decides whether a partially sent nested object is merged or replaced, so it is worth choosing rather than accepting.
Archive Payment Link Stops a link accepting payments while leaving the record and everything it produced readable.

Deep Links

Create Deep Link Creates a link that drops a customer into a specific step of a hosted flow, such as a saved-card update rather than a new payment.
Get Deep Link Reads one deep link with its URL and expiry.
Update Deep Link Updates a deep link's expiry or options.
Delete Deep Link Removes a deep link so it stops working.

Gateways

List Gateways Lists the gateways configured on this instance, which are your accounts with the actual processors.
Create Gateway Connects a processor to this instance. Credential shapes differ per processor, which the processor settings read reports.
Get Gateway Reads one gateway with its processor and status.
Update Gateway Updates a gateway's name or processor credentials. Rotating credentials reaches every payment routed through it, including charges already scheduled on contracts.
Get Gateway Connection Status Asks whether Shuttle can actually reach and authenticate with a processor, which separates broken credentials from a broken request.
Get Gateway Payment Method Count Counts the payment methods tokenized with one gateway. This is the number that decides whether a processor migration is survivable, and the one this page's human gate is built on.
Get Gateway Settings Reads what a gateway is configured to do, without opening the dashboard.

Processors and Capabilities

List Processors Lists the processors Shuttle can connect to, which is the catalog rather than what you have connected.
Get Processor Settings Reads what settings a processor accepts, which is what to read before creating a gateway rather than guessing.
Get Capabilities Reads what this instance can actually do given the gateways behind it: which methods, currencies, and features are available.

Instances

List Instances Lists the instances in your application. A platform operation, so it needs a platform credential rather than an instance key.
Create Instance Creates one merchant's isolated environment. The webhook target set here replaces the application-level target for that instance rather than adding to it.
Get Instance Reads one instance from the platform side.
Update Instance Updates an instance, most usefully its webhook target.
Delete Instance Deletes an instance, which is a whole merchant environment: its accounts, contracts, payment methods, and history.
Get Instance Capabilities Reads what one instance can do, from the platform side rather than the merchant side.

Legal Entities

List Legal Entities Lists the companies money is actually collected on behalf of, which matters for a group with several trading entities.
Get Legal Entity Reads one legal entity by id or code.
List Legal Entity Routes Lists the rules deciding which entity a payment is collected under, which is where a group's routing actually lives.
Get Legal Entity Route Reads one routing rule, which is what explains why a payment landed with one company rather than another.

Workflows

List Workflows Lists this instance's connections to outside systems such as a CRM or an accounting package.
Get Workflow Reads one of those connections with its status.
Get Workflow Connection Status Asks whether a connected outside system is reachable and authenticated, with the same diagnostic value as the gateway version.
Get Workflow Settings Reads the settings stored on one connection.

Webhooks

Attach Webhook Attaches a delivery destination to this instance. There are no event types to choose, so every event arrives and filtering is your side's job, and the target string itself encodes the retry and failover policy.
Detach Webhook Removes a delivery destination from this instance.

Triggers

1 triggers

Event Triggers

On Shuttle Event Fires when Shuttle reports a payment, capture, refund, or void resolving, a contract starting, updating, or completing, a charge created, updated, completed, or written off, a payment method, account, gateway, instance, or legal entity changing, or a payment link moving through its lifecycle. Because the platform delivers every event type to an attached destination, a flow built on this trigger reacts to a gateway change as readily as to a payment, which is what makes incident detection possible without polling.

Frequently Asked Questions

What can FlowRunner do with Shuttle?

FlowRunner agents can run Create Payment, Get Payment, and Capture Payment in Shuttle, plus 67 more actions.

Does connecting Shuttle to FlowRunner require OAuth?

No. Shuttle connects to FlowRunner with basic authentication (a username and password), no OAuth flow required.

Can Shuttle trigger a FlowRunner workflow automatically?

Yes. Shuttle supports 1 trigger that can start a FlowRunner workflow automatically.

Start building with Shuttle

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us