Draft API Preview for the MorphosisBlock Payment API. Endpoints described here are contract proposals. They are not implemented, publicly hosted, or approved for production use.

​
Accept a payment with one integration

Server-to-server sandbox deposits through one payment resource. The MorphosisBlock Payment API preview defines a small, provider-neutral surface for accepting a deposit in Sandbox / TRON Shasta. A merchant creates one payment, shows the returned amount and deposit address to the customer, retrieves the payment when needed, and consumes signed status updates. The API reference is generated from the draft OpenAPI 3.1 contract. The guides explain the merchant decisions around that contract without adding another source of API truth.

​
Contract conventions

​
Draft first-slice contract

Every create request carries an Idempotency-Key. Monetary values use decimal strings for display and string-encoded minimum-unit values for exact accounting.

​
Integration flow

1

Create one sandbox payment

Submit the merchant order reference and an exact USD amount to POST /v2/payments. Persist the returned payment identifier before showing payment instructions to a customer.
2

Present the quoted deposit

Display the returned TRX decimal amount, its exact base-unit amount, and the deposit address exactly as received. Documentation values are illustrative and must never receive funds.
3

Track the lifecycle

Treat the API response as the current state and consume payment.updated events. Use GET /v2/payments/{payment_id} when your system needs a fresh view.
4

Fulfil only after paid

Deliver the purchased product only after the payment state is paid and your own order checks pass.

​
Draft boundary

This preview deliberately provides no callable API server. Examples use https://api.example.invalid, a reserved non-routable domain, and use documentation-only credentials. The initial contract covers deposit creation, retrieval, and the payment.updated event only. Network transport, final commercial terms, service levels, and launch availability remain undecided until the contract and implementation pass separate reviews.

​
Continue

  • Follow the Quickstart to construct and sign a complete draft request.
  • Read Authentication before implementing request signing.
  • Review the Payment lifecycle before mapping states to fulfilment.
  • Implement Webhooks as an idempotent notification path.