Add Recurring Billing/Subscription Support

[ruslantalpa]

Hi
Do you plan to support the "Recurring Billing" capabilities in GraphQL soon?
The reason I need this is because I would need (prefer) to write my integration in Lua, there is no sdk for it and no plain rest api so sending GraphQL queries over HTTP seems like the only option but then ... so support for subscriptions.

Thank you

[lkorth]

@ruslantalpa thanks for opening an issue. At this time we don't have any plans or a timeframe to add recurring billing to the GraphQL API.

I'll update the title of this issue and leave it open for others to vote on it and show interest so we can weigh it against other feature requests we receive.

[ronaldjeden]

yes please add recurring billing!!!!

[Dimitrileroux]

+1 would be great to query search transaction with subscription ID and query subscription as well! Looking forward to it :)

[techieshark]

+1. Lack of this is a showstopper for me, for using the GraphQL API.

[kbarkemeyer]

+1 Would love to use GraphQL for our integration once subscription search is added!

[heri16]

Any progress made?

[jono1024]

By not adding Recurring Payments to GraphQL feels like deja vu when the PayPal rest API was abandoned prior to completion resulting in the need to also perform old SOAP based calls for a complete solution and/or being told to migrate to the Braintree API. So now we are looking to migrate to this, Braintree are blowing their trumpet regards GraphQL - but its not complete, it doesn't support a feature we need so we are stuck with the rest API - where's the progress?

[lkorth]

@heri16 - not as of now, at this time we don't have any plans to add, nor a timeframe to add recurring billing to the GraphQL API.

@jono1024 - the GraphQL API is still very much under active development and in its early days, there are many things it still does not support and does not claim to be complete. The GraphQL API is Braintree's next generation API and will be in development for years to come. Because GraphQL has introspection, and on top of this we publish our schema and changelog in this repo, everyone can follow along with the progress of the API as it happens.

[mikulskibartosz]

+1 (or at least return the SubscriptionId assigned to the Transaction object)

[JackThePie]

+1 having SubscriptionId in Transaction would be great!

[uncvrd]

Would love to see support for subscription transactions in the GraphQL API!

[benka]

+1 this should be an absolute must for the GQL api

[yannlairdc]

The GraphQL API was launched more than 2 years ago now, how is recurring billing still not implemented?

The rest API is already terrible for recurring stuff (hello having to create plans and discounts manually cause you can only GET from the API -_-) and I had hope that GraphQL to solve some of those issues. Man, was I wrong!

[Jo-Pop]

At my organisation, we use Salesforce as our CRM. We would like to use GraphQL to perform the following functionality to integrate between Braintree and Salesforce as we want to update Credit Card RECURRING payments in Braintree from Salesforce in the following ways:

• Increase/decrease amount
• Change frequency
• Cancel recurring payment
• Add a recurring payment
• Skip a recurring payment
• Update card details on recurring payment

Will this ever be developed in GraphQL?

[ursuttam5]

For Salesforce it's a pain to develop server as there is no server sdk written in Apex. So with GraphQL API the server checkout and transaction process can be implemented from salesforce using Apex. But again plan and subscription creation are not supported from GraphQL so again from salesforce system it is not feasible to implement recurring billing (plan and subscription) scenarios. Please include plan and subscription creation in GraphQL API. By doing so braintree can become programming language independent implementation since every programming language supports rest web services. Without that GraphQL API is of no use

[kenwang-coursera]

Want to bump this convo, this is critical to our work flow and not having support for subscriptions is essentially a showstopper for us.

[alexandrutocar]

It was really disappointing to me, as i spent almost a week figuring out the GraphQL API just to end up here.

[beckyconning]

Whats the point of the GraphQL API if it doesn't have subscriptions in it? Why did you suggest using the GraphQL API when this has been an issue for years and still is not resolved. I'd rather not use the GraphQL API and use a normal API instead but this was your recommendation.

As @uceumice puts it:

It was really disappointing to me, as i spent almost a week figuring out the GraphQL API just to end up here.

[kenwang-coursera]

Hi team, are there any updates on this?

[fishygeek91]

Looking for updates.

I'm really surprised there is no functionality for this. We have a client written and working with the GraphQL API and have been asked to add what we thought was going to be a simple feature addition. Now I have to write a separate client to support subscriptions...

[alexandrutocar]

Maybe, as one more reason to get this implemented is the emergence of edge compute services such as Cloudflare, Vercel (Cloudflare Extension), Deno which, while allowing to polyfill some of the Node's APIs, are intended to be as light weight as possible. Here the Braintree's GraphQL API shines, because it basically allows users to use only needed functionality while keeping the bundle as small as possible.

But it's not all there is to the issue.

I personally could not find REST API's documentation to implement subscriptions. There is a heavy accent on using the official client library. But if I do, here come same problems of bundle size and hostile edge-environment which renders Braintree's client useless.

Subscriptions would make the experience complete.

Thank you in advance. 😄

P.S.: I feel like there is not much hope left, because it has already been 4 years. Still I know someone may occasionally stumble upon this issue and include it into the roadmap)

[jondruse]

Shocking that this hasn't been addressed. Regardless of any company's individual use case for this, it's a CORE ASPECT of the system. Also hilarious that this is literally issue #1.

I'd wager that we're in a stand-still here where the GraphQL API hasn't gained considerable adoption, so it's not a priority to finish the things that would help adoption.

IMHO the graphql api should be considered a WIP.