FAQ
This page covers the product, the API, payment links, settlement, security, and the day-to-day operational questions that come up during evaluation and integration.
A clear map for teams evaluating the platform, from what NITY0X is to how the public surfaces fit together.
NITY0X is stablecoin settlement infrastructure. It lets you accept USDT across Ethereum, BNB Chain, Tron, Solana, and Polygon, then follow the payment lifecycle, settlement, balances, payouts, and signed webhooks from one platform.
The product is built for merchant developers, operators, treasury teams, compliance reviewers, and platform administrators who need real payment infrastructure rather than a marketing-only crypto wrapper.
The product is in testnet / pre-mainnet stabilization while the team prepares for controlled mainnet readiness. The public surfaces, dashboard, docs, and lifecycle logic are active so integrations can be evaluated end to end.
No. Those surfaces share the same platform primitives, state model, and event stream. A payment created through the API, hosted checkout, or payment link still lands in the same lifecycle and webhook system.
The dashboard gives operators search, filters, exports, audit trails, account controls, merchant and organization lifecycle management, and a live view of payment and settlement state without requiring a separate admin tool.
How hosted payments work, how state changes are represented, and what happens when an on-chain transaction lands.
The platform is centered on USDT and supports Ethereum, BNB Chain, Tron, Solana, and Polygon. Chain support is visible throughout the landing experience, API docs, payment flows, and dashboard.
A payment advances through a deterministic lifecycle: intent_created, awaiting_payment, pending, confirming, confirmed, with expired and failed as terminal states. The exact state is exposed in the API, dashboard, and webhooks.
Yes. The hosted flow can present enabled networks and the payer chooses one during checkout. That keeps the merchant integration simple while still letting the customer pay from the supported chain they prefer.
Once on-chain confirmation clears, the payment becomes confirmed, the merchant balance is updated, and the signed webhook event fires. That confirmed event is the signal downstream systems should treat as the source of truth.
Expired payments remain visible for auditability, but they no longer complete the normal settlement path. The public docs and dashboard both treat expiry as a terminal state, not something that is silently retried.
Hosted checkout links are short-lived by design so they stay safe, predictable, and easy to reason about.
Payment links expire 30 minutes after creation. The expiry is intentional and enforced in the API and checkout flow so a link cannot be kept alive indefinitely.
No. Expired links are not reactivated. If you need a new checkout request, generate a new payment link so the lifecycle remains unambiguous.
Yes. Payment links can be toggled inactive from the dashboard and API. That lets you withdraw an offer before the 30-minute expiry window ends.
Each link stores the amount, currency, description, active state, creation timestamp, and expiry timestamp, along with the slug and merchant association needed to route the checkout correctly.
Yes. A payment link simply creates a hosted entry point. The actual payment still goes through the same payment state machine, settlement handling, and signed webhook flow as any other payment.
The difference between gross payment value, fees, net settlement, and the actual on-chain transfer out of the system.
Settlement is the internal accounting event that moves a confirmed payment into available balance. A payout is the outward transfer that sweeps a confirmed balance to a destination address on-chain.
Only confirmed, settled balances are eligible for payout. Pending or confirming funds are excluded until the payment is finalized.
Payout destinations are configured per merchant or organization in the dashboard. The settings and settlement pages keep the destination history visible so operators can audit where funds are configured to move.
Failed payouts remain visible in the dashboard and API with their failure state and timestamps. That keeps the operator able to investigate, retry only when appropriate, and preserve a clean audit trail.
Gross value, platform fees, and net settlement are tracked separately so operators can see exactly what was collected, what was retained, and what was available for settlement or treasury reporting.
The integration layer is built to be readable, deterministic, and friendly to teams that want copy-pasteable examples.
API requests use bearer keys. Sandbox and production keys are separated, keys are hashed before storage, and the dashboard exposes the lifecycle needed to create, rotate, and revoke them safely.
Yes. Mutating endpoints support Idempotency-Key so retries do not create duplicate records. That is especially important for payment creation and payout flows that move real value.
Yes. Webhook delivery is signed so your server can verify the event origin before trusting the payload. The public docs include examples and the dashboard provides the related configuration surfaces.
The OpenAPI page provides the machine-readable API specification. It is intended for client generation, tooling, and teams that want to inspect or import the schema directly.
Yes. The public docs are organized around examples and response payloads so developers can read the flow side by side rather than translate a generic reference into working code by hand.
Authentication, 2FA, merchant access, org access, and the guardrails that keep sensitive actions explicit.
Yes. Dashboard login supports TOTP, and the security area includes the related setup, recovery, and device management flows.
Recovery codes are single-use fallback credentials for 2FA. They exist so a locked-out user can regain access without weakening the normal authentication path.
Yes. Admin and platform surfaces support explicit access control for merchants and organizations so operators can suspend or restore access without mutating the underlying record incorrectly.
Suspended access blocks normal operations until it is restored. The lifecycle is preserved so onboarding or active state is not destroyed just because access was temporarily disabled.
KYC and AML are handled as part of the operational dashboard and workflow surfaces, not as an afterthought. They exist so compliance reviewers can inspect status, evidence, and audit actions alongside the rest of the merchant lifecycle.
Yes. Audit views are part of the platform for both merchant and organization scopes, which lets teams trace key changes, approvals, and security events.
Common operational questions, where to look first, and what to do when something does not match expectation.
Check the payment state, the selected chain, the expiry window, and the merchant scope. The dashboard, API, and webhooks should all agree; if they do not, inspect the audit trail next.
Expired objects are expected to remain visible but inactive. Create a new payment or payment link instead of trying to force the old one back into service.
Use the public docs for implementation details and the contact page for sales or hands-on help. The footer also links to the guide and support surfaces for quick navigation.
Use the contact path for product feedback, and include the route, endpoint, or dashboard screen you were using when the issue occurred. That keeps triage efficient and gives the team the context needed to reproduce the problem.
Need something specific?
Integration, compliance, account access, and sales questions can all start from the contact page. If you need product usage help, the docs and guides usually answer faster than email.