Have your say in Community Polls: What was/is your greatest motivation to start your own business?
Our Partner & Developer boards on the community are moving to a brand new home: the .dev community forums! While you can still access past discussions here, for all your future app and storefront building questions, head over to the new forums.

Terms in a reccurrent application charges are not displayed if capped_amout is not set

Solved

Terms in a reccurrent application charges are not displayed if capped_amout is not set

dfioravanti
Shopify Partner
3 0 0

Hey everyone, I am not 100% sure if it is a bug or if it is expected behavior. If I create a RAC (ReccurrentApplicationCharge) where I set both the capped_amount and terms fields, then when the merchant is displayed the page where they need to accept the RAC it shows them the terms. Similarly when they accept the RAC the email contains the terms. But if I do not set the capped_amount neither the acceptance page nor the email contains the terms. Is this a bug with shopify ? The REST API documentation implies that not setting the capped amount is possible, but no where it says that doing that removes the terms. Anyone as an idea of what is going on?
 
Thanks

Accepted Solution (1)
lizk
Shopify Staff
246 58 78

This is an accepted solution.

Hi there 👋

You are right, this could be clearer. I will try to get this documentation updated.

You are right that you don't have to set a capped amount when using `RecurringApplicationCharge`. You can charge a set rate each month, and not have a usage component.

This sentence in the REST documentation touches on the fact that both capped amount and terms are required properties when you want your recurring application charge to also include usage fees. 

You need to include the capped_amount and terms properties in the body of your request when you create a recurring application charge with a price of $0.00.

You can also check the GraphQL documentation for creating usage billing plans, which does show explicitly that both fields are required. 

Sorry about the confusion this has caused you, and I will look to get that documentation updated.


To learn more visit the Shopify Help Center or the Community Blog.

View solution in original post

Replies 4 (4)

lizk
Shopify Staff
246 58 78

Hi 👋

If you want to make a usage billing plan you must include capped amount and terms. We have a bit more context on this in our developer docs here

To learn more visit the Shopify Help Center or the Community Blog.

dfioravanti
Shopify Partner
3 0 0

Thanks for the reply. But the docs say

 

"You can use the RecurringApplicationCharge resource to specify a capped amount that applies to usage-based billing."

 

There  is no indication whatsoever that  a capped amount is mandatory. So is it or is it not? Because I can create a usage charge without the capped amount. But the terms are not showed which less than ideal

lizk
Shopify Staff
246 58 78

This is an accepted solution.

Hi there 👋

You are right, this could be clearer. I will try to get this documentation updated.

You are right that you don't have to set a capped amount when using `RecurringApplicationCharge`. You can charge a set rate each month, and not have a usage component.

This sentence in the REST documentation touches on the fact that both capped amount and terms are required properties when you want your recurring application charge to also include usage fees. 

You need to include the capped_amount and terms properties in the body of your request when you create a recurring application charge with a price of $0.00.

You can also check the GraphQL documentation for creating usage billing plans, which does show explicitly that both fields are required. 

Sorry about the confusion this has caused you, and I will look to get that documentation updated.


To learn more visit the Shopify Help Center or the Community Blog.

dfioravanti
Shopify Partner
3 0 0

Ok thanks, but just as FYI, I can create a RecurringApplicationCharge with only terms but not cappend amout. It just swallows the terms and it does not return an error. It would be helpful if the rest interface would return an error instead of just swallowing part of the request