I need to use our Paypal account to handle recurring charges (we presently just do one-time charges for our online store). What I think I want (feel free to let me know if this is not optimum) is:
We pass a customer from our website to Paypal's website, with the expected monthly charge and the maximum monthly charge. At this point they are registering for a 1 month free trial.
Paypal validates the credit card and returns a token to us for upcoming charges.
After 1 month, and every month after that, we use the token to charge their card. We pass the token and the charge amount.
We get back success or an error code, with the error code giving us the specific problem.
First off, is this the best way to do this? I think it's very safe because that token is only good for our company charging the card and we hold no card info. So even if a hacker gets the token - all they can do is have that person send us money, which will then be reversed.
Second, how do I do this? We're programming in C# using ASP.NET Web API2 for the REST server component and Sencha/javascript for the web pages. Is there any example code for this? Both for the handoff to/return from the paypal page for entering the credit card info and for the code in our server to make the monthly charges.
thanks - dave
I got an answer to this direct from paypal and am reposting it here as it fully answers the question:
"First off, is this the best way to do this?"
What you're looking to do is a product called "Reference
Transactions". With your business model I believe this would be the
best fit for your needs. I do want to mention there is an approval
process, so you'll want to contact our Business Support team sooner
rather than later to ensure when you're done testing you're ready to
go live.
"Second, how do I do this?"
Here's where the documentation comes in:
https://developer.paypal.com/docs/classic/express-checkout/ht_ec-refTrans-SetEC-DoRefTrans-curl-etc/
This page provides instructions on the redirect to PayPal to set up
the Billing Agreement, then walks through running Reference
Transactions for future purchases.
You can find our SDK's here (I've linked the Merchant SDK directly for
you):
http://paypal.github.io/sdk/#merchant
Here is our API explorer to see working examples of our API's:
https://devtools-paypal.com/apiexplorer/PayPalAPIs
Related
I am planning a website based on C# and ASP.NET MVC on which I want to offer a small function for a small amount of money. I dont want to use User Profiles because I dont want to do the managing part (like user/pwd) of it and save time. (I know there is a built in User-Handling in ASP.NET but I dont want a User-Login here because no one would register an account for this little function)
So a Idea comes to my mind that I could simply offer a PayPal-Button to let the User pay the money and let PayPal handle the redirect with an response key/hash (I think this is how it works) and on the redirected page on my site validate the payment through the key/hash from paypal to call the function the user paid for. Something like a paywall I think.
Is this a safe approach to secure my function and only show it to users who have paid or is this vulnerable to brute-forcing my application with a massive amount of keys to get away with not paying at all?
There are two reliable ways to confirm that a PayPal payment has been successful:
Synchronously: A server-side, API-based integration
Asynchronously: Any integration, and wait for a Webhook or IPN notification from PayPal for confirmation.
I'll cover the first way.
Integrate PayPal Checkout, documented here: https://developer.paypal.com/docs/checkout/
Here is a demo pattern of the client-side UI
The server side portion of this type of integration (particularly for the transaction set up and capture API calls) is discussed here: https://developer.paypal.com/docs/checkout/reference/server-integration/
Set up the payment
Capture the payment
If you do choose to implement a server-side integration, then -- once everything is working for the happy path -- don't neglect to implement funding failure error handling: https://developer.paypal.com/docs/checkout/integration-features/funding-failure/ ; This will allow buyers to choose a different funding instrument if e.g. their first card is declined by the capture attempt
I manage a nopCommerce site that uses the PayPal Express checkout plugin. Our accounting department wants the ability to split the payments based on some business rules. This differs from PayPal’s Adaptive Payments because in this case it’s multiple payments for the same receiver. Ultimately, I would need to capture the transaction IDs for each payment to process later on.
Is this possible?
What's the point of splitting a transaction into two if you're sending both transactions to the same PayPal account?
In order to do that you would need to setup a billing agreement for the buyer and then use reference transactions to process the two transactions separately.
It has a message that those APIs are being deprecated soon, but that's not really true. Indeed, they are trying to get people to move to the REST APIs instead of the Classic APIs, however, Classic is still so heavily used (and still has functionality that REST simply doesn't have) that they aren't going to be eliminating them. I still use Classic APIs primarily myself.
I'm a bit confused with the PayPal (REST) integration.
What I want is the following:
My customers on my website see a order-summary, they then click on
'go to payment page'. I only need to set the Currency, Amount and Description.
They arrive on a PayPal page where they choose to signin/as guest, and choose creditcard/paypal account to pay, fill in all the data etc.
I get notified by using a webhook that they actually paid, and process the payment internally.(Receiving an email about the status won't let me automate.)
Somehow all the examples I see are about sending complete payments through paypal, and not just 'setting up a payment page'. Is this even possible?
Thanks!
I hope this helps clarify:
There are 2 types of payments/funding :
credit_card
paypal
If by "payment page" you mean collecting payment info (credit card) on your website and sending it to a "gateway" for processing, then that's the credit_card flow option. There are account requirements for that (and PCI compliance).
The flow you describe above is the paypal flow. Your customers go to Paypal, select whatever payment instrument they have/choose (credit card, bank account, etc.) and then "approve" your request for a transaction.
When they "approve" - don't confuse this with payment, they are merely saying "yes, I want to pay this merchant using my Paypal account/funds", they are redirected back to your web site/application (to complete/finish things). At which point you will perform the necessary steps to "complete" the transaction request (e.g. send an execute, authorizeand capture request - depending on what you want).
So excute and capture (of an authorization) are the actual acts of "obtaining the actual payment so you get paid". You will get some result in the response to these requests at this stage for you to determine things.
If you've used the Classic API, this maps to Express Checkout. I'd map webhook to IPN (optional messaging/event tracking, and really isn't part of your payment/checkout flow).
Hth...
Update:
I'd really suggest that you take a look at the SDK (.Net). It's very well maintained and Paypal dev support is awesome. The samples will really get you going quickly.
Recently I've taken a project which involves PayPal integration. It was a complete disaster for me. The struggle was tough on me for few days until I found the answer above AND after looking into the "Update" link, noticed they suggest to actually use a different NuGet.
So, this repository and quick start guideline was the cure to my pain with Paypal: https://github.com/paypal/Checkout-NET-SDK
I am new to Entity Framework, MVC and Razor but am almost finished with my first project using it.
The final piece of the puzzle is to tweak the "canned" Log-in / Registration piece that comes by default when setting up an MVC project. I need to integrate with Paypal in order to create a monthly subscription. If payment is up-to-date then their account will then allow them to access all the benefits my site has to (hopefully) offer.
I signed up with developer.paypal.com and think I have a good start as far as creating test accounts. I just need to get the code in place.
Is there any sample code that already tackles this? I read through the API doc but
Is there any best practices that relate to what I want to accomplish? For example, should someone pay first, then create an account or vice versa? Should I have to implement managing their subscription cancellation or do they have to do it within their account? etc...
How can I tell if a user is current with their subscription and they didn't cancel.
How can I tie a user to their Paypal transaction?
Any help would be much appreciated. Thanks in advance!
PayPal has Standard Subscriptions and then they have the Recurring Payments API, or what can sometimes be seen as Recurring Billing. I would definitely recommend going with the API's as it will give you much more freedom to do everything you're wanting.
If you're talking about PayPal payments (where people sign in to pay) I'd go with Express Checkout, which consists if SetExpressCheckout, GetExpressCheckoutDetails, and then DoExpressCheckoutPayment and/or CreateRecurringPaymentsProfile depending on what you're doing. In your case it sounds like you'll be doing CRPP because you're working with subscriptions.
That will return a profile ID which you can save locally in your user table(s). Then, when people login you can make a call to GetRecurringPaymentsProfileDetails to lookup the current status of the profile, and then redirect the user to different places depending on the status.
PayPal's .NET SDK should make all of those calls easy on you, but it's really just a matter of building NVP requests and sending them to PayPal via HTTP POST.
If you want to do all of that with credit cards directly then the process is the same, but there are different API calls involved, and depending on the version of PayPal account you have the calls would be different.
If you're using Website Payments Pro 3.0 then you would use the DoDirectPayment platform, which in the case of recurring payments you would just make a single call to CreateRecurringPaymentsProfile and include the credit card details in that request.
If you're on Payments Pro 2.0 that would use the PayFlow API, and that's where it's called Recurring Billing, so you'd just have to setup a PayFlow request accordingly.
I'm creating a online webshop using ASP .net and C#. The website is supposed to receive payment by master card, visa, paypal, and e-transfer. Any reference how can I do that, esp for master card and visa. Is it done via web service? Do i hv to use a payment gateway? Is it possible to connect directly to MC and visa? I totally have no clue on this. Thanks!
Yes you have to use a payment gateway. Banks provide such services. Also Paypal.
I suggest that you use a 3rd party API to handle payments :)
Paypal would be a good choice :)
Take a look at the Paypal SDK here
https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/library_download_sdks
And you might be interested in the Direct Payment API Paypal
https://www.paypal.com/cgi-bin/webscr?cmd=_dcc_hub-outside
As others have said you need to use payment gateway such as WorldPay or PayPal.
I personally chose Paypal due to the wealth of information out there regarding how to implement the payment system into web sites using PHP, JSP, ASP.NET etc...
Plus Paypal offers a good range of packages to suit your needs - you'll also be able to take advantage of their 'IPN' option (Instant Payment Notification).
The Paypal IPN service will make a call to a special asp.net file that you specify on your server everytime a payment is made from your web site... within this call the IPN will send over a bunch of data such as the order number, payee name etc.... you can these use this data to update your database tables such as 'Payment Status', its a great feature!