For a Mobility fleet, a ride begins with a hold
and ends with a number the hold did not know.
For ride-hailing, micro-mobility, EV-charging, car-sharing and MaaS operators, the amount held at pickup, at the unlock or at the plug is almost never the amount captured at drop-off. That gap has to close inside the same payment, on the same card, before the next ride starts. When it does not, the loss shows up as reconciliation work on assets that never stopped running.
- CheckoutBuyer selects a method and confirms
- AuthorisationIssuing bank approves or declines in real time
- CaptureAuthorised amount is submitted for clearing
- SettlementFunds settle from the issuer to the acquirer
- PayoutMerchant receives cleared funds
Licensed Austrian Payment Service Provider and Acquirer with 25+ years of operation
Four payment failures cost the fleet ops time before they cost margin.
A fleet in this business runs micro-transaction volumes across ride-hailing, micro-mobility, EV-charging, car-sharing and MaaS lines. Each ride is a small ticket, and each rider generates many small tickets a month. With that shape, four payment failures do their damage in ops time before they show up as margin loss. By the time the P&L notices, the ops team has already spent the quarter absorbing the difference.
A disputed ride refunds as a chain, not as one reversal.
Structural causeWhen a rider disputes a ride, the refund path today walks through partial authorisations, partial captures, partial reversals and a final acquirer-side reconciliation, in an order that depends on which stage of the ride the dispute arrives at. Each stage carries its own state at the acquirer, at the scheme, and at the issuer.
Commercial consequenceThe fleet’s support team owns refund-status categories instead of rides. Reconciliation at month-end runs against refund-stage tables that do not match ride tables. Finance closes the month against categories the ops team does not use. The operational cost of an ambiguous refund is the ops-time to reconstruct the ride from the refund state, not the refund amount itself.
The dispute clock starts when the rider reads the statement, not when the ride happens.
Structural causeThe rider recognises a charge at the moment the statement lands, days after the ride ended. The descriptor on the statement rarely names the ride the rider took. From the issuer’s side, the 24-hour pre-dispute evidence-assembly window begins the moment the rider marks the charge as unknown, not when the ride was captured.
Commercial consequenceEvery disputed ride now runs an evidence-assembly cycle inside a one-day window that the fleet did not schedule. Ops staff work against a clock set by the issuer, and the assembly load falls on the same team that runs the fleet’s daily service inbox. The descriptor and the pre-dispute window are one operational surface, not two. What the rider sees on the statement determines how much time the ops team has, and how much of that time is spent explaining the ride versus defending it.
On a fleet’s release calendar, a provider’s migration is an outage nobody scheduled.
Structural causeA payment provider migrates staging endpoints, deprecates a certificate path, or ships a schema change without prior alignment on the fleet’s release window. The change surfaces first as a broken pre-authorisation on a live ride, or as a failed capture at drop-off, in an environment the fleet was told was stable.
Commercial consequenceThe engineering team’s next release is either paused or rolled back to accommodate a provider-side change nobody agreed to. The migration cost lands on the fleet’s calendar, not the provider’s, and the fleet’s roadmap slips inside the same quarter. The release calendar and the staging path are the fleet’s operational surface. When a provider moves either without alignment, the cost is measured in released features and not in payment-processing minutes.
Scheme dispute ratios were not sized for a fleet’s small tickets.
Structural causeThe scheme dispute-ratio (VAMP for Visa, EMS for Mastercard) is computed against the fleet’s card volume. On a micro-transaction shape, ten to forty transactions per month per rider, with an average ticket of a few euros, the ratio’s numerator is disproportionate to the ratio’s denominator. A single ride disputed against a small average moves the ratio further than the same number of disputes on a larger-ticket merchant profile.
Commercial consequenceThe fleet reaches a scheme’s warning threshold on a dispute count that would leave a large-ticket merchant well below it. Scheme-remediation costs arrive on a volume the ops team already treated as normal: added per-transaction assessments, remediation-programme fees, delayed settlement. The scheme’s ratio is not a KPI the fleet’s team chose to be measured on. It is a structural surface that costs money whenever the transaction shape and the ratio’s design diverge, and that divergence is native to the fleet’s business, not a symptom of poor operation.
The fleet wins back ops time where four payment failures used to spend it.
The four failure surfaces from the section above are the same four surfaces where a different payment operator can return operational time to the fleet. Not through faster processing, but through where responsibility for reconciliation, evidence assembly, migration timing and scheme-ratio management actually sits. Each criterion below names one of those surfaces and the operating condition that replaces the failure.
Does the rider recognise the ride on their statement?
Descriptors are assembled at the point of capture from the ride’s own metadata: the city, the vehicle class and the session type of the specific ride, rendered inside the issuer’s statement-line character budget. The rider sees the ride they took on the statement they receive, and the “I don’t recognise this charge” contact stops arriving in the ops queue.
The descriptor generation runs at the acquiring endpoint against the fleet’s own metadata schema, so the label the issuer forwards to the statement is deterministic against the fleet’s operational record, not a category taken from an MCC bucket. This makes the pre-dispute window measurable: the rider recognises the ride before the 24-hour clock even starts.
Does the case close inside the pre-dispute window?
Scheme-aligned pre-dispute programmes intercept the case inside the pre-dispute window, before the transaction becomes a chargeback record on the scheme’s report. The rider sees the refund on their statement, the fleet keeps the ride in its reconciliation table, and the scheme dispute-ratio numerator does not tick up.
Interception coverage is method-by-method and issuer-by-issuer, negotiated at the acquirer level rather than assembled per-transaction. The window is treated as a real operational surface with a defined outcome, not as a race against the clock. Ops teams see the intercepted cases inside the same reconciliation view that shows the settled rides, so month-end closes against rides rather than against dispute-workflow stages.
Do a ride’s hold and its capture run as one sequence?
A single pre-authorisation opens the ride. Delta captures adjust the amount as the ride’s shape changes. One authoritative capture closes the ride at drop-off. The rider sees one entry on their card, not a chain of holds and reversals stacked against the same session.
The sequence works against a single SCA event per rider per ride even when the ride’s amount changes mid-session, which keeps the rider inside the exemption profile they entered the ride under. On the fleet’s side, the ride’s payment record is one document across a ride’s lifecycle, not a graph of state changes across a payment lifecycle. Reconciliation and dispute evidence both read from the same document.
Does the versioned staging path follow the fleet’s release calendar?
Staging endpoints are versioned, migrations are announced in advance with named steps and target dates, and parity between staging and production is a firm commitment inside a declared release window. When a provider-side change is scheduled, the fleet’s release calendar sets the pace, and rollback is a defined path.
Migrations are treated as coordinated operational events with a documented pre-parallel period, an announced parallel-run, and a cutover triggered by the fleet, not by the provider. Rollback is available as a first-class path for any release-window incompatibility discovered during parallel-run. The fleet’s engineering roadmap keeps its own calendar; provider-side platform work slots inside it.
The chain that runs the ride is the chain that closes the month.
DaoPay operates the payment chain that begins at the pre-authorisation on the fleet’s side of a ride and ends at the reconciliation line that Finance reads at month-end. Between the two, one operator handles the settlement, reporting and reconciliation that today sit across three provider boundaries. Two handovers stay visible on the seam: one at the pre-authorisation boundary where the ride’s hold enters DaoPay’s chain, one at the reconciliation boundary where the fleet’s month-end reads from DaoPay’s ledger. DaoPay carries the operational weight between them.
- Checkout
- Authorisation
- Capture
- Settlement
- Payout
- Finance ops
- Layer 1
ACCEPTANCE
Local payment methods, cards, wallets, tokenisationThe methods your riders use in each country, in the right currency and with the right authentication flow.
- Handover 1 · Acceptance → ProcessingWhere routing decisions set your capture rate
- Layer 2
PROCESSING
Routing, retries, capture, network communicationRouting per transaction across acquirers, with cascading retries when one path fails.
- Handover 2 · Processing → ReconciliationWhere settlement files meet your ledger, usually left to Finance
- Layer 3
RECONCILIATION & PAYOUT
Settlement matching, fee accounting, payout schedulingOne 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 mobility 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.
Five questions show whether your fleet’s payment shape fits, before a first conversation is booked.
The PreCheck is free and takes about the time of a coffee. The questions are shaped by how a fleet actually moves money: how often a card is charged in a week, what a hold looks like against a delivered ride, how the reconciliation closes at month-end. The answer is honest, including when it is No-Fit. That answer arrives before the first meeting is on the calendar. Free Onboarding PreCheck: Go, Review or No-Fit.
Answer what you can, and anything you are unsure of can stay blank. Nothing is sent until you press the button.
Four rooms inside the fleet decide whether a payment operator gets onboarded.
The four rooms are Finance, Technology, Integration and Compliance. Each one asks a different question, and each gets its own answer below. Three questions the fleet is likely to hear in those rooms are answered further down. Three cards at the bottom of the page cover the next steps, in parallel rather than in sequence.
How does a migration from our current provider fit inside our next release window?
The migration is planned against your release calendar, not against ours. Versioned staging endpoints stand up before the parallel-run period begins, so your engineering team can test the new authorisation path while the incumbent still carries live traffic. Migration steps are announced in advance, and each step is completed inside an agreed release window. If a fleet-side deployment surfaces an incompatibility during the parallel-run, rollback is a defined path, not an incident. Cutover happens when the fleet says it is ready, not when the provider does.
Which regulatory obligations sit with DaoPay under its licence, and which stay with the fleet?
Payment-layer obligations sit with DaoPay under its supervision by the competent Austrian financial market authority. SCA and RTS at the acquiring endpoint, scheme rules for the methods DaoPay processes, PCI where card data is handled. Sector-specific obligations stay with the fleet. For a ride-hailing, micro-mobility, EV-charging, car-sharing or MaaS operator this includes AFIR ad-hoc EV-charging accessibility at the payment layer, DAC7 reporting where the fleet operates as a payment intermediary between drivers and platforms, and tax remittance where the fleet is merchant of record. The exact perimeter is walked through in the onboarding conversation, per method and per licence scope, so Compliance can sign off against the specific boundary rather than a generic statement.
With so many small transactions per rider, does the pricing still work for the fleet?
Pricing is agreed against the fleet’s actual transaction distribution, disclosed in the PreCheck’s five questions and refined in the first meeting after. Interchange-plus with volume tiers, sized to the density of small transactions per rider per month, not to a generic merchant category. The dispute-ratio numerator that feeds scheme-remediation costs is a second cost line beyond per-transaction fees, and pre-dispute interception works that numerator before the ratio prints. Finance can see the transaction shape and the ratio trend from the acquirer side, so the pricing conversation is against the same data the scheme sees, not against a proxy.
Internal Review Pack
A short paper that carries the substance of this page across to Finance, Technology, Compliance and Operations, framed for a fleet’s ride and settlement cycle. Fill in four fields (name, role, company, email) and the pack opens straight away as a PDF in a new tab.