A B2B travel portal is not just a login area where agents search flights and hotels. It is a distribution system that connects suppliers, standardizes data, applies pricing rules, controls credit, manages bookings, and keeps finance records aligned.
The architecture behind it must handle slow suppliers, duplicate hotels, changing prices, agent-specific markups, cancellations, refunds, and reconciliation.
What Does B2B Travel Portal Architecture Look Like?
A practical architecture follows this flow:
Agent portal → booking engine → supplier adapter layer → normalized search model → pricing and credit rules → booking workflow → documents and finance → monitoring and reporting
The agent portal handles search and booking. Supplier adapters communicate with external systems. Pricing decides what each agent sees and pays. The booking layer manages every state from price recheck to refund. Finance connects supplier cost, selling price, commission, payment, and settlement.
These responsibilities should remain separate. A supplier API change should not require redesigning the agent interface, and a new markup rule should not require rebuilding every connector.
Businesses needing an agent-facing platform can review the PHPTRAVELS B2B travel portal alongside this guide.
What Is the Supplier Adapter Layer?
The supplier adapter layer connects the portal with each external inventory source.
A portal may use GDS, NDC, bedbanks, wholesalers, direct contracts, and other XML or JSON feeds. Each source can use different authentication, fields, currencies, errors, and booking methods.
An adapter translates those differences into the portal’s internal format. The booking engine can then use one standard request instead of carrying separate supplier logic throughout the application.
A reliable adapter handles authentication, request formatting, response parsing, errors, timeouts, retries, and supplier references. Keeping this logic isolated makes integrations easier to test and maintain. See PHPTRAVELS’ travel API integration overview for more context.
How Does Supplier Aggregation Work?
Supplier aggregation means searching several inventory sources and combining their responses into one useful result set.
When an agent searches, the orchestration layer sends requests to relevant suppliers in parallel. As responses arrive, the system validates them, converts them into the normalized model, removes unusable records, and prepares results for pricing.
The system must preserve the source behind every rate. A result may look consistent to the agent, but booking must return to the correct supplier with the right rate key, session token, price, and cancellation conditions.
Aggregation is therefore more than displaying several feeds. It must preserve enough supplier data to complete and service each booking safely.
What Is a Normalized Search Model?
A normalized search model is one internal structure for results from different suppliers.
For hotels, it may include property IDs, rooms, occupancy, cancellation policy, price, currency, and rate key. For flights, it may include segments, cabin, baggage, rules, price, and supplier reference.
Without normalization, filters, sorting, markup calculation, and reporting would need different code for every source.
Normalization should not remove important detail. Supplier-specific conditions must remain available when they affect booking, cancellation, ticketing, or payment. PHPTRAVELS explains this hotel-focused model on its hotel booking system API page.
How Are Duplicate Hotels and Rooms Removed?
Hotel deduplication combines supplier records that refer to the same physical property.
Different suppliers may use different property IDs, spellings, addresses, images, or ratings. A portal that simply joins their responses can show the same hotel several times.
A mapping layer assigns one internal hotel ID to matched records. Matching may use coordinates, addresses, phone numbers, names, postal codes, and a maintained mapping table. Low-confidence matches should be reviewed rather than merged automatically.
Room mapping is harder. “Deluxe King,” “King Deluxe Room,” and “Superior King” may be similar, but bed type, occupancy, meals, cancellation terms, and inclusions can differ. The system should use a controlled room taxonomy without hiding meaningful differences.
The goal is one clear property listing with comparable rates and accurate conditions.
How Should Caching and Response Times Be Managed?
Caching should improve speed without presenting stale prices as bookable.
Static hotel content such as descriptions, amenities, images, and destination data can be stored locally and refreshed on a schedule. Live rates, availability, fare rules, cancellation terms, and booking status should be checked when required.
The orchestration layer should set a timeout for each supplier. A slow source should not block every other result. The portal can return available responses, record the timeout, and decide whether late results may still be added.
Useful controls include response-time tracking, health scores, retry limits, and circuit breakers.
How Does the Markup Hierarchy Work?
The markup hierarchy turns a net supplier price into the selling price shown to an agent.
Rules may be set by product, supplier, destination, route, airline, hotel, agent group, individual agent, booking value, season, or channel. A rule may use a percentage, fixed amount, minimum margin, maximum margin, or a combination.
The system needs a clear order of precedence:
Global rule → product rule → supplier rule → agent-group rule → individual-agent override
When several rules match, the portal must know whether to replace, add, or ignore a lower-priority rule.
Every final price should retain an audit record showing supplier cost, taxes, currency conversion, markup, discount, and selling total.
How Are Agent and Sub-Agent Commissions Calculated?
Markup and commission are related, but they are not the same.
Markup is added to supplier cost. Commission is owed to an agent or sub-agent under a sales agreement. Combining them into one figure can create settlement errors.
A multi-level portal can give the main agency, master agents, sub-agents, and staff different pricing, commission, access, and reporting permissions.
The commission engine should define who earns commission, when it becomes payable, what happens after cancellation, and which amount is used as the calculation base.
Keep separate ledger entries for supplier cost, platform margin, agent commission, taxes, discounts, and payment fees.
How Do Wallets and Credit Limits Control Risk?
Wallets and credit limits let approved agents book without making a card payment for every transaction.
A prepaid wallet uses funds deposited by the agent. A credit account allows booking up to an approved limit and settlement later. The portal should show available balance, used credit, pending exposure, deposits, adjustments, and transaction history.
Credit checks should happen before confirmation. The platform may also apply booking caps, product restrictions, branch limits, or approval rules.
Pending bookings may reserve part of an agent’s balance. Cancellations and refunds must release or return the correct amount without duplicate credits.
Connecting every movement to one booking reference gives finance teams a clear record. Card and local-payment workflows can be added through a travel payment gateway integration.
Why Are Pre-Book and Price Recheck Important?
A search result is not a final promise of price or availability.
Before confirmation, the portal should call the supplier’s pre-book, check-rate, reprice, or validation method when available. This confirms the current price, availability, cancellation policy, room details, fare rules, and booking conditions.
If nothing changes, the agent continues. If the price changes, the portal should show the new amount and request acceptance. If the option is unavailable, it should return a clear status and alternatives.
The recheck must use the supplier identifiers and rate tokens saved during search. Rebuilding the selection from visible text can connect booking to the wrong offer.
How Do GDS and NDC Content Coexist?
For a clearer understanding of modern airline distribution, review IATA’s official guide to New Distribution Capability (NDC). It explains how airlines and travel sellers exchange offer and order data across distribution channels.
The portal should normalize common fields such as itinerary, cabin, baggage, fare conditions, price, and ticketing information. It should also preserve source-specific details, including ancillaries, offer identifiers, order references, and servicing rules.
Deduplication should reduce confusing copies, but it should not merge offers with different baggage, flexibility, ancillaries, or ticketing conditions.
Routing rules may prefer a source based on airline, market, agreement, content quality, or servicing capability. Booking and post-booking actions must return to the source that created the reservation.
Travel companies can compare a GDS travel system with an NDC flight booking system.
What Is the Correct Booking Lifecycle?
A B2B booking should move through controlled states instead of one general “booked” label.
A typical lifecycle is:
Search → selected → revalidating → awaiting payment or credit approval → supplier request sent → confirmed or pending → document issued → amended, cancelled, refunded, or closed
Each state should record the time, user, supplier response, payment position, and next permitted action.
Supplier, internal, and payment statuses should remain separate. Payment may succeed while supplier confirmation is pending, or the supplier may confirm before a voucher is generated.
Repeated clicks, browser refreshes, or timeout retries must not create duplicate bookings, charges, or wallet deductions.
How Does Booking Reconciliation Work?
Reconciliation checks whether portal records match supplier, payment, and agent records.
The system should compare expected supplier cost with confirmed or invoiced cost. It should also compare payment collections, wallet movements, commissions, refunds, and outstanding balances.
Useful keys include the internal booking ID, supplier reference, payment transaction ID, invoice number, agent ID, currency, and service dates.
Exceptions should enter a review queue. Examples include price differences, missing confirmations, partial refunds, currency variances, or payments without completed bookings.
A connected travel accounting integration can move booking data into a wider finance process while preserving reference links.
How Should Cancellations and Refunds Be Designed?
Cancellation is a workflow, not a delete button.
The portal should first confirm the supplier penalty. It should show the refundable amount, fee, deadline, and expected status before submission.
After submission, the system should store the supplier response and update the booking, voucher, invoice, wallet, commission, and reports. Partial cancellations need line-level handling because one passenger, room, or service may change while the rest remains active.
Refund status should be separate from cancellation status. A booking can be cancelled while the refund is still pending.
Manual overrides should require permission and leave an audit trail.
What Logging, Monitoring, and Fallback Logic Are Required?
A production portal should make failures visible before agents report them.
Logs should record supplier calls safely, with sensitive values removed. Monitor response time, error rate, timeouts, search success, price-recheck failures, booking failures, duplicate attempts, cancellation errors, and reconciliation exceptions.
Fallback depends on the stage. During search, the portal may continue with other suppliers. During booking, it must not silently switch to another rate after the agent accepted specific conditions. It should stop and offer a newly validated option.
Alerts should identify the affected supplier, endpoint, destination, or booking stage. A general “API error” is rarely enough.
A B2B travel portal should be evaluated through real booking workflows, not only feature lists and architecture diagrams. Agencies can review product screenshots or request a live demonstration showing supplier configuration, normalized search results, agent-specific markups, credit controls, price revalidation, booking status, vouchers, refunds and reports. Practical examples help buyers understand how the system handles supplier delays, price changes, failed confirmations and post-booking operations. PHPTRAVELS can support this evaluation with relevant platform screens and implementation experience, while keeping supplier credentials, payment details and customer information private.
What Is the Difference Between B2B and B2B2C Architecture?
A B2B portal serves registered agents under controlled commercial rules. A B2B2C model also lets those agents distribute a customer-facing storefront or booking link.
Both can use the same supplier adapters and normalized inventory. The difference is mainly identity, pricing, branding, payments, and ownership of the customer relationship.
B2B2C may require agent-specific domains, retail markups, customer payments, analytics, and support routing. Each booking should still connect to the responsible agent.
Keeping channel rules separate prevents consumer prices, agent rates, or commissions from appearing in the wrong interface.
Should a Travel Company Build or Buy the Platform?
Build when the company’s advantage depends on technology or business rules that an existing platform cannot support.
Buy or customize when the main advantage is supplier access, regional knowledge, agent relationships, or service. This can reduce time spent rebuilding standard functions such as authentication, booking states, vouchers, wallets, and reports.
The decision should consider supplier count, product scope, agent hierarchy, accounting complexity, security, expected volume, engineering capacity, and maintenance.
| Decision area | Build from scratch | Buy or customize |
|---|---|---|
| Launch speed | Usually slower | Usually faster |
| Control | Maximum | Depends on platform |
| Initial engineering | High | Lower for standard workflows |
| Maintenance | Fully internal | Vendor-supported or shared |
| Best fit | Unique platform logic | Faster launch on proven foundations |
Businesses needing non-standard workflows can explore custom travel solutions.
Final Takeaway
Strong B2B travel portal architecture keeps supplier complexity away from agents while giving the main agency control over pricing, credit, bookings, documents, and finance.
Supplier adapters make APIs manageable. Normalization creates consistent results. Mapping removes duplicates. Pricing rules protect margins. Wallets control exposure. Revalidation protects booking accuracy. Reconciliation, monitoring, cancellations, and refunds keep operations reliable after confirmation.
The portal should be evaluated as a distribution, rules, and transaction system not only as a search interface.