Security is the product under the product
Here is what actually protects money and personal data on this platform today, and what is still planned — no fabricated certifications, just what is built.
Built, not claimed
What's actually in place today
No raw card data on our systems
Card details are intended to be handled through compliant payment-partner and tokenisation infrastructure. DorskoPay's own systems do not store raw card data.
HMAC-signed webhooks
Every webhook event is signed with HMAC-SHA256 and timestamped, so your endpoint can verify it came from us and hasn't been replayed.
Hashed, scoped API keys
API keys are hashed at rest and can be revoked individually at any time from your dashboard.
Full admin audit trail
Every mutating admin action — refunds, commission changes, account suspensions — is logged with who, what and when.
Login activity logging
Every sign-in attempt, successful or failed, is logged with IP address and device — visible to you in Settings.
Sandbox by default
You can test your entire integration — checkout, subscriptions, webhooks — before a single real transaction happens.
Architecture
How it's actually built
-
lock
Encrypted in transit
Every connection to the platform runs over TLS — checkout, dashboard and API alike.
-
key
Hashed, revocable API keys
API keys are hashed at rest, scoped to your account, and can be revoked individually at any time.
-
shield_lock
Ownership-scoped data access
Merchant dashboards only ever query that merchant's own data — enforced at the database-query level, not just the UI.
-
webhook
Signed webhooks
Every webhook carries an HMAC-SHA256 signature and timestamp, so your endpoint can verify authenticity and reject replays.
-
history
Audit logging
Every mutating admin action is written to an audit trail with the actor, the target and the timestamp — refunds, commission changes, approvals and suspensions included.
-
vpn_key
Secrets management
Credentials and provider keys are held in environment configuration outside the code repository. A managed secrets store is planned as part of the production rollout.
-
admin_panel_settings
Restricted production access
Administrative capability is role-scoped inside the application. Formal, documented production access control is planned as part of the production rollout.
-
fact_check
Supplier KYB controls
Sellers are verified on company, ownership, product and banking details before production access. Production identity verification is designed to run through an approved third-party verification provider; sandbox verification flows may be simulated.
Every payment
Full transaction record — gross, tax, commission, net, status
Every admin action
Who changed what, on which account, and when
Every sign-in
Success or failure, IP address, device
Every webhook
Delivery attempt, response, signed payload
Production controls
Specified, and waiting on a dependency
These controls are designed and documented but depend on infrastructure that is not yet in place. They are listed here as pending, not as implemented.
| Control | Status | Depends on |
|---|---|---|
| Hosted card fields and tokenisation | Not live | The acquiring or gateway partner that ultimately processes card payments. No raw card number or security code is stored on DorskoPay systems today, and none is intended to be. |
| PCI DSS scope determination | Not determined | The acquirer and gateway selection. The applicable SAQ and any AoC requirement follow from that architecture; we do not claim a level before it is fixed. |
| Production identity verification | Integrated, not enabled | A contracted identity verification provider. The platform ships with verification simulated and no provider credentials configured. |
| Acquirer-side fraud tooling and 3-D Secure | Not live | The acquiring partner. Platform-side velocity, device and risk-flag controls run today; scheme-level authentication does not. |
| Managed secrets store | Planned | Production hosting decisions. Credentials are currently held in environment configuration outside the code repository. |
| Formal production access control and change management | Partially implemented | Documented procedures are in place internally; role-scoped administrative capability is enforced in the application. Independent review is pending. |
| Independent penetration test and security audit | Not performed | Scheduling with an external testing provider. No third party has assessed the platform to date, and we do not imply otherwise. |
| Uptime and availability monitoring | Not live | Production monitoring tooling. The status page reflects this today rather than reporting figures we do not measure. |
DorskoPay maintains internal information security, incident response, business continuity and data retention policies. They are internal documents rather than published pages, and are available to a payment partner, an auditor or a customer running a vendor security review on request.
Where we're headed
Formal certifications: on the roadmap, not claimed yet
PCI DSS
Not yet certified. Final PCI DSS scope and applicable SAQ/AoC requirements will be determined once the production acquiring/payment integration is selected. Card details are intended to be handled through compliant payment-partner and tokenisation infrastructure rather than stored on our systems.
SOC 2
Not yet attested. Formal third-party security audits are a goal as the platform matures, not a claim we make today.
ISO 27001
Not yet certified. We'd rather say so than display a badge we haven't earned.
Responsible disclosure
Found a security issue? Email us directly — every report is read by a human.
Doing a vendor security review? Email us — we'll answer honestly about what's in place today and what's still being built.
Ask us anything arrow_forwardTrust is earned
in milliseconds.
Every transaction, every webhook, every login — logged, scoped and encrypted in transit. Ask us what is built and what is planned; we will answer precisely.
Free sandbox account · Cancel anytime · Scheduled payouts subject to settlement and reserve terms