Happy Business Starts Here

Re: Preview subscription endpoint of the REST API returns different prices on subsequent calls

Valued Scholar

Preview subscription endpoint of the REST API returns different prices on subsequent calls

Hello.

 

We've been experiencing some weird behaviour with the endpoint to preview subscriptions in the REST API. By requesting the same preview multiple times in a row, the order of the invoice items returned as well as the prices they contain changes. On our side, this leads to the customer seeing a different price overview although the configuration (contact information, rate plans etc.) for a potential subscription didn't change.

 

Let me explain this issue a bit more in detail. The request we send looks like this:

 

{
	"termType": "TERMED",
	"contractEffectiveDate": "2017-02-17",
	"previewAccountInfo": {
		"currency": "GBP",
		"billCycleDay": "17",
		"billToContact": {
			"country": "United Kingdom",
			"taxRegion": 31464
		}
	},
	"initialTerm": 1,
	"subscribeToRatePlans": [{
		"productRatePlanId": "2c92c0f858199d2401582631f7fb5013"
	}, {
		"productRatePlanId": "2c92c0f857adf3ba0157afd6809f1a3f"
	}, {
		"productRatePlanId": "2c92c0f857b21b5c0157b9965f4727d1"
	}]
}

The configuration for the different rate plans can be found below.

 

  • 2c92c0f95819b30d0158263d878f51b3:
    • Charge Model: Flat Fee Pricing
    • List Price: 199.95 EUR / Billing Period
    • Trigger Condition: Upon Contract Effective
    • End Date: Align to Subscription End Date
    • Billing Period: Annual
    • Billing Timing: In Advance
    • Billing Day: Charge Trigger Day
    • Billing Period Alignment: Align to Charge
    • ----
    • Charge Model: Discount-Percentage
    • Discount Percentage: 20.00 %
    • Level: RatePlan
    • Trigger Condition: Upon Contract Effective
    • End Date: Align to Subscription End Date
    • Billing Period: Annual
    • Billing Day: Charge Trigger Day
    • Billing Period Alignment: Align to Charge

 

  • 2c92c0f857adf3ba0157afd6809f1a3f:
    • Charge Model: Discount-Percentage
    • Discount Percentage: 8.33333 %
    • Level: Subscription
    • Trigger Condition: Upon Contract Effective
    • End Date: Fixed Period after the Charge is triggered 1 Years
    • Billing Period: Annual
    • Billing Day: Charge Trigger Day
    • Billing Period Alignment: Align to Charge
  • 2c92c0f857b21b5c0157b9965f4727d1:
    • Charge Model: Discount-Percentage
    • Discount Percentage: 5.00 %
    • Level: Subscription
    • Trigger Condition: Upon Contract Effective
    • End Date: Fixed Period after the Charge is triggered 1 Months
    • Billing Period: Month
    • Billing Day: Default from Customer Account
    • Billing Period Alignment: Align to Charge

If this configuration is sent to the REST API multiple times in a row, we receive a different order and prices for the second and the third rate plan mentioned above. You can find the part of the response that looks different below.

 

...
{
    "serviceStartDate" : "2017-02-17",
    "serviceEndDate" : "2018-02-16",
    "chargeAmount" : -159.96,
    "chargeDescription" : "Free month discount to be used in the case of a annual subscription",
    "chargeName" : "Free month",
    "productName" : "Discounts",
    "productRatePlanChargeId" : "2c92c0f857adf3ba0157afd680ac1a41",
    "quantity" : 1.000000000,
    "unitOfMeasure" : ""
}, {
    "serviceStartDate" : "2017-02-17",
    "serviceEndDate" : "2018-02-16",
    "chargeAmount" : -87.98,
    "chargeDescription" : "",
    "chargeName" : "Voucher 5%",
    "productName" : "Discounts",
    "productRatePlanChargeId" : "2c92c0f857d113fd0157d1c10ecc0582",
    "quantity" : 1.000000000,
    "unitOfMeasure" : ""
}
...

...
{
    "serviceStartDate" : "2017-02-17",
    "serviceEndDate" : "2018-02-16",
    "chargeAmount" : -95.98,
    "chargeDescription" : "",
    "chargeName" : "Voucher 5%",
    "productName" : "Discounts",
    "productRatePlanChargeId" : "2c92c0f857d113fd0157d1c10ecc0582",
    "quantity" : 1.000000000,
    "unitOfMeasure" : ""
}, {
    "serviceStartDate" : "2017-02-17",
    "serviceEndDate" : "2018-02-16",
    "chargeAmount" : -151.96,
    "chargeDescription" : "Free month discount to be used in the case of a annual subscription",
    "chargeName" : "Free month",
    "productName" : "Discounts",
    "productRatePlanChargeId" : "2c92c0f857adf3ba0157afd680ac1a41",
    "quantity" : 1.000000000,
    "unitOfMeasure" : ""
}
...

Note that the order is reversed and also the prices differ for invoice items that have the same description in both examples. Surprisingly, the sum of the prices is the same in both cases, 95.98 + 151.96 = 247.94 and 159.96 + 87.98 = 247.94. Also, the summary and the total prices for the whole subscription preview do match in both cases.

 

 

Please note that this seems to happen pretty randomly. Sometimes, two or three calls in a row return the same response. But after a few more tries, we keep seeing the other response again. And yes, I'm sure we're sending the rate plans in the exact same order each and every time. Smiley Happy

 

The easiest way I found to reproduce this issue was to use curl on the command line. The command can be found below.

curl -X POST -H 'Content-Type: application/json' -H 'apiAccessKeyId: <<<YOURKEY>>' -H 'apiSecretAccessKey: <<<YOURSECRET>>>' -d '{"contractEffectiveDate":"2017-02-17","initialTerm":12,"termType":"TERMED","previewAccountInfo":{"billCycleDay":17,"billToContact":{"country":"United Kingdom","taxRegion":"31464"},"currency":"GBP"},"subscribeToRatePlans":[{"productRatePlanId":"2c92c0f858199d2401582631f7fb5013"},{"productRatePlanId":"2c92c0f857adf3ba0157afd6809f1a3f"},{"productRatePlanId":"2c92c0f857b21b5c0157b9965f4727d1"}]}' https://apisandbox-api.zuora.com/rest/v1/subscriptions/preview

 

Any insights on this topic are much appreciated. Thanks in advance.

Torsten

8 REPLIES 8
Guru

Re: Preview subscription endpoint of the REST API returns different prices on subsequent calls

I can't speak to the price difference, but I can tell you with the soap call the invoice items in the preview are not in any given order so you can't count on it.  Of course it would be useful to have them return in the same order they were in the request. I have had to resort to putting a unique identifier on my Charge Description in order to match up the responses I receive.

 

 

Maggie Longshore
Valued Scholar

Re: Preview subscription endpoint of the REST API returns different prices on subsequent calls

@MaggieL Hi, thanks for having a look. But first of all, this is a problem with the REST API, not with the SOAP API. Second, the actual order of the invoice items doesn't really matter to us, that's something that we could potentially fix on our side as well. The price difference is what actually concerns us.

Zuora Alumni

Re: Preview subscription endpoint of the REST API returns different prices on subsequent calls

Hello,

 

Can you please private message me your tenant id and api user id?

 

thanks,

 



If you found my answer helpful, please give me a kudo ↑
Help others find answers faster by accepting my post as a solution √

Valued Scholar

Re: Preview subscription endpoint of the REST API returns different prices on subsequent calls

@adam Any news regarding this topic? Thanks.

Zuora Alumni

Re: Preview subscription endpoint of the REST API returns different prices on subsequent calls

Hi @theinrich

 

sent you a reply!



If you found my answer helpful, please give me a kudo ↑
Help others find answers faster by accepting my post as a solution √

Master

Re: Preview subscription endpoint of the REST API returns different prices on subsequent calls

I'm pretty sure the Zuora REST API is actually, internally, just a wrapper around the SOAP API. I think I saw a way to specify the wsdl when using the REST API, but now I can't find it.

 

 

Highlighted
Savvy Scholar

Re: Preview subscription endpoint of the REST API returns different prices on subsequent calls

@theinrich how did you prevent the prices from changing?

Valued Scholar

Re: Preview subscription endpoint of the REST API returns different prices on subsequent calls

@Ben- This issue is not yet resolved, an internal ticket was created in the meantime to further investigate this issue. Once there's a final outcome, I will update this post.