In the REST API, we were able to have merchants on both a monthly + usage-based payment into a single plan.
With GraphQL, these can only be done separately by:
Creating a subscription using appRecurringPricingDetails for the fixed monthly charge.
Separately, creating a usage charge with appUsagePricingDetails using a different mutation for handling usage-based pricing.
The problem comes in the transition. Looks like we have to make merchants approve a new subscription plan using appUsagePricingDetails
Is my understanding correct? Or do these merchants need to approve 2 new subscriptions (one for the monthly recurring, and one for the usage-based pricing)?
Ideally, the merchant would not have to do anything as we transition from Rest API to GraphQL. But looks like some action will be needed on their end
The problem comes in the transition. Looks like we have to make merchants approve a new subscription plan using appUsagePricingDetails
Is my understanding correct? Or do these merchants need to approve 2 new subscriptions (one for the monthly recurring, and one for the usage-based pricing)?
Are you referring to merchants that have already accepted a subscription via the REST API?
If so, no. You don’t need to have them accept a GraphQL version of their subscription in order to incur usage charges.
Just use the GraphQL createUsageRecord mutation with the line item ID for the usage component of their subscription.
You can retrieve their current subscription data from the GraphQL API as well to find the line item ID for the usage plan (not the flat monthly fee plan).
New Merchants
For new merchants you only need to make 1 GraphQL request to create a reoccurring + usage subscription.
The mutation accepts multiple line items, one for each plan type. So make sure to include both the reoccurring and usage plans in the creation of the Subscription Confirmation URL.
Yes, I am referring to merchants that have already accepted a subscription via the REST API
Thank you for your solution! We’ll try it and post an update here.
We no longer offer this combined approach for new merchants, so it’s only grandfathering in the merchants that had this payment model under our Rest API implementation