[React/NodeJS] I'm having a huge struggle in finding the appropriate documentation on this topic -- I am looking to implement PayPal on my website, with the constraint being that the customer is charged after our offline service is completed (has variable costs, but there is something of a solution in mind such that if I can 'authorize' an amount equal to our maximum cost that we will be a-okay). My initial research indicated to me that PayPal Orders fulfill this desire, to at least an effective extent, ie. the order is placed and funds are not placed on hold until we authorize the charge, ideally after the offline service is completed (source: https://developer.paypal.com/docs/integration/direct/payments/orders/#order-response). Upon further inspection, I have discovered that the integration path using PayPal smart buttons is being heavily advocated in implementation docs and appear to be compatible with the orders API (source: https://developer.paypal.com/docs/checkout/).
I began working to implement the software, following the smart buttons implementation linked just prior, and followed the instruction to use server side api calls to process the payment (source: https://developer.paypal.com/docs/checkout/integrate/ and https://developer.paypal.com/docs/checkout/reference/server-integration/set-up-transaction/). Continuing forward, I pursued order creation explicitly using the orders API (mistake perhaps?) and used the docs for the v2 orders api and the docs for the nodeJs sdk package referenced in the paypal docs (paypal/checkout-server-sdk using the github docs). I set up the integration and the sandbox accounts showed that charges were being placed however, and this was contradictory to my desire to not place charges on hold until an authorization is completed. The status returned on the backend is kept at "created", so I was initially optimistic, but the charge placement was unfortunate.
I am struggling to find the next step. As the checkout-server-sdk is utilizing both payments/v2 and orders/v2 (source: https://www.npmjs.com/package/#paypal/checkout-server-sdk), I am lead to believe I can utilize those API endpoints as well, but can't find explicit functions that call the payments api in question in the checkout-server-sdk, which I believe I would need to change order intent in order to create an order (source: https://developer.paypal.com/docs/integration/direct/payments/orders/), but also noticed these docs (linked as active directly from the docs page for paypal I believe -- https://developer.paypal.com/docs/ ) post to payments/v1 (source: https://developer.paypal.com/docs/integration/direct/payments/orders/) which has been deprecated. Long story short, I am now lost and would thoroughly appreciate some guidance on where I walked astray, what docs to refer to, if this implementation is still supported, and potentially what the next step is. If I used incorrect verbiage or have some noticeable jump in logic that was to my detriment, I would love to know as I am fairly new to developer work as a whole. Thank you in advance!
Your use-case of not placing a temporary hold up front requires intent:order, and only the v1/orders API has this available. The v2/* APIs do not.
An intent:authorize hold typically clears from a card after about ~3 days (even though it is capturable up til day 29), so I would recommend using the v2 APIs if that's workable. But if it's important to not do that, then v1/orders can be used. The API is not going to disappear, people are using it. Even-yet-older Classic APIs with similar PAYMENTACTION=ORDER functionality are still in heavy use, after all.
Related
I am developing an eshop website based on Nuxt.js (Vue) for the frontend and Laravel for the backend.
I am at the stage where the payment is being done and thinking what my options are.
My payments provider offers two options: Redirect and Native.
The first option basically redirects the user from my spa to the payments provider page to fill in their card details and perform the transaction. Afterwards it redirects back to a predefined page. This option although it is really common (pretty much every company uses it) it also has the disadvantage that the spa loses its state.
The second option is to have a form inside my spa that sends the information to my api which finally performs the request to the payment provider and completes the transaction.
I believe the second option is the best in terms of ux but I am mostly writing this question to ask for your thoughts on this mostly related to law terms and security in general.
Note that I won't store any card details in the second case but even then, can this process be a bad thing for my company?
Quick disclosure: I'm new to stackoverflow and don't have the points to add comments.
Are you currently integrated with Braintree? The Drop-in UI is an excellent way to complete a transaction in a Single Page Application without worrying about page re-directs.
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact Braintree Support.
I'm working on an app that, as one component, accesses the imgur API. I'm trying to work out if it is considered "Commercial" based on three separate possible models. As you can understand, as the sole developer, I'm just a hobby programmer and I want to know if I can build this without a heavy monthly bill from imgur.
From the imgur API doc page;
Your application is commercial if you're making any money with it (which includes in-app advertising), if you plan on making any money with it, or if it belongs to a commercial organization.
What does that mean in these scenarios:
If I'm building an application that as a component of it uses the imgur API, that is not paid for, does not have any ongoing costs, but has a Patreon/GoFundMe/KoFi account attached to it to support development, is that considered "Commercial" here?
If I build the app, but charge a flat $5 for it, and no advertisement/in-app-purchases, is this considered commercial?
If I build the app, do not charge for it, do not post ads, but accept one-off donations towards developmnent, is this considered commercial as per the above?
If I'm building an application that as a component of it uses the
imgur API, that is not paid for, does not have any ongoing costs, but
has a Patreon/GoFundMe/KoFi account attached to it to support
development, is that considered "Commercial" here?
Possibly. Donations can very well be considered a source of income. In addition, you need to look at the second part of the Imgur ToS that you quoted:
plan on making any money with it, or if it belongs to a commercial
organization.
Will the app remain free forever after a limited period of development?
If I build the app,
but charge a flat $5 for it, and no advertisement/in-app-purchases, is
this considered commercial?
Yes, this can be considered commercial. Because you're charging money for the app.
If I build the app, do not charge for it,
do not post ads, but accept one-off donations towards developmnent, is
this considered commercial as per the above?
This is very similar to the first scenario.
The important thing to understand is that there is a great deal of latitude in enforcing the ToS. This is both to ensure the convenience of users, and also to ensure that Imgur's services aren't abused. One of the statements in their ToS states something to the effect of "Don't use us as your CDN". It would seem that is what you're thinking of doing. Unless your app is for a demonstrably social/charitable purpose like curing cancer or world hunger, Imgur might just as well choose to enforce the ToS. Don't risk it. Go for a paid service (Imgur's or another).
To be really sure, one can directly contact Imgur with a link to the app and check with them.
I am in the middle of the review process for Instagrams new API permissions. We have followed all of their guidelines and fall into one of their valid use cases. Unfortunately we have been denied now 3 times with the only explanation that we don't fall under a valid use case. I would be ok with this response if our software wasn't exactly what they say is a valid use case. So far I am unable to find anyway to contact them or talk about this issue. It would be a lot more helpful if we didn't get a blanket response when getting denied. Anyone else having these issues or have been able to contact their review team?
Perhaps this helps. I have tried two times but our app was declined. I will write the submission text one more time. I also want to go more into detail as the new FAQ says that Instagram expects a very detailed submision.
Cheers,
Christian
FAQ
My submission was rejected but it was a valid use case. What should I do?
A common reason for rejecting a submission is that we do not have enough information to make an assessment of your app. This can happen if your submission was too short, if it missed important information, if you did not provide a good screencast, your website is not working, etc. Before you submit for review again, make sure to provide a long and clear explanation of what your app does and how you use every permission. Make sure also to provide a video screencast and to follow all our Platform Policies.
What should I write in the submission?
The submission should be long enough for us to understand exactly what your app does and why you need the permissions you are asking for. If your submission is too short or does not explain all parts of your integration, then we may not be able to understand and approve your app. For example, your submission should explain what does your app or company do, which of the approved use cases your integration falls into, who will be using your app, how do your user authenticate with your app, how you use the API to power your integration, how does your product use the data acquired from Instagram, etc.
What should I show in the video screencast?
The video screencast is a very important part of a submission and cannot be omitted. Please make sure that the video clearly shows how your application works, including any Instagram login experience and the usage of every permission you are requesting. Since your app may still be in sandbox mode, you can use data from sandbox users to showcase the integration.
My company is working with multiple clients, should I submit one app per project?
No, we do not approve apps that are created for one-off projects (e.g. a hashtag campaign, an event, a website). You should use a single client_id across all your integrations.
Can I revoke a submission if I made a mistake?
You can't cancel a submission that is in progress. You will need to wait until the submission has been reviewed before you can start a new one.
I also have just been denied in the same way. I gave them 20minutes of video and demonstrated everything my app does. I wrote about each action possible in the context of use case 2 and I clearly stated which calls I was making. Short of supplying the source I am not sure what else to tell them.
I want to use categories to explore an area.
If I include a categoryId in a call to the explore endpoint, it seems to work! But, this isn’t documented (on an already-experimental API) so I’m not super comfortable using it.
Is there a reason categories aren’t officially supported on this endpoint?
Related, what differences should I see between an explore and a search in an area (with intent set to browse)?
The venues/explore endpoint is rapidly, so there will frequently be experimental, undocumented parameters showing up. This does also mean that the behavior of undocumented parameters could change at any time. While we try to avoid making changes that break existing users, please be aware that only documented behavior should be depended on.
Reading through the Flickr API documentation it keeps stating I require an API key to use their REST protocols. I am only building a photo viewer, gathering information available from Flickr's public photo feed (For instance, I am not planning on writing an upload script, where a API key would be required). Is there any added functionality I can get from getting a Key?
Update I answered the question below
To use the Flickr API you need to have an application key. We use this to track API usage.
Currently, commercial use of the API is allowed only with prior permission. Requests for API keys intended for commercial use are reviewed by staff. If your project is personal, artistic, free or otherwise non-commercial please don't request a commercial key. If your project is commercial, please provide sufficient detail to help us decide. Thanks!
http://www.flickr.com/services/api/misc.api_keys.html
We set up an account and got an API key. The answer to the question is, yes there is advanced functionality with an API key when creating something like a simple photo viewer. The flickr.photos.search command has many more features for reciving an rss feed of images than the Public photo feed, such as only retrieving new photos since the last feed request (via the min_upload_date attribute) or searching for "safe photos" only.
If you have a key, they can monitor your usage and make sure that everything is copacetic -- you are below request limit, etc. They can separate their stats on regular vs API usage. If they are having response time issues, they can make response a bit slower to API users in order to keep the main website responding quickly, etc.
Those are the benefits to them.
The benefits to you? If you just write a scraper, and it does something they don't like like hitting them too often, they'll block you unceremoniously for breaking their ToS.
If you only want to hit the thing a couple of times, you can get away without the Key. If you are writing a service that will hit their feed thousands of times, you want to give them the courtesy of following their rules.
Plus like Dave Webb said, the API is nicer. But that's in the eye of the beholder.
The Flickr API is very nice and easy to use and will be much easier than scraping the feed yourself.
Getting a key takes about 2 minutes - you fill in a form on the website and then email it to you.
Well, they say you need a key - you need a key, then :-) Exposing an API means you can pull data off the site way easier, it is understandable they want this under control. It is pretty much the same as with other API enabled sites.