Your wallets. Not ours.
True non-custodial by design: every invoice address is bound to a destination you control before a payer sees it. Settlematic watches the chain for reconciliation - we never hold keys that can move your funds.
Definition
What is true non-custodial settlement?
Invoice and checkout addresses are cryptographically bound to merchant-controlled destinations at issuance. Settlematic detects payments on-chain for reconciliation only - no platform private keys, no interim wallet, no redirect of issued addresses.
Businesses invoice in USD or EUR, clients pay in crypto across 8 networks. Every invoice address is cryptographically bound to a destination you control before it is shown to a payer. Settlematic watches the chain for confirmation and reconciliation - we never hold private keys that can move your funds.
Bound invoice addresses
Each invoice or checkout gets a unique address cryptographically bound to a destination you control before any payer sees it. Funds settle there directly - Settlematic never holds an interim wallet or private key that can move them.
No platform signing authority
We do not hold merchant private keys, key shards, or any secret that can authorize fund movement. Merchant API keys are hashed at rest. Watch-only workers detect confirmations for reconciliation - they cannot redirect issued addresses.
Infrastructure
Isolated workers for chain monitoring, signed HMAC webhooks, role-based access across Collect and Gateway, rate limiting, and append-only audit logs for sensitive operations like payout destination changes.
Access control
Team seats with scoped permissions, optional TOTP for operators, and separate sandbox vs mainnet environments so test data never mixes with production funds.
Data protection
TLS in transit, encrypted secrets at rest, and minimal retention of payer PII - checkout collects only what reconciliation requires.
Responsible disclosure
Report vulnerabilities to [email protected]. We acknowledge valid reports and work with researchers on coordinated disclosure.
[email protected]Architecture
Cryptographically bound payment addresses
Each payment uses a unique address fixed to your wallet (or split destinations) at issuance - BIP-84 / CREATE2-style binding, not a temporary platform wallet. Confirmed funds land where you control them. We never hold your funds.
See the payment flow
Operations
Controls finance teams expect
Role-based access, optional TOTP for operators, separate sandbox and mainnet environments, and audit logs for payout destination changes - built for teams who reconcile books.
Security architecture
Security in practice
Controls operators and developers rely on every day.
Invoice-scoped addresses
Each payment gets a unique address bound at issuance - deterministic reconciliation without platform custody.
Signed webhooks
Verify HMAC signatures on every delivery. Replay protection and delivery logs for debugging.
Bound payout destinations
Changing where new invoices settle can require a waiting period; addresses already issued stay bound to their original destination.
Current security posture
Settlematic never holds merchant private keys or key shards that can move funds. Invoice addresses are cryptographically bound to destinations you control; we watch the chain for detection and reconciliation only. Formal SOC 2 certification is in progress; we publish architecture details and accept vulnerability reports at [email protected].
Reviewed by the Settlematic product team. . Keshav Sharma · Editorial standards
No. Invoice addresses are bound to destinations you control at issuance. Settlematic watches the chain for detection and reconciliation only - we never hold private keys, key shards, or interim wallets that can move your funds.
Questions about security?
Our team responds to security inquiries and vulnerability reports promptly.