Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify orders versus subscription when displaying Smart Buttons #46

Closed
JasonTheAdams opened this issue Sep 28, 2020 · 13 comments
Closed

Comments

@JasonTheAdams
Copy link

JasonTheAdams commented Sep 28, 2020

I wanted to expand on #44 (comment) — I believe that issue is resolved, but we have another need I want to clearly spell out.

Our product, GiveWP, provides our customers with the ability to create a donation form on their website. The form can be displayed either as the page is loaded, or in a modal once a button is clicked, or some other way. This creates the common scenario where a page will have more than one donation form displayed at a time.

Right now, the SDK seems to be built around as a global, wherein the SDK applies to the whole document. This is especially evident as the intent=order or intent=subscription is defined as a parameter of the script. In #44 we were given the ability to change between orders and subscriptions by reloading the script, but this isn't a perfect solution in the context of multiple forms potentially being in separate states (i.e. one in single donations, the other in recurring).

As @ravinderk found, we're able to process Orders and Subscriptions by setting vault=true and intent=order, however we get a warning when the Subscription is processed. Is this something stable we can continue to do? Or will it likely break at some point?

In our perfect world, we wouldn't need to globally set whether we intend to process orders or subscriptions, but handle it on a per Smart Buttons and per Hosted Fields basis. Does this make sense?

@issue-label-bot
Copy link

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
Copy link
Contributor

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
Copy link
Author

@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!

@gregjopa
Copy link
Contributor

gregjopa commented Oct 1, 2020

@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.

@ravinderk
Copy link

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

image

@gregjopa
Copy link
Contributor

gregjopa commented Oct 2, 2020

@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
Copy link

@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.

image

@gregjopa
Copy link
Contributor

gregjopa commented Oct 2, 2020

@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

Screen Shot 2020-10-02 at 1 20 26 PM

@ravinderk
Copy link

@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
Copy link
Contributor

gregjopa commented Oct 5, 2020

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
Copy link
Author

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

@gregjopa
Copy link
Contributor

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants