Your shop runs.
Your payment stack keeps getting in the way.
For established online retailers, the friction is not the checkout but the layer underneath: the one that broke recently, or is about to. If you already know which layer that is, see whether we read the same picture.
- 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
Three things your provider doesn’t put on the dashboard.
The dashboard number shows a good day. The three patterns below happen underneath it, on the same book, and an experienced payments lead will recognise each one.
One method quietly stops converting in one country.
Structural causeA local acquiring or scheme relationship degrades in one corridor, with no global signal.
Commercial consequenceRevenue in that country flatlines against the plan, and the reason surfaces two reporting cycles later.
A method disappears overnight from your book, not from the network.
Structural causeScheme monitoring, VAMP escalation or a regulator action removes eligibility, and the provider’s answer is to switch the method off.
Commercial consequenceVolume that ran cleanly last week is refused this week, and the first the merchant hears of it is a customer complaint.
The dashboard is green while one acquiring leg is already down.
Structural causeOnly one acquiring leg is live for the corridor, so a degradation reads as a slow decline rather than a failover event.
Commercial consequenceBy the time the trend shows in the tooling, the checkout has already lost hours of trading at scale.
So the question is not which provider is cheapest. It is how to recognise a payment structure that holds under all three at once, and still holds when you add the next market.
Three questions any provider should answer before your shop signs.
By now you have heard enough pitches to know what a good demo sounds like. A demo does not answer these three questions on its own. Bring them into your next provider conversation, with us or anyone else, and the room gets honest quickly.
Who decides to stop your account, and do you know their name?
Every risk decision on your account should have a name and a documented reason, not an algorithmic score and a status page.
Automated freezes and opaque holds are the moments a merchant finds out the provider was not a partner. On our rail every risk decision is made by a person and is traceable, with the reasoning shared rather than referred to a policy page. Verification and scope questions are handled before onboarding is signed, not after volume has moved.
Ask any provider: when a risk decision last went against a merchant on your rail, who made it and how was it explained?
If your acquirer degrades tomorrow, is there a second leg to route to?
At least two acquiring legs live from day one, not one primary with a fallback that would be added later.
On a single-acquirer book, every degradation becomes a business-continuity event. eCommerce merchants on our rail run with two acquiring legs live in parallel, so a degradation on one shifts traffic to the other at the transaction level. The checkout the customer sees does not change, and our operations side calls the merchant with what happened, rather than the merchant calling the provider.
Put this to any provider: when a route or acquirer last degraded on your rail, what did the merchant actually see, hear and do?
If a method is pulled from you overnight, who notices first?
The notification, the reason and a substitution proposal reach you before the network or the news do.
The days a method disappears are rarely the days a provider tells the merchant calmly. Our commitment is that the notification, the reason and a substitution proposal reach the merchant first, from a named account contact, in writing or on the phone rather than through an automated status page. Substitutes come from methods already inside the contract wherever possible, so the fallback is contractual and technical from day one, not a new integration project.
A useful test for any provider: when a method was last withdrawn from a merchant on your rail, how many hours passed between notification and the substitute going live?
The next section shows where in the payment stack each of the three is decided, and where our answer sits.
Payments don’t break inside a layer. They break at the handover between two.
Every checkout you have run sits on three stacked layers, and most of them work most of the time. The days you remember are the ones where a request left one layer clean and the next layer refused it: a currency it was not briefed on, a method it was not contracted for, a rule that changed since the last release. So we build the three layers to sit under one agreement, and we look after the two handovers between them the way most providers look after the layers themselves.
- Checkout
- Authorisation
- Capture
- Settlement
- Payout
- Finance ops
- Layer 1
ACCEPTANCE
Local payment methods, cards, wallets, tokenisationThe methods your customers 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 eCommerce 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, one person reading them, and an answer to your case within a few days.
A short Onboarding PreCheck reads your business and tells you, in plain terms, where you stand, long before any paperwork begins.
Answer five short questions about your business and we come back to you with the right next step, before any paperwork begins.
What each function asks when payments are on the table.
Every function in the business looks at a payment setup from a different angle. Below is what usually matters for an eCommerce book, and how DaoPay answers it.
Which payment methods, in which markets, are actually inside the same contract?
Cards, the major European APMs, the main wallets and the recurring flows behind them all sit under one master contract.
The full method mix travels under one contract, not a base agreement plus a stack of addenda that reopens every time you add a market. Cards run on our own scheme relationships as an EU-based acquirer, and European APMs and wallets are contracted directly rather than resold. Where a country-specific method is not in scope today, the PreCheck calls it out before signing, along with what would be needed to add it.
Ask any provider: which methods sit under the master contract as it stands today, and which would be a scoped addition?
If a route or acquirer degrades mid-day, what happens to the transactions?
Traffic shifts to the second leg within seconds, without merchant action, and the account contact reaches out with what happened.
eCommerce merchants on our rail run with at least two acquiring legs live from day one, not one primary and a fallback that would be added later. If one degrades, routing shifts automatically at the transaction level and the checkout the customer sees does not change. On our side the shift is visible in real time, and the account contact makes the first call with a short read of what degraded, what shifted and what to tell customer service if a spike follows.
The question to put to any provider: when a scheme or acquirer last degraded on your rail, what did the affected merchant actually see and hear?
If a scheme, VAMP or a regulator withdraws a method overnight, how do you find out, and what runs in the meantime?
The notification, the reason and a substitution proposal come from the account contact before the network or the news deliver them.
The days a method disappears are rarely the days a provider tells the merchant calmly. Our commitment is that the notification, the reason and a substitution proposal reach the merchant first, from the account contact, in writing or on the phone rather than through an automated status page. Substitutes come from methods already inside the contract wherever possible, so the fallback is contractual and technical from day one, not a new integration project.
Worth asking any provider: when a method was last withdrawn from a merchant on your rail, how many hours passed between the notification and the substitute being live?
Same goal, less complexity, and a payment partner that grows with you.
Take the Internal Review Pack into your next meeting.
A short paper that carries the substance of this page across to Finance, Technology, Compliance and Operations. Fill in four fields (name, role, company, email) and the pack opens straight away as a PDF in a new tab.