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 and , a is processed, and other key events in the occur. More specifically, an order persists:
The total , , and payment amounts
A containing a , an amount charged to that source, and the
The following diagram depicts the relationship between an order and other resources in the Digital River APIs.
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.
In addition, these items[] store detailed price, tax, and quantity information that you can display to customers on order confirmation and order detail pages.
To ensure that your integration is functioning properly, you can create test orders using the information on the page.
In the following section, you'll find information on some of an attributes and how you might use them in downstream requests. For a complete list, refer to the reference documentation.
An contains a unique id. You can use this identifier when , , , , , and .
An order's shipTo values are displayed on .
Digital River assigns each of an items[] a unique id. You need this identifier when , , and .
Depending on how you , each of an order's items[] also contains either a or a object.
For more information on subscriptionInfo, refer to the page.
In most cases, Digital River populates an invoicePDFs and creditMemoPDFs with information that you can use to .
For more information about an state and fraudState, refer to the page.
Orders with contain an array of .
An charges[] contains one or more elements, each representing a created from a . Each charge contains a unique identifier, an amount, a , and the identifier of the used to create the charge.
An 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.
An has a defined lifecycle. Each stage of that lifecycle is represented by state. When an state changes, an is created that represents that change. For example, when an order's state transitions from accepted to fulfilled an order.fulfilled event is created.
The following lists an 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:
isn't yet and could still be pending
charge is , but the order requires further , and, as a result, is still not ready to fulfill
charge is , has passed or the (DPL), and is ready to fulfill
fails because it is blocked by or the customer is determined to be on the
is fully
is completely or partially fulfilled and the remaining items[] are cancelled
is and the charge is fully or partially fulfilled with a partially captured charge and the remaining items[] are or
the order
is fully returned or partially returned and its remaining items[] are cancelled or partially/fully
are disputed
The state values for a successful (i.e. the happy path) are pending_payment > in_review > accepted > fulfilled > complete . As the moves from one state to another, that event is recorded with a timestamp in stateTransitions.
An must also pass through a fraud review. When exactly this review occurs in an depends on the 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 is created.
