Providing address information
Learn how to provide billing, shipping and email address-related information.
Last updated
Learn how to provide billing, shipping and email address-related information.
Last updated
You can use and to provide , , and address-related information. During , we use this information to select the correct , determine whether are applicable, , and .
Except in , we don't perform real-time address validation. Instead, we expect you to validate the customer's address before sending it to us.
When , you must carefully consider the . Fulfilling specific is essential before successfully .
For that contain , we recommend you send a customer's and in the .
We suggest this sequencing because, the shipping address takes the highest priority in our tax computation process, followed by the billing address, and then, finally, the . If we generate a tax estimate based on the checkout's , and then update that estimate using a you provide in a request, you could receive the following error when you :
For transactions that contain only , we recommend that you first collect the customer's current billing information and use it to set the checkout's . In a subsequent , you can .
Since no is required for digital-only transactions, this sequence ensures accurate tax estimates and reduces the frequency of order failures. If you don't first send billTo
, an outdated billing address on the may result in an inaccurate tax estimate when you attach the source to the checkout.
In both POST /checkouts
and POST /checkouts/{id}
requests, the first-class email
parameter is technically optional.
Second, if your goods are shipping from the United States, then some additional shipFrom.address
requirements must be met before Digital River’s tax service calculates the taxes.
Specifically, if country
is US
, then:
A postalCode
is required and must, at a minimum, consist of five digits, all of which must be valid for a particular region or address in the United States. For example, a postalCode
of 99999
, because it doesn't map to any actual location, won’t result in a tax calculation getting returned.
A state
is not required, but if you do define this parameter, then postalCode
needs to be valid for that particular state
. For example, if postalCode
is 10001
and state
is MN
, our tax service won’t perform a calculation because the first digit of all zip codes in Minnesota is 5.
With any of these countries, an improperly formatted ship to or bill to postalCode
in a POST /checkouts
or POST /checkouts/{id}
returns the following error:
For a list of acceptable state
values, refer to:
Once the following POST /checkouts
request is submitted, the second element in the items
array will inherit the checkout-level shipFrom
value.
Additionally, any shipFrom
values set at the item-level take priority over the checkout-level shipFrom
.
The shipTo
and shipping
hash tables also contain other child parameters that allow you to send the customer's name
, phone
, email
, and organization
.
You can also use billTo
to send non-address related information, such as the customer's name
, phone
, email
, and organization
.
An Address
represents basic address information. The following table describes each parameter:
line1
The first line of the address
line2
The second line of the address.
postalCode
The postal code. For United States addresses, Digital River supports ZIP+4 codes. They consist of the last four digits of a full nine-digit ZIP code. A nine-digit ZIP Code has two parts: the initial five digits of the zip code indicating the destination post office or delivery area and the last four digits representing a specific delivery route within that overall delivery area.
city
The city of the address
state
country
Brazilian addresses require a neighborhood
for an order to be successfully created. The following example shows how to specify this value for an address in Brazil.
For Japanese addresses, customers can provide their division within their organization (for example, the sales department). Additionally, customers can enter their names in two scripting styles: Hiragana and Katakana. Hiragana is the traditional script, while Katakana is the phonetic spelling. Customer and courier services often want the phonetic spelling so they can correctly pronounce the customer's name when making a delivery. Katakana is also used by foreigners living in the country who don't have a Japanese name.
Use the phoneticName
and division
child attributes of additionalAddressInfo
to provide this information:
State codes in addresses are essential for identifying specific regions within a country. For example, a unique two-letter code represents each state, territory, and federal district in the United States. These codes are used in shipping, billing, and other applications to ensure precise and efficient data handling. Understanding and using these standardized codes helps avoid errors, streamline processes, and facilitate communication across different systems.
AK
Alaska
AL
Alabama
AR
Arkansas
AZ
Arizona
CA
California
CO
Colorado
CT
Connecticut
DE
Delaware
FL
Florida
GA
Georgia
HI
Hawaii
IA
Iowa
ID
Idaho
IL
Illinois
IN
Indiana
KS
Kansas
KY
Kentucky
LA
Louisiana
MA
Massachusetts
MD
Maryland
ME
Maine
MI
Michigan
MN
Minnesota
MO
Missouri
MS
Mississippi
MT
Montana
NC
North Carolina
ND
North Dakota
NE
Nebraska
NH
New Hampshire
NJ
New Jersey
NM
New Mexico
NV
Nevada
NY
New York
OH
Ohio
OK
Oklahoma
OR
Oregon
PA
Pennsylvania
RI
Rhode Island
SD
South Dakota
SC
South Carolina
TN
Tennessee
TX
Texas
UT
Utah
VA
Virginia
VT
Vermont
WA
Washington
WI
Wisconsin
WV
West Virginia
WY
Wyoming
DC
District of Columbia
AS
American Samoa
FM
Federated States Of Micronesia
GU
Guam
MH
Marshall Islands
MP
Northern Mariana Islands
PR
Puerto Rico
PW
Palau
VI
U.S. Virgin Islands
AE
Armed Forces
AP
Armed Forces Pacific
AA
Armed Forces America
AC
Acre
AL
Alagoas
AP
Amapá
AM
Amazonas
BA
Bahia
CE
Ceará
DF
Distrito Federal
ES
EspÃrito Santo
GO
Goiás
MA
Maranhão
MT
Mato Grosso
MS
Mato Grosso do Sul
MG
Minas Gerais
PR
Paraná
PB
ParaÃba
PA
Pará
PE
Pernambuco
PI
PiauÃ
RN
Rio Grande do Norte
RS
Rio Grande do Sul
RJ
Rio de Janeiro
RO
Rondônia
RR
Roraima
SC
Santa Catarina
SE
Sergipe
SP
São Paulo
TO
Tocantins
AB
Alberta
BC
British Columbia
MB
Manitoba
NB
New Brunswick
NL
Newfoundland and Labrador
NS
Nova Scotia
ON
Ontario
PE
Prince Edward Island
QC
Quebec
SK
Saskatchewan
NT
Northwest Territories
NU
Nunavut
YT
Yukon
AN
Andaman and Nicobar Islands
AP
Andhra Pradesh
AR
Arunachal Pradesh
AS
Assam
BR
Bihar
CH
Chandigarh
CG
Chhattīsgarh
DH
Dadra and Nagar Haveli and Daman and Diu
DL
Delhi
GA
Goa
GJ
Gujarat
HR
Haryana
HP
Himachal Pradesh
JK
Jammu and Kashmir
JH
Jharkhand
KA
Karnataka
KL
Kerala
LA
Ladakh
LD
Lakshadweep
MP
Madhya Pradesh
MH
Maharashtra
MN
Manipur
ML
Meghalaya
MZ
Mizoram
NL
Nagaland
OD
Odisha
PY
Puducherry
PB
Punjab
RJ
Rajasthan
SK
Sikkim
TN
Tamil Nadu
TS
Telangana
TR
Tripura
UP
Uttar Pradesh
UK
Uttarakhand
WB
West Bengal
Every that you create . We also .
If a only contains , you're not required to provide either or . However, when that contains , you as well as .
Additionally, we in where products are being shipped or billed to specific countries.
In , unless you're using 2021-03-23
or earlier of the Digital River APIs, we do not use the associated email
, shipping
, and owner
values to populate undefined email
, shipTo
, and billTo
attributes in the .
However, when you , the checkout must contain a properly formatted email
. If it doesn't, the POST /orders
returns a 400 Bad Request
:
Every needs to contain the customer's billing address. So, before you , its must be populated.
More specifically, the billTo
must contain line1
, city
, country
, postalCode
, and name
. If it doesn't, you will receive either a 400 Bad Request
that identifies which parameter is missing or a 409 Conflict
that contains a more general message.
If a contains a , you can fulfill its billTo
requirements by passing the customer's billing address using the . If you set up your integration this way, we use the source's to set the checkout's billTo
.
When you , the billing address information associated with the primary source takes higher priority.
If you only attach to a checkout, you have two options to meet our billing address requirements. You can specify owner
in the . Or you can create the secondary source without owner
and set the checkout's billTo
. If you attach multiple secondary sources to a checkout, and each source contains owner
, we use the last source attached to populate the checkout's billTo
.
that contain must meet certain requirements.
First, they need to have a shipFrom.address.country
. If you don't provide this data when and then , a 400 Bad Request
is returned.
Checkouts that contain must have a name
, line1
, city
, postalCode,
and country
in . This is true for all shipping destinations. Additionally, when physical goods are being shipped to destinations within the United States or Canada, you must provide a state
.
When the , you should also set the shipTo.organization
. This ensures that the company's name is displayed on .
In checkouts that contain , if any of the following values are missing, a or request returns a 400 Bad Request
:
A missing name
returns a similar 400 Bad Request
when you .
When products are shipped and billed to certain countries, a checkout's and must contain and data that adheres to a standardized format.
Digital River uses the same address schemas the returned when performing these postal codes and state/province validations.
Digital River validates the format of postalCode
using a regular expression. You can use the regular expressions to validate customer-submitted postal codes on your front-end before invoking , , createDropIn()
or .
The same error is returned if you with an invalid postal code and then .
If the checkout's and/or country
is either US
(United States of America), BR
(Brazil), CA
(Canada), or IN
(India) and state
is not a 2-letter ISO state/province code value (see , , or ) or 2-letter province code (), then the following error is returned:
The checkout's shipFrom
defines the address from which a physical product is shipped. It consists of child attributes address
and additionalAddressInfo
. Use address
to provide on the shipment's origin and additionalAddressInfo
to give us more .
The shipFrom
parameter can be set at either the or the . This allows you to build an order containing items that ship from different addresses in different countries.
Your request, however, cannot contain a combination of shipFrom
addresses that result in to the transaction.
The checkout-level shipFrom
is mapped to any that but don't have a shipFrom
value.
If you don't set the checkout-level shipFrom
, and one or more physical line items don't specify a shipFrom
, you can successfully create a checkout. In this case, though, returns the following 400 Bad Request
:
By specifying shipFrom
at the item-level, you can containing that ship from different countries. A shipFrom
is not required at the line item-level unless no shipFrom
is provided at the .
When an order contains , you're .
In , unless you're using version 2021-03-23
or earlier of the Digital River APIs, we do not use the associated shipping
values to populate the shipTo
.
You should use address
to provide on the shipment's destination and additionalAddressInfo
to give us more .
The billTo
hash table contains child parameters address
and additionalAddressInfo
. You can use address
to provide on the customer's billing address and additionalAddressInfo
to give us more .
In most scenarios, the billTo
parameter is optional. However, we enforce if you only apply to a transaction.
When , you can use billTo
to obtain an accurate tax calculation before attaching a payment source to the checkout. This is especially useful in transactions that only contain . In these transactions, is typically not sent in the request. Therefore, Digital River needs billTo
to generate a tax estimate.
Once you or , the response from the API includes billTo
. This represents the billing address we used for tax computation purposes. Having this information allows you to know precisely what billing address information was used when calculating taxes. It also allows your integration to more easily retrieve any billing information that you might need to send in an email or other form of customer communications.
The , county, province, or region.
A two-letter as described in the international standard.
You can use the resource to retrieve for many countries. These schemas define the required address parameters and provide regular expressions to validate postal code formats.
Use additionalAddressInfo
to capture any information that's not included in the basic address
. This is especially useful for and .
In , use the following codes as the state
values for the and addresses to represent states, territories, APO/FPO military addresses, and the District of Columbia. See for more information on US state codes.
In , use the following codes as the state
values for the and addresses to represent Brazilian states and the federal district. See for more information on Brazilian state codes.
In , use the following codes as the state
values for the and addresses to represent Canadian provinces and territories. See for more information on Canadian state codes.
In , use the following codes as the state
values for the and addresses to represent Indian states. See for more information on Indian state codes.