Before this page
- Your firm’s API credentials work against the gRPC target for your environment, and you can mint an access token holding the
write:cash-movementsgrant — see Authentication. - You know which of your two firms is which — see Firms, participants and accounts.
- At least one participant has reached
kyc.approved, and you recorded itsparticipantIdand itsprovisionedAccount— see KYC flow.
API reference: Funding. Opens on the public documentation site in a new tab.
Where it disagrees with this page, this page is authoritative for the partner surface.
The funding model
- ISV
- Introducing broker
The model
Cash is pre-positioned so that a user who just deposited in your app is not paced by a bank rail: you fund your pool in advance, and each order is funded from it by a transfer into the user’s participant account.The three parties
You do not hold customer funds, and an omnibus account at our DCO is not available to ISVs. Every end-user dollar sits either in your pool or in that user’s participant clearing account, never in an account of yours that mixes users.Cash movement is firm-scoped: you name only the participant account and we resolve your funding account from the relationship established at KYC. Do not send
x-participant-id on these calls. The mechanics are under Move cash.Your funding entity must exist first
Your Wallet Co funding entity must exist and be active before your firm’s API credentials are enabled. There is no order of operations in which you integrate against a live credential and add the funding entity afterwards.Removed 2026-08-06
Rails you cannot use
CheckoutAPI and Aeropay are not entitled for ISVs. Both return 403 method not permitted. Do not build a deposit UX against either; the 403 is the entitlement, not a misconfiguration on your side.Rails you can use
Production deposits into your pool are wire only, as of August 2026. There is no card, ACH or wallet rail on the ISV funding path.Pre-production pools are funded manually by us on a Slack request. There is no self-service test funding, so plan a preprod pool top-up as a human step with a lead time, not as a scripted fixture.Move cash
If you are an IB, this differs.
For an ISV the pool is a working-capital question. For you it is the whole of the permitted
structure, because you may not accept or hold customer funds at any point — see
Funds handling. Wallet Co segregation is a prerequisite and is unspecified in
writing, so get it confirmed. The sub-cent residue below is a reporting problem for you,
not only a reconciliation annoyance — see Reporting pack.
CashMovementService, and read the outcome off the returned status.
The service
CashMovementService has three RPCs. CreateCashMovement is the one that moves cash.
CashMovementService is firm-scoped. Do not send x-participant-id on any call to it. That header is required on account-scoped reads such as positions and reports, and sending it here is wrong rather than harmless.
Direction is fixed by the reason
You do not name a source and a destination. You name the reason, and the reason fixes the direction. You name only the participant account; we resolve your funding account from the relationship established server-side at KYC.
Three transfers you may be planning are structurally impossible, not merely unsupported: a transfer to your own firm, a transfer between two participants, and a transfer to any external destination. There is no field on the request that could express them, so do not design a product flow that needs one.
Create a transfer
There is no REST path for
CashMovementService. Every call in this section is gRPC against
grpc-api.{env}.polymarketexchange.com:443. The command-line tab below is grpcurl with a local
proto file rather than curl, and it passes -proto because gRPC server reflection is
entitlement-gated and returns PermissionDenied: method not permitted without the grant.The four statuses
Idempotency
The dedupe key isidempotency_key. What is established is the terminal-rejection case: a terminally-rejected key replays its stored rejection instead of making a fresh attempt.
Two decimal places
amount accepts at most 2 decimal places. Balances carry more, and have been observed at 172.395 and 1377.57275. Never round a balance up to construct an amount; the consequences and the interim practice are under Sub-cent balances.
Rate limit
Sub-cent balances
Balances carry more decimal places than transfers accept, so there is a residue you cannot move. Before you act on this section, know which balance figure you are reading — see Which number is spendable.The numbers
- Balances carry more than two decimal places. Observed values:
172.395and1377.57275. amounton a transfer accepts at most two decimal places.
The consequence
Your balance sheet cannot reach zero today. A participant account holding172.395 can be drained to 172.39 by one WITHDRAWAL and no further. The residue is real cash in a real account that no call on the partner surface can move, and there is no sanctioned handling for it.
Interim practice
Do these three things until the sanctioned answer exists.1
Track the residue in your own ledger
Carry the full-precision balance and the two-decimal transferable amount as separate columns per
account. The difference is the residue. Parse money as a decimal type, never as a float you then
round —
int64 fields are serialized as strings in JSON for the same reason.2
Never round up into a transfer
Truncate toward zero when you derive
amount from a balance. Rounding 172.395 up to 172.40
asks for cash that is not there, and the failure lands on a money path rather than in your tests.3
Reconcile the difference as a known standing balance
Close your daily reconciliation with the residue as an expected, named line rather than as a
break. A per-account residue under one cent that does not change between runs is the correct
state today, not a defect to chase.