Skip to main content

​
📄 Guide

The funding side has one principle: fund first, spend second. This page walks “deposit → transfer → balances → reconciliation”; the funding-owner concept is in Holders and the funding model.

​
Deposits

① Get the receiving account: GET /open-api-corp/fund/v1/deposit-info?subjectType=...&subjectId=...&currency=... — returns the owner’s (COMPANY pool / CARD dedicated balance) receiving VA for that currency: payeeAccountNumber, payeeBankCode / payeeBankName, payeeAccountName, payeeSwiftCode (required for cross-border wires), bank and recipient addresses, and remark (the required transfer reference). ② The customer wires the funds to the VA using those details. ③ Arrival notification: the webhook BANK_TRANSFER_INFO (success / failure distinguished by status, carrying depositId / amount / currency / sender details).

​
Pool ⇄ card transfers

POST /open-api-corp/fund/v1/transfer — internal transfers between the company pool and dedicated-balance cards, same currency, no FX, closed loop within one company: COMPANY→CARD funds a card (allocates budget), CARD→COMPANY sweeps balance back. The response status is SUCCESS / PROCESSING / FAILED; on PROCESSING you must poll GET /fund/v1/transfer-query?transferRef=... for the final result. SHARED cards hold no balance and cannot be a transfer endpoint (CARD_NOT_DEDICATED); an underfunded sender returns INSUFFICIENT_FUNDS.

​
Balances

GET /open-api-corp/fund/v1/balance?subjectType=...&subjectId=... — per-currency balances for a funding owner, each returning availableAmount (the current available balance).

​
Reconciliation on three levels

Key transaction fields: transactionCategory (PURCHASE / REFUND / FEE / REPAYMENT / CASH_ADVANCE / DEPOSIT / TRANSFER), postStatus (POSTED / UNPOSTED authorization hold / null for repayment-type rows), the original and posted amount/currency pairs (originalAmount/originalCurrency, postAmount/postCurrency), postTime (null while on hold) and merchant (merchantName / mcc / merchantCountryCode). Statement list: POST /statement/v1/statements — by company (type=SHARED) or by card (type=DEDICATED, cardId required) over a time range, cycles in reverse order. Each statement returns statementId (null for the open statement), statementPeriod, status (OPEN / SETTLED), statementDate / paymentDueDate, paymentStatus (CURRENT / AWAITING_PAYMENT / PAID / OVERDUE, computed live) and a per-currency summary (purchases / refunds / fees / repayments / cash advances / amount due / overpaymentAmount totals). Statement detail: POST /statement/v1/statement-detail — the header + per-currency summary + transaction lines (pagination applies to the lines only). For a settled statement pass statementId; for the current open statement pass statementId=null + status=OPEN.
The settled statement is final: the open statement is a live summary of the current cycle including unsettled authorization holds, so its totals fall back as transactions clear — expected behavior. The billing mechanics and key dates are in Limits and statements.
BANK_TRANSFER_INFO (VA deposit arrival) / the balance-change notification / LOW_BALANCE (pool low-balance alert; configuration in Managing companies).

​
Next steps