I'm trying to integrate PayPal's Express Checkout API into a homegrown shopping cart. I've looked at how to make the proper API calls but what's not clear to me is how I'm able to maintain the state of my cart during the time the buyer is logging into and verifying payment in PayPal. When control passes back to my application via returnURL or cancelURL, how would the state of my cart have been maintained? Currently, my cart content isn't written into the db until the order is finalized and paid. Sorry for the naive question - I'm just not seeing the answer to my question in any of the API docs.
You can look into the use of cookies and temporary data. If the cart is of your own creation, you should use a cookie. A cookie expiration of around a month or two would be appropriate. Bear in mind, on successful payment you would need to void this cookie.
Related
My dear fellow IT developers...
I am currently working for a client of mine on Laravel 5.5 and we are using omnipay library for PHP and it's PayPal part omnipay-paypal. Now since this a specific request from client I am using PayPal-Express method to redirect the users to PayPal then there they login and pay with their account PayPal or CreditCard and come back to my clients page on Thank you page.
Now since the client wants to create an upSell page which stands between checkout page and Thank you page, and it offers 1 additional unit of the product on 50% discount.
The story is that after the first charge I would need to recharge them again somehow, ideally with what I already have and that is PayPal Express.
On our checkout page we have two options PayPal or Checkout.com, the latter one offers storing of card_id property and after that you can do the recharging, this is already implemented and working like charm with Checkout.com. Now back to PayPal.
I've spent fair amount of time trying to find the same solution for PayPal but with no luck. If there is some good soul out there to help me out with this I would appreciate it very much, so Omnipay PayPal library + recharge the customer if they click Yes on upSell page after initial successful charge/payment via PayPal Express.
Thank you in advance.
There isn't an easy solution to this problem, however I can point you in the direction of a couple of things you need to do:
What you need is a card token. That's where (in Omnipay) you call a method like createCard() with the customer's credit card details and you get back a token. You can't do that with a PayPal account, you have to capture the customer's credit card details and then charge the card.
Creation of card tokens can't be done by the PayPal Express gateway. It can be done using the PayPal REST gateway (an alternative and newer gateway in the same Omnipay package as PayPal express) which means you need to switch from PayPal Express to REST. That's as simple as generating a new set of API keys. That will allow you to call createCard() with the card data and get back a card token (called a cardReference in Omnipay) just like you do with checkout.com
Just to reiterate, what you're trying to do can't be done with a PayPal account. You need to have the customer's credit card details.
I am working with paypal first time.
I have a product and I want to integrate paypal with it.
I want to achieve the following tasks :
Client comes to my website and select a plan,which is a monthly recurring plan.
Then client is redirected to Paypal for payment.
Client makes payment.
Return backs to home page.
I have gone through the documentation of paypal and I have the following questions.
What should I use REST API or Classic Sdk, as I want to create Recurring Profile,Work with EXPRESS-CHECKOUT and REFERENCE TRANSACTIONS.
I have customers all over globe and it is stated in the documentation that, for the customers in Germany and China , I have to use REFERENCE TRANSACTION.
Some where in the documentation of Merchant SDK it is stated that the classic API's will be deprecated, so is it a good approach to use Classic SDK
I also wanted to track the transactions(payment) made by user, so that I can show him the amount that is deducted in each month in his profile details.
Please suggest a feasible solution to my problem.
Thanks in advance.
Here's what I use. I went to Web Payments Standard and created a Subscription button. (I like the unencrypted variety, but you can encrypt if you want.) In there, you set the terms of the subscription, as well as where to post the IPN message. When the IPN message comes back, you deal with it. You'll get a subscr_signup at the start along with a subscr_payment. Then, on renewals, you'll get a subscr_payment again. What I like to do is store every verified IPN message in the database for my customer.
For handling the management of those subscriptions for things like tracking info, refunds, subscription cancellations, and voids, you'll need to use NVP API, which is a very simple API. If you stored in a database every IPN message with all those fields, then you should be able to pass certain fields of those to the NVP API in order to get what you need done.
If you're worried about longevity of the APIs, then don't. All they do when they deprecate APIs is stop giving you good docs on them. They still let those older versions run. If they didn't, there would be major upheaval on the web with web commerce products breaking all over the place. However, that said, if you want to prepare for the future, then get on the Braintree Payments API because PayPal bought Braintree and that's the future of their API.
Hello guys I am developing a web store where users are already registered it must track both users the one that is selling the item and the one that is buying the item also some instructions the buyer might to express to the seller.
I have not performed this kind of tasks before have been reviewing the Paypal developer Api however have not found the exact functionality I need right now.
i need to pass session variables from my app into the paypal mechanism.
Please let me know how to integrate a button for buying an item and then store the details about the transaction in my db cause need to know the userid of the users within my app.
Thanks a lot.-
In your case you can use the Express Checkout API or simple PayPal Standard + IPN
If you use Express Checkout, then you don't need to send any session variable to PayPal as the session is not closed and the last step of the transaction (DoExpressCheckoutPayment) occurs in your website. But, if you really want to send some custom data to PayPal you can do it by sending "PAYMENTREQUEST_n_CUSTOM" inside the SetExpressCheckout call.
If you use PayPal Standard + IPN. You can pass to PayPal the variable called "custom" (Pass-through variable for your own tracking purposes, which buyers do not see) and retrieve it back in the IPN.
I am building website which requires customer to update paypal account.
Is there anyway to check the reality of customer's account?
When my customer fill out their paypal account in my site, I want them to be directed to paypal login page to login and paypal will return the result.
Does paypal api support this situation?
Pretty much any implementation of PayPal you choose would follow the flow you mentioned.
Payments Standard would allow you to create basic buttons or create an HTML form and POST directly to PayPal to process. It would send the user to PayPal for login and approval to complete the payment. The transaction details would include the payer status (verified or unverified) as well as the address status (confirmed or unconfirmed) and lots of other details about the order.
Express Checkout is basically the API version of Standard, but it's much more advanced and open to integrate in the way that works best for your site or application. In this case, some of buyer/transaction data is available during the process within your app through API requests and responses, and then you can also get to it via transaction details after the fact just like payments standard provides.
Another option would be to use Adaptive Payments, but if you're doing a general payment of any kind you probably don't need that. That's what you would use if/when you start wanting to split payments among multiple receivers within the same transaction, setup preapproval profiles, etc.
If you happen to be working with PHP my class library for PayPal will make the API calls very simple for you.
You could do what PayPal itself does when you register. Send them a few cents and have them tell you how many when they get it. The payment itself will fail if the account doesn't exist, and telling you how many cents proves that they own the account.
My company uses PayPal Payments Standard. Currently our checkout process works via the "cart upload" method and IPN to verify payment via PayPal's website. Should continue to use this method or if we should replace this with the REST API? From what I understand, the REST API is only to be used when the customer stays on our website for checkout, as opposed to going to the PayPal site and returning to our site after checkout. If this is true, I assume the cart upload with IPN method is still the best choice for us, since at this time we prefer to have PayPal handle credit card data. Am I understanding this all correctly?
The REST API is just a different way to integrate the payments programatically. The functionality is very similar and you'll be just fine sticking with what you're doing. No logical reason to spend the time redeveloping it if what you have is working fine for you. They won't be killing it or anything like that (at least not any time in the foreseeable future.)
As i see from a brief view, REST API for Paypal offers webhooks instead of IPN as a way to notify your system about payments and their progress. Each webhook describes which url gets notification request when some type of event takes place.