scope is how you separate your money from your customers’. Partner returns your own
transactions, Customer returns your customers’, and All returns both — which is rarely what
you want on a reconciliation run.Narrowing to one customer
PasspartnerCustomerGuid to get a single customer’s transactions.
This replaces the separate per-customer transaction endpoints that used to exist. Everything is
now a filter on
/v1/transactions, so one code path and one response shape covers every case.The parameter keeps its wire name, partnerCustomerGuid — send it exactly as spelled here.Filters
All parameters are optional and combine with AND.
The response is paginated:
The four ways a transaction is classified
These are independent axes, not a hierarchy. A single transaction has a value for each.
Use
scope to filter; partyType is the value you read back on each item.
transactionType is the precise label, and is the one to switch on in code:
List items are trimmed
The list returns enough to render a table. Fetching one transaction returns considerably more — including the fields you need to investigate a failure. Look it up by itsreference.
reference is the transaction’s id. It is the value the dashboard shows as the ID, the
string that travels on the payment, and what your customer quotes on a bank transfer — so it is
the one you already have. Every row of the list response carries it.Reconciling a deposit
1
Filter to what settled
?scope=Customer&category=Deposit&status=Completed&from=2026-09-01&to=2026-09-302
Match on reference or counterparty
If you provisioned the customer a virtual IBAN, the transaction is already attributed. If you
are sharing one IBAN across customers, match on
reference — see Customers.3
Investigate anything Pending
Fetch it by
id and read the timeline. The last entry tells you which step it is sitting on.Prefer webhooks to polling. Subscribe to transaction status events and you will be told when
something reaches a terminal state — see Receiving webhooks.