Hi Shopify Community & Team,
I’m working with the Admin GraphQL API, specifically the draftOrderCalculate mutation (using the latest API version).
The Issue:
When calculating a draft order for a customer in a different currency than the shop’s base currency (e.g., customer using EUR, shop base is HUF, using Shopify Markets), the calculatedDraftOrder.availableShippingRates field only returns the shipping prices in the shop’s currency.
The availableShippingRates.price field is of type MoneyV2, which only contains the amount and currencyCode corresponding to the shop’s currency (shopMoney).
This contrasts with other price fields in the same response, such as subtotalPriceSet, totalPriceSet, totalShippingPriceSet etc., which are of type MoneyBag and correctly include both shopMoney and presentmentMoney (the customer’s currency).
Example GraphQL Query Structure:
`GraphQLmutation draftOrderCalculate($input: DraftOrderInput!) {
draftOrderCalculate(input: $input) {
calculatedDraftOrder {
# Correctly includes presentmentMoney
subtotalPriceSet {
shopMoney { amount currencyCode }
presentmentMoney { amount currencyCode }
}
totalPriceSet {
shopMoney { amount currencyCode }
presentmentMoney { amount currencyCode }
}
# PROBLEM AREA: Only returns shopMoney via MoneyV2
availableShippingRates {
handle
title
price { # This is MoneyV2, only shop currency
amount
currencyCode
}
}
# If a shipping line IS selected, it correctly shows presentmentMoney
shippingLine {
originalPriceSet {
shopMoney { amount currencyCode }
presentmentMoney { amount currencyCode }
}
}
# ... other fields
}
userErrors {
field
message
}
}
}
`
Use Case & Impact:
When building custom checkout experiences or backend tools that create draft orders (especially for international customers), it’s crucial to display the available shipping options with prices in the customer’s currency before they make a selection. Currently, we only get the prices in the shop’s base currency (e.g., HUF), which leads to a confusing user experience for customers expecting to see prices in their own currency (e.g., EUR).
While the selected shippingLine.originalPriceSet does return presentmentMoney correctly later, this doesn’t help when presenting the initial list of available options.
We’ve considered workarounds like calculating an implicit exchange rate from other MoneyBag fields in the response (e.g., subtotalPriceSet) and applying it manually to the HUF shipping rates. However, this feels like a hack, is prone to potential rounding discrepancies, and isn’t officially supported.
Expected Behavior:
Ideally, the availableShippingRates.price field should be of type MoneyBag (or have an equivalent field added) to include presentmentMoney, consistent with other price representations in the API response.
Question:
Is this a known limitation? Are there any official workarounds recommended? Could this be considered a bug or a feature request for improvement in future API versions?
Providing presentmentMoney directly for availableShippingRates would greatly improve the developer and user experience for multi-currency scenarios.
Thanks for your time and any insights you can provide!