Reorg protection
No credit on a single block. A payment climbs Pending → Safe → Finalized, with automatic re-verification up to finality and a manual ReverifyBlock for edge cases.
SECURITY
Security built for moving money
Eight arms, one job: get the money to you and prove it stayed. A payment is held until the configured finality threshold. That comes with reorg re-verification, idempotent APIs, atomic balances that never go negative, scoped API keys, and 2FA. We are just as clear about what we don't do yet.
How we protect your payments
Crypto acceptance breaks in specific, boring ways. A block gets re-mined. A retry double-charges. One leaked key opens everything. Each card below is a part Suward already runs in code, not a promise, and you can follow any of them to the detail.
Idempotency
Send the same create request twice with its Idempotency-Key and you get the same payment back, not a second charge.
Reliable internal handling
Inside Suward, an outbox carries status events from the monitor to cryptopay so a service hiccup can't lose them. You read status by polling the API, not from a webhook.
Confirmations and finality
Each chain sets its own required_confirmations: 12 on Ethereum, 15 on BSC, 128 on Polygon. A fast L2 and a reorg-prone chain don't earn trust at the same pace.
API keys and rate limits
Keys are scoped per project. Rotate the legacy key, or run several named v2 keys and revoke one at a time. Requests are rate-limited.
2FA and team access
TOTP two-factor with backup codes, plus organizations, projects, and roles so people see only what their role allows.
Atomic balances
Every credit is atomic and stored as Decimal128, split into safe and accepted, and it never drops below zero.
Fund custody
HD addresses across EVM chains, a unique deposit address for every payment. Withdrawals go through operator review today. On-chain auto-payout is on the roadmap.
Reorg
Finality you can see
A chain can quietly rewrite its recent history. A naive listener credits that reverted block and never takes it back. Suward won't. A payment is never accepted on one block. It moves Pending → Safe → Finalized, held until the configured finality threshold for that chain. Reorgs are handled automatically up to finality. For the rare edge case, an operator can re-check any block by hand with ReverifyBlock.
PendingSafeFinalized
Pending
Safe
Finalized
Money that adds up
Decimal128
Balances
Safe and accepted stay separate. Each is stored as Decimal128, so there's no float drift to reconcile later, and every credit is atomic. If a reorg moves the chain underneath, Suward recomputes the balance from on-chain reality. It never goes negative.
HD wallets
Custody, stated plainly
Suward runs HD wallets on EVM. It mints a fresh deposit address for every single payment, which is the simple reason two payments are never confused for one and no address is ever reused. Withdrawals run through an operator flow today. A person confirms the txHash. On-chain auto-payout is on the roadmap, so we won't dress a manual step up as instant.
Access and integrity
API keys
Legacy keys rotate with RotateAPIKey. The v2 model adds CreateAPIKey and RevokeAPIKey for several named keys per project, each scoped so a leak in one project doesn't reach the others.
Idempotency
An Idempotency-Key on payment creation means a retried request returns the original payment. Build aggressive retries without ever counting a payment twice.
Internal event handling
An outbox carries status events from the monitor to cryptopay so they survive a service failure. This is internal plumbing. You get a payment's status by polling the API, because merchant webhooks aren't here yet.
2FA and roles
Two-factor uses TOTP plus backup codes. Work is organized into organizations and projects, and roles such as ROLE_OWNER decide who can do what.
Infrastructure & company
Health checks and Prometheus metrics back the service. The status page shows a component-level picture, not a polished uptime number we can't yet stand behind. Company, contacts, and legal documents are linked, not hidden.
What we don't claim
No SOC 2 or PCI certificate, because we don't hold one. No claim of feature parity with larger gateways. No instant payout, since withdrawals are reviewed by an operator. No live merchant webhooks yet, so today you poll the API. And our ERC-20 detection reads the transfer() calldata only. That's why we ask payers to send a standard transfer to the unique address. Saying so is the point.
Security FAQ
When it reaches the configured finality threshold for its chain, the point where the status reads Finalized. That's per-network: 12 confirmations on Ethereum, 15 on BSC, 128 on Polygon. Until then it sits at Pending or Safe. You hold the goods.
Suward recomputes the balance from on-chain reality. The safe and accepted figures move together, atomically, so your ledger never shows money the chain took back. That's exactly why a single early block is never enough to credit you.
Not yet. Today you poll the payment status through the API, and that response is the source of truth. Webhooks and live SSE events are on the roadmap, marked Soon, and we won't show them as shipped until they are.
API keys are scoped per project. With v2 keys you can run several named keys and revoke just the compromised one with RevokeAPIKey. A freshly created key keeps the integration running. Pair that with TOTP 2FA and roles on the account.