Developer docs

PayChainHQ docs for payments and contract automation

Workflow-first documentation for external teams integrating PayChainHQ business APIs for invoices, contract interactions, on-chain settlement, treasury withdrawals, and reconciliation.

Canonical integration surface: public docs pages + downloadable OpenAPI contract snapshot.
Sandbox and live are documented separately so operators do not confuse approval state with activation.
Examples use cURL and Node.js/TypeScript, with raw-first monetary payloads throughout plus contract interaction examples for EVM ABIs and Solana Anchor IDLs.
Reference pages are grouped by workflow so your team can jump from quickstart to detailed endpoint behavior.

Start with the shortest successful path

Most external teams need the same sequence: open a sandbox business in the dashboard, provision an API key, create invoices for supported ERC-20 or SPL payments, optionally register contract surfaces for controlled reads and execution, confirm settlement with webhooks, then move treasury funds out safely.

1. Authenticate once

Create a sandbox business in the dashboard, then provision a business API key for server-side requests.

2. Create customers and invoices

Generate a deterministic deposit request with the right token, network, expiry, and tolerance settings.

3. Confirm by webhook first

Use signed webhook events for real-time updates and invoice reads as reconciliation fallback.

4. Quote and withdraw

Quote treasury availability first, then create withdrawals by dashboard step-up or a dedicated payout API key.

5. Register contract surfaces carefully

If your backend needs controlled contract reads or executions, register EVM ABIs or Solana Anchor IDLs first, then publish constrained actions.

6. Separate sandbox from live

Sandbox activation and live approval are different states. Treat them as separate operator workflows.

7. Store request IDs

Persist `requestId`, your own `clientReference`, webhook delivery IDs, and invoice / withdrawal IDs for support and auditability.

Recommended reading order

If you are onboarding a new engineering team, use this order.

Contract interactions are part of the supported surface

PayChainHQ does not stop at payment collection. You can also register chain-specific interfaces and expose a constrained automation surface to your backend.

EVM contracts

Register a contract address plus ABI, discover write and query operations, then publish only the actions you want your backend to execute.

Solana programs

Register a program ID plus Anchor IDL, query decoded accounts, simulate instructions, and publish single-business-signer actions with explicit account mappings.

Split responsibilities cleanly

Operators create integrations and publish actions in the dashboard. Your backend later queries, quotes, and executes the already-approved surface with API keys.

Machine-readable contract and written guidance serve different jobs

Use the docs pages for operational guidance, and the OpenAPI artifact for code generation or SDK scaffolding.

  • The downloadable OpenAPI artifact is regenerated from backend Swagger annotations and filtered to the external business/public surface.
  • The written docs remain richer than the contract: they include workflow ordering, reconciliation notes, environment warnings, and operational cautions.
  • First-party dashboard/session routes are intentionally excluded from the external developer surface.
  • If an endpoint appears on a reference page, it is part of the supported external docs inventory even if the machine-readable contract lags behind a newly added annotation.

Do not treat docs examples as accounting truth

All monetary values in real integrations are raw-first. Use `raw`, `decimals`, and immutable event-time metadata for reconciliation. Display strings are there for human readability.

API Docs | PayChainHQ