Security • Trust • Risk Controls • Operational Transparency
Security & operational trust
without the “KYC-loop” pain.
EcomTrade24 Pay is built for merchants who need reliable payments in complex industries. This page explains — in plain English — how we handle security, onboarding, and operational controls to reduce the chaos merchants face.
Legal businesses only • Risk-based onboarding • Encrypted transport (TLS) • Webhooks + logs
What “trust” means in payments
Not hype. Not promises. Clear controls, predictable behavior, and transparency for merchants.
Encrypted transport
Platform communication is designed to run over HTTPS (TLS). Merchants should also enforce HTTPS on their shop to keep the full path encrypted.
- ✅ TLS for data in transit
- ✅ Secure session handoff patterns
- ✅ Reduced exposure of sensitive fields
Risk-based onboarding
“No KYC loops” means we avoid invasive document onboarding for standard merchants. Verification escalates only when risk or volume requires it.
- ✅ Fast start for standard onboarding
- ✅ Escalation only when needed
- ✅ Clear rules: legal businesses only
Operational transparency
Merchants need predictable status updates. We emphasize webhooks, logs, and clear events so your system can stay in sync.
- ✅ Webhooks for status changes
- ✅ Event logs for auditability
- ✅ Integrations for WooCommerce & API
Funds flow and “no platform balance”
Many merchants get burned by “platform balance” mechanics (holds, freezes, payout schedules). Our approach is designed to avoid a custodial platform wallet where possible, and to keep the flow predictable.
Tip: Use webhooks + idempotency so order status stays correct even during retries.
Merchant-side best practices (recommended)
- ✅ Enforce HTTPS on your shop and admin panels
- ✅ Validate webhook authenticity and process idempotently
- ✅ Store only what you need (data minimization)
- ✅ Keep server software up to date (PHP, OpenSSL, dependencies)
- ✅ Restrict admin access with strong passwords + MFA where possible
Data handling: simple, minimal, purpose-based
Trust improves when everyone stores less. We aim for data minimization: only store what’s needed to operate payments and support merchants.
For details about privacy and merchant data, see the privacy policy.
Clear rules (protect merchants long-term)
We are high-risk friendly — but we are not “anything goes”. Clear acceptable use reduces abuse, improves routing stability, and protects serious merchants.
- ✅ Legal businesses only
- ✅ Merchants must comply with our terms
- ✅ Misuse results in access restrictions
If you’re unsure about your category, contact support before scaling traffic.
Security FAQ
Short answers to the trust questions merchants actually ask.
Do you require KYC/KYB to start?
We avoid invasive document onboarding for standard merchants. We use risk-based onboarding and may request enhanced verification only if volume, dispute patterns, or risk indicators require it.
Do you store customer card data?
We do not aim to store raw card numbers ourselves. Payment data is handled in the secure payment flow provided by the underlying payment methods/providers. Your integration should never capture raw card details on your server.
How do you secure data in transit?
We use encrypted transport (TLS) for platform communication. Always ensure your shop and server also enforce HTTPS to keep the full path encrypted.
How do webhooks stay trustworthy?
Use webhook verification and idempotent processing: validate the source, verify signatures/tokens (if configured), and treat webhooks as the source of truth for payment status updates.
Are you high-risk friendly?
Yes — we support complex industries that get blocked elsewhere, as long as the business is legal and complies with our rules and acceptable use.
Operate payments like infrastructure.
Risk-based onboarding (no invasive KYC loops) • Encrypted transport • Webhooks + logs • High-risk friendly (legal only)
Legal businesses only • Risk-based onboarding • Security-first operations