However, what really interested me were their new identity services. Now, several sites have been jumping up and down with headlines like “PayPal becomes an identity provider,” which is a tad odd. They have been for a while with both an Authentication API (Though, I think Coding Futures may have been the only company outside of PayPal who were and still are using it.) and more recently, OpenID implementation. What the new services do is bring these experiments to the main stream, with support for both identification and authorisation.

PayPal Identity Implementation

The OpenID system is PayPal’s new standard mechanism for identification for third parties. It’s part of a collective of mechanisms for identity provision called PayPal Access. This is an interesting step to create a brand.

One of the biggest problems we have faced in the past with PayPal identity services is convincing users to make use of it. Many users, when asked to “Login” via PayPal assume they are being asked to enter a payment flow. The OpenID implementation follows the OpenID v2 specification. It can return basic details such as name and the user’s address, and for people running PayPal related services, two exceptionally useful parameters: PayPal account type and the PayPal Verified status. Unlike a normal OpenId implementation, the domain you’re using it on needs to be whitelisted. And to make full use of the system, the entire process should be under https.

PayPal Authorisation Implementation

What is new is the announcement that at last PayPal will be supporting OAuth. OAuth is a token-based service that, once a users identity has been confirmed, grants permissions for your site to take certain actions. Initially, these actions will be limited to accessing certain information, but hopefully, the old permissions API and Adaptive Payment flows will be initiated from Oauth token.

PayPal Access – Branding Identity

As I already mentioned, for me the biggest issue with PayPal’s previous identity services was the lack of branding and PayPal’s attempt to instill user confidence. Having spent so much time and energy into preventing phishing scams, PayPal trained its users not to trust anything that looks like PayPal from a third party site. Consequently, digital payments, embedded goods payment flow and its previous identity service attempts have had issues with consumer confidence.For PayPal to be able to push PayPal Access, they will need to not only push the concept to developers, but also to consumers.

Unifying the technologies into a brand is a good starting point. Making the user experience and language coherent and obvious that no additional charges will be made isn’t quite there yet. The PayPal Access login and approval screens still look too much like a payment flow. They also fail to tell the user why they are logging in until post-login. That said, as PayPal access becomes more widespread, and people are regularly confronted with it, confidence will improve.

On to the cool stuff…
If you are a privacy advocate do yourself a favour look away now…

User Profiling with PayPal Identity Services

In addition to the refreshed OpenID and implementation of Oauth, PayPal also added some additional identity services to improve user profiling: Prospect API, Segmentation API and Product Recommendation Service API. Each of these allows a site to gain information about a PayPal user and their buying habits. It also harnesses the power of the Intelligence Engine on Ebay to product categorise — You can cross-sell from your own inventory to that user.

Prospects and Segmentation APIs

How much is any given user worth? What are their spending habits? How active a shopper are they? With the segmentation and prospects API, a merchant is able to profile individual users overall PayPal habits, including how frequently they shopping, the average spend value of a shop, etc. None of this is finite data. Instead, users are grouped in terms of usage frequency the groups are: Engaged, Habituated & Casual

So, what can you do with this data? Well, for your initial sale, probably not much. But post-sale, this data provides extra details about the user’s sales prospect. For example, if we wished to sell a group of products, we could do so in two ways: individually at a low price, or bundled together at a higher price. With our customers profiled we could target groups differently.

The casual user but big spending group could be targeted with the bundle deal. The super engaged but low spending users could then be targeted with individual products over a range of time.

This does lead to the obvious privacy concerns, of course. In reality, people have been buying and selling this data for years, and all major eccomerce sites are using prospect analysis of some sort.

PayPal is bringing this down to mid-level merchants. It’s worth emphasising that this is PayPal, so expect it to be near impossible to get access to these APIs, without jumping through a dozen or so hoops, while standing on one leg.

The problem comes in when offering these services — There really is no way to do it, without providing user information. The grading bands are wide enough that the demographic information could not be used to judge any financial information. After all, just because someone is a heavy PayPal user does not mean they’re wealthy or poor.

The new data, while interesting and useful, really is scratching the surface. An aspect I would love to see included in the data is a user’s refund/chargeback rate and their average subscription rate. For membership sites and other recurring subscription sites, an idea of how long they have got the user for could totally change the way they present information.

For example, if I know a member subscribes for roughly 3 months, while my overall average is 4 months, I can change my content delivery strategy, so that open content (that starts 1 week and ends the next) is sitting over a 3 month period and not the 4 month mark.

Future of PayPal Identity Services

The announcements are a good start, albeit a slow one. Most of what I have talked about is still in Alpha (with exception of OpenID) rushed out for Innovate. And given PayPal’s track record, these are still a year or more away from becoming a reality.

The shift to OAuth is important. PayPal is not just providing services to identify users, but also a fully-fledged authorization system, which is an industry standard. This has to be applauded, but the old user experience bugs from the old identity system are still there. Even with branding and without a large marketing push, consumers will still struggle to see PayPal as being used for anything other then paying.

One of the things I hope OAuth brings is a unified system. Then, I as a merchant can use OAuth to authenticate and authorize the user, make a call to the segmentation API, present my offer, and start the payment flow with the auth token. This way, the user only has to sign in once.

As a merchant and developer, I want a flow similar to:

Login -> Segmentation API -> Show Offer -> Make Payment -> Show Upsell -> Setup Subscription

This flow should be easy for the consumer. Sadly, this flow currently requires 3 separate PayPal sign ins. And each successive sign in degrades consumer confidence and will power.

With the whole X.Commerce brand, PayPal is trying to create a platform like Amazon and Facebook have. The cornerstone of any platform is opening it to third parties, but given the nature of PayPal’s business, this has to be done in a controlled manner.

The identity services are a step in the right direction, but so often before PayPal has taken a step in the right direction, only to have its own bureaucracy prevent any real usage. I really hope this is not going to be the case and the X.Commerce platform lives up to its promise.

Dear PayPal

I think we are petty close, I develop on your services, you charge me lots of money in fees, I go to your conferences and generally moan to your dev team. Normally I keep my scorn of idiotic mistakes to just your ears but PayPal Pro Hosted really is a nasty mess.

So what, most of PayPal is a hideous mess! But the Adaptive APIs are so nice and a standard you should be looking to (though docs still need updating and the SetPay API is just nuts). Hosted Pro on the other hand is like someone took a bunch of kindergarden kids and asked them what they want in a system result shiny encrypt-able buttons.

The thing is it was so easy for it not to be…

1. User comes to site and starts payment flow
2. Server sends some details to PayPal, PayPal returns a token, which you append to a URL and open in an Iframe.
3. A box with Credit Card details appears you fill in the card details and hit go, on success you return the frame to a dedicated page, and on failure another if you want you can even frame bust on the way out.
4. The server then can double check via getTransactionDetails with the token you gave.

Sound familiar? It’s the same way your other APIs work, and guess what it works quite well!

It’s neither hard nor complicated, it doesn’t involve pretty buttons, and if someone wants to send extra parameters across they can do so in a controlled sane manner.

This seems like such a sensible approach, it’s hard to believe it wasn’t thought about and unless I have missed some major flaw, the current implementation still generates and populates an Iframe it just does it in a really ugly manner especially when you switch javascript off. The worries about security with Iframes are still there but generally with a far worse user experience, as in most cases Hosted Pro requires at least 1 more superfluous button and a lot of styling to make the Iframe work in the page.

Right now PayPal Pro Hosted is not a solution it’s a toy, I can sort of understand why it’s perhaps a little unloved, but when I saw it originally I really wanted it to be so much more I wanted a feature rich chromeless PayPal screen which I could take credit and debit card transactions, I wanted reoccurring billing and the option to authorise cards. Just think if you actually put the time and effort you did into Adaptive into PayPal Hosted it could be an awesome service and let’s face it with PRO you are not only getting the transaction fees but also charging a monthly fee so its in your interest to make me want to use it (ok not me but my clients certainly).

Sadly I’m having to look for an alternative for our in house apps, as I do not want to go through running a full PayPal Website Pro integration, especially when sadly there are cheaper merchant gateways out there that won’t suddenly freeze access to all your account and money. I’m still a fan, I’m not even that upset I’m just disappointed…

Hugs and Kisses

Tim

If anyone has a suggestion for a UK based solution, that uses Iframes to process the actual payment, rather then web forwarding, or doing Direct Card Payments, please do let me know.
Hopefully the above letter can be used inside PayPal to chivy some sort of sanity amongst them, but meh I’m just a pesky developer.

Adaptive Payments – PaymentDetails

If you ever need to know the status of a Adaptive Payment then you can make a call to:
https://svcs.paypal.com/AdaptivePayments/PaymentDetails
Sending over a PayKey and an error language as post keys, the example below using PHP and CURL with the response language is JSON


$headers[] = 'X-PAYPAL-SECURITY-USERID: '.$api_handler_username;
$headers[] = 'X-PAYPAL-SECURITY-PASSWORD: '. $api_password;
$headers[] = 'X-PAYPAL-SECURITY-SIGNATURE: '.$api_signature;
$headers[] = 'X-PAYPAL-REQUEST-DATA-FORMAT: NV';
$headers[] = 'X-PAYPAL-RESPONSE-DATA-FORMAT: JSON';
$headers[] = 'X-PAYPAL-APPLICATION-ID: '. $api_key;
$headers[] = 'X-PAYPAL-SERVICE-VERSION: 1.3.0';
$post_data_array['payKey'] = $paykey;
$post_data_array['requestEnvelope.errorLanguage'] = 'en_US';
$post_data = http_build_query($post_data_array, '', chr(38));

//time to fire off CURL
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt ($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt ($ch, CURLOPT_SSL_VERIFYHOST, false);
curl_setopt($ch, CURLOPT_VERBOSE, 1);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
//curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_POST, 1); // set POST method
curl_setopt($ch, CURLOPT_POSTFIELDS, $post_data); // add POST fields
$return = curl_exec($ch);
if(curl_errno($ch))
{
die(‘ERROR: ‘ . curl_error($ch));
curl_close($ch);

$json = json_decode($return);
if($json->responseEnvelope->ack == ‘Success’){
if($json->status == ‘COMPLETED’){
//Success Get details and commit
}
else {

//failure grab the status to find out whats going on
}
}

I find the simplest way to use the above is combined with a queueing system, or simple cron job, taking pending transactions, processing through and changing status, if completed. The advantage to this method is you can also check the timestamps and set a point at which it is abandoned.

Do you still need IPN

Depending on your scenario yes, for example if the transaction is refunded, chargeback, held etc. you may also wish to use IPNs. This way, if someone takes an exceptionally long time, or PayPal has a flaky moment, and you have marked the transaction as abandoned, you can get a return from IPN and change the notification accordingly. What’s more, there is no need to verify IPN. When you receive it, you simply make a PaymentDetails request making data poisoning much harder.

The two big releases from Paypal have been Adaptive Payments and Adaptive Accounts, Adaptive Payments is a collection of methods of payments that changes the way you do business online (at least that’s what the marketing department at Paypal said I still think they are pretty useful though) while Adaptive Accounts will allow you to generate your customers with Paypal accounts on the fly (yes you read that right) This article I’m going to focus on Adaptive Payments and in particular split payments, though fear not I will be talking about the other features over the next few weeks and months.

Split (parellel) or Chained Payments

One of the features that is going to appeal to Internet Marketers and Ecommerce developers is the Split and Chained payment feature, this allows someone to make a singular payment but the payment is split amongst several receivers this immediately opens up some amazing possibilities. With Adative payments you have:

• A Purchaser or Buyer – the party who is buying the product
• A Receiver – a party receiving money from the Purchase
• An API Caller/handler – a Party which instigated the transaction and determines where funds are sent, the API caller maybe a receiver but can’t be the purchaser.

Split Payment

A singular Payment is split so the money is divided amongst one or more parties, each party is shown on the invoice, in effect while their has been one payment their are several transactions. The purchaser can see each party and interact with them, for example requesting a refund against one of the payments rather then all.

Chained Payments

A Chained Payment a singular party becomes the API Caller the purchase is made in the API caller name and the payment is then split to other parties which could include the original API caller. In this scenario the buyer only sees the API Caller in the purchase even if several transactions have occurred.

Paypal Split and Chained Payment Usage Examples

Trials and Upsells

Using Split payments a merchant can provide multiple payment cycles for different products for example:

A user visits a site and purchases the online version of a product and is also offered access to a Joint Venture Partners product as part of an upsell if he agrees a split payment is made one to the original merchant and the other to the JV partner, while the user has made just one payment his invoice clearly shows two separate transactions. A problem with one of those transaction that results in a refund only effects that transaction. Allowing JV partners to have a direct financial relationship with the customer during the merchants sales person. Transactions do not have to be of the same type, while the original purchase maybe a one off payment a JV transaction might be a pre approval subscription.

Drop Shipping

Dropshipping is where a site actually does not have any stock but purchases directly from a drop shipper on purchase. When the purchase is made the dropshipper is sent the shipping details of the client and the order as well as the wholesale price of the product plus their commission. They then ship the product on behalf of the original site. With Adaptive Payments Chained payments this can be instantly automated into just 2 payments rather then just one. When the purchaser sends payment to the Merchant the merchant then generates a split payment to all drop shippers along with sales information.

The advantage is that within Paypal every item purchased by the purchaser is passed to multiple dropshippers as one job making tracking processing a lot easier and far fewer payments.

Instant Affiliate Payments

Have a direct relationship with Affiliates you can literally split the payment, Why is this better then a monthly pay back, if their is a refund you can refund from both your Merchant account and the Affiliate account, either partially or fully! Allowing Affiliates instant access to their cash as long as they have the understanding it maybe refunded, of course you can choose to take the entire refund or indeed in part.

Is your Ecommerce system ready for Adaptive Payments?

Almost certainly not but over the next few months and years the larger e-commerce software will start to adopt this technology but by then a new breed of payment systems will be in place which can take maximum benefit. For Eccomerce systems to accept split payments they will need to create Adaptive Payments Gateway as a payment provider however to make maximum use then it will require a change in the way eccomerce systems work.

Ways current Ecommerce Systems could use Adaptive Payments?

So you want to use these right now with Zen Cart or OS commerce and similar? Well with a little work you could get something working, here is how I would implement Adaptive Payments Split Payments to notify 3rd Parties.

Let us assume certain products within your shopping cart require paying 3rd Parties, these are treated as regular products we just store their Product ID for future use along with who we have to pay and what call we need to make.

Assuming your Ecommerce system has flexible gateway system, building an Adaptive Payments gateway is very similar to building any Paypal based API gateway their are a couple of strange authentication changes meaning you will need to send Public Keys in Headers rather then in Post data. To generate the Payment details we would need to look at the Product IDs in the basket and check for third party products. Create a Payment button with the correct data and send the chained or Split Payment with the IPN return set to the cart, on return of the IPN request make additional calls as required to notify the third party suppliers, this is not unusual most carts have the ability to allow such calls after purchase for autoresponders. Of course this does require the third party to accept such calls and have some sort of headless Ecommerce system.

Why Headless Ecommerce Systems are the future of Ecommerce!

A headless system is one with no user interface, so no pretty web pages, rather its designed to be interacted with by web services. Think of them as listeners when data is sent to them they process the data and return if the transaction is completed. When combined with split payments these systems can be used to automate the purchase and delivery of digitial products or order of physical product without the user ever having to go to the companies own web site in effect allowing them to expand beyond their own user base. With Headless Eccomerce Systems a web site procurement program can be added directly into other peoples systems.

Examples

Membership site – A headless Application manages membership to a site allowing site owners to subscribe users to the site, after payment the API generates the user with subscription appropriate to whatever was purchased. The Membership can be integrated directly into the original merchants checkout process as a cross sale.

Printing on Demand API – A headless API which accepts print on demand orders from Publishers who as part of their upsell process offer hard copies of their book, on purchase the Publisher makes a split payment with the royalties going to the Author, Printer and themselves, after payment is complete they call the Printers API to fire off the print job.

This was a quick introduction to what split and chained payments can do as well as introducing the idea of headless ecommerce systems, over the next few weeks and months I plan to show more and more of the ideas as well as more practical examples of usage.