Digital River coordinated returns
Learn how to manage returns when Digital River is your designated fulfillment coordinator
Last updated
Learn how to manage returns when Digital River is your designated fulfillment coordinator
Last updated
In , you can use the to and returns. After you create a , you should monitor and respond to the .
When requesting a fulfillment return, you should first . Once you've done that, you can .
Before providing customers the option to return an item, you should ensure that the item is in a . Customers shouldn't be allowed to return pending
, backordered
, or cancelled
items. You can obtain this information by or .
You may decide you want to build your integration so that customers have the pending
and backordered
items.
When customers indicate they want to return all or part of a , submit a POST /fulfillment-returns
request that specifies the items to return and in what quantity. More specifically, you need to provide us the these items are attached to, to return, and the .
The fulfillmentOrderId
parameter is used to specify the associated with this return.
For each item you want to return, you must provide the and the quantity
of that item to return.
In the request, you should also set upstreamId
to the . This allows you to retrieve this identifier from the payload of a and use it when .
POST
fulfillment return requestFulfillment Orders
id
âž”
fulfillmentOrderId
Fulfillment Orders
items[].id
âž”
items[].fulfillmentOrderItemId
Orders
id
âž”
upstreamId
The items
array of a fulfillment return contains information on requested and accepted returns. For each item in this array, quantity
is the number of items you requested to be returned. The quantityAccepted
is how many items have been accepted for return by the fulfiller.
When quantityAccepted
is less than quantity
, then the fulfiller has not yet approved all products for return.
has been received by the fulfiller but they haven't approved or rejected it yet
created
has been approved by the fulfiller but the returned items haven't been received at the warehouse yet
pending
has been accepted by the fulfiller because the returned items have been received at the warehouse
accepted
has been rejected by the fulfiller
rejected
The state
attribute at the item level indicates where a line item is in its return lifecycle. The values for a successfully returned line item (i.e., the happy path) are pending
> accepted
.
identifier is sent in a successfulPOST/fulfillment-returns
request but the product(s) is not yet approved for return by the fulfiller
pending
has been received by the fulfiller at the warehouse and the product(s) return is accepted
accepted
return request is rejected by the fulfiller
rejected
The type
attribute indicates who initiated the return. A client
return is standard and is typically initiated by a customer through the storefront. A warehouse
return is initiated when a shipment is refused.
When you submit a successful POST /fulfillment-returns
request, we send you a fulfillment_return.created
event. This indicates that your return request has been created by Digital River but has not yet been approved or rejected by the fulfiller.
A fulfillment_return.rejected
event indicates the fulfiller has rejected the return.
When defining a POST /fulfillment-returns
request, you can retrieve the required data from the following upstream and resources.
Once you've successfully submitted a POST/fulfillment-returns
request, you get back a fulfillment return with a unique id
which you can use to later .
The object provides you with information on each . A fulfillment return also contains enumerations that indicate its and .
Once the , we also provide the where the customer should ship the items.
A Digital River coordinated physical return has a defined lifecycle at both the and level. Each stage of these lifecycles is represented by the state
attribute.
The state
attribute at the fulfillment return level indicates where a is in its lifecycle. The values for a successful fulfillment return (i.e., the happy path) are created
> pending
> accepted
.
Once is approved by the fulfiller, we populate the location
hash table. This data structure provides the address where a customer should return the products. To be notified of these approvals, you can subscribe to events.
Once you submit a POST /fulfillment-returns
request, you can determine its status by or .
There are two methods in the that can be used to retrieve fulfillment returns. You can filtered by optional query parameters. You can also by sending its unique identifier as a path parameter.
You can to listen for fulfillment return events. The data.object
of every one of these consists of a .
If the fulfiller approves the return request, we send you a fulfillment_return.pending
event. You can use this event to determine and and then convey this information to the customer.
When the fulfiller notifies us that they've received and accepted the returned products, we send you a fulfillment_return.accepted
event. If you don't want to reimburse customers until they have returned products, your integration should wait to receive this event before .