Forms of Payment (FOP) Engine: Control Payment Options Across Booking and Post‑Booking Flows
In travel agencies, payment choice is more than a checkout detail. It impacts fees, reconciliation, compliance, and booking speed.
But payment options aren’t unlimited. They start with airline relationships – each carrier supports specific payment methods based on their processing capabilities and BSP agreements. Then comes the commercial layer: the relationships negotiated with payment providers, where some charge transaction fees that erode margins, while others offer rebates or revenue share. Finally, there’s the organizational structure – hierarchies of sub-agents and POS locations, each potentially with different cost structures and compliance needs.
The result? In many booking flows, agents face payment complexity – wither too few options that limit flexibility, or too many that create confusion and drive up costs ,with little consideration for which choices actually make financial sense.
Modern agencies need both: comprehensive payment support and intelligent control.
The Forms of Payment (FOP) Engine gives you exactly that. We support all standard payment methods BSP Cash, major credit cards, agency credit, and IATA Easy Pay and give you the flexibility to configure which payment methods appear, where, and for whom, without adding complexity for frontline agents.
Built for TMCs, OTAs, and agency networks managing multiple teams, stores, or partner agencies.
This article explains how the FOP Engine works, where it applies, and most importantly how agencies use it in real-world scenarios to standardize payment behaviour across teams and stores.
What Are the Forms of Payment (FOP) Engine?
The FOP Engine allows travel agencies to configure rules that exclude specific payment methods from the payment screen during the shopping and booking process.
Instead of showing every supported payment method by default, the engine ensures that:
- Only approved payment methods are visible
- Rules can be applied centrally and inherited across POS hierarchies
- Agents see a simpler, cleaner checkout experience
The result: faster bookings, fewer errors, and better cost control.
Why the FOP Engine Matters
The FOP Engine isn’t about limiting choice – it’s about presenting the right choices at the right time.
What you get:
- Comprehensive payment support with visibility control
- Cleaner checkout experiences tailored to agent roles and contexts
- Consistent payment behaviour across teams
- Better financial control with minimal operational effort
What it demonstrates:
- Strong governance without slowing agents down
- Flexibility across booking and servicing flows
- A scalable approach to managing payments in complex agency structures
Where the FOP Engine Applies
The FOP Engine works across key booking and post-booking scenarios:
- Prime Booking flow
- Book and Hold
- Post Booking flow, including:
- Exchange
- Split Ticket
- Ancillaries / Seats
- Book and Hold in the Post Booking flow
This ensures consistent payment behaviour from initial booking through servicing and changes.
Supported Payment Methods
The FOP Engine supports a wide range of commonly used payment options, including:
- BSP Cash
- Credit Cards (CC):
- Visa International
- MasterCard
- American Express
- Discover Card
- Diners Club
- China UnionPay
- On Account With Agency (Credit Limit)
- IATA Easy Pay (IEP)
Rules determine which of these methods are visible to agents in specific contexts.
How the FOP Engine Works (Simple Flow)
Here’s what happens behind the scenes:
- A travel agent shops for offers and selects a flight.
- On the “How does your customer want to be invoiced for their flights?” screen: The engine checks the payment methods supported by both the supplier and organisation databases.
- The engine applies any configured exclusion rules
- Any payment method explicitly excluded is removed from the screen
- The agent selects from the remaining approved options and completes payment
If no exclusion rule exists, all supported payment methods remain visible.
How Payment Rules Scale Across an Agency
In agencies with multiple locations or teams, payment rules are typically set centrally by head office and then applied automatically to individual stores, teams, or sub-agent groups. This means a single configuration can control what payment methods appear at checkout across the entire organisation, without needing to manage each location separately. Teams can still operate independently day‑to‑day, but payment behavior stays consistent because everyone inherits the same approved rules unless explicitly overridden.
Practical Scenarios: How Agencies Use the FOP Engine
Scenario 1: Reducing Credit Card Fees Across All Stores
Problem:
A multi‑store travel agency allows multiple credit cards and BSP Cash at checkout. Agents choose payment methods freely, often defaulting to higher‑fee credit cards, even when lower‑cost options are available.
Solution with FOP Engine:
- Head office (Main Point Of Sale) creates a rule excluding specific credit card types
- individual stores, teams, or sub-agent groups
- Agents only see approved, cost-effective payment methods
Value delivered:
✅ Lower transaction fees
✅ Consistent payment behaviour
✅ No agent training required
Let’s Quantify the Impact
Assumptions (typical mid‑to‑large agency):
- 5,000 bookings per month
- Average ticket value: USD 600
- Monthly transaction volume: USD 3,000,000
Before FOP Engine
- 35% of payments via high‑fee cards (≈ 3.5%)
- 65% via lower‑cost methods (≈ 1.5%)
Monthly card fees:
- High‑fee cards:
35% × USD 3,000,000 × 3.5% = USD 36,750 - Lower‑cost methods:
65% × USD 3,000,000 × 1.5% = USD 29,250
✅ Total monthly fees: USD 66,000
After FOP Engine
- High‑fee cards excluded at checkout
- 90% of transactions routed to lower‑cost methods
Monthly card fees:
- Lower‑cost methods:
90% × USD 3,000,000 × 1.5% = USD 40,500 - Edge cases using higher‑fee cards:
10% × USD 3,000,000 × 3.5% = USD 10,500
✅ Total monthly fees: USD 51,000
✅ Estimated Savings
- USD 15,000 per month
- USD 180,000 per year
And this reduction is achieved without changing agent behavior only by controlling what appears on the payment screen.
Scenario 2: Simplifying Checkout for Frontline Agents
Problem:
Agents see 6–8 payment options at checkout, leading to confusion and occasional incorrect selections.
Solution with FOP Engine:
- Admin excludes rarely used or scenario-specific payment methods
- Checkout screen displays only 2–3 relevant options
Value delivered:
✅ Faster checkout
✅ Fewer booking errors
✅ Improved agent confidence
Scenario 3: Standardizing Payment Rules Across POS Hierarchies
Problem:
Different stores follow different payment practices, creating reconciliation issues and policy gaps.
Solution with FOP Engine:
- A Level 0 POS defines global exclusion rules
- Rules automatically apply to all subordinate POS levels (L3–L6)
Value delivered:
✅ Central governance
✅ Local execution
✅ No need to manage rules per store
Scenario 4: Controlling Payments in Post Booking Changes
Problem:
During exchanges or ancillaries purchases, agents unintentionally use payment methods not approved for servicing transactions.
Solution with FOP Engine:
- Exclusion rules apply in post booking flows
- Only allowed payment methods appear during exchanges and seat/ancillary purchases
Value delivered:
✅ Consistent servicing behaviour
✅ Reduced financial risk
✅ Cleaner post-booking operations
Scenario 5: Using “On Account” Only for Approved Teams
Problem:
Agency credit limits should only be used by specific teams, but the option appears for everyone.
Solution with FOP Engine:
- Exclude On Account With Agency payment method for selected POS levels
- Allow it only where credit usage is approved
Value delivered:
✅ Better credit control
✅ Reduced misuse
✅ Stronger financial governance
Scenario 6: Preventing ‘ADM’ Risk When Working with Sub‑Agencies
Consolidators and larger agencies often work with sub‑agencies or newly onboarded agencies that issue tickets on their behalf. While this expands reach, it also introduces financial risk especially when tickets are issued using BSP Cash.
If a sub‑agency makes an error (for example, incorrect ticketing or fare handling), the mother agency may receive an ADM (Agency Debit Memo) from the airline, This results in unexpected costs, disputes, and reconciliation effort that are difficult to recover after the fact. To reduce this risk, many consolidators prefer to limit which payment methods are available at checkout.
Configuration Best Practices
FOP exclusion rules do not apply in the following scenarios if a Validating Carrier or Fare Type is configured within a rule:
- Book and Hold
- Exchange (Reshop/Reprice)
- EMD issuance in the post-booking flow
Understanding these conditions helps avoid unexpected behaviour and ensures rules are designed correctly.
Roles and Permissions: Who Can Do What
Before using the FOP Engine, roles must have the correct permissions enabled:
- Form of Payments – Enables access to the FOP Engine feature
- Read – View the FOP Rule List
- Write – Create, update, and delete FOP rules (L0 and L1 only)
Additional admin capabilities include:
- Export rules to an .xlsx file
- Filter rules for easier management
- View change history for audit and governance purposes
Ready to take control of your payment operations?
- Explore how to configure FOP rules for your agency
- Review supported payment methods and scenarios
- Book a product walkthrough to see the FOP Engine in action
