I am using PayPal iOS sdk . But I am totally confused about payerID. What is this and how to works. Given that it may be email or unique identifier . Can I make it hardcoded like XYZ#gmail.com for every payer .
#Nikhil Chaurasiya, Dave from PayPal here.
Here is the relevant bit from PayPalPaymentViewController.h:
/// If payerId is nil, then PayPalPaymentViewController will treat the user as a one-time "guest":
/// - if the user logs into their PayPal account, then at the completion of their
/// transaction they will be logged back out; subsequent payments will require fresh logins.
/// - if the user pays with a credit card, that credit card information will not be "remembered"
/// for subsequent payments.
So if you do not know whether the user is the same one who last used the app, you should provide nil for payerId.
On the other hand, if you have a definite way of identifying the user (such as the user's email address), then you would provide that identifying string each time in payerId. The result would then be that the user's PayPal login or their credit card information would be remembered from one transaction to the next.
If in doubt, the safest approach is to pass nil for payerId.
Related
Our user flow is like this:
User will request service with apple pay
(PKPaymentSummaryItemTypePending)
Stripe will provide apple pay token
We will provide the service
We will charge the user for the service
We have a radar rule to block prepaid cards. Unfortunately, if you use apple pay with a prepaid card, it will pass through steps 1 - 3, then get blocked at step 4.
Therefore user will get the service free.
The goal is to block them at step 2.
How do we validate the card before step 3?
Upon creation of apple pay token, check at the "funding" of the card and block it if it is prepaid
Instead of just charging the apple pay token, attach it to a customer object then simply charge the customer later.
From Stripe:
reference 1
When you have a Radar rule set on your Stripe account, it doesn't
actually run the rules on the tokenization stage. Instead, it runs
when the charge attempt is being made, which is why it didn't occur
when you first tokenized that Apple Pay card. When you tokenize a card
and attach it to a customer object, we do a $0 or $1 authorization to
ensure the card details are valid. This doesn't run anything like
Radar rules on the card, however. It's only a step to make sure we can
theoretically charge a card.
If you're looking to be able to "block" prepaid cards in the
tokenization stage before a charge is attempted, this would need some
custom development, as the Radar rule you have in place to block
prepaid cards will only work in the charge stage. To prevent prepaid
cards from making it past the token stage, what you can do is have
some code in place on your end that looks at the "funding" of the card
token after you create the token. This tells you what type of card it
is, such as a debit, credit, or prepaid card.
https://stripe.com/docs/api#token_object-card-funding
If your code confirms it's a prepaid card, you can simply stop the
charge process here and instead choose to show your customer that
prepaid cards aren't accepted, and to use a normal debit or credit
card
reference 2
Stripe will automatically attempt a $0 / $1 authorization once you
attach a token to a customer. The authorization will happen once a
customer's created, or if they're using Checkout. Here's a link with a
little more information:
https://support.stripe.com/questions/why-does-my-customer-see-an-extra-1-00-charge-on-their-statement
That authorization doesn't use the token, it's a back end event that
happens on our side.
I'm using firebase authentication for my app and I have the users sign up, login, and log out all set up and going. However, I'm a little confused on how to manage the state of the users login status. Currently, if a user is logged into the app, but doesn't use the app for an extended period of time, firebase doesn't recognize them as logged in. I'm looking at the documentation and the approach is a bit unclear.
Should I be storing a FIRAuthCredential every time the user logs in, and then call reauthenticateWithCredential using that credential?
Firebase Auth only requires recent sign-in for sensitive operations like: deleting a user, changing a user's email or password. These are for obvious reasons. You want to make sure it is the same user before making such sensitive changes. Otherwise, the user is considered signed in indefinitely by the Firebase Auth backend (your assumption that "firebase doesn't recognize them as logged in" is not correct). Of course, a developer may also require re-auth before other operations like updating credit card, shipping address, etc. A developer would check the auth_time on the Firebase ID token. Only in such cases would you re-auth. You should never store credentials such as password on the client to avoid prompting the user to reauthenticate. It is needed to protect the user's account.
yes I think that is going to be right approach or second approach you can try is like when a user press login button instead of directly calling Authenticate User put a check in which last login timestamp value will be stored when user login compare timestamp value and then perform selected operation as you want . NOTE - you will be required to check weather user exist or not , but I think first approach will be better as if you had noticed in many Social apps like kik it ask for reauthentication after a long period of time but first it authenticate user instead of displaying home screen it take to reAuthenticate screen
I am trying to set up a simple payment using PayPal and MVC, right now I have code which accepts an ID from the database on items you can purchase.
I have managed to find code which takes me to this screen:
I have some code which after you click "Continue" PayPal will return to and call, but the only thing I have in that bit of code is this:
public ActionResult PayPalExpressCheckoutAuthorisedSuccess(string token, string PayerID)
{
return RedirectToAction("GivePurchasedItemsToUse");
}
I can see they have given me the token and payer id, but I am unsure where to go from here, in the PayPalExpressCheckourAuthorisedSuccess method, do I send something back to PayPal? Nothing yet has been displayed on any of the two PayPal accounts I am using.
The tutorial I followed was: http://rituranjangupta.blogspot.nl/2012/10/paypal-with-aspnet-mvc.html
Assuming I understood the state of where you are, which is after a user has "approved*" a Paypal Payment (where Paypal redirects back to your RETURNURL), you will need to "complete" the transaction.
GetExpressCheckoutDetails - (optional) if you want to obtain details e.g. Paypal shipping address
DoExpressCheckoutPayment - this is the actual step that completes the transaction
Extensive Reference: Paypal Developer -> Express Checkout
*approved
TIP: Don't misinterpret "approved" as "payment" - all it really means is that the user has approved a Paypal payment for you to use (e.g. user has agreed to pay some amount, chosen what funding source, shipping, etc.) - you still need to "finalize" things
Hth..
Using the PayPal REST API, I cannot seem to figure out how to cancel a payment after a client clicks the "Cancel order and return to website" link. Perhaps in production mode PayPal cancels these payments automatically, but in sandbox mode they seem to stay in the "created" state.
That observation lead me to believe that I need to programmatically cancel each payment upon return to the website's "cancel_url" page. However, I cannot seem to find a cancel function in the PayPal REST API documentation.
https://developer.paypal.com/docs/api/
For what it's worth, I'm using the Ruby API.
I have been in contact with PayPal's technical support last week and this is what they said:
If the buyer has completed the work on the PayPal checkout page
without cancelling the checkout, then they are redirected back to your
site. If you wish for them to have a cancellation at that point, you
can build the Return URL to have a final confirmation (showing final
total to be billed). So at this point the buyer is on your site, but
the payment execution has not happened. If the buyer decides to
proceed, then you run the execute command, updating your database with
the successful payment details. If the buyer decides to cancel at
that point, you do not run the execute command, and purge the payment
ID and the buyer's Payer ID. There would be no request that you would
need to pass to PayPal to cancel what the buyer did on PayPal. This
would be the same type of process done with the Classic APIs using
Express Checkout. Once the buyer gets sent over to PayPal, they
choose the funding source and shipping address and get sent back to
your site, if they want to cancel the transaction, your site does not
send any API call to PayPal to cancel or void the EC token. It is
just not used to collect the payment.
When asked how to handle non-executed payments and if they automatically void non-executed payments after a certain amount of time:
Yes, I recommend deleting the Payment ID from your database, so there
is no accidental payment. Our system, by default, will expire the
payment approval made by PayPal payers if the payment hasn't been
executed within 3 hours.
Permission has been given by PayPal to post their answer here.
I actually talked directly with someone from PayPal. The answer was:
Once a user authorized a sale, the sale has to be executed. It cannot be canceled
past beyond that point. So if the user comes back on your return URL, you are
simply expected to run an "execute" command on your payment.
This may not directly apply to your case. I think that the only way to "cancel" would be to first "execute", then apply a full "refund". Otherwise, never execute (which I also view as strange because that looks like a potential for security problems. That said, the main problem that could happen is an "execute" on the payment and your company would receive the money that you can then manually refund if necessary...)
I think you need to void the authorization of the payment:
https://developer.paypal.com/docs/api/#void-an-authorization
I used paypal api v2, and there is cancel order api.
https://developer.paypal.com/docs/api/orders/v1/?mark=cancel%20order#orders_cancel
I use Authlogic to handle login/authentication/sessions etc and I'm using paypal to handle my payment for subscription to my site. For users whose trial has expired, i'd like to log them in automatically after they go through the paypal payment process, but i can't work out how to do this without a password. My flow is thus:
expired user logs in
their trial has expired, so i push them to the subscribe page, keeping track of who they are via their unique persistence_token field, which i put in a param which gets sent on to paypal.
when i get the payment notification from paypal, i get their token as well, so i know which user has paid, and i amend their account accordingly.
when they have paid in paypal, the button to send them back to my site has the unique token of their order, so i can tell that it is the person who has just paid that is going to that 'subscription complete' page rather than anyone just typing in the url to their browser.
when they return from paypal to the site, they are still logged out, and they have to go through the login/registration process.
In the above situation, because i get the order token in the params to my 'subscription_complete' page, i know that the user is the same one who has just paid, and so i have enough information to trust them, as if they had logged in. So, i would like to log them in automatically, ie create a UserSession record for them. But, the problem is that i don't know their password (because passwords are 1-way encrypted), and i need the passsword to create the user_session.
So, my question is: if i trust the current user, but don't know their password, can i still log them in anyway? If so, how?
I've used UserSession.create(#user) before. Doesn't this work for you?