Checkout-sessions
Gain a better understanding of how to define a checkout-session
Last updated
Gain a better understanding of how to define a checkout-session
Last updated
A checkout-session determines what information and options are presented to customers in low-code checkouts.
At a minimum, your create checkout-session request needs to contain currency and product data.
You can also tell us whether your prices are tax-inclusive.
If the customer’s cart contains physical products, make sure to provide shipping method options for customers to select from.
When checking out registered customers, you can send their unique identifier and their saved addresses.
For complete specifications, refer to the checkout-sessions API reference docs.
In upstreamId, you can pass the unique identifier of the order in your system. If upstreamId is not null, Prebuilt Checkout displays its value as the order number during the thank you stage.
You need to pass currency in your create checkout-session request. This value determines how amounts are denominated in the checkout experience.
To control how the checkout experience, purchase invoices, and credit memos are localized, you can pass language in the create checkout-session requests.
For a list of accepted values, refer to Supported languages.
If you define options.language in the Prebuilt Checkout's configuration object, that value gets assigned to the checkout-session's language.
Digital River uses the checkout-session's language to set the checkout's language, which determines how purchase invoices and credit memos are localized once the order is successfully created.
For each product in the customer’s cart, you'll need to use items[] to send its:
skuId or productDetails. For details, refer to Product basics.
price or aggregatePrice. For details, refer to Setting product price.
quantity
You can also use items[] to provide:
a shipFrom location.
a discount on the product
a strikeThroughPrice that highlights how much customers are saving
If you're using an external subscription service and would like the billing frequency of the subscription that the customer is acquiring to be displayed in the checkout experience, then specify a plan.interval and plan.intervalCount in items[].subscriptionInfo of your create checkout-session request.
For details on how to configure a checkout-session for use with Digital River's subscription service, refer to Processing subscription acquisitions.
Digital River reads those values and displays them in the order summary section of Prebuilt Checkout.
This feature is not yet supported in Components.
Additionally, if you need this data to populate email notifications or some other potential use case, then we also add these key-value pairs to the event with a type of checkout_session.order.created.
To highlight how much customers are saving when purchasing a product, you can send items[].strikeThroughPrice. The value you assign this parameter in a create checkout-session request typically represents the original, pre-discounted price of an items[], which Digital River then crosses out and displays next to the discounted price.
Other parameters in the request don't affect how strikeThroughPrice is rendered in the checkout experience. Digital River displays its value as is. For example, we don't adjust it depending on the taxInclusive setting.
So, if an items[] has a quantity that's greater than 1, and you're trying to communicate a discount, make sure you implement pre-request logic that ensures strikeThroughPrice is less than price multiplied by quantity. Otherwise, the product's price will appear to be marked up instead of discounted.
The parameter is not intended for use with either discount or items[].discount since this might result in conflicting information being displayed in the experience.
If you're using the local pricing service, then we perform a currency conversion on strikeThroughPrice, just like we do with price, based on what users have selected when they initiate checkout.
A checkout-session's shoppingCountry represents the country in which a customer is based.
If you send a shoppingCountry that's not null, Digital River uses that value to populate the checkout-session's shipTo.address.country. This is true whether items[] represents physical, digital, or mixed goods.
You can also save a default shopping country in Digital River Dashboard. If you do so, shoppingCountry in a POST /drop-in/checkout-sessions overrides (but doesn't overwrite) the value saved in the Digital River Dashboard.
Additionally, shoppingCountry prompts Digital River to disable the shipping country drop-down menu and blocks customers from selecting any options.addresses[] whose country doesn't match shoppingCountry.
However, a checkout-session's shoppingCountry and billTo.address.country don't need to match. As a result, the bill to country drop-down menu remains operable and customers can choose from any options.addresses[].
The following create checkout-session request passes shoppingCountry and its single items[].skuId references a digital product.
The shoppingCountry also plays a role in determining:
What address validations a customer's inputs are subjected to.
Whether customers are shown a form that collects their tax identification number and whether they have the option to enter a value or are required to do so.
The options that are displayed in the payment collection stage.
The designated selling entity affects what compliance disclosures are displayed and whether a purchase invoice is eventually generated.
If items[] contains physical products, then your checkout-session needs to meet certain shipFrom.address requirements.
Refer to Ship from requirements on the Providing address information page for details. There, you will find checkout requirements, which the checkout-session wraps.
To get this data added to the checkout-session, you can:
Send shipFrom in a create checkout-session request.
Save a default ship from address in the Digital River Dashboard. If you do this, then any shipFrom values sent in a POST /drop-in/checkout-sessions override (but don't overwrite) those saved in the Digital River Dashboard.
Use a shipping endpoint to dynamically provide Digital River with one or more shipFrom locations during the checkout process.
The checkout-session's customerType indicates whether customers are making the purchase as an individual or on behalf of a business.
If customerType is business, customers must enter their company's name in both the shipping and billing information collection forms.
In many cases, a value of business is required to activate the tax identifier collection form. For details, refer to Supported tax identifiers.
You can pass customerType in a create checkout-session request. But to do so, you'll need to have this information before initiating checkout.
If you'd like Digital River to ask customers during the checkout process whether they're making the purchase on behalf of a business, then you'll need to turn this feature on in Dashboard and your POST /drop-in/checkout-sessions must (1) omit customerType (2) or assign a value of individual or null to this parameter.
For details, refer to:
B2B transactions in Name and address stage on the Prebuilt Checkout page
Business to business transactions on the Address Component page.
The taxInclusive boolean determines how we treat product prices when calculating tax.
It also dictates how prices are displayed in the checkout experience. The default value is false. If you set taxInclusive to true, then the experience indicates that the total amount includes VAT.
For checkouts initiated by a registered customer, your create checkout-session request can include the following:
To checkout customers registered in your system, send their customerId.
Digital River uses this value to determine whether a customer with that identifier exists in our system.
If it does, we retrieve that customer's transaction-applicable taxIdentifiers[] and payment sources[] and, for convenience purposes, present them as options in the tax identifier and payment collection forms.
If the customer doesn’t yet exist in our system, we create a new object and assign it the customerId you provided.
In either case, as registered customers progress through a Prebuilt Checkout, they can save their shipping information, tax identifiers, and billing information for use in future transactions. They can also do the same for their selected payment method in both Prebuilt Checkout and Components.
If you persist registered customers’ addresses, and the customer checking out has one or more saved values in your system, you can use options.addresses[] to send Digital River this data.
In the address collection stage, we present these saved values to customers for convenience purposes.
For each options.addresses[], Digital River only displays its name and address.
If items[] contain physical products, you must provide Digital River shipping options for customers to select from. You can do this in one of the following ways:
First, you can send options.shippingMethods[] in the create checkout-session request.
Alternatively, you can save default shipping methods in the Digital River Dashboard. These represent static options (i.e., ones whose amount and serviceLevel are not dependent on where the products are being shipped or how much they weigh). If you use this approach, options.shippingMethods[] sent in the create checkout-session request overrides your saved values in the Digital River Dashboard.
Finally, you can set up a shipping endpoint that Digital River calls at checkout time. This lets you offer your customers dynamic options in the shipping method selection stage. The data returned by this endpoint overrides any options.shippingMethods[] sent in your request or saved in the Digital River Dashboard.
For each of the checkout-session's options.shippingMethods[], the user is displayed its amount, description, and shippingTerms, as well as businessDaysInTransit, estimatedArrival.date, and estimatedArrival.dayOfWeek in deliveryInformation.
Each options.shippingMethods[] requires an amount but not a serviceLevel. However, this data helps Digital River detect fraud, so we highly encourage you to pass it.
If you submit a POST /drop-in/checkout-sessions with physical items[] but without options.shippingMethods[], and you don't have default shipping methods or a shipping callout endpoint saved in Digital River Dashboard, then the request returns the following error:
In the create checkout-session request, options allows you to pass one or more storeCredits[]. Each element in this array can be defined by an amount, name, upstreamId, iconUrl, and lastFour.
In the payment collection forms, we display amount, name, iconUrl and lastFour to customers.
For more details, refer to Offering store credit.
amountThis required parameter represents how much credit you’re offering the customer.
nameThe name of the store credit offer. Omitting name or passing a null value doesn't throw an error, but it does mean that that particular storeCredits[] won't be displayed in the payment collection form.
upstreamIdThis required parameter uniquely identifies the line of credit in your system. Passing multiple storeCredits[] that share the same upstreamId is not allowed.
iconUrlThe web address of your store credit logo.
lastFourThe last four digits of the customer's store credit card.
You can control the appearance and visual behavior of a Prebuilt Checkout by defining style in a create checkout-session request.
For details, refer to Defining experience.
