The reference cashier is a controlled Stage Sandbox checkout. It demonstrates the same Payment API v2 create / retrieve / webhook path your server should implement.

What the cashier proves

The cashier is a minimal TRX merchant checkout:
  • Fixed test product priced at USD 10.00
  • Payment asset TRX on Tron Shasta
  • Business quote validity of 15 minutes
  • Buyer-facing UI that never exposes Morphosis signing secrets
Use it to validate connectivity and UX before wiring your own backend.

Buyer path

1

Open the cashier

2

Get a live TRX quote

The cashier requests a quote for the fixed USD amount, then shows the TRX amount the buyer should send.
3

Create the payment

Order creation calls Morphosis POST /v2/payments with HMAC v2 from the cashier server. The browser never sees the signing secret.
4

Show deposit instructions

The UI presents the deposit address and exact TRX amount returned in payment_instructions.
5

Track settlement

The cashier polls GET /v2/payments/{payment_id} and accepts signed payment.updated webhooks. Fulfilment is allowed only after paid.

Map cashier behaviour to your integration

Operator cross-check

While a cashier payment is in flight, open the Payment Gateway routing console to confirm the sandbox routes for:
  • POST /v2/payments
  • GET /v2/payments/{payment_id}
  • GET /openapi/payments-v2.yaml
Traffic and log views on the same console help correlate a failed create with auth, validation, or upstream errors without exposing secrets in the merchant docs.

What not to copy blindly

  • The cashier may still use a separate quote path for display before create. Your production UX can quote however you like; settlement authority remains the Payment API payment resource.
  • Cashier-local recovery tables and portal diagnostics are harness details, not part of the public Payment API.
  • Do not scrape the cashier for credentials. Request your own sandbox merchant profile.