Help center
Account, workflow status, and support routing.
Resources
Support, compliance resources, and product guidance in one place.
A clear entry point for support channels, compliance references, product FAQs, developer placeholders, and service notices while backend implementation and legal review continue.
This page is a resource structure preview. Final policy wording, API documentation, service status, and support SLAs require backend, legal, and operations confirmation.
Resource centerWhat users should find
HelpAnswers to common product and account questions
ComplianceLegal drafts and review expectations
DevelopersFuture API and webhook documentation
StatusMaintenance and incident notice placeholder
Resource hub
Organize support and product information before the backend is connected.
Keep the resource center useful without implying unconfirmed product availability, support SLAs, live APIs, or final legal wording.
Compliance resources
Legal drafts, AML/KYC expectations, and disclosures.
Developer docs
Future APIs, webhooks, exports, and integration notes.
Status and notices
Future maintenance, incident, and customer notices.
Recommended pathStart with support routing, then legal drafts, then developer documentation once backend scope is confirmed.
Developer documentationAPI preview, webhook model, status definitions, and future integration notes.Client portal previewCustomer dashboard modules, payment visibility, activity feed, and role concepts.Onboarding and KYB flowBusiness review journey, required documents, review statuses, and control points.Legal draftsCompliance, risk disclosure, privacy, terms, and AML/KYC policy drafts pending legal review.
FAQ
Answer high-risk questions with conservative wording.
FAQs for payment products should reduce confusion without making unsupported claims about approval, banking, settlement, APIs, or coverage.
Is OrbitLink Pay a bank?
No. OrbitLink Pay is not a bank. The site should keep MSB registration, compliance controls, banking partnerships, and custody language clearly separated.
Can a customer start using payment services immediately?
No automatic approval should be implied. Business type, region, counterparties, use case, documentation, compliance review, and partner availability may affect access.
Where should support requests go?
General product support should go to [email protected]. Business and partnership inquiries should go to [email protected].
Are API and webhook documents ready?
Not yet. Developer documentation should remain a placeholder until backend implementation, security controls, authentication, and legal terms are defined.
Documentation roadmap
Prepare the doc structure now, publish details only when confirmed.
Developer docs and policy resources should become real operating assets later. For now, they should remain clearly marked as placeholders.
ComplianceMSB disclosure, AML/KYC policy, risk disclosure, privacy policy, and terms.
OperationsPayment status definitions, exception handling, reconciliation exports, and support workflow.
DevelopersAPI authentication, webhooks, sandbox testing, error codes, and reporting formats.
StatusMaintenance windows, customer notices, incident history, and service availability notes.
Support routing
Route requests by intent, not by a single generic inbox.
Separating support, business, and complaints early makes future response-time tracking, escalation handling, and operational reporting cleaner.
Product support
General account, product, access, and workflow questions.
[email protected]Business inquiries
Sales, partnerships, use case review, and demo requests.
[email protected]Feedback and complaints
Complaints, suggestions, service feedback, and escalation signals.
[email protected]Publishing boundaries
Keep Resources useful without overstating operational readiness.
Resource pages can accidentally imply product maturity. These boundaries keep the page aligned with the current project stage.
No live API claim until backend and documentation are ready
Use placeholder language until evidence, systems, and legal review are available.
No real-time service status claim until monitoring infrastructure exists
Use placeholder language until evidence, systems, and legal review are available.
No final policy wording until legal review is complete
Use placeholder language until evidence, systems, and legal review are available.
No support SLA promise until operational coverage is defined
Use placeholder language until evidence, systems, and legal review are available.
Resource center next step