Design Contest
Groupon Clone Script
captcha










  1. PayPal Adaptive Payments – An Open Letter To PayPal

    Peter on January 16th, 2011

    Dear PayPal,

    As one of your long time users and close followers of developments on your x.com developer website we are finding ourselves getting quite frustrated with the way you appear to be treating some of our customers. Most of this mistreatment seems to stem from a lack of understanding of who Agriya are and what they do.

    There has been talk and discussion that since Agriya markets the products as ‘clones’ then it must be copying some aspect of the other site. The word ‘clone’ is used simply as an SEO and marketing term since that’s what people are searching for, and as a business we must go where the market is. It’s certainly not our choice to use the word ‘clone’, but that’s the quickest and easiest way to get the message across to a potential customer what our product does. We actually call our products as platforms and encourage customization to make each website unique, so the customer purchases a base and then makes it work the way they want it.

    The mistreatment of our customers is typified by a recent case where we integrated the excellent PayPal adaptive payments in to a website for a client. The client has been doing business with PayPal for a number of years and the flexibility that PayPal Adaptive Payments provides makes it a game changer amongst online payment processors. However for the last month the client has been unable to launch his site. Why? Because the staff at PayPal refuse to approve his application based on some misguided belief that the code has been taken from elsewhere.

    This lack of understanding about what Agriya does and provides has caused problems for our other clients when you froze the accounts of dozens of people who ran fixed price job portals when you thought they had used the code or infringed the copyright of a major player within the market. Our customers create websites that cater to this market, much like Youtube, Dailymotion and Vimeo cater to the video sharing market – and you wouldn’t say either of these sites are infringing on the copyright of the other, would you? If you can say no to this question why would you have one rule for large sites and another rule for small startups where the owners are trying to earn a living?

    As we mentioned earlier, we love the stuff we can now do with PayPal Adaptive Payments and we want to roll it out to promote this service to all our customers, but when you make it difficult for our customers to use your system we are less inclined to promote this excellent service.

    Agriya is a large 10 year old company with over 200 developers. We have built over 2,000 web applications and have sold in the region of 20,000 products – most of which have some form of PayPal payment gateway integrated. We would love to be able to promote PayPal Adaptive Payments to all of these customers and drive business your way, but when you are causing so many problems to our clients who are trialling the new payment methods then it does make us wonder whether it’s worth the effort of working and innovating with PayPal’s systems in the future.

    So far Agriya has invested a lot of time and effort researching how we can bring more payment features to our platforms and client projects. Some of our achievements include:

    • One of the early adopters of adaptive payment and also promoting it to customers
    • Promoting PayPal’s preauth concept as “PayPal Connect” (till date noone seem to do so, unless PayPal confirm otherwise)
    • Escalated PayPal issues or circumvented through hacks
      • for example, PayPal mass pay doesn’t have option to override IPN
      • Adaptive payment’s App ID could be developer based instead of every installation / instance based
      • Adaptive payment: Sender can’t be set to pay fee with preauth
      • Adaptive payment: Marketplace site can’t be act as a primary receiver in delayed chained payments due to chargeback possibility
      • Adaptive payment: Marketplace site can’t be set as secondary receiver in delayed chained payments as may require API access to refund to another primary receiver.

    When it comes to your PayPal Adaptive Payments and x.com development community it’s going to be the developers and progressive merchants that make it a success, but when you make it so difficult you are only hindering your own growth in this area. Agriya can quite easily recommend alternative merchants such as Authorize.net, PayPoint or Amazon’s new FPS, all of which compete with PayPal in terms of flexibility and features.

    To conclude this open letter, we’d like to say that we want to keep working with and promoting PayPal Adaptive Payments, but this will not be possible unless the relationship is reciprocated and innovative apps developed for our customers are approved by your staff. We even want to go further and be able to help with things like the simplification of the adaptive payment process since we know it so well, assisting with creating a better API focused on the online marketplace industry where payments are sent between users with the site admin acting as a middle man and creating free sample scripts and wizards for other developers to get involved with PayPal Adaptive Payments.

    We hope that you listen and take on board the information presented in this letter and can work to improve the knowledge and understanding of Agriya’s business model and make it easier for our clients to take advantage of the fantastic payment system you are developing.

    Yours sincerely,

    Agriya Custom Projects Team
    FP Platform Development Team
    GroupDeal Development Team
    PeeweePay Development Team

    PS. You have been telling some of our clients that your team are in touch with Agriya. This is not the case as we haven’t heard anything from any representative of PayPal, but we are very eager to talk and discuss any issues you might have so we can put your mind to rest as to what it is we do.

    20th January Update: PayPal have been in touch with us regarding this letter and confirmed that the issue they have is with the use of the word ‘clone’. Their legal department has a very different definition of the word when compared to how we use it within the web development industry. We’ll keep you posted on any updates.

    4th February Update: Last night Agriya had a very successful conference call with the head of the PayPal Adaptive Payments team and the PayPal legal department. They have explained that they are being very cautious over the word ‘clone’ because what ever they decide now will set a precedent on how they will operate in the future. Agriya have been asked to sign a legal indemnity document confirming that all the code is custom developed and not copied from any other site that it ‘clones’. Agriya will have to stand by this legally binding document in a court of law so we must be very sure that all the coding belongs to Agriya or uses licensed technology (such as one of the various Open Source licenses).

    9th February Update: Agriya have signed the legal indemnity document requested by PayPal. It’s been returned to PayPal and the manager for the PayPal Adaptive Payments department has requested that Agriya customers add a comment in their application that they are using an Agriya product.

  1. Why We Don’t Need Google’s WebP

    Peter on October 6th, 2010

    Much cheer, Google has announced yet another open source project that is designed to move the web forward and make browsing a faster, better experience. The new project is called WebP (pronounced “weppy” according to Wikipedia) and it’s designed to be a new image format for the Internet that makes file sizes smaller and thus quicker to download.

    The highlights of this new image format are:

    • Lossy compression (like JPEGs)
    • Uses block prediction to ‘guess’ the missing colours
    • Google claims that WebP can compress a standard JPEG image by 39% and retain the same picture quality
    • Still under development and no browser (or image editing software) currently supports this format
    • Alpha support is planned (enables transparency)

    If you want to see some examples of how much WebP can compress an image without affecting the quality, Google have put up a WebP comparison page here.

    However, feedback from the community hasn’t been particularly great so far with many professional photographers claiming that the new format produces more blurry images, has colour loss and saturation problems. But who knows, since this is an open source project maybe these problems will be fixed before the WebP format is adopted en-masse.

    Now the question that web designers and web developers need to ask ourselves is: Do we really need a new file format? Let’s be fair, if we properly optimized all our images before uploading then speed would be less of a problem. What’s the difference between saving the image as a WebP file if it’s just going to be the same size?

    Another reason why so many people are perplexed about Google’s decision to introduce a new image format is because we already have the perfect alternative to JPEG in the form of JPEG-2000 (.jp2). While this is not very well known about outside the professional photography industry, JPEG-2000 provides superior compression while maintaining a high quality – effectively you can continue to compress a JPEG-2000 image well beyond the point where a normal JPEG image starts to take on a blocky effect.

    JPEG vs JPEG-2000

    So the WebP format claims to be able to offer a 39% compression while maintaining image quality, so in theory a 100kb JPEG could be replaced by a 60kb WebP image. How does that compare to using JPEG-2000 images?

    On the left we have the standard JPEG image and on the right we have the corresponding JPEG-2000 image. Please note that since most browsers still do not support the JPEG-2000 format we have saved the image as a PNG file as this is a lossless format – it preserves the image EXACTLY as it looks as a JPEG-2000 image.


    JPEG File Size: 162 kb


    JPEG-2000 File Size: 166 kb

      


    JPEG File Size: 61.2 kb


    JPEG-2000 File Size: 59.6 kb

      


    JPEG File Size: 48 kb


    JPEG-2000 File Size: 46.9 kb

      


    JPEG File Size: 39.3 kb


    JPEG-2000 File Size: 39.1 kb

    As you can see the lossy compression (which to be fair was designed in the late 80′s!) in the original JPEG images starts to distort very quickly. In technical circles the ‘blocky’ effect you start to see around the edges is known as ‘artifacts’, left over from the sampling algorithm as it tries to remove pixels and guess the colours instead.

    On the other hand the JPEG-2000 images retain much of their quality even when the file size has been compressed by over 75% of the original image!

    We would even argue that the quality of a 30.2kb JPEG-2000 image is virtually the same as the 61.2 kb JPEG image – which is just over 50% compression. What do you think? Can you tell much difference between the two?


    JPEG File Size: 61.2 kb


    JPEG-2000 File Size: 30.2 kb

    Agriya does appreciate the initiative Google is taking to try and get web developers to use images with smaller file sizes, but when we already have the existing technology that can deliver 50% compression with the same image quality, shouldn’t they be focusing their resources on promoting it rather than trying to reinvent the wheel?

    Add your thoughts below…

Related Posts from the Past:

Page optimized by WP Minify WordPress Plugin