Documentation
Feedback
Guides
API Reference

Guides
Integration Guides
Tax Service
Specification

Below, we are going to go over tax service integration works, and if you want to know more about how to implement a client to connect your tax calculation provider to VTEX’s APIs, this recipe and example might help you.

How it works

In synchronous integration, VTEX’s Checkout API triggers and sends a request to the external tax service API whenever there are changes to a customer’s cart, such as adding or removing items.

Timeout for the request is five seconds. There is no retry in case of timeout. If the external service that responds to the request times out constantly, the store will not be able to finish the order. If this integration is active, it applies to all stores in that account.

Checkout Configuration

Synchronous tax integration can be activated or deactivated through a request to the Checkout Configuration API.

First, it is necessary to GET the current orderForm settings from this endpoint:

https://{accountName}.{environment}.com.br/api/checkout/pvt/configuration/orderForm

Then, Checkout settings can be updated via a POST call to the same endpoint. The full request body can be found in the Update orderForm configuration, as well as more details on that API. Here we will focus on the taxConfiguration object, which defines the External Tax Service settings:


_10
"taxConfiguration": {
_10
"url": "https://accountname.myvtex.com/tax-service/order-tax",
_10
"authorizationHeader": "99b9935b048dfd86893d0bf9gas628849",
_10
}

The most important data in this object is the url. This is the endpoint URL that the Checkout will query to receive the calculated taxes. In other words, this is the external API endpoint of the tax tool.

The authorizationHeader defines the value that the Checkout will use in the Authorization header of calls to the external tax calculation API. This field can be used to define the access credentials for this API.

Once the POST for the Checkout Configuration API has finished processing the request with this data, its synchronous integration with the Tax API is activated.

When a purchase is made in a store, the location from which the order is shipped matters for tax calculation purposes. Because of this, when items from White Label Sellers are part of an order, tax configuration for the marketplace (seller 1) is not taken into account for those items. Each seller must have its own tax service configuration in order for this type of integration function properly.

Tax calculation request

The tax calculation tool must provide an endpoint that will receive a POST request. In this request, Checkout provides a body in a specific format. This means that either the endpoint must be prepared to receive this body format, or the integration must contain a parser to adapt it to the correct format.

Let’s see an example of that body sent by Checkout:


_69
{
_69
"orderFormId": "e5098ad8c4jk490bb2f6f03400ac1413",
_69
"salesChannel": "1",
_69
"items": [
_69
{
_69
"id": "0",
_69
"sku": "26",
_69
"ean": "12345678909123",
_69
"refId": null,
_69
"unitMultiplier": 1,
_69
"measurementUnit": "un",
_69
"targetPrice": 8.2,
_69
"itemPrice": 8.2,
_69
"quantity": 1,
_69
"discountPrice": 0,
_69
"dockId": "1125a08",
_69
"freightPrice": 0,
_69
"brandId": "2000002"
_69
}
_69
],
_69
"totals": [
_69
{
_69
"id": "Items",
_69
"name": "Items Total",
_69
"value": 820
_69
},
_69
{
_69
"id": "Discounts",
_69
"name": "Discounts Total",
_69
"value": 0
_69
},
_69
{
_69
"id": "Shipping",
_69
"name": "Shipping Total",
_69
"value": 0
_69
},
_69
{
_69
"id": "Tax",
_69
"name": "Tax Total",
_69
"value": 0
_69
}
_69
],
_69
"clientEmail": "client@email.com",
_69
"shippingDestination": {
_69
"country": "BRA",
_69
"state": "RJ",
_69
"city": "Rio de Janeiro",
_69
"neighborhood": "Botafogo",
_69
"postalCode": "22250-905",
_69
"street": "Praia Botafogo"
_69
},
_69
"clientData": {
_69
"email": "client@email.com",
_69
"document": "12345678909",
_69
"corporateDocument": null,
_69
"stateInscription": null
_69
},
_69
"paymentData": {
_69
"payments": [
_69
{
_69
"paymentSystem": "2",
_69
"bin": null,
_69
"referenceValue": 820,
_69
"value": 820,
_69
"installments": null
_69
}
_69
]
_69
}
_69
}

This body has eight main fields:

FieldTypeDescription
orderFormIdstringOrder form ID.
salesChannelstringType of sales channel.
itemsarrayList of objects which are the order products, where dockId is a field that refers to its identification on the logistics system that contains information of its address.
totalsarrayTotal amount of the order form, divided into taxes, shipping, discounts, and the items themselves.
clientEmailstringClient's email address.
shippingDestinationobjectShipping information. Mandatory field.
clientDataobjectInformation regarding the client that placed the order.
paymentDataobjectContains an array of payments, where there is information regarding the payment methods, etc.

Tax provider response to the request

In response to the request sent by Checkout, we expect an array of products, each with its own array of taxes. See the example below:


_17
[
_17
{
_17
"id": "0",
_17
"taxes": [
_17
{
_17
"name": "TAX 1",
_17
"description": "",
_17
"value": 3.48
_17
},
_17
{
_17
"name": "TAX 2",
_17
"description": "",
_17
"value": 22
_17
}
_17
]
_17
}
_17
]

FieldTypeDescription
idstringRequest item index, which means the SKU's position on the items array sent by the request body.
taxesarrayList of all the taxes types for an SKU.
namestringTax name that will appear on the checkout.
descriptionstringInformative field, which does not appear on the storefront.
valuenumberAbsolute numeric value that will be added to the original price.

In the example above, the only item in the items array has a cost of 10, and, including the calculated taxes returned by the tax calculation tool, the total value would be 10 + 3.48 + 22 = 35.48.

If no taxes apply to the items in the order, the expected response is an empty array ([]).

For the Checkout API to understand the request body, the content-type must be set to application/vnd.vtex.checkout.minicart.v1+json.

Jurisdiction fields

If you use Avalara as your tax calculation provider, response bodies might also include the following fields, which refer to the different jurisdictions that may apply according to location.

FieldTypeDescription
jurisTypestringType of jurisdiction that applies to calculation.
jurisCodestringUnique code that identifies the appropriate jurisdiction.
jurisNamestringName of the jurisdiction that applies to the calculation.

These fields are also read by Checkout and added to the priceTag.

Below is an example for values that may be contained in these fields, and you can download all of the jurisdictions and respective codes used by Avalara here.


_10
{
_10
"jurisType": "State",
_10
"jurisCode": "20",
_10
"jurisName": "Kansas"
_10
}

Contributors
3
Photo of the contributor
Photo of the contributor
Photo of the contributor
+ 3 contributors
Was this helpful?
Yes
No
Suggest edits (Github)
Contributors
3
Photo of the contributor
Photo of the contributor
Photo of the contributor
+ 3 contributors
On this page