I just thought I'd share some of the lessons I learnt, and I that checking out this blog entry might save you a bit of time if you need to do something similar.
So, it's been a very interesting week for me learning how we might be able to accept online donations and payments from our Members directly online.
We are currently configuring our Salesforce.com system and I was initially very encouraged when a quick look on the AppExchange showed more than 20 different applications that promised "simple" online payment processing.
Some of the top providers listed at the time we were researching options included:
Getting started
I was amazed that Salesforce.com didn't have any sort of payment processing functionality out of the box, but several of the application providers I spoke to explained that they focus on the core Customer Relationship Management (CRM) side of the system and encourage 3rd party developers to maintain an ecosystem of related apps.
Playing with the Apps
Being a hands on I.T type my first step was to install and have a play with a number of the apps listed. Their functionality was very similar and it was easy to set up a template invoice, send it via email to a customer, and even manually log in and mark whether a payment was received. So far, so good.
However one of our core requirements was to be able to give customers the option of paying via Credit Card or PayPal and then their payment automatically being tracked within Salesforce.
When is PayPal not PayPal?
Several of the apps stated that they had PayPal payment support but it turns out there are different versions of PayPal in existence and not all are treated equally by the apps. So, a slight diversion whilst I went on a rapid learning curve to learn about PayPal Account Types.
We signed up for a PayPal business account for our non profit organisation, followed the instructions provided by several vendors and still couldn't get the payment processor connected. After several attempts, I went back to the vendors for more support.
Why your organisation's host country is important
So, after waiting a while we got responses back from the vendors saying there are different PayPal connection mode, API and PayPal Payment Flow. When I asked what the difference was, I was told that the API connection would require me manually setting up our own checkout pages on our site (the vendor gives you a template but you basically set it up yourself), whereas the Payment Flow tool would simply require a username/password combination and would then be good to go.
Naturally, I wanted to go for the path of least resistance so I tried to apply for PayPal Flow. However, PayPal flow is currently only available to US registered customers (you have to provide a US address and US credit card number). Doubly annoying, several of the applications I liked the most on the AppExchange told me that they only integrate with Payment Flow.
Getting around the country problem
A couple of vendors suggested we register a new branch of our organisation in the US so that we could open a bank account there and direct all payments to an account registered in the US.
They said this would be an "easy" workaround, but we didn't really want to go down the route of having multiple registered addresses, bank accounts in different countries, and any associated legal and tax issues that this could create. We decided to continue looking for a solution that would work for us in Thailand.
Alternatives to PayPal?
At this stage, several of the vendors suggested I look at other Payment tools instead of PayPal (they were probably trying to get me off their support boards!). So, off I went on a search for an alternative. To quickly summarise this extra research, I found that no other well-known payment processor was available to us in Thailand. It just seems that Thailand isn't on the radar of the best known payment processors yet.
- Authorize.net (US, Canada, UK)
- Cybersource, (US, Canada, UK)
- Google Checkout (US, UK)
- Worldpay (Andorra, Australia, Austria, Belgium, Cyprus, Czech Republic, Denmark, Finland, France, Germany, Gibraltar, Greece, Hong Kong, Hungary, Ireland, Israel, Italy, Liechtenstein, Luxembourg, Malta, Monaco, Netherlands, New Zealand, Norway, Poland, Portugal, San Marino, Singapore, Slovenia, Spain, Sweden, Switzerland, Turkey, the United Kingdom, the United States and the Vatican City State) source (http://www.worldpay.com/products/index.php?page=ecom&c=SG)
Back to the API
So, we could only use PayPal and we could access it via the API. So I spent a few days trying to follow the instructions from the vendors on creating Force.com pages on Salesforce.com to act as our checkout page. To give you an idea of what this looks like, check out some instructions from Acertis Invoice IT.
I got the pages set up but still no successful connection between PayPal and our Salesforce.com system!
Thankfully the guys at OnCommerce came to the rescue and helped me successfully connect the 2 so I could finally do an end to end test.
Success!
It was a very geeky, but still exciting moment when I raised our first invoice in Salesforce.com for $2, sent it to myself, then paid it via PayPal, to then have it successfully show as Paid back on the Salesforce.com account.
Lessons learnt
Now that the Force.com pages and API to PayPal link has been tested successfully we can begin invoicing customers for real.
Here are a few things I learnt from this adventure...
- There are multiple payment processing services available if you want to accept payments on your site.
- Your country will narrow down the services available to you, (although if you're based anywhere else but Thailand it should be easier than our journey). I started all of my later conversations with vendors with "we are based in Thailand" is your service available here.
- There are different connection options and account types for PayPal. Towards the end of the week, I asked each vendor whether they worked with both "PayPal business" and "PayPal Payment Flow" to help narrow down the choices.
- PayPal Payment Flow looks like it would be easier to connect to a payment application but the API gives more flexibility (and in our case was the only option available). However, you have to manually create and sit the payment pages on your site.
- Comparing products is difficult, some are free to set up but have higher fees. Some have a fixed set up cost, but lower monthly billing. Some just take a % of all revenue that you process through them (in addition to the PayPal commission). My suggestion would be to put each one in a grid to get an overall comparison.
- We will still need to provide our customers with an option to post a cheque or do an on-line bank transfer, so we'll still need to manually mark some invoices as paid.
Future requirements
We'd still like to find an option that directly connects to our bank account in case customers pay via bank transfer. OnCommerce say they are working on this feature at the moment and hope to have it ready early next year so I'm looking forward to testing it out then.
Other posts on this topic:
No comments:
Post a Comment