I've been integrating Azure API Management with Paypal.
Here is the current flow
User goes to APIM portal and Signs In
Azure B2C flow is executed
On Auth Success the Delegation endpoint is executed to evaluate the APIM operation (SignIn, Subscribe, etc)
When the operation is Subscribe, redirect to the corresponding Paypal subscription link
Paypal flow is executed
Paypal return to the delegation endpoint configured in Paypals returnurl
So far so good, the issue I'm having is that the ony thing I have access to from paypal is the referer, which is like this
https://www.sandbox.paypal.com/webapps/billing/subscriptions?ba_token=[BA_TOKEN]&country.x=US&locale.x=en_US&mode=member&token=[TOKEN]
I'm lost on how I could use those tokens to identify which product the user subscribed to.
In step 4, store the subscription link or its ID before redirecting the user, as a pending checkout/order.
When they return, note any additional parameters in the return URL.
This should give you enough information to match the return event with the original subscription redirection and user.
For the best experience, change your flow to use no redirection at all.
See the modern "in-context" JS buttons solution here, which keeps your site loaded in the background: https://developer.paypal.com/docs/subscriptions/integrate/#4-create-a-subscription
(If you don't know what that means, click the PayPal button in this demo and note the window that opens; that's essentially the experience: https://developer.paypal.com/demo/checkout/#/pattern/client )
Related
I'm working on creating a REST API and one feature is to allow users to register. The general flow is the following:
The user specifies his email and password using the client application (SPA application) and presses the submit button.
A request to the API is made. The API adds the user to the database, generates a verification token and sends an email to the user.
The user verifies his email and clicks a confirmation link.
The API marks the user account as verified.
My question is regarding the confirmation link.
Should the link point to the client SPA application? In this case, the client application will make a POST request to the API with the verification token and the user email.
Also, how should the API know the link to the client application (the link needs to be added in the email and this is done by the API). Should the API store this link, or should the SPA client send the verification link to the API when sending the request to register the user?
Another approach would be for the link to go to an endpoint defined by the API. In this case a GET request will be made with the user email and verification token and the API will set the account as verified and inform the user that his account is now active.
I have read that this approach doesn't conform to the REST principles because a GET request should never change the state of a resource. In this case, the user resource will be modified.
I'm not sure which of the 2 solutions is better or if there is a better solution, so my question is what is the best approach?
Thanks!
Should the link point to the client SPA application?
If your 'Client SPA application' is the sole frontend for end-users, then yes: it should point there. Some people deploy a separate oauth2 / authentication server but that doesn't sound like it's the case here.
The client application will make a POST request to the API with the verification token and the user email.
The token should be enough. I'd avoid sending email addresses through urls.
Also, how should the API know the link to the client application (the link needs to be added in the email and this is done by the API). Should the API store this link, or should the SPA client send the verification link to the API when sending the request to register the user?
Both seem like really valid designs. If you want the API to be completely unaware of the front-end and support a multitude of frontends, it would make sense to me that the client sends their own endpoints. There is a security concern though, you don't want arbitrary clients to register arbitrary urls.
If you're just building a single frontend, I don't see a problem with the API knowing the activation url. It also sounds like it would be easy to change if your requirements change later.
I'm not sure which of the 2 solutions is better or if there is a better solution, so my question is what is the best approach?
Ultimately it doesn't really matter that much. Neither approach sounds like you're really painting yourself into a corner. Either you have a standard endpoint that uses a javascript HTTP request to activate a user, or you have a separate endpoint that redirects a user after activation. Both will work.
I'm using Stripe API(REST) and I need to put a link in email where user can directly unsubscribe/delete subscription(https://stripe.com/docs/billing/subscriptions/canceling-pausing).
I need to know if it is possible to put the arguments and operation in a URL so that when user clicks it, Stripe api is called and subscription is cancelled.
thanks in advance.
The short answer is NO.
Cancelling subscriptions from Stripe API requires your Secret Key which you should NEVER expose in the front end and made public because user will have access to your stripe account in that case.
Saying that, what you could do is to expose an endpoint in your own web server, which you will need to
1) create a on time use token which you can look up your customer and related subscriptions; include the token in your URL send to the user
2) when user click the the url, verify the token (valid non expired) and find the customer and subscriptions
3) Call stripe API with your secret keys to cancel the subscription for the customer.
I am a long paypal API user and am trying to use the new(er) REST API for my app. I have been pleased with the quality of the docs and API over our existing integration with paypal masspay, but I fear I have misunderstood the use of the REST API.
I have done at least a dozen other OAuth2 integrations with a lot of different services, and every one of them sets up a connection and gives us (the 3rd party app owner) a token, which lets us act on their behalf.
When I discovered the "My Apps" and REST API of paypal, saw it generated a client_id/secret, naturally I assumed I could create an app, and integrate it into my software, so that my clients can 'add' the app (initiating an oauth connection), and then I have a token that I can use to create payouts on their behalf. What led to the confusion, in retrospect, is that I was able to obtain a token, and then make SOME REST API calls (specifically, the identity calls, which give me info about my clients paypal account), but even if I added the following oauth scopes:
https://api.paypal.com/v1/payments/.* https://uri.paypal.com/payments/payouts
I am getting permission denied whenever I try to initiate a payout, or use any API other than the identity calls.
So after further digging, I am coming to the conclusion that the REST API, and the whole 'apps' thing is simply for writing apps for your OWN account (except for identity), NOT for allowing my app to act on behalf of a 3rd party, as has been the case for every other oauth integration I have ever done.
Does this sound correct? Am I missing something that lets me identify what merchant I am acting on behalf of?
I'd really like to move off the masspay API as its very clunky. Please help!
My app allows third party users to login via PayPal and to authorise it to collect UserInfo such as name and address. I now want to get permission to do a transaction list on their account using the token they provide.
I get 401 Not Authorized using the current tokens and OAuth won't accept 'https://api.paypal.com/v1/payments/.*' as a scope.
Calling api.paypal.com/v1/Payments on behalf of third parties isn't currently supported using the REST APIs.
You can only get payment info (and transaction info) for yourself.
In order to get Transaction data on behalf of third parties, you need to use the Classic APIs, first using the Permission Services to request access, then use the Merchant API Services to get transaction data.
Edit: Jan 6th, 2016
To make requests on behalf of third-parties, you need to use the Permissions Services API to request the proper scope.
As far as I can tell (from reading the documentation), you still cannot request 3rd party payment data using the REST api. You must use the Classic Name-Value Pair/SOAP api.
I'm developing web-service, where one users (companies) can receive payments directly from another (company's customers). Currently company need to enter its PayPal username, password and signature to receive payments via express checkout api. Is it normal, that users (companies in my case) will enter their PayPal credentials on remote site or it's secure information? I can't find any information about it. But i found, that some services work in the same way:
http://www.getharvest.com/help/invoices-and-estimates/online-payment-and-gateways/paypal-website-payments-pro
http://support.getresponse.com/faq/how-find-api-login-data-paypal
help.wildapricot.com/display/DOC/PayPal+Payments+Pro
Also i found another way for receiving direct payments - generate button (on the PayPal site or manually), where you need only PayPal email of seller. What the differences between these methods, its advantages and disadvantages?
Yes, they are considered private. Since it grants you access to all API operations, it can also be used to empty your PayPal account.
What I would recommend instead of collecting API credentials, is to use 'third-party permissions'.
This means initially requesting permission from the account holder via a pop-up dialog. Once granted, you'll receive an access token. This access token can then be included in the HTTP header of your API calls to make calls on behalf of the customer.
Your users can either manually grant permissions to you (they'll need to log into their PayPal account and navigate to the right section within their Profile), or, if you want to make it easier, you can implement the 'Permissions API'.
I would suggest taking a look at https://developer.paypal.com/webapps/developer/docs/classic/products/permissions/ for more information.
To get started, sign up for an 'application' with PayPal via https://apps.paypal.com/.
Ensure you request access to the Permissions Service and receive an Application ID.
This will be the AppID for the Live environment. For Sandbox, you can use APP-80W284485P519543T.