Using a shipping endpoint
Gain a better understanding of how you can use a shipping endpoint to present dynamic shipping options in low-code checkouts
Last updated
Gain a better understanding of how you can use a shipping endpoint to present dynamic shipping options in low-code checkouts
Last updated
With low-code checkouts, you can save a shipping endpoint in the Digital River Dashboard. Digital River calls it during physical product checkouts and uses the response to present customers with their shipping options.
If you are using an external logistics provider, the service you set up to handle our call can either filter and adjust the shipping options we send or use the request's data to make yet another request to your external provider to get their available options.
In both cases, you must respond with the options you want us to present to customers in the shipping choice selection stage.
On this page, you’ll find details on:
In your , include the weight and weightUnit of each physical product in the cart in either the SKU referenced by items[].skuId or directly in items[].productDetails.
Goods eligible for inclusion in cross-border shipments should also be assigned a name, description, image, and url. They must also contain a product taxonomy to identify the correct tariff codes. For details, refer to Item Classification.
For each physical items[], if you want the carrier to provide one or more logisticsOptions, and you decided not to save these options to the product's SKU Group, then make sure you enumerate them in deliveryOptions[] and/or dangerousGoods[]. This ensures that the cost of each service gets added to the shipping quotes customers select from.
You'll need to restrict the countries customers can select from during the shipping address collection stage to those you support.
If you (1) select either a low-code checkout solution, (2) save a shipping endpoint in the Digital River Dashboard and (3) engage an external logistics service, you can use this section to understand better:
Since we don't yet know what shipping options are available, the request contains no shippingMethods[].
For each items[], we also give you an id that uniquely identifies that line item in our system.
After you accept our request and determine that it contains no shippingMethods[], you can use its currency, items[], and shipTo to call your logistics provider and get the transaction’s available shipping options.
In that request, you'll most likely want to pass the weight and weightUnit of each items[]. Your logistics provider can typically use that data for more precise shipping rates.
In addition, depending on the sophistication of the integration you have with your provider, they might be able to give you the location of the warehouse(s) from which each items[] will be shipped.
After your logistics provider returns the available shipping options, your service could add a markup, discount them, and/or filter them by terms.
Your response must contain shippingMethods[], which lists the options you want Digital River to present in the shipping choice selection stage. Each element in this array must have an amount, description, and serviceLevel and can optionally include an id, deliveryInformation, shippingTerms, and a shipFrom location.
If your logistic provider informed you where each line item is shipping from, your response can also contain shipments[], each of which should have a single shipFrom and an array of itemIds[], each mapped to an items[].id we sent in the request.
For each shippingMethods[], Digital River displays its amount, description, and shippingTerms to customers in the shipping choice selection stage. If businessDaysInTransit, estimatedArrival.date, and/or estimatedArrival.dayOfWeek exist in deliveryInformation, then their values are also displayed.
If your service checks this data and determines that it's invalid, perhaps because line1 or line2 indicate that the customer is trying to ship the goods to a PO Box, and you don't support that or additionalAddressInfo.neighborhood isn't serviced by your carriers, then it can return an error.
We'll then display that error's message in the checkout experience.
What you need to do to get this message displayed depends on whether you're using Prebuilt Checkout or Components.
When implementing this feature in Prebuilt Checkout, here are some things to keep in mind:
Your server must return one of our stock errors.
Don't modify the stock error's code. If you do, then its message won't display in the checkout experience. Instead, users will be told that an unknown error occurred.
Altering your error's message does not affect what's shown to users. If its code matches one of our supported values, then that stock error's message is displayed, unmodified, in the checkout experience.
To get the message displayed, your server needs to respond with a status code of 400 or 409 and the error's type must be bad_request or conflict.
Digital River blocks customers from advancing to the shipping choice selection stage until they correct the issue.
The following lists the stock and preformatted errors that are available. For illustration purposes, we also show how each is rendered:
If you're implementing this feature in Components:
The error returned by your service must have a message, but doesn't need a code.
The value you assign to message is customizable.
Any valid HTTP status code in the 4xx or 5xx range is accepted, but we recommend that you send back a 400 Bad Request.
In addition, if your response contains an error, that component's done() function will return false, which, if your application is set up correctly, should block customers from proceeding to the shipping choice selection stage.
For details, refer to Controlling the checkout flow.
For details on how to do this, refer to on the page.
Once customers input a shipping address and Digital River determines that an external logistics provider is facilitating the transaction, we send a request to .
It does, however, contain the currency, shipTo, items[], and unique identifier (sessionId).
For each shipments[] in your response, we iterate through its itemsIds[], looking up that resource in our system, and then using the shipments[].shipFrom to set the appropriate items[].shipFrom value(s) in the .
Each time customers make a selection, we use its data to update the shippingChoice and, if that selection contains a shipFrom , we also use it to set that resource's .
After Digital River converts the to an and sends you the with a type of order.accepted, you can pass its data to your fulfillment service, which can then read the line-item level and/or order-level ship from values and route ship requests to the appropriate warehouses.
The body of the Digital River sends to your server always has (1) shipTo, which contains the customer's designated address and, depending on their selected country, might also have additionalAddressInfo as well as (2) the details of each items[] the customer is purchasing.
The error's message isn't translated into the . Rather, it's always rendered in English.
Digital River displays your error's message in the address component. Before doing that, we don't translate it into the or perform any other operations.
