System Status

Order basics

Learn more about the orders resource.

Orders handle customers' purchases. When you create an order, you instruct Digital River, the authorized reseller, to send an authorization request to start the collection process.

The data of an order persist, acting as a permanent record of the sale, which Digital River must maintain for auditing purposes.

An order maintains an enduring record of when it was placed, a charge is created and captured, a refund is processed, and other key events in the order lifecycle occur. More specifically, an order persists:

The following diagram depicts the relationship between an order and other resources in the Digital River APIs.

To ensure that your integration is functioning properly, you can create test orders using the information on the Testing Scenarios page.

The orders resource

In the following section, you'll find information on some of an order's attributes and how you might use them in downstream requests. For a complete list, refer to the Orders API reference documentation.

Unique identifier

An order contains a unique id. You can use this identifier when initiating physical fulfillments, cancelling shipments, capturing and cancelling payments, creating physical returns, handling third-party returns, and issuing refunds.

Ship to values

An order's shipTo values are displayed on invoices and credit memos.

Amounts, fees, and taxes

The total amount, fees, taxes, and other order costs are the same as those presented to customers when they confirm the purchase. You can retrieve these values and display them on the customer's order confirmation page.

Line items

Digital River assigns each of an order's items[] a unique id. You need this identifier when capturing and cancelling payments, handling third-party returns, and issuing refunds.

Depending on how you send product data in checkouts, each of an order's items[] also contains either a skuId or a productDetails object.

In addition, these items[] store detailed price, tax, and quantity information that you can display to customers on order confirmation and order detail pages.

For more information on subscriptionInfo, refer to the Subscription information page.

Tax invoices and credit memos

In most cases, Digital River populates an order's invoicePDFs and creditMemoPDFs with information that you can use to access and share tax invoices and credit memo files.

State and fraud state

For more information about an order's state and fraudState, refer to the Order lifecycle page.

Tax identifiers

Orders with applied tax identifiers contain an array of tax identifier objects.

Charges

An order's charges[] contains one or more elements, each representing a charge created from a primary or secondary payment source. Each charge contains a unique identifier, an amount, a state, and the identifier of the payment source used to create the charge.

Request to be forgotten

An order's requestToBeForgotten indicates whether an order's data is scheduled for deletion. It is the only attribute (other than metadata) that you can modify in an update order request.

Gets an order by ID

get

Retrieves the details of an order. Supply the unique identifier of the order you would like to retrieve.

Authorizations
AuthorizationstringRequired
Bearer authentication header of the form Bearer <token>.
Path parameters
idstringRequired

Order ID

Query parameters
expandbooleanOptional

Enhanced Payload

Responses
200

OK.

application/json
get
/orders/{id}

The order lifecycle

An order has a defined lifecycle. Each stage of that lifecycle is represented by state. When an order's state changes, an event is created that represents that change. For example, when an order's state transitions from accepted to fulfilled an order.fulfilled event is created.

Order states and events

The following lists an order's enumerated state values and the events associated with each state change. These state transitions are listed in the approximate sequence they might occur in an order's lifecycle:

(1) When the order...
(2) state transitions to...
(3) and an ... event is emitted.

charge isn't yet capturable and could still be pending fraud review

pending_payment

order.pending_payment

charge is capturable, but the order requires further fraud review, and, as a result, is still not ready to fulfill

in_review

order.review_opened

charge is capturable, has passed fraud review or the Denied Parties List (DPL), and is ready to fulfill

accepted

order.accepted

fails because it is blocked by fraud review or the customer is determined to be on the DPL

blocked

order.blocked

is fully cancelled

cancelled

order.cancelled

is completely fulfilled or partially fulfilled and the remaining items[] are cancelled

fulfilled

order.fulfilled

is fulfilled and the charge is fully captured or partially fulfilled with a partially captured charge and the remaining items[] are cancelled or

the order charge is complete

complete

order.complete

is fully returned or partially returned and its remaining items[] are cancelled or partially/fully refunded

returned

order.refunded

charges are disputed

dispute

order.dispute

The state values for a successful order (i.e. the happy path) are pending_payment > in_review > accepted > fulfilled > complete . As the order moves from one state to another, that event is recorded with a timestamp in stateTransitions.

Fraud review

An order must also pass through a fraud review. When exactly this review occurs in an order's lifecycle depends on the payment method used by the customer. The different stages of the review are represented by fraudState, whose enumerated values are review_opened, blocked, and passed. When fraudState changes, an event is created.

PreviousOrdersNextPayouts

Last updated