Subscription Contract Calculation rejects subscription-only discount

GraphQL Admin API Troubleshooting
1

We are testing SubscriptionContractCalculation API in our dev store but the coupon validation seems to be backwards.

Coupon with purchase type subscription works with subscriptionDraftDiscountCodeApply, but applying it through discountCodes.redeemCode in the SubscriptionContractCalculation API returns:

[{"code":"DISCOUNT_CODE_NOT_APPLIED","message":"<strong style="text-transform:uppercase">snowboard-15 discount code isn’t valid for the items in your cart"}]

Changing its purchase type to one-time purchase makes it apply in the new API.

For some reason it seems like that purchase-type eligibility is evaluated backwards.

query that doesn’t accept subscription coupons:
#graphql
mutation SubscriptionContractUpdateCalculate(
$contractId: ID!
$input: SubscriptionContractCalculationContractUpdateInput!
) {
subscriptionContractUpdateCalculate(
contractId: $contractId
contractUpdateInput: $input
) {
subscriptionContractCalculation {
... on SubscriptionContractCalculationPending {
id
}
}
userErrors {
field
message
}
}
}

old query that works:
#graphql
mutation SubscriptionDraftDiscountCodeApply($draftId: ID!, $redeemCode: String!) {
subscriptionDraftDiscountCodeApply(draftId: $draftId, redeemCode: $redeemCode) {
appliedDiscount {
id
redeemCode
rejectionReason
}
draft {
id
}
userErrors {
field
message
code
}
}
}
;

API version: unstable

2

Hi @Hannu_Jaakkola, I reproduced this on a test store. With a code restricted to subscription purchases, a calculation returns DISCOUNT_CODE_NOT_APPLIED with the same “isn’t valid for the items in your cart” warning, while a one-time-purchase code and a code set to both types apply on an identical setup. So your input isn’t the cause. The docs note that a line’s originSellingPlanId isn’t applied as a selling plan during calculation, so the purchase-type check appears to treat your lines as one-time purchases. That’s why subscription-only codes never apply.

Passing the code via discountCodes/redeemCode is the documented route in the migration guide, so you’re doing that part right.

There are two workarounds in the meantime. Set the code’s purchase type to both (the trade-off is it then also applies to one-time purchases at checkout), or apply the value through manualDiscounts instead of discountCodes.

I’ve raised this with the relevant team to confirm whether the behavior is intended and whether a change is planned. I’ll follow up here when I hear back - thanks for posting!