A merchant selling in one country buys a payment provider and is mostly done. A merchant selling across several assembles a system.
That system typically has a checkout from one vendor, a fraud tool from another, a verification provider for merchant or customer onboarding, an accounting integration, and a reconciliation process that is frequently a spreadsheet. Each component works. The difficulty is in the joins, and the joins are where the operational cost lives.
This post is about those joins. It is written from the perspective of someone building infrastructure in this space rather than someone selling a payment service, and it is deliberately non-specific about vendors.
The reconciliation gap
The most reliably painful join is between what the payment processor says happened and what the merchant's own records say happened.
These disagree routinely, for ordinary reasons. A payment authorises but captures later. A refund is issued in one currency and settles in another. A chargeback arrives weeks after the transaction. Fees are deducted at settlement rather than at transaction time. Payouts batch transactions in groupings that do not match any order boundary.
None of these are errors. They are the normal behaviour of payment systems. But they mean the merchant's order table and the processor's settlement report describe the same events with different timing, different granularity and different amounts.
Multiply across processors and currencies and reconciliation becomes a permanent job rather than a monthly task. It is also the join where money actually goes missing — not through fraud, but through discrepancies nobody had capacity to investigate.
Currency is not a display problem
Handling multiple currencies is usually treated as a presentation concern: show prices in the customer's currency.
The harder questions are downstream. At what rate, and fixed when? If a customer is quoted a price on Monday and pays on Wednesday, who absorbs the movement? When a refund is issued three weeks later, is it at the original rate or the current one? Which currency are the merchant's books kept in, and where does the difference land?
Getting this wrong does not usually produce a visible failure. It produces a slow leak that appears as an unexplained variance, and by the time it is large enough to notice it covers months of transactions.
Fraud controls have a cost on both sides
Fraud tooling is sold on catch rate. The number that matters more to most merchants is the false positive rate, because declined legitimate customers are an invisible loss.
Cross-border makes this sharper. The signals that fraud models weight — billing and shipping country mismatch, unusual IP geography, an issuing bank in a different country than the delivery address — describe a substantial share of perfectly ordinary international customers. A model tuned on domestic traffic will systematically over-flag exactly the segment a cross-border merchant is trying to serve.
The practical implication is that fraud thresholds need to vary by corridor rather than being global, and that the review queue needs to be usable enough that flagged-but-legitimate orders get resolved quickly rather than expiring.
Merchant onboarding is verification, again
Any platform that handles payments on behalf of other businesses has to verify those businesses: the entity is real, the people behind it are real, and the ultimate beneficial owners are known.
This is the same problem covered elsewhere on this blog under company and beneficial-owner verification, and it has the same difficulties — layered ownership, register data of varying quality by jurisdiction, and the need for a stopping rule when the chain cannot be resolved.
It is worth noting because it is easy to treat onboarding and payments as separate domains. They are the same verification problem appearing in a different context, and building them twice is a common and expensive mistake.
The state that nobody owns
Underneath all of this is a single structural issue: no component owns the complete state of a transaction.
The checkout knows the order. The processor knows the payment. The fraud tool knows the risk decision. The accounting system knows the ledger entry. The customer service tool knows the complaint. When a customer asks why they were charged twice, answering it means reading four systems and reconstructing a sequence.
That reconstruction is the actual work of payment operations, and it is done manually far more often than anyone plans for.
The infrastructure worth building is not another processor. It is the layer that holds the transaction's full lifecycle in one place — authorisation, capture, settlement, refund, dispute, ledger entry — so that answering a question is a lookup rather than an investigation.
What good looks like
From an operations perspective, a small number of properties matter more than features:
- One timeline per transaction, spanning every system that touched it.
- Reconciliation as a continuous process with exceptions surfaced, not a monthly batch.
- Fraud thresholds per corridor, with a review queue that is actually worked.
- Verification performed once and reused, rather than repeated per integration.
- An audit trail sufficient to answer a question months later without reconstruction.
None of these are glamorous. All of them determine whether payment operations scale with transaction volume or with headcount.
Where this sits at Dorsko
DorskoPay is Dorsko's work in this area. It is in development: it is not a licensed payment institution, it is not a bank, it does not process live transactions, and it does not hold client funds. No integration or partnership with any payment provider is implied by this article.
What is described above is the problem space the roadmap addresses — merchant onboarding, checkout workflows, payment orchestration, fraud controls, analytics and operational tooling — and the reasoning behind it. It is not a description of a shipped product, and we would rather say so plainly than let a roadmap read as a capability.