Collections

Collect, read, follow. The central resource is the operation; the nominal journey is the hosted checkout.

Create a collection

POST /v1/payments

Field	Required	Description
asset_id	yes	The asset, by identifier (GET /v1/assets)
amount_minor	yes	String, in minor units ("500000" on a zero-decimal asset is 500,000)
country	yes	Country of the operation (ISO 3166-1 alpha-2)
platform_id	yes	The collecting platform (GET /v1/corridors)
platform_account_handle	—	The sub-account to credit. Empty = the corridor's primary
rail	—	Forces a specific rail instead of letting routing choose
payer	—	{ "name", "phone", "email", "country" }
client_ref	—	Your reference, returned on reads and webhooks
description	—	Free text
expires_in_seconds	—	How long the payment intent stays valid

The response is an operation in status initiated, with what you need to make the customer pay:

{
  "id": "op_01J8Z9K2QW",
  "ref": "NP-...",
  "client_ref": "order-1042",
  "kind": "payin",
  "status": "initiated",
  "asset_id": 1,
  "amount_minor": "500000",
  "fee_minor": "...",
  "net_minor": "...",
  "payment_url": "https://pay.neo-pays.com/...",
  "is_test": true
}

rail forces, it does not suggest. Omit it and routing picks the best open rail; name it and an unavailable rail fails the creation instead of falling back to another.

Read and list

GET /v1/payments/{id}   — one operation
GET /v1/payments        — paginated list (page, per_page)

{id} accepts the internal identifier, the operation's reference, or your own client_ref.

The read is local: nothing is asked of the rail. The payer's contact details are masked there, because the read model never holds the raw ones — the creation response does return what you just sent.

Lists are served from a read replica: no report can ever slow a payment down.

The other families

The same object under its own name: /v1/payouts, /v1/refunds, /v1/transfers, /v1/rebalances. GET /v1/payouts/{id} and its siblings return the same masked view, with the same ownership check.