Skip to main content
Use the generated endpoint pages for the complete query parameters and response schemas.

List orders

Filter and paginate organization-scoped orders.

Get an order

Inspect one order and its available payment-channel identifiers.

​
List and detail behavior

The list operation supports payment-status checks and operational views. Its status filter matches the human-facing displayStatus, while the response also preserves the canonical status. You can also narrow orders by customer_id or Anyway subscription_id. Merchant API order detail does not expose payment-provider or provider account identifiers. orderId is the canonical order identifier. The legacy id response field contains the same value but is deprecated. amount is the pre-tax amount in display units; amountCents is that amount in minor units. taxAmountCents is the tax, and totalAmountCents is the total including tax, both in minor units. Card orders can also include fundsSettled and settledAvailableOn. Use fundsSettled as the payout-eligibility state; settledAvailableOn is only the provider’s estimated availability time. Both fields are omitted for payment methods without this settlement lifecycle.

​
Subscription relationships

An order created for a recurring payment includes subscriptionId. The initial payment has no originalOrderId; each renewal points originalOrderId to that initial order. Use GET /v1/orders?subscription_id=SUB_EXAMPLE to retrieve the order history for one subscription.

​
Checkout Session correlation

When you create a Checkout Session through the API, submit merchantReference and metadata. The associated order returns checkoutSessionId and retains merchantReference and merchantMetadata. A Session being COMPLETE does not establish that the order is paid; fulfill from the order payment state and verified notifications. Append URL-encoded query parameters when sending a payment link to a buyer:
When checkout opens, Anyway stores the query parameters on the Checkout Session as merchantMetadata. If a key matches merchant_reference or merchantReference, Anyway also promotes its value to the Session’s separate merchantReference field while keeping the original key-value pair in merchantMetadata. When payment is confirmed, both values are copied from the Checkout Session to the order record. Subscription renewal orders inherit them from the initial order. This persistence path makes the same correlation data available through order responses and Webhooks after checkout has finished. Payment-link query parameters are exposed through two complementary fields:
  • merchantReference is the promoted value of the merchant_reference query parameter. It is stored separately as a first-class correlation field, and the orders list can filter it with merchant_reference.
  • merchantMetadata contains every custom payment-link query parameter as string key-value pairs. Merchant API responses return the map, but arbitrary metadata keys cannot be used as list filters.
After receiving an order ID from a webhook or success redirect, retrieve the order and read both fields:
Treat merchantMetadata, buyer-supplied notes, and URL query parameters as untrusted input; never use them alone to authorize access or set a price.

​
Fulfillment

Fulfill from a verified paid state or a verified order.paid webhook. Make delivery idempotent by the Anyway order ID. Anyway protects paid orders from duplicate payment events and status regression, but your fulfillment handler must also tolerate retries.
A successful API response does not make buyer-controlled metadata trustworthy. Authorization and pricing decisions must come from server-controlled records.