At felloh, we’ve always believed travel payments are deeply connected to the rest of the operational stack, bookings, reconciliation, customer communications, protection requirements, refunds, reporting, and finance workflows.
Our recent SDK release was about making those connections easier for developers to build into their own systems. The launch of the felloh MCP server is the next step, making those same workflows accessible to AI tools and conversational interfaces.
The result is not a separate AI product or isolated automation layer. It is another way for businesses to interact with the same connected payment infrastructure they already use today.
What is MCP, and why does it matter?
Model Context Protocol (MCP) is an open standard that allows AI tools to connect directly to external systems and services.
Tools such as Cursor, VS Code, Claude Desktop, Claude Code, Windsurf, and ChatGPT can use MCP servers to securely access live operational data and perform actions conversationally. Rather than manually navigating dashboards or writing API calls from scratch, developers and operators can interact with systems through natural language while still using structured, production-grade infrastructure underneath.
For travel businesses, this matters because operational workflows rarely live in one place.
Booking systems, payment providers, finance tools, ledgers, approval flows, and reconciliation processes are often spread across multiple systems. Even relatively simple operational tasks, such as checking a balance payment, generating a payment link, or processing a refund, typically require moving between several tools and data sources.
The felloh MCP server gives AI agents a structured way to interact with those workflows conversationally, without businesses needing to build custom glue between systems themselves.
How the felloh MCP server works
The felloh MCP server is hosted at https://mcp.api.felloh.com and connects directly to your existing felloh account using your API key pair.
There is nothing to deploy or self-host. You simply configure your preferred AI tool to point at the MCP endpoint and pass your public and private API keys as headers.
Authentication and token management are handled automatically behind the scenes, so developers can focus on operational workflows rather than session handling.
The server currently supports setup across:
- Cursor
- VS Code
- Claude Desktop
- Claude Code
- Windsurf
- ChatGPT
Each platform requires only a small configuration block to establish the connection.
Full setup instructions are available in the developer documentation:
What your AI agent can access
The MCP server exposes a broad set of operational tools across the felloh platform.
This is not a simplified “AI summary” layer. The MCP server provides structured access to the same operational capabilities already available through the felloh API.
AI agents can:
- Create, update, search, and manage bookings
- Generate and manage payment links
- Create ecommerce payment sessions
- Issue refunds
- Complete pre-authorised transactions
- Reassign transactions between bookings
- Access customer and supplier records
- Create scheduled payments using tokenised cards
- Generate approval links
- Review chargebacks and charges
- Query ledger entries with filtering
- Access disbursements and credit notes
- Create and activate beneficiaries
- Search felloh developer documentation directly from the editor
Importantly, these capabilities remain grounded in the same operational controls and permissions businesses already use today.
Conversational workflows for travel operations
What makes MCP interesting is not that it replaces APIs or existing systems. It changes how developers and operators can interact with them.
Traditional integrations are procedural. A developer writes logic for a specific workflow and hardcodes the sequence of API calls required to complete it.
With MCP, the interaction layer becomes conversational.
Instead of manually stitching together multiple systems or navigating several dashboards, an AI agent can orchestrate operational steps using the appropriate tools and context in real time.
Booking and deposit collection
Consider a customer booking flow.
A well-configured AI agent can:
- Find or create the customer record
- Create the booking
- Calculate the required deposit based on company policy
- Generate a payment link
- Send the payment link to the customer
- Schedule the balance payment using a tokenised card once the deposit has been paid
Each step maps to a specific MCP tool. The agent selects and sequences the relevant actions based on the operational context and customer conversation.
Balance collection workflows
The same applies to balance management.
An AI-assisted workflow can:
- Check outstanding balances
- Review existing scheduled payments
- Cancel duplicate scheduled collections
- Generate updated payment links
- Reconcile payment status against the booking
These are tasks operations and finance teams already perform daily. MCP simply provides a new interaction layer for accessing them.
Refund workflows
Refund handling is another example where conversational workflows become useful operationally.
An AI agent can:
- Retrieve the relevant booking
- Check cancellation terms
- Calculate refund eligibility based on departure date
- Identify the original transactions
- Initiate refunds across multiple payments if required
Importantly, these workflows still operate within the operational controls defined by the business.
Guardrails and operational controls
Giving AI tools access to payment operations naturally requires clear safeguards.
In practice, production-ready workflows still need the same operational controls travel businesses already apply today.
For example:
- Refunds above a certain threshold may require manager approval
- Chargebacks may need immediate escalation to a disputes team
- Failed payment attempts may trigger human review
- Certain booking states may block automated actions entirely
If an agent is uncertain about policy or encounters conflicting information, the workflow should escalate to a human operator.
We view this as an important part of building AI-assisted operational tooling responsibly. The objective is not uncontrolled automation. It is creating faster, more connected operational workflows while maintaining appropriate oversight.
Our documentation includes guidance on:
- System prompt design
- Escalation patterns
- Human-in-the-loop workflows
- Error handling
- Expired token management
- Disputed payment handling
- Missing booking resolution
Further guidance is available here:
Testing safely in the sandbox
The felloh sandbox environment works identically with MCP, allowing teams to test workflows end-to-end before connecting to production environments.
We strongly recommend validating all major operational flows using sandbox credentials first, including:
- Deposit collection
- Balance payments
- Refund handling
- Failed payment scenarios
- Approval workflows
- Escalation logic
This is also important for validating operational edge cases, particularly around:
- Minor currency units
- Duplicate payments
- Missing bookings
- Partial refunds
- Expired payment methods
- Transaction reassignment
The goal is not simply to verify API connectivity, but to ensure operational workflows behave predictably in real-world scenarios.
APIs, SDKs, and MCP together
We do not see MCP as replacing APIs or SDKs.
Different businesses operate at different stages of technical maturity and require different integration approaches.
At felloh, we increasingly think about connectivity in layers:
- The API provides low-level, fully flexible access for custom implementations
- The SDKs provide structured, language-native tooling for application development
- The MCP server enables conversational and agentic operational workflows
These are complementary approaches, not competing ones.
Some businesses will continue building directly against APIs. Others will prefer SDKs for developer ergonomics. Increasingly, some teams will also want conversational access to operational infrastructure through AI tooling.
Our goal is simply to make the underlying infrastructure accessible in the way that best fits how each business operates.
Connected infrastructure, not isolated tooling
The launch of the MCP server reflects a broader direction we believe travel technology is moving toward.
Operational systems are becoming more connected. The boundaries between finance workflows, payment operations, customer servicing, and conversational tooling are starting to blur.
We think the next generation of travel operations will rely less on isolated systems and more on connected infrastructure that can be accessed flexibly through APIs, applications, and increasingly conversational interfaces as well.
That is ultimately what the felloh MCP server is designed to support.
Not a separate AI product.
Not another disconnected operational tool.
Just another way to interact with connected travel payment infrastructure.
Getting started
The felloh MCP server is available now and can be connected using your existing API credentials.
Documentation, setup instructions, available tools, and implementation guidance are available here:
.svg){kind=small}
.png){kind=small}
.svg){kind=small}
.svg){kind=small}
.png)
.png)
.png)
.svg)
.avif)
.png)
.png)
.png)
.png)
.png)
