Integration your teams can evaluate
before live processing begins
Public guidance, controlled staging and a request path for internal review.
Public technical guidance your team can evaluate directly.
The technical starting point is public. DaoPay’s API 2.0 Integration Guide sets out the core structures, authentication, signature calculation and transaction-lifecycle handling, so your technical reviewers can see the shape of the work before the first integration call, without implying self-service access to a live developer portal.
For a CTO or technical product owner, it is the first orientation layer: what has to be signed, which lifecycle endpoints are visible, how status returns to your system, and which parts to discuss with DaoPay before staging begins.
Treat it as reference material, not a promise of unguided setup. Staging access, credentials and callback verification stay controlled through the Integration Team.
This is the first layer your team can bring into the Internal Review Pack later on this page.
A controlled staging path, carried by the Integration Team.
DaoPay’s test environment is a controlled staging layer, coordinated by the Integration Team, not a self-service playground. It is where your implementation is checked with the same team that later carries the technical validation, before any production credential is used.
The staging path
In staging your engineers validate the request path, status checks, refunds and Payment Status Notifications before production credentials are used. This is controlled validation before live processing.
For an internal reviewer, that is a more concrete answer than a generic sandbox claim: who owns credential delivery, where callback behaviour is checked, and how the build moves from test credentials toward production readiness.
- Register
- Merchant, on the DaoPay Business Portal
- Test credentials
- Integration Team issues Appcode and Secret Key
- Staging validation
- Merchant and Integration Team together
- Production credentials
- Integration Team, once staging is confirmed
Payment Status Notifications, the webhook layer behind
SDKs & Webhooks, are documented and verifiable.
A payment outcome doesn’t end at checkout. DaoPay sends the result to your system as a Payment Status Notification, asynchronously, over HTTP(S), and your system verifies it against DaoPay’s documented signature before acting on it. This is documented, verifiable outcome handling, not SDK marketing.
- 01
DaoPay emits
When a transaction outcome is known, DaoPay sends a Payment Status Notification to your endpoint over HTTP(S).
This is the asynchronous outcome channel. DaoPay initiates the call when the result is known, so the outcome reaches your system after checkout rather than being polled for.
- 02
Your endpoint receives
Your endpoint receives the notification. Plan the endpoint before staging so reception can be validated with the Integration Team.
Reception is validated with the Integration Team during staging, before production credentials are used.
- 03
Verify the signature
Your system checks the notification against DaoPay’s documented signature calculation before acting on it. Unverified notifications are not acted on.
This is the trust boundary of the pipeline. The signature calculation is published in the public API reference, so verification is checkable, not a claim.
- 04
Handle the outcome
Only verified outcomes drive status handling. The merchant-side system reconciles the result after checkout.
Status handling stays tied to documented, verified notifications, so your system defines how the outcome is reconciled after checkout on a sound basis.
Building toward one destination
Documentation, staging and notification handling are now on the table. This is the technical foundation the Internal Review Pack later on this page brings together for your internal discussion.
See what this builds towardThe payment method families
your team needs to evaluate.
DaoPay supports the five method families that matter for integration planning: credit cards, bank transfers, wallets, prepaid vouchers and mobile payments. Every family is handled through the same API-led surface, so the architecture conversation does not fragment into a separate integration story per family. Which families actually fit for your geography, operating model and payment mix is assessed during the process, not read off a generic catalogue.
Related: Full payment method coverage on the Payments page
Once the method mix is clear, the checkout route follows next.
The route is matched to your checkout architecture.
With the method mix in view, the next question is architectural. DaoPay doesn’t assume your checkout. The integration route is matched to your architecture, and the split comes down to one question: does your team own the checkout logic?
The two routes
- Custom API-led checkout
- The primary route, when your team owns the checkout logic. The technical discussion starts from the API surface, your checkout flow and your implementation model, where integration depth is most predictable.
- Platform-mediated checkout
- Clarified with the Integration Team when your stack includes a shop platform, CMS layer or commerce middleware. The route is decided once the architecture is known, not from a plugin catalogue.
There is no universal plugin answer before the architecture is known. You can understand your route without any public platform-name or plugin-coverage claim.
A controlled path
from fit assessment to live processing.
Integration follows a structured path with clear ownership at each stage. These are the commercial, readiness and technical gates your technical, commercial and operations teams can see before live processing begins, not a jump from documentation straight into implementation. It opens with the Onboarding PreCheck: an upfront fit assessment with three honest outcomes, Go, Review or No-Fit, before the seven stages begin. The Internal Review Pack later on this page carries this process map into your internal discussion.
- 01
Enquiry
First intent and case scoping. Initial business and integration context is gathered so the right internal and DaoPay-side counterparts can be involved early.
- 02
Qualification
Operating model, geography, payment mix and technical route, assessed before deeper effort. It is the readiness checkpoint that decides whether the case moves into deeper integration effort.
- 03
Commercial Offer
Pricing, commercial shape and contracting readiness. Commercial and finance stakeholders can prepare the internal discussion before legal and operational setup move forward. This stage keeps commercials aligned with the actual route rather than treating integration as a detached technical exercise.
- 04
Identity & Verification
Corporate structure and operational readiness check. DaoPay Compliance & Risk carries this stage on DaoPay’s side while merchant-side compliance and risk counterparts align the case context.
- 05
Service Agreement
Signed commercial and operational contract in place. The agreed scope is converted into the contractual operating setup before production credentials are used.
- 06
Technical Integration
Staging setup, credential delivery, callback verification and merchant-side implementation. DaoPay’s Integration Team coordinates staging, credentials and technical validation. The merchant-side technical or product owner carries checkout implementation.
- 07
Go-Live
Staging validated, production credentials issued, live traffic begins. Live processing follows controlled validation rather than instant or unguided self-service access.
Ready to bring this to your team
The path is now clear from fit assessment to go-live. The Internal Review Pack turns this process map into something your internal stakeholders can review together.
See what this builds towardIdentity & Verification, viewed from the integration side.
Before any production credential is issued, corporate structure, operating perimeter and merchant-side context are checked against the payment setup. That check is the readiness stage inside the integration process. For the technical reader the value is not a compliance deep dive. It is that readiness is clarified before implementation has moved too far, rather than discovered after the work has gone too deep.
Two sides, working in parallel
- DaoPay side
- Compliance & Risk carries the stage, running the corporate and operational check against the payment setup.
- Your side
- Compliance & Risk counterparts clarify the operating case, so deeper integration continues on cleared ground.
A security baseline
your team can assess directly.
The integration environment is built around documented technical primitives: transport, credentials, signatures, notification verification and tokenised handling. These are the things a technical team can reason about before it accepts an integration route, and most of them point to where they are documented or exercised elsewhere on this page. This is assessable evidence, not decorative trust badges or broad hosting claims.
HTTPS/TLS transport
Transport security is part of the documented integration baseline.
This keeps the assurance layer anchored in how the integration is transported and verified, rather than in decorative trust signals.
Merchant credentials
Merchant-specific credentials support authenticated requests.
Credential issuance remains part of the controlled staging path carried by the Integration Team.
Signature calculation
Cryptographic signature calculations are part of the public technical reference.
This gives engineering teams a concrete verification surface before and during staging. The calculation is documented in the public API reference.
Notification verification
Payment Status Notifications can be checked on receipt.
Verification belongs in the asynchronous notification handling plan and should be considered before production use.
Tokenised flows
Card-data handling is supported through tokenised flows.
Tokenised handling helps separate sensitive card details from ordinary merchant-side data flows and gives technical reviewers a concrete card-data boundary to discuss.
The Integration Team is your technical counterpart.
During staging and technical integration your engineers work with DaoPay’s Integration Team, and the same counterpart continues past go-live. The integration is not positioned as an unguided developer-portal exercise. The counterpart that validates your staging is the one you keep.
The same counterpart, across three phases
- During staging
- Credential delivery, staging validation, checkout flow review, and callback and notification validation.
- At go-live
- Go-live support for the integration route.
- After launch
- Integration-related follow-up, still on the same route.
A practical next step for your internal stakeholders.
By this point your team has seen the whole integration surface. The Internal Review Pack gives that journey a practical destination, a short form away from a document your internal stakeholders can review together.
What your team has already seen
- Documentation surface
- Staging model
- Notification handling
- Method coverage
- Checkout route
- Process map
- Readiness layer
- Technical baseline
- Integration Team ownership
What’s inside the Review Pack
- A one-page fit summary for your internal discussion
- Open questions organised by stakeholder role: technical, compliance, risk, finance and business owner
- What DaoPay is not, so you can rule out mismatches early
Built for stakeholder alignment
- Supports technical, compliance, risk, finance and business-owner perspectives
- Helps your team discuss operating fit before deeper engagement
- Request-based access. The next step stays aligned with your merchant case, not a public file download
The page has already separated what can be evaluated publicly, what is clarified in staging, what belongs to fit assessment, and what must be owned before live processing. The request path turns that structure into something your stakeholders can review together.