Payments & Operations

The Payments group gives operations teams visibility into activity across your merchants: Payments → Transactions (all payments), plus Merchants, Recurring, Settlements and Disputes.

Finding a transaction

Partner Portal → Payments → Transactions. Filters mirror the API's (GET /api/v1/transactions):

• Merchant
• State and type
• Rail (card / ACH)
• Date range (from / to)
• Amount range
• Free-text search — matches the gateway transaction id as a substring, or an exact transaction UUID

There is no search by customer email or card last-four on the list — open a merchant's stored credentials for instrument-level views.

Transaction detail

A transaction's page shows its state timeline, amounts (base / surcharge / convenience fee), the idempotency key, masked instrument details, and its follow-up operations (captures, refunds, reversals).

Issuing a refund

From the transaction detail, on a settled parent:

1. Click Refund
2. Enter the amount (or leave it for a full refund of the remainder)
3. Select a refund reason — it is required, structured (customer_requested, overpayment, …; other_with_note takes a note)
4. Confirm

Portal refunds create the same REFUND / PARTIAL_REFUND transactions as the API and fire the same webhooks (transaction.refund_issued, transaction.refunded). Pre-settlement there is no refund — cancel instead (below).

Cancelling before settlement

For an uncaptured AUTHORIZED payment, the detail page offers Reverse authorization (AUTH_REVERSAL) — the rails-level release of the issuer hold, the right call for customer-facing cancellations. A VOID (ledger-only cancel) is also valid pre-settlement via the API; the hold then lingers until the issuer expires it on its own schedule — there is no fixed release window to promise a customer. See Auth Reversal vs. Void →.

Exporting payment data

Payments → Transactions → Export streams your filtered transactions as CSV — the same synchronous export as GET /api/v1/transactions/export, with the same filters and row-cap headers.