SEseismic
Orders

Submit a supporting document

File the supporting document a payment is waiting for: an order reading status: under_review with status_reason documents_required, or documents_rejected after a submitted document was turned down. The order moves to documents_under_review as the document is filed, so a retried or concurrent call answers 409 rather than filing twice; it reads processing with documents_approved once the payment continues. Each change after the filing fires order.status_changed.

post/v0/customers/orders/{id}/documents

Request

  • Base URL
    https://orchestration.seismic.systems/api
  • Auth
    API key in header Api-Key

Path parameters

idstring uuid required

Order id.

Query parameters

funding_instructionsFundingInstructionsVersion (unresolved $ref)

v2 returns funding_instructions in one shape for every rail and order: type, currency, amount and rail, plus a fiat or crypto object. Without it, the details as received, whose keys vary; that shape will be retired.

Request body

filestring required

The document as a base64 data URI: data:<mime>;base64,<contents>. PDF / JPEG / PNG, at most 5 MB.

type'invoice' | 'purchase_order' | 'delivery_slip' | 'contract' | 'customs_declaration' | 'bill_of_lading' | 'other' required

What a supporting document filed with a payment is: the transaction document set, distinct from the identity documents a verification profile carries. Compliance review reads a payment's document as this type, so a held payment clears faster when it matches the document.

Response

The order, now documents_under_review.

commentstring nullable
created_atstring date-time required
idstring uuid required
idempotency_keystring required
payment_reason'charitable_contributions' | 'education_fees' | 'employee_salaries_or_wages' | 'gifts' | 'investments' | 'dividend' | 'purchase_of_goods' | 'purchase_of_services' | 'personal_transfers' | 'rent' | 'loans' | 'utility_bills' | 'family_support' | 'friends_support' | 'real_estate' | 'insurance' | 'intercompany_transfer' | 'taxes' | 'travel'

Why a payment is being made. Banks key compliance decisions off this, so downstream settlement networks require one of these fixed categories on every payment. Partner-facing: supplied on the accept request, persisted on the order, and mapped to the settlement network's enum at dispatch.

Distinct from [SourceOfFunds] — that answers where the money came from; this answers why it's being sent. The two are carried as separate fields end to end.

referencestring nullable
status'awaiting_funds' | 'pending' | 'under_review' | 'processing' | 'sent' | 'completed' | 'expired' | 'failed' | 'canceled' | 'refunded' | 'unknown' required
status_reasonstring nullable

Why the payment is in its current status. A payment that ended in a terminal failure — a refunded or failed order — carries the settlement network's reason code (e.g. COMPLIANCE_BLOCKED, INVALID_EXTERNAL_ACCOUNT_DETAILS). A processing order held for a supporting document reads documents_required or documents_rejected (submit one with POST /customers/orders/{id}/documents), then documents_under_review, then documents_approved once it continues. Omitted for healthy orders and when no reason was reported.

transaction_hashstring nullable

On-chain settlement hash for the order's crypto leg, present once the order settles over a blockchain rail and Seismic has observed the settlement. Absent for fiat-only orders.

uetrstring nullable

SWIFT Unique End-to-end Transaction Reference (UETR) of the order's fiat leg, present once the settlement network reports it for a wire payout. Give it to the beneficiary's bank to trace the payment. Absent for other rails and until the network reports it.

Changes

No recorded changes to this operation across all 1 revision of this API.