Payment object

A Payment represents a monetary transaction detected by Orbi and associated with an Order. Payments are immutable records used for reconciliation, accounting, and audit purposes.

An order may have one or multiple payments depending on the payment rail and order capabilities (for example partial payments or retries).


Amounts are decimal strings

All monetary values in Payments are represented as decimal strings. Floating-point numbers must not be used.

{
  "paid_amount": "100.00",
  "fee_amount": "2.50",
  "net_amount": "97.50"
}

Decimal precision depends on the payment currency. See Amounts and currency conversion for details.


Payment fields

FieldTypeDescription
idstringUnique payment identifier (e.g., pay_...).
merchant_idstringIdentifier of the merchant that owns the payment.
order_idstringIdentifier of the order this payment is associated with.
statusstringCurrent payment status. See Payment status below.
payment_railstringPayment rail used to process the payment.
provider_idstringProvider-side identifier (for example an on-chain transaction hash or internal provider reference).
paid_amountstringGross amount received from the payer, as a decimal string.
fee_amountstringFees applied to the payment, as a decimal string.
net_amountstringNet amount credited after fees (paid_amount - fee_amount).
currencystringCurrency or asset code of the payment.
metadataRecord<string, string>?Optional provider-specific metadata.
created_atstringISO-8601 timestamp when the payment was recorded.
updated_atstringISO-8601 timestamp of the last payment update.

Payment status

Payments progress through a defined set of statuses during their lifecycle.

StatusMeaning
receivedThe payment was detected but not yet applied to the order.
appliedThe payment was successfully applied to the order balance.
failedThe payment attempt failed and has no effect on the order.
refundedThe payment was refunded after being applied.
orphanThe payment could not be matched to a valid order.

Note
Payment status changes are delivered via payment-related webhook events.


Relationship with orders

  • Payments are always associated with one order
  • An order may have multiple payments
  • Order totals are derived from applied payments
  • Payment records remain immutable for audit purposes

A typical flow:

  1. A payment is detected (received)
  2. The payment is validated and reconciled
  3. The payment is applied to the order (applied)
  4. The order status is updated if the payment completes the order

Fees and net amounts

Fees are calculated based on the selected payment rail and merchant configuration.

  • paid_amount represents the gross amount received
  • fee_amount represents platform or processing fees
  • net_amount represents the amount credited to the merchant

All three values are always expressed in the payment currency.


Important notes

  • Payments are append-only records and can not be modified by merchants.
  • Always rely on status to determine whether a payment affects an order.
  • Do not assume that a payment implies an order is paid; rely on the Order status.
  • For partial payments, multiple Payment objects may exist for a single order.

Did this page help you?