Create a payment order via the POST /payment_orders endpoint; specify the type (ach, wire, rtp, eft), direction (credit or debit), amount in the smallest currency unit, originating_account_id, and the receiving_account object with routing and account details
Set the effective_date for ACH to the desired settlement date, accounting for NACHA cutoffs; for RTP and wire, omit effective_date as these settle the same day
Monitor payment order status via webhooks (payment_order.status_changed events) or polling; statuses progress through pending_approval → approved → processing → sent → returned/cancelled
When using Modern Treasury's ledger product, create a ledger transaction linked to the payment order to record the double-entry bookkeeping impact; specify ledger_account_id and direction (debit/credit) for each ledger entry
Handle returned payment orders by inspecting the return_reason field; create a reversing ledger transaction to offset the original entries and trigger customer notification logic
Known gotchas
Modern Treasury does not move money directly — it orchestrates payments through your connected bank accounts; ensure your bank integration is active and funded before creating payment orders
Approval workflows: if your Modern Treasury configuration requires human approval for payments above a threshold, payment orders sit in pending_approval until approved — automate approval via the API only if your compliance process permits it
Ledger transactions are append-only and immutable once posted; to reverse a ledger entry you must create an equal and opposite transaction — you cannot delete or edit posted entries
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp