Back to Industries

Corporate travel payments
that close the month on booker and corridor.

For corporate travel programmes on TMCs, OBTs and expense platforms: a payment layer that reconciles at settlement, with no new dependency for Finance and no rebuild for Platform.

  1. CheckoutBuyer selects a method and confirms
  2. AuthorisationIssuing bank approves or declines in real time
  3. CaptureAuthorised amount is submitted for clearing
  4. SettlementFunds settle from the issuer to the acquirer
  5. PayoutMerchant receives cleared funds

Licensed Austrian Payment Service Provider and Acquirer with 25+ years of operation

01Business reality

Three payment patterns that cost a corporate travel programme its margin before Finance sees them.

Ask a Head of Payments on a corporate travel programme where the last quarter went wrong, and the answer is rarely one failed transaction. It is a pattern that surfaces in the numbers weeks later, when Finance closes the month.

  1. One provider, and no second leg when a booking wave hits.

    Structural cause

    One provider carries card acceptance, deposit-and-balance flows, multi-currency settlement and the TMC integration. That is convenient until it is the only relationship, and every scheme change, method withdrawal or corridor regulation lands with that one provider.

    Commercial consequence

    When that relationship tightens, the programme has no second leg to route to. A booking wave hits a degraded acquirer, and the payments team is on the phone to the account manager instead of watching traffic shift.

  2. Finance rebuilds the month by hand.

    Structural cause

    Booker, budget, method, corridor and refund cycle rarely close on the same date. If the reconciliation trail is not built at settlement, with booker, budget, method and settlement date on every line, Finance rebuilds it by hand every month.

    Commercial consequence

    The workload that scales badly is the reconstruction, not the transaction volume. Each corridor the programme adds also adds hours of reconciliation in Finance, and that cost stays invisible until Finance flags it.

  3. Deposit-and-balance bookings that depend on a plugin.

    Structural cause

    FIT bookings and group reservations run deposit now, balance later against a corporate account. When mandate handling is a plugin rather than a contractual capability, each new corridor or method opens another integration project.

    Commercial consequence

    The peak booking window is where the plugin gets stress-tested, and it was scoped for the previous window, not this one. Multi-leg bookings then survive one way: someone routes them by hand.

Next

The fix is not more providers. It is a payment layer whose default setup already carries what a corporate travel programme needs across bookers, currencies and corridors.

02Better state

Four questions to put to any payment provider before the programme signs.

Four criteria separate a payment layer that carries a corporate travel programme forward from one that only carried the last one. Put each of them to the next provider you talk to.

  1. Who holds the licence: your counterparty, or someone further down the chain?

    A licensed Austrian payment institution as your counterparty, not a pass-through orchestrator working on someone else’s licence.

    Corporate travel sits close to acceptance boundaries other verticals do not touch. A programme review can turn on the answer to one underwriting question, and Compliance wants that question named by the counterparty itself, not by a downstream sub-processor. A licensed Austrian institution with 25+ years of operations is a footing that holds through a scheme-monitoring event, a regulator advisory or a network cascade, because the licence belongs to the party the programme contracts with, not to someone the orchestrator passes the volume on to.

    Ask any provider: which entity in the chain actually holds the licence the programme depends on, and how many hops sit between that entity and the merchant contract?

  2. Can Finance close the month without rebuilding the trail?

    Reconciliation records arrive built at settlement, with booker, budget, method, corridor and settlement date on every line.

    In corporate travel, what scales badly is the reconciliation rebuild, not the transaction volume. When the trail Finance closes on arrives at settlement with booker, budget, method, corridor and settlement date already on it, the payment layer keeps its cost predictable as the programme adds corridors. One master contract, one licensed counterparty, no orchestrator sub-processor chain: the trail Finance receives is the trail Finance closes on.

    Put this to any provider: what does month-end reconciliation look like on your rail when a corporate travel programme has added three corridors and two new methods in the last quarter?

  3. What changes in your OBT, TMC and expense stack, and is it written down?

    The layer attaches to your existing OBT, TMC and expense stack, with the scope of change documented before signature, not after.

    Platform will not sponsor a rebuild for the payment layer alone. The useful question is not “will your API work”. It is “what exactly changes on my side, in writing, before I commit”. Deposit-to-balance mandate handling that is contractual on the payment rail, rather than a plugin per method, is what lets multi-leg bookings survive integration cycles without a project. The scope of change is a shared document, not an onboarding surprise.

    Ask every provider for it in writing: the exact scope of change to my current OBT / TMC / expense stack before I sign, including deposit-and-balance handling.

  4. Where in the chain are your currencies converted, and who sets the FX treatment?

    EUR, USD, GBP, CHF and neighbouring corridors settle directly at the acquirer, not converted downstream.

    Corporate travel spend moves across currencies at settlement, while reporting often consolidates in a single reference currency. When conversion happens downstream, inside an orchestrator or an intermediary, the FX treatment is inherited rather than chosen, and Treasury inherits it too. When payment currencies are handled directly at the acquirer level, the FX treatment is documented per corridor before signature and shows up on the reconciliation line as a named position, not as a hidden liability.

    The question for each provider: for each of my active currencies, where in the chain does the conversion happen, and what FX treatment applies?

Four criteria, four questions that hold up in any provider conversation. Below is how DaoPay answers each of them for corporate travel.

03DaoPay in practice

Payments don’t break inside a layer. They break where one layer hands over to the next.

Every corporate travel payment stack has three real layers: acceptance at the booker’s card, settlement across currencies, and reconciliation into Finance. The layers themselves were solved years ago. The handovers between them were not, and that is where corporate travel programmes lose the month. The diagram reads left to right: what DaoPay carries at each layer, and what each handover looks like when it is contractual rather than best-effort.

  1. Checkout
  2. Authorisation
  3. Capture
  4. Settlement
  5. Payout
  6. Finance ops
  1. Layer 1

    ACCEPTANCE

    Local payment methods, cards, wallets, tokenisation

    The methods your bookers use in each country, in the right currency and with the right authentication flow.

  2. Handover 1 · Acceptance → ProcessingWhere routing decisions set your capture rate
  3. Layer 2

    PROCESSING

    Routing, retries, capture, network communication

    Routing per transaction across acquirers, with cascading retries when one path fails.

  4. Handover 2 · Processing → ReconciliationWhere settlement files meet your ledger, usually left to Finance
  5. Layer 3

    RECONCILIATION & PAYOUT

    Settlement matching, fee accounting, payout scheduling

    One reconciliation feed across all methods and acquirers, with payouts on an agreed schedule.

Which layer owns each journey station, and the two handovers where multi-provider stacks break.

Not sure if corporate travel fits your setup?

We built one page for each industry we know how to serve. Pick the one closest to your business, or use the visual guide below to see where your business fits.

Prefer a head start?

Pick your industry below to see the journey built for it.

eCommerceView journey →TravelView journey →TicketingView journey →Digital MediaView journey →Online EducationView journey →Online Games (MMOG)View journey →MobilityView journey →StartupsView journey →Voucher PlatformsView journey →iGamingView journey →
04Choose your next step

Corporate travel sits close to a hard boundary. A short read tells you which side you are on before anyone commits.

Your account contact reads the case, checks it against how DaoPay underwrites corporate travel programmes, and comes back with Go, Review or No-Fit, in writing and with the reasoning.

GoThe setup fits. Your case matches what we already operate. You move into onboarding.
ReviewA point needs a closer look. Most of the case fits; one or two elements need a specific answer before we can commit.
No-FitNot today. We don’t have a good answer for your specific case as it stands. You get told which part doesn’t fit and what would change it.
A person reviewing a printed document
Onboarding PreCheck · five questions0 / 5 answered

Answer what you can, and anything you are unsure of can stay blank. Nothing is sent until you press the button.

01 Country in which your business is registered?
Your main company / headquarters: one country only.
02 What is your monthly processing volume?
Enter the amount in euros (EUR).
03 Describe your business and industry you wish to onboard?
04 Which payment methods do you require?
05 Anything else you’d like to share or ask?

Nothing is shared with a third party. Nothing is committed by submitting. We use your answers only to assess fit and to prepare the next step. No account is created, and nothing is shared outside DaoPay.

Prefer to keep reading first?Not ready yet: read about DaoPay first

05Internal alignment & close

What Finance, Technology, Treasury and Compliance will ask before they sign off.

A corporate travel payment decision rarely closes in one room. Each function wants the reasoning in a form it can defend in its own review. The four rows below are what a Head of Payments hands to each of them.

FunctionWhat matters for a corporate travel programmeHow DaoPay reads on it
FinanceA corporate travel book closes the month on booker, budget, method, corridor and refund cycle at once. Rebuilding that trail by hand after the fact is the workload that scales badly, and Finance rejects any payment-governance layer that adds a new dependency without earning it.Reconciliation records arrive built at settlement, with booker, budget, method, corridor and settlement date on every line. One master contract, one licensed counterparty, no orchestrator sub-processor chain: the trail Finance receives is the trail it closes on, without a new lock-in dependency.
TechnologyThe booking tool, the expense platform and the reservation system are already integrated. A payment change that asks Platform to re-integrate any of them turns a decision into a rebuild proposal, and Platform will not sponsor a rebuild for the payment layer alone. Deposit-to-balance mandate handling for FIT and group bookings is where plugin-based approaches usually break.The payment layer attaches to your existing OBT and expense stack, with the scope of change documented before signature rather than after. Deposit-to-balance flows are contractual on our rail, not a plugin per method, so multi-leg bookings survive integration cycles without a rebuild.
TreasuryCorporate travel spend moves across EUR, USD, GBP, CHF and neighbouring currencies at settlement, while reporting often consolidates in a single reference currency. The applicable FX treatment is a Treasury question, not a booking question. Deposit-and-balance schedules also open timing gaps between booking, supplier payment and final settlement, a real cashflow governance concern when they run unmanaged across a seasonal booking calendar.Payment and reporting currencies are handled directly at the acquirer level rather than converted downstream, and the applicable FX treatment is documented per corridor before signature. Deposit-to-balance timing is contractual, so the gap between booking, supplier payment and final settlement is a named position on the reconciliation line rather than a hidden liability.
ComplianceCorporate travel sits close to acceptance boundaries other verticals do not touch. A regulator advisory, a scheme-monitoring event or a corridor pulled overnight can land in the middle of a booking wave. Compliance wants the counterparty’s regulatory footing to be unambiguous, and the fit boundary named early rather than after commitment.Every review is fit-first: Go, Review or No-Fit, in writing, with the reasoning documented. The counterparty is one licensed institution rather than a sub-processor chain, so Compliance evaluates one relationship instead of four. No algorithmic freeze, no silent method removal: every scheme or regulator event is handled by a named human before the network delivers the news.
Which corporate travel payment patterns sit under one master agreement today?

Card payments on the booker’s side, deposit-and-balance for FIT and group, and account-to-account for corporate invoicing are on one contract; corridor-specific methods are named in the PreCheck.

Corporate travel books rarely run on one method alone. A booker charges an executive card at authorisation; a group reservation runs deposit now, balance later against a corporate account; a TMC settles invoiced volume monthly against a treasury reference. All three sit under one master agreement, with the scheme relationships held by DaoPay directly as an EU-based acquirer rather than resold through a downstream partner. Corridor-specific methods that are not in scope today are called out in the PreCheck, together with what it would take to add them.

Ask any provider: which of the three corporate-travel patterns above are inside your master contract today, and which would open a new agreement?

If an acquiring leg degrades during a booking wave, what does the booker see and what does the payment team hear?

Traffic shifts to the second leg at the transaction level within seconds; the booker sees no change; the payment team gets a written read from the account contact.

Corporate travel programmes on our rail carry at least two acquiring legs live from day one, chosen for the currencies and corridors each programme actually uses. If one leg degrades, routing shifts at the transaction level and the booking flow the traveller sees does not change. On our side the shift is visible in real time, and the account contact makes the first call to the payment team: what degraded, what shifted, and what to tell the OBT team if booker questions spike in the next hour.

The question to put to any provider: at what latency does your rail detect an acquiring degradation, and who on your side makes the first call to the payment team?

A scheme, regulator or acquirer pulls a method or corridor overnight during a booking peak. What keeps running, and who tells the programme?

The substitution is proposed by the account contact before the news reaches the programme through the network; fallback methods already contracted keep the wave moving.

Corridors get pulled at the wrong moment more often than not, and in corporate travel the wrong moment is a Friday afternoon during a booking wave. Our commitment is that the account contact is the first person the programme hears from, with the reason and a substitution proposal in writing, before the network or the trade press delivers the news. Substitution methods come from what is already inside the master contract wherever possible, so the fallback is contractual and technical rather than an emergency integration project.

A useful test for any provider: the last time a scheme or regulator pulled a method or corridor on your rail, how many hours passed between the programme learning about it and the substitute going live?

See the full FAQ & support section →
Where to go next.
Internal review pack

Take the Internal Review Pack into your next meeting.

A short paper that carries the substance of this page across to Finance, Technology, Treasury and Compliance. Fill in four fields (name, role, company, email) and the pack opens straight away as a PDF in a new tab.

Get the Internal Review Pack →
IntegrationSee how DaoPay connects to the OBT and expense stack you already run.Endpoints, certification paths and developer resources for the OBT, expense-management and reservation-system stacks corporate travel programmes run on, for the platform lead who wants the technology question answered before the fit conversation.Self-serviceRead the licence and the entity structure first.25+ years of operations. DaoPay GmbH, licensed Austrian Payment Service Provider and Acquirer, for readers who want the paperwork before the fit conversation.