Account and balance

Returns the account behind the key, the scopes the key carries, your lifetime card counts, your float broken down, a summary of your load rate, and the commission you have earned. This is the call to make first when wiring up an integration, and again whenever you need a current spendable balance. Everything it returns is scoped to your own account.

• float.available_usd is the only figure a top-up is checked against. It is the smaller of your balance and any spending limit we have set, floored at zero.
• You cannot recompute available_usd from this payload, because the figure it subtracts is not returned here. Read it, do not derive it. When float.limit_usd is null it equals balance_usd.
• cards.total counts every card you have ever ordered. Closing a card does not return capacity, so your remaining allowance is cards.limit minus cards.total.

Returns the funding address for each network you can fund your balance on, with the tokens it accepts there, refreshed at least every 10 minutes. Only networks whose transaction hashes POST /funding can verify and credit are listed, and only addresses that are currently enabled. Send only a token listed here, from a wallet you have registered with us, to the address listed for the network you send on, and at least 10 USD per transfer.

• Read the addresses before each transfer rather than storing them. They are refreshed at least every 10 minutes, and a network or token that is not listed at that moment cannot be credited through POST /funding.
• Send at least 10 USD per transfer, from a wallet you have registered with us. A smaller transfer is never picked up, so it cannot be credited: POST /funding rejects it with reason below_minimum.
• A 503 returns no address at all: wait and retry, and do not send until it answers. It never falls back to a guessed address, and it also answers 503 when only the BNB Chain and Base addresses cannot be read. The address in the example is illustrative: never send funds to an address copied from this documentation.

Send USDC or USDT to the funding address GET /funding/addresses returns for the network you send on, then submit the transaction hash here. We verify it on-chain immediately, then credit your balance once the funds arrive: the amount sent on-chain, minus the load fee on your agreement. On Polygon this is usually within minutes. On BNB Chain and Base the funds are routed first and we credit only once your transaction is final on its network, so it can take several hours. Before your first transfer, tell us through your contact or the support channel which wallet or wallets you send from. A transfer is credited automatically only when exactly one wallet paid into your funding address in that transaction, that wallet is registered to your account (or, if your account is set to accept any wallet, from any wallet, such as an exchange), and it paid directly: the wallet itself sent the transaction straight to the token contract, or it is a smart wallet, such as a multisig, executing its own transfer. A gasless, bundled (ERC-4337) or relayed transfer goes to review. Anything else goes to review or is rejected. Accepted: USDC and USDT on Polygon, BNB Chain and Base, as GET /funding/addresses lists them, at least 10 USD per transfer, always sent to your funding address and never to a card address. No Idempotency-Key is needed: the call is idempotent on the transaction hash. Each transaction can be credited once.

• A 200 means the hash is recorded, not that it is credited. Read status, then poll GET /funding/{fundingId} or listen for `float.credited`. Tell us which wallets you send from before your first transfer: credit is automatic only when exactly one wallet paid into your funding address, it is registered to your account (or, if your account is set to accept any wallet, from any wallet, such as an exchange), and it paid directly: it sent the transaction straight to the token contract itself or, as a smart wallet such as a multisig, executed its own transfer. When the only wallet that paid is another account's registered wallet, it is rejected with reason unregistered_sender; one from an unregistered wallet, or gasless, bundled (ERC-4337), relayed or routed through another contract (routed_transfer), goes to review.
• No Idempotency-Key is needed: submitting is idempotent on the hash, so retry a timeout or a 5xx with the same hash and network. Named the wrong network? While your submission is unverified (pending with a null amount_usd, or rejected with reason not_found), submit the same hash with the right network: the same submission, same id, is looked up there. The 24 hours run from your first submission, so correct it early. Once the transaction is verified its network is fixed. At most 5 of your submissions can be unverified at once: past that, a new submission answers 429 TOO_MANY_PENDING, with no Retry-After; a correction is still accepted.
• Send only a token GET /funding/addresses lists for the network, only to the address it lists, at least 10 USD per transfer, and never to a card address, then submit as soon as the transaction is broadcast. A hash belongs to the account whose registered wallet alone sent the money (registered before any other account claimed the hash), and its submission replaces another account's unpaid claim; failing that, the first account to submit it on the right network keeps it. A paid claim is never displaced. 503 UNAVAILABLE means another account's claim on the hash could still give way to yours (it is still being looked up, or is verified on your network but not paid) and yours could not be verified yet: retry shortly. Retrying 409 ALREADY_SUBMITTED does not help: check the network and that your sending wallet is registered, then contact us. A transaction that delivered bridged funds into the funding address, on any network, is rejected with reason bridge_fill: if you bridged them yourself, contact us with both hashes.

Returns one submission to POST /funding and where it stands. Poll it until status is credited or rejected, or listen for the float.credited webhook instead. A submission in review is resolved by us and then becomes one of those two. A credited submission that was not your money can later be reversed by us, and then reads rejected with reason reversed_by_operator.

• Once status is credited, credited_usd is what reached your balance and GET /me already reflects it. amount_usd here is always the amount sent on-chain, while float.credited carries the amount credited, which after a review can be lower; fee_usd and credited_usd match the webhook.
• A review status is ours to resolve: the submission verified but could not be credited automatically, and reason says why. It then becomes credited, with a float.credited webhook; credited with reason credited_separately if the funds were credited to your balance by other means (no webhook, null fee_usd and credited_usd, amount_usd still the amount sent); or rejected with reason rejected_by_operator. Do not resubmit it.
• A credited submission that was not your money can later become rejected with reason reversed_by_operator. fee_usd and credited_usd keep their figures, GET /ledger gains a negative funding row referenced funding-reversal-<NETWORK>-<tx_hash> and a positive :fee row, and your balance drops by credited_usd. No webhook is sent.

Returns your 50 most recent submissions to POST /funding, newest first, each with its status. There is no paging.

• Returns your 50 most recent submissions and does not page. Keep the id each POST /funding returns and read older submissions back by id.
• A submission replaced by another account's claim, because that account's registered wallet sent the money or its claim verified on the right network, disappears from this list, and reading it by id answers 404.

Returns your load rates, your own markup, and the card usage rates. Read your rates from here rather than hardcoding them, so a change on our side reaches you without a deploy. GET and PUT return the identical payload shape.

• Rates are fractions, not percentages. A value of 0.02 means 2%.
• The rates under transaction are a published rate card, not the figures any one movement is charged at. What a purchase was actually charged is on its card.authorized event, not on its settlement event. Its row in GET /cards/{id}/transactions shows the card processor's figures rounded to the cent. Reconcile against those, not against this response.

Sets the rate you add on top of the KTAP load fee, as a fraction. The change takes effect on the next deposit quoted, and the response is the full GET /fees payload with the new rate applied. Any key holding users:write can change this rate for the whole account, with no approval step.

• Send markup_pct as a fraction. 0.025 is 2.5%. Sending 2.5 returns 400.
• The accepted range is 0 to 0.5 inclusive, stored to five decimal places. A value with more precision is rounded on write and the response echoes the rounded figure.
• This rate applies to direct card funding only. On a prepaid balance it changes nothing you are billed.