How long does onboarding take?

There is no fixed SLA on this public site. Timelines depend on intake quality, capacity, risk review, and how quickly your team can join technical discussions. Expect a measured process rather than same-day universal activation.

What information should I prepare?

Company or project identity, website, use case, rough monthly volume, required rails (networks and assets), a technical contact, and a preferred follow-up channel (Telegram or email). Never prepare or send private keys, seed phrases, API keys, or webhook secrets to qualify.

Do all merchants get approved?

No. Approval is a risk and fit decision. We may decline, defer, or scope access when the model, geography, or technical posture is not aligned with what we can support safely on selected rails.

Which rails can be enabled?

Rails are selected and enabled per merchant environment where available—not as universal open-ended coverage. The exact set is agreed after review and is not represented as a public inventory on this marketing site.

Can I test integration before production?

Non-production access and materials are discussed after approval and alignment on scope. This site does not promise public self-serve sandbox keys; plan for server-to-server patterns, webhook verification, and reconciliation dry-runs from the first environment you receive.

Can approval be partial or scoped?

Yes. Access may be enabled with limited rails, non-production first, or operational holds until your mapping, monitoring, and reconciliation posture match what you intend to run in production.

Merchant access & onboarding

Review process

We triage inbound requests for basic fit: business model, geography, rails needs, and whether your use case matches B2B server-to-server integrations. The structured intake on the request access page reduces back-and-forth.

Integration discussion

Technical alignment covers payment creation, lifecycle semantics, webhook signing on raw bytes, idempotent consumers, and how you map external states to orders and finance controls. Sessions coordinate engineering and treasury stakeholders — we do not collect secrets in email or chat.

Merchant approval

Approval is not guaranteed. Outcomes include scoped production access, deferral pending information, or decline when the model cannot be supported safely. Partial approval — limited rails or staged enablement — is normal. See the merchant review walkthrough on Operations (illustrative, not an SLA).

Example operational flow: merchant review →

Environments and rollout

Non-production and production are separate configurations: credentials, webhook URLs, rails, and confirmation policy. Rollout is deliberate — mapping review, verification tests, monitoring baselines, then controlled traffic. Integrations typically iterate over multiple cycles before steady-state operations.

Operational requirements

Operate API keys and webhook secrets only on your infrastructure. Monitor delivery failures and signature errors. Treat withdrawals and settlements as policy-governed operational flows with human review where configuration requires it.

Selected rails

Enabled networks and assets are agreed per environment and may differ between non-production and production. Unsupported combinations should fail at creation — we do not publish a volatile public asset matrix on this site.

Support expectations

Support coordinates integration and operational clarity for approved merchants — not custody of keys, remote wallet access, or urgent verification scams. Escalations should include payment_id and lifecycle context.

Separate environments. Non-production and production use distinct configuration: API credentials, webhook URLs, rails, and confirmation policy. Do not share secrets across environments.
Scoped approval. Approval can be partial: limited rails, staged access, or operational holds until mapping and monitoring meet your production bar.
Configuration drift. Portal settings, consumer code, and finance rules can diverge over time. Periodic alignment reviews reduce “paid in portal, wrong in ERP” incidents.
Controlled rollout. Rollout is sequenced: mapping agreement, verification tests, monitoring baselines, then production traffic — integrations mature over weeks, not a single deploy.

Onboarding coordination. Intake, technical review, and environment enablement are coordinated — not a single anonymous signup button.
Integration iteration. Expect multiple webhook test cycles, idempotency fixes, and mapping clarifications across environments before steady production traffic.
Webhook monitoring. Monitor non-2xx delivery, signature failures, and consumer error rates on your side. Operational drift surfaces in logs before treasury escalations.
Escalation paths. Engineering owns verification and consumers; finance owns recognition rules and exception queues. Route with payment_id — not wallet access.

Full walkthroughs: /operations · Request access

FAQ

01: How long does onboarding take?
There is no fixed SLA on this public site. Timelines depend on intake quality, capacity, risk review, and how quickly your team can join technical discussions. Expect a measured process rather than same-day universal activation.
02: What information should I prepare?
Company or project identity, website, use case, rough monthly volume, required rails (networks and assets), a technical contact, and a preferred follow-up channel (Telegram or email). Never prepare or send private keys, seed phrases, API keys, or webhook secrets to qualify.
03: Do all merchants get approved?
No. Approval is a risk and fit decision. We may decline, defer, or scope access when the model, geography, or technical posture is not aligned with what we can support safely on selected rails.
04: Which rails can be enabled?
Rails are selected and enabled per merchant environment where available—not as universal open-ended coverage. The exact set is agreed after review and is not represented as a public inventory on this marketing site.
05: Can I test integration before production?
Non-production access and materials are discussed after approval and alignment on scope. This site does not promise public self-serve sandbox keys; plan for server-to-server patterns, webhook verification, and reconciliation dry-runs from the first environment you receive.
06: Can approval be partial or scoped?
Yes. Access may be enabled with limited rails, non-production first, or operational holds until your mapping, monitoring, and reconciliation posture match what you intend to run in production.