Rasmus Lerdorf Talks PHP 5.6, 6.0 and Beyond

Rasmus Lerdorf likes to joke that he’s the most famous programmer from Greenland that we’re likely to meet this month.  Truth is, the creator of PHP is one of the great legends of open source.  The software he created is one of the most widely used technologies for server-side web programming. We were fortunate to catch up with Rasmus at the WePay office, listen to his talk on the present and future of PHP.

His presentation is available here.  It covers PHP 5.5, PHP 5.6 and web deployment.  Rasmus also responded to questions from the audience about PHP 6.0.

The hot topics were performance, security, web deployment, compatibility with different PHP versions, and his perspective on Facebook Hack.


Here’s a sample of the great discussion that Rasmus had with the audience.

Q: Tell us about the direction of PHP, in particular PHP 6.

Rasmus:  First, I want to emphasize that PHP is driven by the needs of developers.  People will present features, including test cases.  If it’s reasonable, then the feature will get into PHP.  It’s not about my wishlist. I don’t have a team of developers. This is a community of developers building PHP for other developers.

Q: But, if you did have a feature wish list, what would you wish for?

Rasmus: If I had a wishlist, I would probably wish to clean up the internal API. It’s gotten a bit nasty over the years. The other thing is of course, performance.  

Q: What about backward compatibility?  I’m worried that PHP might go down the path that Python went down with Python 3 not compatible with Python 2.

Rasmus: We’re not planning a Python type of break. Chances are that anything that breaks in PHP 6 will be features that resulted in pretty hard warnings in PHP 5, which means that it wasn’t in the best interest of the developer to do that in the first place. No drastic changes are planned in PHP 6.

Q: What’s your take on the static code analysis?

Rasmus: Etsy uses static analysis. I would love to see it. The community is hoping to get Facebook to release their static analysis system as a standalone tool. This type of tool would make it much easier to be compatible between PHP 5.x and PHP 6.

Q: Any thoughts on Facebook Hack?

Rasmus: Facebook has done some amazing things. That said, not all of their work is going to be applicable to the entire PHP community. If we’re going to put new features into PHP, it has to be something that is good for the developer, not a special case for a specific company.

WePay’s Terms of Service as it relates to Adult Entertainment

Over the past 48 hours, there have been a flurry of conversations and activities related to the Eden Alexander campaign via our partner GiveForward.  WePay honors the privacy of all our merchants and our intention is not to divulge the intricacies of campaigns but to set the record straight. 

The Facts

The campaign was set up on May 11, 2014 and the money collected through May 14, 2014 has been settled to her bank.  Upon reviewing payments starting May 15, 2014 WePay discovered tweets from others retweeted by Eden Alexander offering adult material in exchange for donations.  This is in direct violation of our terms of service as our back-end processor does not permit it. WePay has worked with other adult entertainers who use our service and abide by our terms of service without any issues.

WePay is extremely empathetic to what Eden Alexander is facing and her hardship is unfathomable.  We are truly sorry that the rules around payment processing are limiting and force us to make tough decisions.

WePay notified GiveForward and the campaign has been shutdown as of May 17, 2014.  Upon further review, WePay suspects Eden may not have been aware of the terms of service and we are offering her the ability to open a new campaign for further fundraising.  We have reached out directly to Eden to help.

Thank you, 


WePay API Documentation Revamp

WePay’s API has always been designed with platforms in mind - marketplaces, crowdfunding sites and small business software providers. In January, with our new Series C funding, we doubled-down and focused solely on platforms and the API. Now our documentation more clearly reflects this focus as well and makes it even easier for platforms to integrate our API.

Step by Step Examples

We’ve provided step-by-step examples for our top platform types to quickly integrate based on their unique needs.

Each of these examples:

  • Explains the overall scenario use case

  • Gives code samples you can copy & paste

  • Gives both the Simple and Advanced integration options

First Look: WePay’s Risk API

Today at the Finovate Spring conference, we’re announcing WePay’s new Veda Risk API publicly for the first time. InvoiceASAP is our demo partner - they’re helping highlight some of the API’s new features.

The new Risk API is an extension of WePay’s longtime risk engine, Veda. For awhile now, Veda has been able to factor in data from a diverse range of sources: how a user behaves on WePay, that user’s “identity footprint” (official business registrations, identity databases, credit reports, etc.), and also that user’s social web footprint (Facebook, LinkedIn, Twitter, etc.).

WePay’s Risk API will now give Veda access to a new data source: custom partner data. Soon any WePay platform partner will be able to pass us risk-related information so that Veda can make better risk decisions.

Product Update: Improving WePay’s Withdrawal Process

Making sure people get paid quickly and efficiently has always been WePay’s first priority. Today we’re announcing a few product changes that should improve that process even further.

Both of the changes outlined below require you to use the latest version of the API. You can implement them whenever you like, and not all changes have to be implemented simultaneously. For more information about WePay’s versioning process, please explore our documentation.