Implementing Paypal for a UK based NGO where they are selling certain services plus accepting donations.
I am using REST API for selling services which is working well but do we use the same API for Donation as well. I would like to handle Gift Aids as well. I dont see any payment type option within the API.
If I use the standard Donation button, how do I get the transaction Id and other values back so that I can save them in my system.
There is no real technical difference between donations and payments for goods and services. (The donations button is just a few cosmetic differences on top of a regular website payments standard or EC payment experience.) The REST is not yet as feature rich as the older payment flows and may not have those same cosmetic tweaks available, but you can definitely use either the REST or the classic API for both services and donations.
I would recommend not using both REST and classic together on your site; you will encounter many annoyances due to differences in the underlying models. It is not just the initial payment integration that is different; the payment IDs are different, the APIs you can use to manage the payment lifecycle are different etc.
As one such example, to answer your question #2 you cannot get REST-style payment IDs for non-REST transactions. You get back classic transaction IDs in the payment redirect or the DoEC API response, depending upon which integration you use. You also get classic payment IDs if you integrate IPNs (whereas with REST you would integrate webhooks... the differences keep coming!).
Related
Is it possible to retrieve shipping quotes on the fly through an external API when a user purchases something through my eBay store?
eBay (and previously PayPal) does not expose the shipping quotes API for various reasons (including technical, business, and pricing reasons) so the short answer is "no, there is no way". In fact it gets the quotes from an external (independent) source.
You can try integrating with Pitney Bowes or a similar provider to get the shipping quotes but that solution is for large players.
UPDATE: Since your company is the one hosting the quote service...
When a user purchaes an item on ebay a "purchase notification" is sent out to a merchant. There are a few different versions of it which you can read about on eBay's dev site. One of them is ItemSold Notification that you can use.
UPDATE 2:
If I understand you correctly you are trying to inject some business logic into eBay's purchasing UI? I'm afraid you are out of luck here. You have limited (pretty much none) influence on the eBay's web flow.
I'm looking for a way to allow our clients to do recurring payments to discount these payments based on the credit in their account which can be earned or deposited in many ways. For example, if they need to pay $20 and have $5 in credit, I would like to only bill the remaining $15 automatically without any need for additional website visits.
Looking at the documentation for PayPal's REST APIs, I don't see any clear way to do this. Is the only way to do this to send them a refund automatically? Or is there a way to get approved to bill clients up to X amount per month but allow us to bill under that amount. I thought billing agreements would allow for this, but after reading the documentation, I'm unable to figure out a way to do it. If it's possible, could someone walk me through what API calls would be needed to do this?
Thanks for any help you can offer.
There are a couple of different ways you could do this sort of thing, but I would avoid the REST API for now. It's still too new and doesn't provide as much functionality and features as the classic API.
Within the classic API, you can use either use Preapproved Payments, which consists of Preapproval and Pay APIs, or you could just use Express Checkout and/or Payments Pro with Reference Transactions.
Either way you'd basically be building your own recurring payments system where you'd setup a billing agreement and then your app would trigger the variable amount payments accordingly.
I'm building a marketplace application:
The customer pays the seller on the marketplace
The marketplace takes a cut of the payment
I would have a payment processing system with the following features
The cut and the 100%-cut are sent directly to the marketplace and seller accounts (ie, I don't want to have 100% on the marketplace account and then to forward the 100%-cut to the seller)
I would love to have a UI as much integrated with the marketplace website as possible. This implies that the customer in the worst case has to put only name, surname and credit card number on the payment processor interface (the ideal would be a payment interface totally integrated with our website)
I don't want to force the customer to register to any third party service
It should work nicely with Ruby on Rails
It should work for non US-based companies and should support multicurrency payments
What are the options out there?
Thanks.
I'd recommend you look at our product Balanced. It's built to solve exactly this problem so I think it's a good match.
At a high level payments in are done via credit card like a normal payment processor, funds are deposited into an escrow account which is a sum of all funds collected - all funds disbursed. When you're ready to push funds out you can currently pay out via next-day ACH (US only) but we're building out international support which sounds like it would be useful for you.
I believe it matches your other requirements:
there is no requirement to send users offsite, they do require accounts but you can create and edit them via the API.
Balanced has an excellent ruby gem
You can split up the payment, taking a cut from the proceeds as profit
Balanced provides you with a merchant dashboard for you and your customers to get a head start but you can build the exact same thing via API access.
One area where it's not going to meet your requirements is multi-currency charges. Currently you'll need to charge in USD and convert.
Check out https://github.com/drhenner/ror_ecommerce It doesn't have all the features you want but will give you a big head start.
Basically active merchant will connect to most gateways. You need to add the custom code. Look at the video for more help http://ror-e.com/info/videos/1
what are the must have functionalities for an e-commerce web shop?
e.g.
unlimited categories and sub categories
multiple categories per product
multiple product images
product consumer ratings and comments
payment gateway integration
delivery service integration
Best Sellers
Newest Products List
discount facilities
promotional facilities (buy one get one free)
I know we shouldn't just link to elsewhere, but this link is within stackoverflow. I'll just quote it all here:
Do you need to build one at all? Most of this has been done for you in
various shopping cart packages
including google checkout,
oscommerce, and others, but if
you must take the plunge try to at
least think about the following...
Secure session for users
Storing 'items' in the cart via the session / cookies
Payment processing
what external systems do you interface with
what kinds of payments do you accept
what currencies do you accept
Some kind of dispatching system for when a purchase occurs
If a purchase occurs, who is notified to mail out the items?
where is the purchase logged?
Interaction with an inventory system of some sort
is the item in stock?
what to do when out of stock?
Total / shipping calculations
how much do you charge shipping for different customers/destinations
where do you want to ship / where will you not ship
A shopping cart is far more complex a
concept than it appears to be. The
specific answer to these questions
will depend on what kind of
organization you are working for. Big
company? Small startup? Family
business? High volume vs low volume?
Etc.
I've written a subscription based web app that I want to charge (by credit card) a monthly fee. There are 3 different plans and once they sign up, they should be billed that amount, automatically, every month until they cancel. Is there an easy way to set this up (some sort of online service maybe?).
You can use Paypal's merchant service to provide reoccurring charges for a subscription.
Pretty easy to implement, they provide plenty of examples and even a sandbox to get you up and running.
There are now some service providers that take care of your billing and subscription needs. You use their API and they handle billing and subscriptions for you. Their services work with payment systems like PayPal and Authorize.Net.
Take a look at the following sites:
Chargify
Spreedly
Cheddargetter
I would suggest not using Paypal or Authorize's recurring payments directly. Their APIs are brutal, and the functionality is very rudimentary. It may work fine for when you're just starting out, but if you ever want to change anything down the line, you'll be in trouble.
I work for CheddarGetter, so I'm biased, but you should check us out.
Our competitors are not as robust or flexible, but they are definitely better than using Paypal or Authorize.net directly.