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
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:
Creating the checkout-session
In your create checkout-session request, 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.
A product's weight should be exclusive of its packaging but inclusive of its dunnage. In other words, don't include the weight of the product's box but do include the weight of the protective and supporting materials that go inside of it.
Goods eligible for inclusion in cross-border shipments should also be assigned a name, description, image, and url. They also need to 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 of these services gets added to the shipping quotes customers select from.
Restricting available ship to countries
You'll need to restrict the countries customers can select from during the shipping address collection stage to those you support.
For details on how to do this, refer to Shopping country on the Checkout-sessions page.
In Prebuilt Checkout, you can also use its configuration object to restrict shipping and billing countries.
Using the endpoint with an external logistics provider
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:
The shipping quotes request
Once customers input a shipping address and Digital River determines that an external logistics provider is facilitating the transaction, we send a request to your shipping endpoint.
Since we don't yet know what shipping options are available, the request contains no shippingMethods[].
It does, however, contain the checkout-session’s currency, shipTo, items[], and unique identifier (sessionId).
For each items[], we also give you an id that uniquely identifies that line item in our system.
Processing and responding to our request
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 to give you back 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.
How Digital River processes your response
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 checkout-session.
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.
In Prebuilt Checkout, Digital River renders shippingTerms in such a way that its meaning is clearer to customers.
Each time customers make a selection, we use its data to update the checkout-session’s shippingChoice and, if that selection contains a shipFrom , we also use it to set that resource's shipFrom.
Defining the ship request
After Digital River converts the checkout-session to an order and sends you the event 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.
Displaying errors
The body of the request 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.
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.
Prebuilt Checkout
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 itsmessagewon't display in the checkout experience. Instead, users will be told that an unknown error occurred.Altering your error's
messagehas no effect on what's shown to users. If itscodematches one of our supported values, then that stock error'smessageis displayed, unmodified, in the checkout experience.To get the
messagedisplayed, your server needs to respond with a status code of400or409and the error'stypemust bebad_requestorconflict.Digital River blocks customers from advancing to the shipping choice selection stage until they correct the issue.
The error's
messageisn't translated into the checkout-session'slanguage. Rather, it's always rendered in English.
Stock errors
The following lists the stock and preformatted errors that are available. For illustration purposes, we also show how each is rendered:
Components
If you're implementing this feature in Components:
The error returned by your service must have a
message, but doesn't need acode.The value you assign to
messageis customizable.Any valid HTTP status code in the
4xxor5xxrange is accepted, but we recommend that you send back a400 Bad Request.
Digital River displays your error's message in the address component. Before doing that, we don't translate it into the checkout-session's language or perform any other operations on it.
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.
Last updated
