Migrating from Trust Payments

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

Trust Payments has been a popular choice for UK travel businesses, particularly those needing trust account support. However, its API is showing its age — XML-based request formats, complex site reference authentication, and limited tooling for modern agent-based workflows. Felloh provides a modern JSON REST API with native booking management, scheduled payments, and AI agent integration via MCP.

Concept mapping

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

Direct equivalents

Different concepts

Felloh concepts with no Trust Payments equivalent

These are features you gain by moving to Felloh.

No Felloh equivalent

The booking model

The biggest conceptual shift is that every payment in Felloh is tied to a Booking. In Trust Payments, you submit an AUTH request with an orderreference — the gateway has no concept of what the payment is for. In Felloh, you create a booking first, then collect payments against it.

Trust Payments flow:
  orderreference → AUTH request → Settlement
  (you maintain the link to your booking system)

Felloh flow:
  Customer → Booking → Payment Link / Ecommerce / Scheduled Payment → Transaction
  (booking is a first-class object — payments are linked automatically)

This means you can remove any custom code that links Trust Payments transaction references to your booking system. Felloh handles this relationship natively.

Choosing a payment method

In Trust Payments, you submit an AUTH request (direct API) or redirect to Payment Pages. In Felloh, you choose based on the scenario:

Code migration

Authentication

Trust Payments uses a site reference, username, and JWT (or the older XML-based authentication with site reference and security code). Felloh uses a public/private key pair to generate a bearer token.

import axios from 'axios';
import jwt from 'jsonwebtoken';

// Trust Payments — generate JWT for Webservices API
const payload = {
  iss: 'jwt.user@example.com',        // JWT username
  iat: Math.floor(Date.now() / 1000),
  payload: {
    requesttypedescriptions: ['AUTH'],
    sitereference: 'your_site_reference',
    // ... payment details ...
  },
};

const token = jwt.sign(payload, 'your-jwt-secret-key');

const response = await axios({
  method: 'post',
  url: 'https://webservices.securetrading.net/jwt/',
  headers: { 'Content-Type': 'application/json' },
  data: { jwt: token },
});

Creating a customer

Trust Payments doesn't have a dedicated customer creation API — billing details are passed with each payment request. Felloh has a dedicated customer resource.

// Trust Payments — customer details embedded in the AUTH request
const payload = {
  requesttypedescriptions: ['AUTH'],
  sitereference: 'your_site_reference',
  billingemail: 'sarah@example.com',
  billingfirstname: 'Sarah',
  billinglastname: 'Jones',
  billingstreet: '10 Downing Street',
  billingtown: 'London',
  billingpostcode: 'SW1A 2AA',
  billingcountryiso2a: 'GB',
  // ... payment details ...
};

Creating a booking (new concept)

This has no Trust Payments equivalent — it's the step that replaces your custom booking-to-payment mapping.

const response = await axios({
  method: 'post',
  url: 'https://api.felloh.com/agent/bookings',
  headers: {
    'Content-Type': 'application/json',
    Authorization: `Bearer ${token}`,
  },
  data: {
    organisation: 'your-organisation-id',
    booking_reference: 'TRIP-2026-001',
    gross: 150000,            // £1,500.00 in pence
    currency: 'GBX',
    customer_email: 'sarah@example.com',
    customer_name: 'Sarah Jones',
    departure_date: '2026-08-15',
    return_date: '2026-08-22',
  },
});

Collecting a payment

import jwt from 'jsonwebtoken';

const payload = {
  iss: 'jwt.user@example.com',
  iat: Math.floor(Date.now() / 1000),
  payload: {
    requesttypedescriptions: ['AUTH'],
    sitereference: 'your_site_reference',
    accounttypedescription: 'ECOM',
    currencyiso3a: 'GBP',
    baseamount: 50000,          // £500.00 in pence
    orderreference: 'TRIP-2026-001-DEP',
    billingemail: 'sarah@example.com',
    billingfirstname: 'Sarah',
    billinglastname: 'Jones',
    // Card details collected via JS Library or Payment Pages
  },
};

const jwtToken = jwt.sign(payload, 'your-jwt-secret-key');
const response = await axios.post(
  'https://webservices.securetrading.net/jwt/',
  { jwt: jwtToken }
);

Processing a refund

const payload = {
  iss: 'jwt.user@example.com',
  iat: Math.floor(Date.now() / 1000),
  payload: {
    requesttypedescriptions: ['REFUND'],
    sitereference: 'your_site_reference',
    parenttransactionreference: 'original-transaction-reference',
    baseamount: 20000,          // £200.00 partial refund
  },
};

const jwtToken = jwt.sign(payload, 'your-jwt-secret-key');
const response = await axios.post(
  'https://webservices.securetrading.net/jwt/',
  { jwt: jwtToken }
);
// Refund is processed immediately

Scheduling a future payment

Trust Payments supports subscriptions for recurring payments, but they use fixed intervals (daily, weekly, monthly). Travel installments need specific dates. With Trust Payments, you typically store the transactionreference from an initial payment and run your own cron job.

// Step 1: Initial payment stores the card via ACCOUNTCHECK or AUTH
const initialPayload = {
  requesttypedescriptions: ['AUTH'],
  sitereference: 'your_site_reference',
  credentialsonfile: 1,         // Store credentials for future use
  // ... card and payment details ...
};

// Step 2: Store the transactionreference in your database
// Step 3: Build a cron job to charge on the right date

// When cron triggers, submit AUTH with stored reference:
const recurringPayload = {
  requesttypedescriptions: ['AUTH'],
  sitereference: 'your_site_reference',
  parenttransactionreference: 'stored-transaction-reference',
  baseamount: 100000,          // £1,000.00
  currencyiso3a: 'GBP',
  credentialsonfile: 2,         // Merchant-initiated transaction
  orderreference: 'TRIP-2026-001-BAL',
};

Currency mapping

Trust Payments uses ISO 4217 currency codes with amounts in minor units (baseamount). Felloh uses minor-unit currency codes. The numeric values are the same — only the code changes.

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

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

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

Webhook event mapping

Trust Payments uses URL notifications configured in the MyST portal. Felloh uses standard webhooks with HMAC-SHA256 signatures configured via the API.

Migrating a notification handler

app.post('/notifications/trustpayments', express.urlencoded({ extended: true }), (req, res) => {
  // Trust Payments sends form-encoded POST notifications
  // Verify using the notification hash (configured in MyST)
  const {
    transactionreference,
    settlestatus,
    errorcode,
    orderreference,
    notificationreference,
    responsesitesecurity,
  } = req.body;

  // Validate site security hash
  // (hash algorithm configured in MyST portal)

  if (errorcode === '0' && settlestatus === '100') {
    handlePaymentSuccess(orderreference, transactionreference);
  } else if (errorcode !== '0') {
    handlePaymentFailure(orderreference, errorcode);
  }

  res.send('OK');
});

What you can remove

Migrating from Trust Payments to Felloh lets you remove significant custom code.

Migration plan

A step-by-step approach to moving from Trust 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 — Audit and plan

1. Identify your Trust Payments integration type — Webservices API (JWT), Payment Pages (STPP redirect), JS Library, or a combination
2. List all payment flows — initial AUTH, stored credential charges, subscriptions, MOTO
3. Review MyST configuration — note any fraud rules, notification URLs, and payment page templates that need to be recreated in Felloh
4. Create customers in Felloh — pull customer data from your booking system
5. Create bookings for any active reservations

Phase 3 — Migrate payment flows

1. Replace Payment Pages (STPP) with Felloh payment links
2. Replace JS Library integration with Felloh ecommerce sessions and the Felloh SDK
3. Replace stored credential charges (cron jobs with parenttransactionreference) with Felloh scheduled payments
4. Replace REFUND requests with Felloh's two-stage refund process
5. Replace URL notification handlers with Felloh webhook handlers
6. Remove JWT generation code — Felloh uses a simpler bearer token
7. Remove settle status parsing — Felloh uses clear event types

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 Trust Payments and Felloh in parallel for a transition period — new bookings go through Felloh, existing Trust Payments subscriptions and scheduled charges complete naturally
3. Monitor the Felloh Dashboard for transaction status
4. Decommission Trust Payments integration and remove legacy code
5. Close MyST portal configuration (notification URLs, fraud rules — now in Felloh)

Common migration questions

Can I run Trust Payments and Felloh in parallel? Yes. Route new bookings to Felloh and let existing Trust Payments subscriptions and scheduled charges complete. There's no conflict between the two.

Do I need to re-collect card details? Yes, for new payments. Trust Payments stored credentials (transactionreference 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. If you were using Trust Payments' JS Library for card tokenisation, the Felloh SDK provides equivalent security.

I use Trust Payments subscriptions. How do they translate? Trust Payments subscriptions repeat at fixed intervals (daily, weekly, monthly). Felloh scheduled payments are more flexible — each one has a specific date and amount. For a travel installment plan, create individual scheduled payments rather than a subscription. This gives you full control over amounts and timing.

I have fraud rules configured in MyST. Can I replicate them? Yes. Felloh Fraud Shield supports 3DS rules, card rules, customer rules, device fingerprinting, location checks, and velocity limits. Configure them in the Felloh Dashboard. Most MyST fraud rules have a direct equivalent in Fraud Shield.

What about 3DS (Strong Customer Authentication)? Felloh handles 3DS automatically on payment links and ecommerce sessions. You can configure 3DS rules in Fraud Shield — for example, setting velocity thresholds for when 3DS challenges are triggered. No more manual 3DS configuration in MyST.

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.