Selling entities
Learn how Digital River dynamically assigns selling entities and how to use them in your integration
As the authorized reseller of your products and services, Digital River engages with multiple local selling entities. These entities allow us to support localized payment processing, payment methods, and fulfillments.
Selling entities help determine a transaction's eligible payment methods and payment processors. In addition, we use them to compute taxes and to decide whether tax identifiers and tax certificates are applicable to the transaction.
How Digital River assigns a selling entity mainly depends on whether a transaction's products are physical or digital, as well as its shipping or billing information.
You can use selling entities to configure front-end methods that display required disclosures and validate customer's data.

How Digital River assigns selling entities

During the checkout process, Digital River assigns a sellingEntity to the transaction.
Checkout
1
{
2
...
3
"sellingEntity": {
4
"id": "DR_IRELAND-ENTITY",
5
"name": "Digital River Ireland Ltd."
6
},
7
...
8
}
Copied!
For transactions that contain physical products, the sellingEntity we assign is based on the checkout's ship from and ship to addresses. If transactions only contain digital goods, Digital River uses the checkout's bill to address.
We also analyze your eligible entities. These are determined by your trading patterns and your contract with Digital River.
Depending on your needs, we can enable and configure specific eligible entities in your Digital River contract.

Transactions with physical products

In transactions that contain physical SKUs, the following explains the logic used by Digital River to make a selling entity determination.
In the table, Ship from represents a checkout-level or item-level shipFrom.address.country and Ship to represents a checkout's shipTo.address.country.
Digital River supports a limited number of ship from countries and there is no default value
For each record's Ship from country, an eligible destination country is listed in the Ship to column. An asterisk (*) represents a wildcard. When making an entity determination, Digital River first attempts to find an exact match. If an exact match can't be found, we use the wildcard to assign an appropriate entity.
For example, let's say your application is building a checkout to ship a physical product from Germany to the United States. Your contract specifies DRGT as an Eligible entity. Since no exact Ship from match exists, the wildcard is used to assign DR globalTech Inc. to the checkout's sellingEntity.name. In this same transaction, if DRGT were not one of your eligible entities, we would assign Digital River, Inc. to sellingEntity.name.
Ship from
Ship to
Eligible entity
sellingEntity.name
sellingEntity.id
*
US
*
Digital River, Inc.
DR_INC-ENTITY
*
US
DRGT
DR globalTech, Inc.
C5_INC-ENTITY
*
CA
DRGT
DR globalTech, Inc.
C5_INC-ENTITY
*
*
*
Digital River Ireland Ltd.
DR_IRELAND-ENTITY
*
GB
*
Digital River UK
DR_UK-ENTITY
*
IM
*
Digital River UK
DR_UK-ENTITY
GB
GB
*
Digital River UK
DR_UK-ENTITY
GB
IM
*
Digital River UK
DR_UK-ENTITY
JP
JP
DRJP
DR Japan
DR_JAPAN-ENTITY

Transactions with only digital goods

In transactions that only contain digital SKUs, the following explains the logic used by Digital River to make an entity determination.
In the table, Bill to represents a checkout's billTo.address.country. The asterisk (*) represents a wildcard. Digital River first attempts to find an exact match. If an exact match can't be found, we use the wildcard to assign an appropriate entity.
For example, let's say your application is building a checkout that only contains digital goods and the checkout's billTo.address.country is US. Your contract specifies DRGT as an Eligible entity. Since an exact match exists, we assign DR globalTech Inc. to the checkout's sellingEntity.name. In this same transaction, if DRGT were not one of your eligible entities, we would use the wildcard and assign Digital River, Inc. to sellingEntity.name.
Bill to
Eligible entity
sellingEntity.name
sellingEntity.id
US
*
Digital River, Inc.
DR_INC-ENTITY
US
DRGT
DR globalTech, Inc.
C5_INC-ENTITY
CA
DRGT
DR globalTech, Inc.
C5_INC-ENTITY
JP
DRJP
DR Japan
DR_JAPAN-ENTITY
JP
DRJPIC
DR Japan
DR_JAPAN-ENTITY
GB
*
Digital River UK
DR_UK-ENTITY
IM
*
Digital River UK
DR_UK-ENTITY
BR
DRBR
DR Brazil
DR_BRAZIL-ENTITY
*
*
Digital River Ireland Ltd.
DR_IRELAND-ENTITY

Multiple selling entity scenarios

A transaction can only be assigned a single selling entity. If you submit a POST/checkouts or POST/checkouts/{id} that results in a checkout with multiple items[] that can't be handled by a single selling entity, then a 400 Bad Request with a code of selling_entity_not_found is returned.

Using selling entities

Once Digital River assigns a selling entity, you can use the sellingEntity.id returned in the checkout to:
Last modified 7d ago