checkout_session.order.created
event.checkoutId
in the body of a POST/orders
.POST/orders
whose payload contains checkoutId
plus additional parameters (provided they adhere to the request's data contract). But, when processing the request, Digital River ignores this additional data. So, if you'd like to update the checkout, you must do so prior to submitting a POST/orders
.POST/orders
that contains the checkout's identifier, an updated email
, and also adds an upstreamId
that identifies the order in your system, then the response contains a 201 Created
status code. However, email
is not updated and upstreamId
is not populated.checkoutId
in a POST/orders
and, instead, create an order with a registered customer's identifier.POST/orders
responsePOST/orders
(assuming all upstream checkout requirements have been met), the response will contain a 409 Conflict
or 201 Created
status code.409 Conflict
status code indicates that Digital River did not create an order, either due to a payment authorization failure or suspected fraud. The error's code
and message
contain more specific information about what triggered the failure.message
to inform end customers of the problem. Do not, however, share code
. Doing so may aid parties that are attempting to carry out fraudulent or malicious activities.409 Conflict
status code, refer to the Handling rejected orders page.id
, state
, fraudState
, and charges[].state
, and use these values to update the corresponding attributes in the upstream commerce platform's order.state
is pending_payment
, then the fraud review process has been successfully completed but the payment charge is not yet authorized. For more details, refer to handling pending payment orders.state
is in_review
, then this indicates that Digital River is conducting a secondary fraud review. For more information, refer to handling in review orders.state
is accepted
, then the transaction has successfully passed fraud review and the payment charge is authorized. For more information, refer to handling accepted orders.state
, fraudState
, and charges[].state
(if available) from its payload, and use this data to update the corresponding attributes in the upstream commerce system's order.payment.charges[]
and inspect them for a failure code or message. The failureMessage
however is not always available. But when it is, you can use it to provide more specific payment failure information to customers.failureCode
to end customers. Doing so potentially aids malicious and fraudulent actors.order.blocked
event. The payload of this event consists of an order whose state
is blocked
. The order's fraudState
is also blocked
. Since these are both terminal states, you should inform end customers that the transaction has failed.order.pending_payment
event indicates that Digital River detected no fraudulent activity during its fraud review. However, don't use this event as a trigger to initiate fulfillment operations. This is because the order's payment.charges[]
are not yet fully authorized.payment.charges[]
are authorized and no irregularities are detected during the fraud review, Digital River creates an order.accepted
event. Respond to this event by moving the commerce platform's order into a ready to fulfill state.accepted
state, your integration should wait until it receives order.accepted
before initiating fulfillment operations. Doing so reduces the risk of fraud and the frequency of disputes and chargebacks.cancelReason
is not populated.order.cancelled
event may have multiple origins. For example, if your site contains a cancel order button, then order.cancelled
may originate with customers requesting to cancel their order.POST/fulfillment-cancellations
that requests to fully cancel each of a fulfillment order's line items.order.cancelled
as the event that triggers a cancellation complete notification to customers. This is because, once an order is accepted
, it doesn't become cancelled
until the state
of all of its payment.charges[]
is also cancelled
.order.cancelled
event could also be triggered when customers fail to transfer payment by a designated date and time and, as a result, the source expires. This applies to wire transfers, Konibini payments, and other type
(s) of sources with a payment flow
of receiver
.type
is wireTransfer
, once you successfully convert the checkout to an order, the order typically moves into a state
of pending_payment
. When handling this order state change event, you should provide instructions to customers on how to provide payment.order.cancelled
event is fired. In this scenario, since no charge is created, you won’t receive any order charge related events.order.cancelled
eventorder.cancelled
event, we recommend that you:stateTransitions.cancelled
attribute)pending_payment
indicates that a payment charge has not yet been authorized. Orders in this state
should not be fulfilled.POST/orders
response or the order.pending_payment
event, retrieve the payment.sources[].id
of the order's primary payment source.GET/sources/{id}
request. From the response, retrieve the source's clientSecret
.id
and clientSecret
to configure the delayed payment instructions element on your front end.order.accepted
event. If they don't make payment within the allotted time, you receive order.cancelled
.in_review
should not be fulfilled. After an order transitions out of this state
, Digital River creates either order.accepted
or order.blocked
. So make sure your integration is set up to handle both of these events.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.items[]
a unique id
. You need this identifier when capturing and cancelling payments, handling third-party returns, and issuing refunds. items[]
also contains either a skuId
or a productDetails
object.items[]
store detailed price, tax, and quantity information that you can display to customers on order confirmation and order detail pages.invoicePDFs
and creditMemoPDFs
with information that you can use to access and share tax invoice and credit memo files.charges
array 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.requestToBeForgotten
indicates whether an order's data is scheduled for deletion. This is the only attribute (other than metadata
) that can be modified in an update order request.metadata
, the only order attribute that you can update is requestToBeForgotten
.POST/orders/{id}
request and pass in the order identifier as a path parameter. If the customer has requested that the order be forgotten, then set the requestToBeForgotten
parameter to true
.checkoutId
in a POST/orders
request, and that Checkout has already been consumed by a different POST/orders
request, you'll get back a response with a 404 Not Found
status:POST/orders
that omits checkoutId
, thereby bypassing the Checkouts API. In this case, the request should contain a registered customer and a reusable payment source saved to that customer's account. The POST/orders
must also meet all currency, address, shipping method, product, and payment session requirements.