Migrating from Mint Payments

A practical guide for travel businesses migrating from Mint Payments (mPay) to Felloh. This covers concept mapping, code migration patterns, and a step-by-step migration plan so you can move with confidence.

Mint Payments and Felloh share some common concepts — both have bookings, payment links, and payment schedules. This makes migration more straightforward than moving from a general-purpose gateway. The key differences are in how these features work, the depth of travel-specific tooling, and the addition of AI agent integration via MCP.

Concept mapping

Understand how Mint Payments concepts translate to Felloh before writing any code.

Direct equivalents

These concepts map closely between the two platforms.

Different concepts

Felloh concepts with no Mint equivalent

These are features you gain by moving to Felloh.

Booking field mapping

Both platforms use bookings as a core concept. Here's how the key fields map.

Choosing a payment method

In Mint, you create a transaction token then submit a purchase, redirect to the HPP, or use the embedded OTT. In Felloh, you choose based on the scenario:

Code migration

Authentication

Mint uses a bearer API key with a company token in the request body. Felloh uses a public/private key pair to generate a bearer token.

import axios from 'axios';

// Mint — API key as bearer token, company token in body
const mintClient = axios.create({
  baseURL: 'https://api.mintpayments.com/v5',
  headers: {
    'Content-Type': 'application/json',
    Authorization: 'Bearer your-mint-api-key',
  },
});

const companyToken = 'your-company-token';
const businessUnitId = 'your-business-unit-id';

Creating a customer

Mint doesn't have a standalone customer creation API — customer details are embedded in bookings. Felloh has a dedicated customer resource.

// Mint — customer details embedded in the booking
const booking = await mintClient.post('/bookings', {
  companyToken,
  businessUnitId,
  bookingReference: 'TRIP-2026-001',
  customerName: 'Sarah Jones',
  customerEmail: 'sarah@example.com',
  // ... booking details ...
});

Creating a booking

Both platforms have booking creation — the fields map closely.

const booking = await mintClient.post('/bookings', {
  companyToken,
  businessUnitId,
  bookingReference: 'TRIP-2026-001',
  grossAmount: 150000,
  currency: 'GBP',
  customerEmail: 'sarah@example.com',
  customerName: 'Sarah Jones',
  departureDate: '2026-08-15',
  returnDate: '2026-08-22',
});

Collecting a payment

const paymentLink = await mintClient.post('/payment-links', {
  companyToken,
  businessUnitId,
  bookingReference: 'TRIP-2026-001',
  amount: 50000,
  currency: 'GBP',
  customerEmail: 'sarah@example.com',
  description: 'Deposit for August trip',
});

// paymentLink contains the URL to send to the customer

Processing a refund

const refund = await mintClient.post('/payments/refund', {
  companyToken,
  transactionId: 'original-transaction-id',
  amount: 20000,              // £200.00 partial refund
});
// Refund is processed in one step

Scheduling a future payment

Both platforms support payment schedules. Felloh's scheduled payments use tokenised cards from prior transactions rather than requiring explicit card tokenisation.

// Step 1: Tokenise the card
const cardToken = await mintClient.post('/payments/tokenize', {
  companyToken,
  // ... card details or reference ...
});

// Step 2: Create a payment schedule
const schedule = await mintClient.post('/payment-schedules', {
  companyToken,
  businessUnitId,
  bookingReference: 'TRIP-2026-001',
  amount: 100000,
  currency: 'GBP',
  cardToken: cardToken.data.token,
  scheduledDate: '2026-07-16',
});

Currency mapping

Mint uses standard ISO 4217 currency codes. Felloh uses minor-unit currency codes. Both use minor units for amounts, so the numeric values are the same — only the code changes.

const MINT_TO_FELLOH_CURRENCY = {
  GBP: 'GBX',
  USD: 'USX',
  EUR: 'EUX',
};

function convertCurrency(mintCurrency) {
  const fellohCurrency = MINT_TO_FELLOH_CURRENCY[mintCurrency.toUpperCase()];
  if (!fellohCurrency) {
    throw new Error(`Unsupported currency: ${mintCurrency}`);
  }
  return fellohCurrency;
}

// Amount values stay the same — both use minor units
// Mint:   { amount: 150000, currency: 'GBP' }
// Felloh: { amount: 150000, currency: 'GBX' }

Field naming conventions

Mint uses camelCase for field names. Felloh uses snake_case. Here's a quick reference for the most common fields.

What you can remove

Migrating from Mint to Felloh simplifies your integration in several areas.

Migration plan

A step-by-step approach to moving from Mint Payments to Felloh.

Phase 1 — Set up and validate

1. Create a Felloh account and generate sandbox API keys from the Sandbox Registration Form
2. Set up authentication — implement token generation and caching
3. Create a test booking and payment link to verify your integration works
4. Connect the MCP server (optional) — useful for exploring the API interactively during migration

Phase 2 — Migrate data

1. Audit your current Mint integration — identify all payment flows (payment links, HPP, direct API, payment schedules)
2. Create customers in Felloh — Mint embeds customer data in bookings, so extract it from there or your booking system
3. Create bookings for any active reservations — the booking model is similar, so this is largely a field mapping exercise
4. Map your existing booking references to Felloh bookings using the booking_reference field

Phase 3 — Migrate payment flows

1. Replace Mint payment links with Felloh payment links
2. Replace HPP / OTT integration with Felloh ecommerce sessions and the Felloh SDK
3. Replace payment schedules with Felloh scheduled payments
4. Replace refund calls with Felloh's two-stage refund process
5. Replace webhook handlers with Felloh webhook handlers
6. Remove explicit card tokenisation — Felloh tokenises automatically
7. Replace companyToken + businessUnitId with a single organisation ID

Phase 4 — Test in sandbox

1. Run through every payment flow in the Felloh sandbox
2. Test edge cases: declined payments, partial refunds, expired tokens
3. Verify webhook delivery and handling
4. Confirm customer-facing payment pages work correctly

Phase 5 — Go live

1. Switch to production API keys
2. Run Mint and Felloh in parallel for a transition period — new bookings go through Felloh, existing Mint payment schedules complete naturally
3. Monitor the Felloh Dashboard for transaction status
4. Decommission Mint integration

Common migration questions

Can I run Mint and Felloh in parallel? Yes. Route new bookings to Felloh and let existing Mint payment schedules complete. There's no conflict between the two.

The booking model is similar — is migration easier? Yes. Both platforms centre around bookings, so the conceptual shift is smaller than migrating from a general-purpose gateway. The main work is mapping field names (camelCase → snake_case) and switching currency codes (GBP → GBX).

Do I need to re-collect card details? Yes, for new payments. Mint card tokens are not transferable to Felloh. Customers will enter their card details on their first Felloh payment, and the card is automatically tokenised for future use.

What about PCI compliance? Felloh handles PCI compliance the same way — card details are collected via Felloh's hosted payment pages or SDK, never touching your servers.

Mint has open banking. Does Felloh? Yes. Felloh offers open banking as a payment method on every payment link and ecommerce session. Customers can choose to pay by card or bank transfer. The approach is simpler than Mint's consent-based model — it's just another payment option on the checkout page.

What about 3DS (Strong Customer Authentication)? Felloh handles 3DS automatically on payment links and ecommerce sessions. You can configure 3DS rules in Fraud Shield. No manual 3DS redirect handling required.

Can I use the Felloh MCP server during migration? Absolutely. Connect the MCP server to your AI editor and use it to explore the API, create test bookings, and debug your integration interactively. This is a feature Mint doesn't offer.