-
Notifications
You must be signed in to change notification settings - Fork 63
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
Comments
Issue-Label Bot is automatically applying the label Links: app homepage, dashboard and code for this bot. |
Hi @JasonTheAdams and @ravinderk, I recommend using query param 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. |
@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 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! |
@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. |
@gregjopa I am getting this error when reloading script. Do you have any thoughts? |
@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? |
@gregjopa I fixed the above error but now I am struggling with other errors. I am passing |
@ravinderk I'm glad you fixed the "zoid destroyed all components error". That's progress 😄
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 |
@gregjopa I am creating a product and plan on the server and then passing the plan id to |
@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. |
Thank you for confirming! We'll stand by for your post. 👍 |
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. |
@gregjopa I tested and it is working fine for me. |
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
orintent=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
andintent=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?
The text was updated successfully, but these errors were encountered: