Building checkouts
Learn the basics of how to sequence the checkout process as well as define, create, update, and use checkouts
Last updated
Learn the basics of how to sequence the checkout process as well as define, create, update, and use checkouts
Last updated
Your site's checkout experience should contain pages for customers to provide their shipping address, billing address, and payment information. Your site should also have an order review and submission page. Once customers place the order, we recommend you direct them to an order confirmation page.
On this page, you’ll find information on how to:
During the initial stages of an eCommerce transaction, customers land on your storefront, review products, build a cart, confirm the cart's details, and initiate checkout. Digital River is typically not involved during these early pre-checkout interactions.
As a result, this section doesn't provide guidance on how to structure these early transaction stages. Instead, it focuses on how to initiate the checkout process. Then, for shopping carts containing physical products, it explains how to sequence the create and update requests and the create and authenticate requests that you send to Digital River.
Once customers start adding items to their cart, we recommend you activate a proceed to checkout button. We recommend a similar button on your review cart page. Each button’s click event handler should direct customers to your initial checkout page.
Once customers click the proceed to checkout button, we recommend using your checkout pages to obtain their shipping and billing addresses. Once customers enter new address information or confirm saved information, retrieve and save that data.
You can then use this saved address data, along with product data in the customer's cart, to define items[], shipTo and billTo and then submit the create checkout request.
Since you can’t with additional items[] or modify the quantity of existing items[], this sequence reduces the probability that customers will add products to their cart after you submit the create checkout request.
It also provides Digital River with the data we need to generate a tax estimate that you can display to the customer.
For more information, refer to sequencing address information in checkouts on the Providing address information page.
You must display disclosures on all of your checkout pages, typically in the footer. You can use the compliance element to do this.
This ensures customers are shown localized disclosures relevant to their shopping country and the transaction's designated selling entity.
If you allow guest checkouts, collect and send us the customer's email address. For more information, refer to address requirements on the Providing address information page.
If the shopping cart contains physical products, once you have the customer's ship-to information, you’ll typically request a shipping quote from your logistics partner. In most cases, your partner replies with an array of quotes, each containing an eligible shipping method, the shipping method's cost, and one or more ship-from addresses.
For Digital River coordinated fulfillments, refer to the Using shipping quotes page.
A checkout's shipFrom can be set at the checkout-level or the line item-level.
However, before you can do that, the payment methods presented to the customer must apply to the transaction. With Drop-in payments, you accomplish this by building a configuration object and passing it to the createDropIn() method. If you use DigitalRiver.js with elements, you'll need to configure and invoke retrieveAvailablePaymentMethods().
In registered checkouts, you can use this same method to filter the customer's saved sources by transaction applicability before presenting them to the customer. If the customer selects a saved source from this filtered list, you'll need to use authenticateSource(). This method first determines whether strong customer authentication (SCA) is required and then, if it is, opens a modal window that takes customers through the authentication process.
In both guest and registered checkouts, if customer's decide to provide new payment information, both of our primary source creation methods require a payment session identifier. You can retrieve this session identifier from the checkout.
Both methods also require the customer’s billing address. Unless the customer indicates otherwise, you can use the address you collected earlier in the checkout process.
Once the payment source is successfully created or authenticated, you must apply it to the checkout.
If customers request that a newly created source be saved to their account, wait until the source is chargeable. Then verify that it supports storage (supportsStorage) and is ready for storage (readyForStorage). After that, you can save the source to the customer before attaching the source to the checkout.
If the source is not scheduled for storage, once it's chargeable or pending_funds, you can attach the source to the checkout.
For more information on payments, refer to:
The Drop-in payments integration guide
The DigitalRiver.js quick start guide
The Building your payment workflows page
The Managing sources page
After you verify that the checkout’s payment session state is valid, activate a place order button on your order review page. Convert the checkout to an order to handle this button’s click event.
For more information, refer to the Processing orders page.
*The creditAmountparameter is only available in versions 2020-09-30, 2020-12-17, and 2021-02-23
Each time you submit a POST/checkouts or POST/checkouts/{id} request, use the data in the response to update the data in the upstream commerce platform. This ensures that the values in your system stay in sync with ours.
The response contains price, tax, landed cost, and fee information at both the checkout and line item levels. During the checkout process, display this information to customers in your UI.
Make sure you save the checkout's unique identifier and unique line item identifiers because they're required when submitting downstream requests. Additionally, the checkout contains payment session details that you use to create payment sources and determine when to submit an order request.
You can use the checkout's payment session identifier to create payment sources, authenticate saved payment sources, retrieve available payment methods, and validate tax identifiers.
In versions 2021-02-23 and lower, you find this identifier in the paymentSessionId attribute. In versions 2021-03-23 and higher, it's contained in payment.session.id.
This data is only returned in versions 2021-03-23 and higher.
Each time you access the , determine whether sellingEntity.id, language, and shipTo.address.country or billTo.address.country exist, and, if they do, use them to define compliance.entity, compliance.language, and compliance.country, respectively, in the element's configuration object and then pass that data to the create or update method.
If your integration only allows registered checkouts, you must prompt customers to sign in or create an account at some point during the checkout process. When customers create an account, use the Customers API to in Digital River’s system.
In registered checkouts, you can use the same API to and retrieve previously saved shipping information. To expedite the checkout process, you may present this saved shipping address to the customer as an available option.
You should present these quotes to customers and, once they make a selection, send an a that contains shippingChoice and shipFrom. We can then use this information to generate a more precise tax calculation.
At this stage of the checkout process, you'll need to collect payment information from the customer and use it to create or authenticate a .
The following lists some of the key parameters to use when defining checkouts. The table also indicates whether these parameters are available in and , and provides links to additional information on how to use these features. For comprehensive specifications, refer to the reference docs.
☨ In a request, you're restricted to modifying certain line item attributes.
To create a checkout, submit a request. Once you've created the object, and you want to update it, retrieve its unique identifier, and then pass it as a path parameter in a .
The following request creates a registered checkout that contains physical products and meets all of our address requirements.
Every checkout contains a unique identifier. You can use this identifier to , , , and the checkout. You can also use the identifier to attach a source to the checkout and then detach the payment source if the customer wants to apply a different payment method.
When you're ready to convert the checkout to an order, pass this identifier in the body of a .
Once you create a , Digital River assigns each of its items[] an id. During the checkout process, if you want to modify items you must send these identifiers in requests.
Depending on how you send product data in checkouts, each items[] also contains either the skuId or the productDetails object you sent in the request.
The id of an items[] in a is not the same as the id of the corresponding items[] in the associated .
contain a unique payment session identifier and other payment session information.
The payment.session contains an amountContributed, amountRemainingToBeContributed, and a state. You can use these values to determine when to create an order.
