Checking out guest and registered customers
Learn how to create guest and registered checkouts
Last updated
Learn how to create guest and registered checkouts
Last updated
A checkout's customerId references the customer making the purchase. You can pass this identifier in both create and update checkout requests.
For more information, refer to sequencing the checkout process on the Building checkouts page.
If you want to process a guest checkout, then don't set customerId. Conversely, if you want to process a registered checkout, then you should set customerId.
If you don't set a checkout's customerId, then no customer is associated with the purchase. So, when you want to checkout a guest, don't send customerId in the body of a POST/checkouts or POST/checkouts/{id} request.
In guest checkout scenarios, you'll need to acquire a customer's shipping address (assuming the cart contains physical products), billing address and email address. In addition, you must create one or more payment sources, and, when required, you'll also need to create a tax identifier.
Once you obtain these addresses and create these resources, you must associate their data with the checkout.
| Guest customer | Checkout | |
|---|---|---|
For more information refer to:
Address requirements on the Providing address information page
Creating sources and attaching sources to checkouts on the Managing sources page
When checking out a registered customer, make sure you send customerId in the body of a POST/checkouts or POST/checkouts/{id} request. This associates the referenced customer with the checkout.
When developing registered checkout flows, you should be aware of (1) what attributes customers and checkouts have in common and (2) how customer data can be passed to the checkout.
Customers and checkouts have some common attributes. In registered checkouts, the following data in a customer can be passed to a checkout. The options that exist for passing this customer data to checkouts are version dependent.
For more information refer to:
Address requirements on the Providing address information page
The Tax identifiers page
In registered checkouts, the Digital River APIs version you're using determines how customer data can be passed to checkouts:
2021-12-13 and laterIn versions 2021-12-13 and later, when you associate a customer with a checkout, Digital River doesn't, by default, pass that customer's data to the checkout. In other words, undefined common attributes in a checkout are not populated with the customer's data.
Instead, once registered customers have signed on to your site and you've obtained their unique identifier, you can make a GET/customers/{id} request to retrieve their shipping address, saved payment sources, billing addresses associated with those sources, tax identifiers, and other personal information.
At each stage of the checkout process, you can present this saved information to customers as an available option. Whether customers select the saved option presented to them or they use your site's forms to enter new information, you must pass this data to the checkout.
For example, when obtaining a ship to address in a checkout that contains physical products, you can get the customer's shipping, display it as an available option, and ask customers whether they want to use this saved address. Regardless of whether customers select the saved address or enter a new address, you must set the checkout's shipTo.
2021-03-23 and earlierIn versions 2021-03-23 and earlier, when you associate a customer with a checkout, Digital River by default passes the customer's data to the checkout. In other words, any undefined common attribute in the checkout is automatically inherited from the associated customer.
The only exception is taxIdentifiers[]. Unless applicable to the transaction, we don't pass any of a customer's taxIdentifiers[] to the checkout. For more information, refer to using tax identifiers in registered checkouts on the Tax identifiers page.
Data you set in the checkout takes precedence over inherited customer data. Additionally, any data inherited by default from the customer can always be overwritten in subsequent update checkout requests.
For example, the following create checkout request contains a customerId but doesn't specify email, shipTo, billTo, locale, customerType, taxIdentifiers[] or sourceId.
Once you submit this request, Digital River determines what common attributes, if any, are undefined in the checkout, whether the associated customer contains any of these undefined attributes, and, if it does, retrieves that data and sends it to the checkout.
In this particular example, Digital River uses the customer's email, shipping, defaultSourceId, locale, and type to set the corresponding checkout attributes. Note that the owner.address, owner.firstName, owner.lastName, and owner.email in the customer's default payment source are used to populate the checkout's billTo.
| Customer | Checkout | |
|---|---|---|
Shipping details
➔
shipTo
Billing details
➔
billTo
Email address
➔
email
Tax identifiers
➔
taxIdentifiers[]
Business or individual?
➔
type
Payment method(s)
➔
payment.sources[]
shipping
➔
shipTo
sources[].owner
➔
billTo
sources[]
➔
payment.sources[]
taxIdentifiers[]
➔
taxIdentifiers[]
locale
➔
locale
email
➔
email
customerType
➔
type