marketplace

POST /v1/marketplace/vendor/payout-methods

Propose a destination to be paid at.

Dhammaan marketplace bixiyayaasha

Xaqiijinta aqoonsiga

U dir fure API ahaan calaamad muujisa (bearer token). Barta dhammaadka ee kani ma caysino luqad ahaan oggolaansho gaar ah oo ku dhex jirta qeexidda, markaa sii furahaaga inta ugu yar ee uu u baahan yahay oo fiiri jawaabta halka aad wax ka qaadan lahayd.

Boggan ma qaato aqoonsiga ururka. Furahaagu wuxuu horay u aqoonsanayaa ururka uu ka tirsan yahay, jawaabtuna waxay ku kooban tahay halkaas.

Isku day

Ku beddel wax kasta oo ku dhex jira qeebaha xaglaha ah qiimayaashaada, sidoo kalena haystaaha furaha ku beddel fure ka dhex muuqda dashboordigaaga.

curl -X POST https://api.zinndigital.com/v1/marketplace/vendor/payout-methods \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "rail": <string> }'

Ma sign-garaysay? Qalabka API ee ku jira dashboard-kaagu wuxuu buuxiyaa aqoonsigaaga ururka ee dhabta ah iyo furahaaga gaarka ah, wuxuuna ku shaqeysiiyaa codsiga API-ga nool si aad u aragto jawaabta dhabta ah. Kani ka fur barta kontoroolka ee API

Details

docs/82 §7c. The row is created **unverified** and can receive nothing: only staff verification makes it payable, and then only after the 48-hour cooling-off. ⛔⛔ **A change of destination is a new row, never an edit** — there is deliberately no endpoint that changes `destination` on an existing one. §7c: *"Change of payout details is the account-takeover cash-out route, and must be treated as one."* Editing a verified row would keep its verified state and its long-expired hold while pointing the money somewhere nobody looked at. ⭐ Re-adding a destination the seller already has returns the existing row rather than minting a second one — otherwise "change it and change it back" resets the cooling-off clock in two requests. ⛔ The **network** is its own field, not part of the address. Sending USDT TRC20 to a BEP20 address loses the money irrecoverably, so the same address on two networks is two destinations, each earning its own proof and its own hold.

Codsiga jidhkiisa

MagacaNoocLoo baahan yahayMaxay tahay
railstringHaa
destinationstringMayaEmpty for account credit, which has nowhere to send.
networkstringMaya
labelstringMaya

Jawaab

MagacaNoocLoo baahan yahayMaxay tahay
idstringHaa
railstringHaa
rail_namestringHaa
destinationstringHaa⛔ **Masked, always.** Enough to recognise which account this is, never enough to reproduce it. The whole value never leaves the engine on a read path.
networkstringHaa⛔ Its own field, never folded into the address. Sending USDT TRC20 to a BEP20 address loses the money irrecoverably (docs/82 §7b), so the network is part of the destination's id…
labelstringHaa
stateMarketplacePayoutMethodStateHaaWhere one destination is in its own verification (docs/82 §7c). `retired` rows are kept rather than deleted — a payout that went there is explained by them.
proof_kindMarketplacePayoutProofKindHaaHow ownership of the destination was shown. ⛔ Crypto is the honest exception and is recorded as one: docs/82 §7c states that *no document can prove wallet ownership*, so a signe…
rejection_reasonstringMaya
is_defaultbooleanHaa
verified_atstringMaya
hold_untilstringMayadocs/82 §7c's 48-hour cooling-off on the **first** payout to this destination — long enough for the change notice to land, short enough that a seller who genuinely changed bank…
permitted_proof_kindsMarketplacePayoutProofKind[]Haa

Cilladaha ay bartaani soo celin karto

401 · 404 · 422