Rootline

List individual payments, newest first, with server-side filters. SPLIT PAYMENTS: upstream, every split is its own payment, so a split checkout produces a root row PLUS one row per split — same amount, same timestamp, ids differing only near the end. By default those split sub-payment rows are hidden (one row per customer transaction) and the result says how many were hidden. Pass `include_splits=True` for the full ledger; split rows are then marked and excluded from the summed total. Counts and sums over the default view are per customer transaction — never double-counted. SPLIT ROWS ONLY: scope `account_ids` to an account that RECEIVES splits — a marketplace seller, or a funds-holding entity such as a Dutch `stichting derdengelden` — and a page can hold only split rows, because each root sits on the paying account, outside this scope. Those rows are kept and the result says `split_rows_only`: report them as split amounts routed in from checkouts taken elsewhere, totalled apart in `split_total_lines`. One page's shape does not prove what kind of account this is; say what the page shows. The paying account is not on the rows. Pagination is **page-based, not cursor-based** (unlike `list_reports`): pass `page=0` for the first page, `page=1` for the second, etc. Page size is fixed at 50 rows, and paging stops at page 19 (1000 rows): a question that needs more rows than that is answered by narrowing the filters or by `get_account_activity`, not by walking on. All filters are AND-combined. List filters (account_ids, checkout_statuses, payment_methods) are OR within themselves. Enum filter values are CASE-SENSITIVE and lowercase, and they differ from the display forms shown in results: - `checkout_statuses`: use the lowercase status as returned in `checkout_status` — e.g. "succeeded", "failed", "open". Uppercase ("SUCCESS") is rejected. - `payment_methods`: use the lowercase method code — e.g. "ideal", "visa", "mastercard". The display-case the rows show ("Ideal") is NOT a valid filter value — it silently matches zero rows. There is no currency filter (the upstream filter is broken today) — narrow by date/status/method and read the currency off the rows. `start_date`/`end_date` accept an ISO date (`YYYY-MM-DD`, whole day) or an ISO datetime (`YYYY-MM-DDTHH:MM:SS`, UTC if no offset) for sub-day windows such as the last hour. CLOCK TRAP: these bounds are **UTC**, but every time this server *displays* is local wall-clock in the deployment's display zone (CET/CEST by default) — two hours apart from UTC in summer. Reusing a displayed time as a bound returns an empty window with no error to notice. Build sub-day filters from a row's `created_at_utc`, or convert explicitly and say you did. `min_amount`/`max_amount` are in WHOLE currency units (euros), NOT minor units/cents: passing eurocents over-filters by 100×. Both bounds are STRICT: min_amount=100 returns payments ABOVE €100.00, so an exact €100.00 is excluded (max_amount=1 likewise excludes an exact €1.00). At whole-euro granularity "€100 or more" has no exact form: use 99 and say the result starts at €99.01. `query` is a free-text search across reference + customer fields. Use this for individual rows or a specific payment — 'show me payments for account X last week', 'top recent payments', 'declined payments for method Y', or 'payments in the last hour' (pass start/end one hour apart). For a single known `pmt_…` ID, use `get_payment` instead — it returns the full detail tree (authorizations, captures, refunds, …). For a how-much / summary total over a window, use `get_account_activity`, which walks and aggregates internally. "Biggest / largest payment": there is NO server-side sort by amount, so this takes reasoning over rows, never a search loop. Pull the window ONCE and compare the amounts in the returned rows. Only when that window overflows a page (`has_next`) narrow it, with a tighter date range first or a `min_amount` floor, and stop after one or two narrowings rather than ratcheting upward call after call. Do not claim a maximum you didn't actually see in rows you received. ACCURACY TRAP: filtering `checkout_statuses=["succeeded"]` excludes failed and abandoned attempts, and the largest attempt is often a decline — so a "biggest payment" answer scoped to succeeded can silently miss it. Leave the status filter off (or say you scoped to succeeded) when the question is about the largest attempt, not the largest *successful* payment. Returns: - `payment_summaries[]` — each row has `payment_id`, `created_at` (the upstream value, whose shape isn't guaranteed), `created_at_utc` (the same moment as an unambiguous ISO-8601 UTC instant — **this is the one to build a filter from**), `created_at_display` (local wall-clock with its zone label, for reading aloud — never for filtering), `account_id`, `amount` (with currency + value), `payment_method`, `checkout_status`, `reference`, `is_split` (true only on a split part routed to this account; the list cannot say whether a payment has splits, `get_payment` can; the older `is_split_root` is still sent for one release and is true on every top-level payment). On a platform the account is the platform's on every row, so `reference` (the merchant's own order id) is the only per-row clue to which seller or venue a payment belongs to. - `hidden_split_count` — split sub-payment rows hidden from this page (0 when `include_splits=True`, and 0 on a split-rows-only page). - `split_rows_only` — true when every row on this page is a split row (see SPLIT ROWS ONLY above). - `total_lines` — root amounts summed per currency; `split_total_lines` — split-row amounts summed per currency. Never combined. - `total_display` — present ONLY when every root row shares one currency. Across several currencies there is no single total and the field is empty by design: quote the per-currency `total_lines` instead, and never add currencies together or headline one of them as the total. - `unpriced_row_count` — rows with no readable amount or currency. They are left out of every total and are not zero; say so when it is non-zero. - `total_count` — rows on THIS page after the filters. The backend gives no filter-aware total; `has_next` (not the count) says whether more pages exist — pass page+1 to fetch them. - `page_limit_reached` — true on the last page this tool serves. `has_next` may still be true, but the rows beyond are only reachable by narrowing the filters.

list_payments

List financial reports, one cursor-paginated page sorted newest first. Filter by `report_type` (e.g. `settlement_report`), `account_id`, and `since`/`until` dates on the report's period ("which report covers 5 August", "reports from July"). `page_size` is 1-100 (values above 100 are rejected). Each row says what its period means (`period_meaning`) and when it was generated. Returns `{rows: [...], next_cursor, has_next, total_in_scope}`. Each row has: `id_raw` (report_xxx), `kind_label`, `account_name`, `window_label`, `status`, `filename`, `version`, and `dashboard_url`. `has_next` is true when a further page exists; `total_in_scope` is the total number of reports matching the filter (across all pages). To walk further pages, pass the returned `next_cursor` back exactly as returned as the `after` parameter — never construct, modify, or reuse a cursor across different filters.

list_reports

Fetch a single Rootline account by its `acc_…` ID — its configuration AND its current balance in one answer. Call after `find_accounts` returns an `acc_…` id — never guess an id or ask the operator for one. Returns the account's display name, description, namespace, the company id of its main contracting entity (`company_id_raw`; its name and legal detail come from `get_company`), and the live available/pending balance per currency. It does NOT return processing options, enabled payment methods or permitted processing currencies: say those are not available here rather than inferring them from past payments or the balance. Accounts are flat: any `parent_id` references the owning organisation, not another account, so there is no account hierarchy to surface. Use this to answer 'what is account acc_…?' / 'show me account X' — it gives the full picture (config + balance) so the operator rarely needs a follow-up.

get_account

Fetch a single Rootline company by its `co_…` ID. Chain from `find_companies` (or an id another record carries) — don't guess ids. Returns the company's legal/trade name, verification status + pending next action, and the nested address (with country). (Registration and VAT numbers are not on this record.) Companies are the legal-entity layer above accounts: an account belongs to a company. This record is the LEGAL entity, not the money-holding account — balances, payment activity, and terminals live on the account tools (`get_account` / `get_account_overview`), never here. Use this to answer 'who legally owns account X', 'show me company co_…', or 'what's this merchant's onboarding status'. `accounts` lists the company's accounts this login can see (up to ten, with `account_count`): the way from a company to its money-holding accounts, to chain into the account tools. One company can hold several accounts, and an account's name need not match its company's.

get_company

Look up a single Rootline payment by its `pmt_…` ID. Returns live data, so it works for today's payments too — before they settle. Returns one curated record: - identity: `id_raw`, `amount_display` + `currency_symbol`, `checkout_status`, `reference`, `merchant_name`, `account_id_raw`, `payment_method_display`, `dashboard_url`, `details[]`. - outcome: `failure` ({response_code, response_message, ...} — the decline reason when an auth fails) or `success` (headline + stats); `gateway_summary` is the one-line gateway verdict either way. - `timeline[]` — created/authorized/captured/refund events in order. - `splits[]` (destination account, amount, fees), `refunds[]`, `authentication` (3DS / SCA outcome when present). - refundability: `can_refund`, `can_partial_refund`, `refundable_display`. Use this to answer 'what happened to payment <id>'. For declines, cite `failure.response_code` + `failure.response_message`; if those are blank fall back to `gateway_summary`. Card instrument details (brand, last-4, funding, issuing country, 3DS result) are returned when available. The bank identification number (BIN) is excluded. Customer identity (name, email, phone, address) is omitted by default; set `include_contact_details=True` ONLY when the operator explicitly asks about the customer (for example 'who paid this?' or 'what is their email?'), and it REQUIRES `contact_details_reason`: why they need it, in their words. The disclosure is recorded against the operator who asked, so the reason must be theirs. If they have not said why, ask them rather than supplying one. RISK — `risk` carries the screening decision, whether it ran before or after authorization, the score against the block threshold, and the features that moved it. What surfaces depends on the decision: - BLOCKED (or blocked by rule): the full explanation, without being asked. A blocked payment has no issuer response to cite, because screening stopped it before the bank ever saw it, so `failure` is empty and this is the only account of what happened. - CHALLENGED: the decision only. The payment went through after a 3-D Secure step-up, so there is no unexplained outcome to justify. - ALLOWED / TRUSTED: nothing. Set `include_risk=True` for the full explanation on ANY decision — use it when the operator asks about risk, screening or 3-D Secure directly. `risk` absent does NOT mean the payment was clean, and it is the COMMON case: risk screening is a separate product, so most merchants have no assessments at all. It is also what you see when the login may not read risk data. Those causes are indistinguishable from here, so when `risk` is absent, do not mention risk at all — not "no risk found", and not "not available to this login" either, which points at a product the merchant may never have bought. Risk is READ-ONLY. There is no way to unblock, allow, whitelist or change a rule from here — never imply otherwise; that is a dashboard action.

get_payment

Fetch a single payment device (terminal) by its `device_…` ID — or by the serial number printed on the physical unit. Operators read the serial off the terminal, not the internal id, so pass whichever they gave you: a `device_…` id is looked up directly, and anything else is treated as a serial and resolved to the terminal automatically. Never ask the operator to convert a serial into a `device_…` id themselves. Returns the terminal's serial number, model, the accounts assigned to it (TIDs are not available here), and `fleet`: `online` (a heartbeat in the last 5 minutes), `last_seen` (when it last went online or offline, so for an online terminal the start of that streak, not its latest beat) and `last_payment_at`. Software, app versions and configuration sync are not available here. A terminal that has not reported yet has `online` null: say its connection is unknown, never that it is offline. The `state` pill is ASSIGNMENT status (assigned vs unassigned), not connectivity. Use to answer 'which terminal is device_…?', 'is terminal <serial> assigned, and to which account?', 'what account does it bill to?', or to enrich a `payment.payment_device_id` reference.

get_payment_device

Assign a payment device (terminal) to an account. **Two-call confirm contract, enforced server-side.** This is a mutating tool, so it dry-runs first: the FIRST call changes nothing and returns a plan — the action, the environment it would run against, and the device + account it touches — for the operator to confirm. The plan also returns a `confirmation_code`. The write happens only on a second call carrying BOTH `confirm=True` and that code, so `confirm=True` on a first call cannot write: it just returns the plan. Ask the operator, then echo the code back. The plan names the environment the terminal was actually found in, which is where the write will land — pass that `environment` back on the confirming call to pin it explicitly. After assignment, transactions taken on the device bill to `account_id`. The backend checks assignment eligibility and permissions when the confirmed write runs. `device_id` must be `device_…`; `account_id` must be `acc_…`. The terminal's current state is checked before the write. If the desired state already exists, return success with changed=false and issue no write. An uncertain write response causes one state read in the same environment. A matching state is an observation; otherwise the outcome is unknown. Never repeat an uncertain write automatically.

assign_payment_device

Unassign a payment device (terminal) from an account. **Two-call confirm contract, enforced server-side.** This is a mutating tool, so it dry-runs first: the FIRST call changes nothing and returns a plan — the action, the environment it would run against, and the device + account it touches — for the operator to confirm. The plan also returns a `confirmation_code`. The write happens only on a second call carrying BOTH `confirm=True` and that code, so `confirm=True` on a first call cannot write: it just returns the plan. Ask the operator, then echo the code back. The plan names the environment the terminal was actually found in, which is where the write will land — pass that `environment` back on the confirming call to pin it explicitly. After unassignment, the device no longer bills to that account (it may still be assigned to others — see `get_payment_device(...)`). `device_id` must be `device_…`; `account_id` must be `acc_…`. The terminal's current state is checked before the write. If the desired state already exists, return success with changed=false and issue no write. An uncertain write response causes one state read in the same environment. A matching state is an observation; otherwise the outcome is unknown. Never repeat an uncertain write automatically.

unassign_payment_device

Answer a conceptual / how-to / integration question from Rootline's PUBLIC documentation, grounded in real doc content with canonical links. USE THIS TOOL for knowledge questions — how a feature works, what a term or field means, how to integrate, setup/onboarding concepts, error-code meanings. These are questions about Rootline itself, not about any specific account, payment, company, device, or report. DO NOT use it to look up records or tenant data (a merchant's payments, an account balance, a device's status, a report's rows) — those go to the data tools (get_account, list_payments, get_payment_device, …). If a question mixes both ("how do payouts work, and when is MerchantX's next one?"), answer the concept from here and the specific fact from the data tool. Grounds every answer in retrieved doc excerpts and returns the canonical documentation links — never invents fields, endpoints, or behaviour. Cite only the links this tool returned, verbatim; do not relabel them or append a plausible-looking URL or #anchor of your own. If the docs don't cover it, say so plainly rather than guessing.

search_rootline_documentation