I'm in the process of integrating PayPal into my mobile application, using PayPal's Mobile SDK v2.0.
Is it possible to have the end-user approve an immediate payment and pre-approve possible future payments together?
Here's the flow I am thinking about:
User logs in.
User wishes to make a payment using PayPal and checks a box for the application to not ask the user to re-enter PayPal credentials for future purchases.
User is taken to the PayPal native view and enters credentials.
User confirms the payment (and pre-approval of future payments) on the same view.
User comes back some time in the future and attempts to pay using PayPal again.
The application does not show the user the PayPal native view any-more.
Sure this is possible. Basically the idea with future payments is to have your app securely store a token and refresh token once a user has given their consent. So if a user has given consent in the past, when they come to the payment screen you would already have the tokens stored and not need them to log in. When they click pay you would simply use the refresh token to get a new token on your back end server and use the new token to pay without any user interaction.
If you don't have previously stored tokens for the user who wants to pay, you would then show them the PayPal view to log in and give consent, get the authorization code and then use that to get the token and refresh token. You then use the token you just got to pay immediately and store the two tokens for later use.
Related
Is it possible to add or link PayPal to an account (get from paypal user access token or something like this ) to allow payments without authorization ( without log in and confirmation like with card if we have card number and cvc ) ?
And second question, I am using paypal sandbox and I cannot refresh the token when trying to execute the query
I get this answer
{
"error": "invalid_refresh_token",
"error_description": "No consent were granted"
}
Its possible they disabled this options on sandbox ?
Regards
Credit card company rules do not permit a cvc to be stored under any circumstances, so you would never "have" this information. It can only be transmitted when a card is first processed and then must be immediately discarded. As for storing card numbers themselves, there are many rules about that (PCI SAQ-D is a place to start, if you need to research it)
To your PayPal question, to be able to bill a PayPal account without the payer signing in (though they will always have to sign in for initial agreement/set up), the receiving PayPal account must have a feature called "reference transactions". The account owner can contact PayPal's general business support (not technical support) to explain the business need and inquire about being approved for enabling this feature. Once enabled, PayPal can guide you on which API to implement -- be it the older billing agreements API or a newer v2 or v3 vault one.
Refresh tokens are used by a Log in with PayPal integration to obtain a new access token when the old one (originally obtained from an authorization_code) is expired. If you are not integrating Log in with PayPal, refresh tokens are not applicable to what you are actually trying to do, and so the request in your screenshot won't be useful to you.
Refresh tokens are not used to obtain a regular REST API access token for authentication, which uses grant_type=client_credentials . If that's what you're actually trying to do, the documentation is here. The public PayPal Postman API collection sample takes care of this step for you, in the collection-level pre-execution script.
I have a PayPal REST API implementation that has new users first log in via a "Log In via PayPal" button, and then immediately redirects to a Reference Transactions approval page. This works, but having it be 2 discrete steps results in an unusual user experience.
The login button goes to this page: https://www.paypal.com/connect?flowEntry=static&client_id... and the user logs in and grants permission to access their profile data via the Identity userinfo API; then redirected back to our site, we pull user info, see there isn't an existing payment token, and immediately redirect to a Reference Transaction approval page: https://www.paypal.com/agreements/approve?ba_token=BA-...
I'm approved for reference transactions but not to receive most of the payer fields (and I was told only large companies get approved for it), but we have approvals for those fields with the Identity userinfo API. I screen for things like requiring a verified Paypal account, so the info is needed.
Is it possible to make this into a single redirect that grants permission for account userinfo and approves the billing agreement in the same step? Like another permission I could ask for on the login page that would let me approve the billing agreement with a server-sided request?
Currently my flow is
User clicks PayPal Button
User gets redirected to PayPal approval URL
User gets redirected back to my website with a Token
I make a call to my server with the returned Token to execute the payment.
Now if user tries to refresh the page, token is passed again to my backend and subscription is processed again with same token.
Is there anyway to avoid this? Is the flow correct?
A user clicks on a buy now button on my website which takes them to PayPal where they can purchase my item. I then receive the relevant information through my IPN listener. This all works fine with sandbox accounts.
To implement this with my live business account, am I right in thinking I don't need to worry about creating live API certificates etc? I understand this is needed when making API calls to live accounts but I'm assuming a simple buy now button doesn't need this stuff setup.
Correct. You only need API credentials when you will make an API call. IPN is a push notice, so PayPal is sending the data to you instead. All you need to do is post the data back to PayPal to verify it and then process the POST data.
Our iPad app has been processing payments successfully in sandbox mode using v1.0.5 of the iOS SDK. However, we found one defect while testing our application. Please find steps below.
Login into PayPal.
Use email or phone and type in your credentials.
click on send payment. You will see the payment complete screen. Click on done button.
Now open your sandbox account and change the password/pin (Profile->Update password).
Then go to the application and try to make payment again. PayPal sdk navigate you directly to the confirmation page.
Click on send Payment.
PayPal SDK allow user to pay with old credentials(password/pin).
Is this a known issue or I am missing anything?
Also is there any way to log out user after every payment. (Force user to login every time he tries to make the payment without manually clicking logout button).
moka, I think that the scenario you describe is okay as is.
Within your app, the user logs in to her PayPal account, pays you, and chooses to not log out from PayPal.
Later, within your app she remains logged in to her PayPal account, even though elsewhere she has changed her password. And therefore she can still pay you from this account.
That all seems fine to me.
Regarding your second question:
When you call [PayPalPaymentViewController initWithClientId:receiverEmail:payerId:payment:delegate:], the SDK uses the payerId to determine whether this is a new user or a returning user.
So if you change the payerId each time you call the SDK, then each time this will be interpreted as a new user, who will therefore require a fresh PayPal login. (For example, you could set payerId to something like [NSString stringWithFormat:#"%d",rand()].)
-- Dave Goldman (eBay/PayPal/card.io)
Set rememberUser property to NO for PayPalConfiguration instance like this
payPalConfiguration=[[PayPalConfiguration alloc] init];
payPalConfiguration.rememberUser=NO;
It will then ask each time to login.