Specify orders versus subscription when displaying Smart Buttons about paypal-sdk-client

[gregjopa]

@JasonTheAdams thanks for your feedback on this issue. We have received other complaints about the Developer Experience related to requiring a script reload when switching between certain products. Note that we are actively investigating solutions that would not require a reload. But in the mean time reloading the script is your only option for switching between orders and subscriptions.

Thanks again for the honest feedback and please continue to share how your implementation goes.

[issue-label-bot]

Issue-Label Bot is automatically applying the label feature_request to this issue, with a confidence of 0.84. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[gregjopa]

Hi @JasonTheAdams and @ravinderk, I recommend using query param vault=true for subscriptions only. I also recommend using intent=subscriptions but it isn't required. It will help differentiate your intent for subscription functionality vs future products coming out related to vaulting (remembering the user and their previously used funding instrument). The intent param will be used to differentiate between what type of vaulting you want to do.

I recommend sticking with the reloading approach when switching between orders and subscriptions. This will ensure that all eligible funding sources are shown to your buyers for each use case.

[JasonTheAdams]

@gregjopa We're playing around to see what we can do, but I want to see if I can help outline our issue — as it may very well be an issue for others using the SDK.

It seems that the SDK is built with the assumption that there will only be a single entity utilizing the SDK on a given page. I say this in contrast to the SDK encapsulating each Hosted Field and Smart Button instances. Perhaps this is due to the fact that vault or something like that requires a global context.

For us, since we allow multiple forms on a page, each form is considered its own unique instance. A user can have one form on a page that's subscription only, another that's one-time only, and yet another that allows the donor to choose. Presently, they do not interact or intersect in any way. Our Stripe integration, for example, has no opinion about what "sort" of fields the Stripe Element fields are, as it's not important until the moment of donation. This means that so long as each form tracks what kind of donation (single or recurring) it needs to process, the system works just fine.

Admittedly, this SDK is the first time (we integrate with around two dozen payment gateways) we've run into the issue where the donation type must be globally defined (as the script and its parameters are global). I do not mean that to dig on the great work of the SDK team, but to just give perspective as to why this poses a unique challenge for our integration.

Happy to provide any further context, and I'll report back with our findings as we test further.

Much appreciated!

[ravinderk]

@gregjopa I am getting this error when reloading script. Do you have any thoughts?

[gregjopa]

@ravinderk that error is thrown from zoid when it's initializing new components and fails to cleanup any existing components (https://github.com/krakenjs/zoid/blob/cf323bebe078a4f78b31795281d24d4cfec46b31/src/component/component.js#L294-L326). Usually this error is just informative and everything continues to work as expected. Can you share a code snippet that reproduces the error?

[ravinderk]

@gregjopa I fixed the above error but now I am struggling with other errors. I am passing intent=subscription&vault=true with SDK URL but still getting this error when creating a subscription.

[gregjopa]

@ravinderk I'm glad you fixed the "zoid destroyed all components error". That's progress 😄

Expected intent from order api call to be subscription, got capture. Please ensure you are passing intent-capture

For the above error, are you using the server-side integration with making an api call to createOrder? If so, you also need to pass this intent value with the api call as well. See this note from the docs: https://developer.paypal.com/docs/business/javascript-sdk/javascript-sdk-configuration/#intent

[ravinderk]

@gregjopa I am creating a product and plan on the server and then passing the plan id to actions.subscription.create as mentioned here: https://developer.paypal.com/docs/subscriptions/integrate/#create-the-subscription

[gregjopa]

Expected intent from order api call to be subscription, got capture. Please ensure you are passing intent-capture

@ravinderk I spoke with my team and this is a bug. Thanks for pointing this out. You should not be getting this error when using subscriptions. We are working on releasing a fix. I'll post back here after it's released.

[JasonTheAdams]

Thank you for confirming! We'll stand by for your post. 👍

[gregjopa]

Hi @JasonTheAdams and @ravinderk this bug has been fixed. I’m going to close this one out. Feel free to reopen if you’re still having issues with subscriptions.

[ravinderk]

@gregjopa I tested and it is working fine for me.