Payments held for review (transaction monitoring, manual approval) surface as payment requests. The back office reviews and resolves them here. Both endpoints require a back-office role.

​
Review the queue

GET /v1/payments/requests — across customers, scoped by programId or allPrograms=true (bounded to your entitled programs). Without a status filter you get the actionable ones: PENDING and PENDING_TM (held by transaction monitoring). Filters: customerId, accountId, id, type, subType, currency, fromDate/toDate; paginate with page/limit; resultType=file exports CSV (presigned URL, short expiry).

​
Resolve

POST /v1/payments/requests/status: 
{
  "paymentIds": ["pay_req_1", "pay_req_2"],
  "status": "COMPLETED",
  "errorReason": "…"
}
  • status is COMPLETED (approve — the payment proceeds) or FAILED (reject).
  • Up to 50 paymentIds per call.
  • errorReason is required when rejecting — it’s stored on the request’s history.
Only requests currently in PENDING / PENDING_TM can be resolved.

​
Transaction-monitoring decision

For a payment held specifically by transaction monitoring, record the officer decision with POST /customers/{customerId}/accounts/{accountId}/payments/compliance-trigger (claim payments.create) — body { "paymentRequestId" | "transactionId", "action" } where action is APPROVED or REJECTED.