Global Account › API Reference › Remittance Orders

Remittance order details

GET /v1/remittances/{id} scope: remittances:read

On behalf of a member · x-on-behalf-of required

⚠ Responses exclude upstream costs and our margin. They show what this transaction charged you.

Merge forward by status_version, allowing only newer updates. Without this, a slow response can regress “received” to “processing”.

source_amount has the same format as the list endpoint’s locked_amount: a fixed-point string with its decimal point included, such as "500.250000", with precision given by ledger_scale. Before 2026-08-13 this page described the detail amount as an integer string without a decimal point; that described a now-fixed implementation. Following it would introduce a factor of 10^ledger_scale error.

status uses the same mapping as creation and list responses. pending_merchant_funds, meaning your prepaid balance is insufficient and no member funds have moved, maps to pending in all three places. Inspect queue depth through GET /v1/merchant/pending. Other statuses are exposed unchanged; render unrecognized ones as unknown, never default to “processing”.

failure_code uses the same mapping as the list endpoint. It is nonempty only for failures and is a stable public code, not an internal reason. An empty string means either the order did not fail or we have no machine-readable reason for this failure. For the latter, show failure with an unknown reason and direct users to your support. Do not interpret an empty string as success.

⚠ supplement is easily overlooked on this screen. A non-null value means the order awaits documents, requested during our review or through an upstream RFI. To the member, such orders otherwise look like locked funds with nothing happening. submit_url is our hosted supplementary-document page and can be given directly to the end user; it is the same URL linked in our email to them.

⚠ submit_url is itself a credential containing a single-use token in the path. Do not log it, include it in support tickets, or expose it to third parties. It has no expiration time: validity depends on the document-request and order states. After submission, replacement by another round, or order completion, the page explains the situation itself. Do not display a countdown or cache and reuse the URL across rounds.

supplement fields:

round: the round number. An order can have multiple rounds, each an independent set of requirements.
status: PENDING awaits user submission; SUBMITTED awaits our or the upstream’s decision. These require different user interfaces; do not collapse them into a boolean.
source: upstream is an upstream RFI, with funds already at the partner bank and the order irreversible; admin originates during our review, while funds remain in the member’s locked bucket. Explain these situations differently to users.
items[].submitted: whether this item was submitted. Multiple requirements can be uploaded in separate visits. Without this flag you would ask users to re-upload completed items, overwriting their earlier files.
items[].label: already localized. Specify Accept-Language to choose a language; otherwise the member account’s preferred language is used, matching their email.
items[].type: the required form of submission. Currently only file exists; the upstream also supports attachments only, without text answers. This field gives your switch a discriminator for future additions. Without it, a new text requirement could silently leave your UI showing only an upload control. Expose unrecognized values as received.
submitted_at: an empty string means not yet submitted.

Path Parameters

Field	Type	Required	Description
`id`	string	Required	Order ID. The `rmt_` prefix is optional and is stripped by us.

Field	Type	Required	Description
`x-on-behalf-of`	string	Required	Member on whose behalf the call is made. Accepts your `external_member_id` or our public `mem_<uuid>`.

Response

200OK

{
  "id": "rmt_9c1f0a7e-3b2d-4f81-9a55-1d2e3f4a5b6c",
  "status": "pending_docs",
  "source_asset": "USDT",
  "source_amount": "500.250000",
  "ledger_scale": 6,
  "payout_currency": "GBP",
  "payout_amount": "380.00",
  "status_version": 3,
  "failure_code": "",
  "supplement": {
    "round": 1,
    "status": "PENDING",
    "source": "upstream",
    "message": "Please provide proof of the source of funds.",
    "items": [
      {
        "field_key": "proof_of_funds",
        "label": "资金来源证明",
        "type": "file",
        "required": true,
        "submitted": false
      }
    ],
    "submit_url": "https://api.zinfra.vip/remit/supplement/6f1c2b9d4a8e47f0b3d5c1a2e9f80b7c",
    "created_at": "2026-08-12T10:05:00Z",
    "submitted_at": ""
  },
  "created_at": "2026-08-12T09:30:00Z"
}

404not_found: the order does not belong to this member or does not exist. Both use the same response, avoiding an order-ID discovery oracle.

Request

curl -X GET 'https://api.zinfra.vip/v1/remittances/{id}' \
  -H 'x-auth-token: Bearer $TOKEN' \
  -H 'x-on-behalf-of: $MEMBER_ID'

const res = await fetch("https://api.zinfra.vip/v1/remittances/{id}", {
  method: "GET",
  headers: {
    "x-auth-token": "Bearer $TOKEN",
    "x-on-behalf-of": "$MEMBER_ID",
  },
});
// Keep monetary amounts as strings, never numbers.
const data = await res.json();

import requests

res = requests.get(
    "https://api.zinfra.vip/v1/remittances/{id}",
    headers={
        "x-auth-token": "Bearer $TOKEN",
        "x-on-behalf-of": "$MEMBER_ID",
    },
)
# Use Decimal(str(...)) for amounts, not float.
data = res.json()

req, _ := http.NewRequest("GET", "https://api.zinfra.vip/v1/remittances/{id}",
    nil)
req.Header.Set("x-auth-token", "Bearer $TOKEN")
req.Header.Set("x-on-behalf-of", "$MEMBER_ID")
res, err := http.DefaultClient.Do(req)
// Decode amount fields as string, not float64.

HttpRequest req = HttpRequest.newBuilder()
    .uri(URI.create("https://api.zinfra.vip/v1/remittances/{id}"))
    .header("x-auth-token", "Bearer $TOKEN")
    .header("x-on-behalf-of", "$MEMBER_ID")
    .method("GET", HttpRequest.BodyPublishers.noBody())
    .build();
// Use String / BigDecimal for amounts, not double.

$ch = curl_init('https://api.zinfra.vip/v1/remittances/{id}');
curl_setopt_array($ch, [
  CURLOPT_CUSTOMREQUEST => 'GET',
  CURLOPT_RETURNTRANSFER => true,
  CURLOPT_HTTPHEADER => [
    'x-auth-token: Bearer $TOKEN',
    'x-on-behalf-of: $MEMBER_ID',
  ],
]);
$res = curl_exec($ch);
// Use bcmath / strings for amounts, not floatval.

200

{
  "id": "rmt_9c1f0a7e-3b2d-4f81-9a55-1d2e3f4a5b6c",
  "status": "pending_docs",
  "source_asset": "USDT",
  "source_amount": "500.250000",
  "ledger_scale": 6,
  "payout_currency": "GBP",
  "payout_amount": "380.00",
  "status_version": 3,
  "failure_code": "",
  "supplement": {
    "round": 1,
    "status": "PENDING",
    "source": "upstream",
    "message": "Please provide proof of the source of funds.",
    "items": [
      {
        "field_key": "proof_of_funds",
        "label": "资金来源证明",
        "type": "file",
        "required": true,
        "submitted": false
      }
    ],
    "submit_url": "https://api.zinfra.vip/remit/supplement/6f1c2b9d4a8e47f0b3d5c1a2e9f80b7c",
    "created_at": "2026-08-12T10:05:00Z",
    "submitted_at": ""
  },
  "created_at": "2026-08-12T09:30:00Z"
}

Remittance order details

Path Parameters

Request Headers

Response