Attach the transaction hash of your USDT send
This is what attributes your deposit to this order. Attaching a different hash to an order that already has one is refused (409), never an overwrite — the first hash may already have been matched, and re-pointing the order would orphan a real deposit. Re-sending the SAME hash is safe and returns 200, so a retry after a lost response is fine.
Authorization
partner-key In: header
Path Parameters
Your order id
Request Body
application/json
TypeScript Definitions
Use the request body type in TypeScript.
Response Body
application/json
application/json
application/json
application/json
curl -X PATCH "https://example.com/v1/orders/string" \ -H "Content-Type: application/json" \ -d '{ "txHash": "5d6a3c7b1e4f2a908c6d5b4a3928170f6e5d4c3b2a1908f7e6d5c4b3a2918070" }'{ "orderId": "3a7c1f90-8b2d-4e56-9a01-cd23ef456789", "status": "awaiting_usdt", "txHash": "5d6a3c7b1e4f2a908c6d5b4a3928170f6e5d4c3b2a1908f7e6d5c4b3a2918070"}Create a sell order (USDT in, KES out) POST
Consumes a sell quote and returns your deposit address. Payout is asynchronous: nothing is paid out until you attach the transaction hash of your USDT send with PATCH /v1/orders/{id} and the order reaches a terminal state. A signed webhook tells you when it settles; polling is the fallback. Retry-safe: creating twice with the same partnerReference returns the original order rather than a second one. Your deposit address is the same for every order, so we cannot tell your orders apart by it — the transaction hash is what attributes a deposit.
Read one of your orders GET
Scoped to your own orders: another partner’s order id returns 404, not 403. The shape follows the order’s side. A BUY order carries the payment instructions, our paymentReference, and — once your payment has been matched — the provider’s own references for it: the M-PESA/PesaLink code your customer recognises, plus the bank’s transaction id. A SELL order carries the deposit address and the transaction hash you attached.