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.
Related
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 )
I'm using JWT authentication on my REST endpoints, but once you make an account you can opt to purchase a subscription.
However, the purchase endpoint is a POST to /subscribe/new and if anyone gets the jwt from session storage, they can pretty much make CURL request to the endpoint and purchase a subscription.
Is this how it is supposed to work? How do I stop someone from just doing CURL to purchase a subscription? Obviously they need to supply additional information in the body like their payment details and stuff, but if they do that then it will go through provided they have the token.
So if a bad person gets that JWT somehow from the user's session storage, they can pretty much wreak havoc right?
You simply can't avoid that someone post a request to your endpoint. See https://security.stackexchange.com/questions/42586/ensure-web-service-only-accessed-by-authorized-applications
So assume it can happen and if it is a risk for you, be prepared:
do not authorize access to the service with this JWT
use an additional authentication factor for restricted operation:a password, an SMS, etc.
request the needed data and validate it before authorize access: for example the credit card number
Our application uses oauth2 & openid connect for auth&auth. It's built using an angular client that calls a REST API. I would like to know how to authorize access to the API, based on the possession of an unguessable url.
I'll explain this a little more. In the application, a user can invite another user. When this happens, an email is sent to the second user. When user 2 clicks a link in the email, he is sent to a webpage with details about the invitation.
Only user 2 should be allowed to see the invitation page. I was planning to solve this by using an 'unguessable url' in the email. Upon visiting the url, the user must somehow be authorized to fetch the invitation details from the API.
The question: how do I authorize a user, based on knowing the unguessable url? How do I assign a claim when the page is loaded, and how do I verify this claim in the API call that follows? The only solution I see, is to set a cookie containing a token. But this is not in line with our existing auth mechanism. I prefer not writing my own token validation code, and let the Identity Provider handle this.
Additional info: user 2 may or may not have an account in the system, and he may or may not be logged in. Neither should prevent the user from seeing the invitation details. In other words: a totally unknown user should be able to see the page. The knowledge of the url should be the only requirement.
Any solution to this problem? Or am I handling it all wrong?
After asking around, the general consensus is to NOT let the external auth mechanism take care of this, but to validate the link ourselves.
The solution is to turn the unguessable part of the url (the 'link id') in some kind of token, which can be validated upon calling the API. This is done by the API itself, not by the Identity Server.
Applied to the invitation issue: when an invitation is created, store the link id together with some info, i.e. what kind of access it allows (invitation access) and the id of the invitation. When the user calls the API to get the invitation, pass the link id for validation. Match the invitation id with the invitation id stored in the link, and if it doesn't, throw an error.
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.