Build on a canonical payment model

Design integrations around stable internal payment records, explicit state transitions, idempotency and a universal ledger rather than coupling application logic to one provider.
Make your first authenticated request
First register the website or app you are building in the authenticated Developer Console. Then select that application to create its sandbox API keys and webhooks. Keep secrets on your server, not in browser JavaScript or a public repository. Every write must include a unique Idempotency-Key.
curl -X GET "https://paymatrixai.com/_api/developer_api_status" \ -H "Authorization: Bearer pmx_sandbox_YOUR_SECRET"
/_api/developer_api_statusVerify sandbox authentication and see capability gates.
/_api/developer_api_capabilitiesRead API version and supported permission scopes.
/_api/developer_api_payments?limit=25List sandbox payment records.
/_api/developer_api_paymentsCreate a sandbox payment; requires payments:write and Idempotency-Key.
/_api/developer_api_customersCreate a sandbox customer; requires customers:write and Idempotency-Key.
/_api/developer_api_transfersCreate a sandbox transfer quote; requires transfers:write and Idempotency-Key.
All endpoints above are sandbox-only. The API does not move real money or enable production credentials.
Core resources
Every write is explicit
Write requests use an Idempotency-Key. PayMatrixAI fingerprints the method, route and request body. Reusing a key with a different request is rejected; a completed request can be safely replayed.
Authorization: Bearer pmx_sandbox_…\nIdempotency-Key: order_2026_0001\nContent-Type: application/json
Traceable API responses
Responses include a request ID and sandbox marker. Errors use structured codes. Payment and transfer state changes are validated server-side before persistence.
{
"object": "payment",
"sandbox": true,
"requestId": "…",
"status": "pending"
}Use a scoped sandbox key and organization context.
Attach a unique idempotency key to each mutation.
Inspect request IDs, webhook delivery and state history.
Canonical records, provider-neutral integration
PMX records remain the application-facing contract. Provider transaction identifiers are stored separately. State transitions are server-enforced, financial integrity is reconciled against provider events, and live provider activation remains gated behind production readiness controls.
developer key → scope → idempotency → audit trail
Sandbox endpoints and contracts are presented for inspection. No live API credential, production payment rail or real-money execution is implied by this public page.
The public developer surface describes the current sandbox architecture. Live credentials and real-money execution require separate production authorization, regulated provider connectivity, compliance approval, security verification and operational readiness.
