The unique identifier of customer linked to order.

The unique identifier of document linked to order. This document entity should contain the required documents to process incoming payments. Refer this Document entity for more details.

The status of the order.

• active — the order has been created and can be paid.
• action_required — Glomo needs more information before the order can be paid. Respond to the open RFI to continue.
• under_review — the information you submitted is being reviewed. The order returns to active if the review passes.
• paid — the order has been paid in full. Terminal.
• failed — the order could not be accepted, for example because the review did not pass. Terminal.
• cancelled — the order was cancelled before it was paid. Terminal.
• expired — the order passed its expiry time without being paid. Not always final: a payment that was already under way when the order expired can still complete it, moving it to paid.

The currency the order is collected in, as an uppercase ISO 4217 code. Must be one of the listed values; the match is case-sensitive. INR is not accepted.

The amount you want to receive, a positive integer representing the smallest currency unit. For example, if the amount is $299.00, then pass 29900 in this field. In the case of three decimal currencies, such as KWD, BHD and OMR, to represent an amount of 295.991, pass the value as 295990. And in the case of zero decimal currencies such as JPY, for amount ￥295, pass the value as 295.

Why you are receiving this payment, as a code from a fixed set: see Payin purpose codes. This is not free text. Pass a listed code exactly, for example P1401; matching is exact and case-sensitive. Payins and payouts use different sets, so a payout code such as S1401 is rejected here. An unrecognised code is rejected with 400 Bad Request.

Optional on orders. When omitted, Glomo applies your account's default payin purpose code if one has been configured.

Number/Id of the invoice submitted with order. LRS orders (sent with lrs) don't store this field and return it as null, but a value you send is still validated.

Description about the invoice submitted with order

The amount on the invoice, in the smallest unit of the order's currency, the same unit as amount (cents for USD). 1000 is $10.00 when currency is USD. Must be greater than or equal to amount.

optional identifier to be sent for reconciliations

The unique identifier of 'Price' entity linked to the order. This is the referral fee for this order. Note: price_id is only applicable for platform businesses.

The pricing splits to apply, each entry an id returned by Create a pricing split. A split fixes your share of a dynamic rule's fee and the customer bears the remainder. Omit split_ids and no dynamic rule is applied — pricing falls back to your normal (non-dynamic) rules.

split_ids and payment_methods are independent. payment_methods restricts which methods the checkout offers. split_ids only changes how the fee for a method is priced: a split applies to its own payment method whether or not that method appears in payment_methods, and a split never adds a method to the checkout or removes one from it. One checkout can therefore price one method from a dynamic split and another method from your normal rules.

Every id must exist, must belong to your business, and must still point at a live dynamic rule. When two dynamic rules share a dimension — the same payment method, subtype, rail, currency and fee type — declare a split for every one of them or the request is rejected. On payment links and orders, a split whose payment method is not enabled for your business is also rejected.

A subscription only ever charges card, or pay_via_bank when SEPA-eligible, so a split declared for any other payment method is rejected at subscription creation and on an auto debit. An auto-debit override must be declared for the method the subscription actually charges.

Glomo can configure your account to require a declaration. On such an account, a payment link, an order, a payin quote or an as_presented subscription that omits split_ids is rejected.

Details of the product that the payment is related to.

Optional key-value pairs for attaching custom metadata (e.g. invoice references, project codes). Keys must be strings and cannot collide with reserved field names. Your account may require some notes fields: Glomo configures custom field rules per account, and for beneficiaries they are checked when the beneficiary is created. Some fields are also validated by the beneficiary's country (for example, a PAN format for Indian beneficiaries). A missing required field returns 422 with Validation failed: Notes <field> is required, and type and validation errors (such as enum constraints) are returned the same way. The rule is set on your account, not by currency or rail. No API lists the fields, but the 422 names each missing one: add that key to notes with the value your account expects, and ask your Glomo account manager if you don't know what the field should hold. See Custom fields. Each key appears as a separate column in CSV report exports, with corresponding values populating the rows.

Optional bank account details to associate with the customer for this order. When provided, the bank account will be linked to the customer and associated with this order. Either bic_primary or bic_secondary must be provided when including this field.

Send this object to create an LRS order: a remittance from a customer resident in India, funded from their Indian bank account. If you send lrs, lrs_quote_id and remittance_information are required.

• Create the quote first with POST /lrs/quotes. The order's amount must equal the USD side of the quote (from.amount for a USD source quote, to.amount for an INR source quote), and currency must be USD. Otherwise the order is rejected with 400.
• The quote must not have expired. The order expires when the quote does.
• The customer's country must be India, otherwise the order is rejected with 400.
• An LRS order doesn't store invoice_number, invoice_description, invoice_amount, reference_number, document_id or product; they come back as null or are left out. A value you send is still validated, so leave these fields out.

Returned on the order when it was created as an LRS order.

Array of payment methods that should be available for the customer on the checkout page. This field allows you to control which payment options your customers can use to complete the payment. You can specify one or multiple payment methods in the array. Each value must be a payment method enabled on your account; any other value is rejected with a 400. Omit the field to offer every payment method enabled on your account.

When the order was created, as an ISO 8601 date-time in UTC.

When the order was last updated, as an ISO 8601 date-time in UTC.

Your unique identifier for this order, used to reject duplicates. If an order with the same request_id already exists on your account, the request is rejected with 400 and the message Order already exists for this request_id; the existing order is not returned. Look it up with GET /v1/orders?request_id=<your_request_id>. Returned on the order and its webhooks; null if you sent none.

List of required documents for RFI (Request for Information). This field is only present when the order status is 'action_required', indicating that sanction screening has been triggered and additional documents are required to proceed with the payment.

When the order expires, as an ISO 8601 date-time in UTC. An order created from a quote inherits the quote's expiry.