maybe it's because I'm not a native english speaker and don't understand the financial side very well, but I thought they had really pocketed the profits and devalued the company in the way. The fact that they killed one of the products kinda reinforced that notion.
This actually a very exciting development. As a B2B provider of fundraising software for nonprofits, StayClassy (www.stayclassy.org), we do everything we can to put our customers' brands first. This reduces donor confusion, and ends up helping everyone involved be more successful.
Having WePay sunset their consumer-facing products has a similar effect in that it allows us to transact more money through WePay while reducing potential confusion around which services are responsible for which part of the fundraising process.
The WePay team has always been extremely responsive to questions and feature requests, so I'm excited to see what they do with the added resources and renewed focus on partner services.
> we do everything we can to put our customers' brands first. This reduces donor confusion, and ends up helping everyone involved be more successful.
Yup, this is very important: it's one of the reasons why Balanced is 100% white label. We've heard this sentiment echoed over and over again from our customers. They want to own that relationship.
I looked around for a simple pay solution to integrate into my site and chose wepay about a year ago. It was one of the few services where I didn't have to become a "pay API code ninja" to use. I got an email that they will also phase out the easy-to-use buttons.
I want to focus on delivering value to my customers - I'm not trying to become a pay button implementation expert. I'm not very happy about wepay making this move. I think I am going to be switching to stripe.
Hi Keith - I'm sorry the shutdown is disruptive to your business. Discontinuing our direct-to-merchant products was a tough call for us and something we debated intensely.
At the end of the day, unlike Stripe which is building broader payment functionality - we're trying to provide payments for a very focused usecase: platforms (like marketplaces, crowdfunding sites, small business software, etc)
Any product that isn't directly working towards that takes resources away from our platform work. In addition, because it isn't our core focus, it won't be a best-in-class product. That's why we made the tough call to do this.
If there's anything I can do to help make the transition to Stripe or anyone else easier, please let me know - bill@wepay.com Thanks for being a customer.
Agreed, we have a lot of respect for the guys & gals at Stripe. Patrick, John & I were in the same YC batch and we know them well. I think we have different visions - in my words (not theirs), Stripe is looking to build a general-purpose payment API for developers. WePay is trying to build a payment company to serve platforms only.
We believe we can service platforms better by focusing on that usecase. For example, we built Veda, our risk engine the specializes in underwriting the risk of individuals and small businesses using social media. Because of this, we can pay out marketplace sellers faster, collect less data from them (making signup easier), and not hold the marketplace accountable for fraud loss.
I think that platforms are such an interesting segment of ecommerce that they deserve special attention.
If you're looking for payments buttons, Ribbon does that very well and we're about to expand that. Same focus on not requiring you to be a "pay API code ninja" to use.
Drop me an email and I'll tell you more. hany@ribbon.co
I use WePay's invoices for a non-profit that I help run. While they weren't perfect (what is?) they did the job and let me focus on other things. I'm now on the lookout for a simple invoicing platform that supports single and multi-payment invoices and some basic branding capabilities. I might even look at building something on their API or Stripe (would lean towards Stripe as I've used them before but IIRC their fees are a touch higher).
Sad to see these services go, but I can imagine that the support burden of a consumer-facing service is something they'll be glad to be rid of if nothing else.
You might want check out our partner invoiceASAP: www.invoiceASAP.com
Just to be clear, our fees are the same as stripe's - we're not any cheaper. Although I would still encourage you to check out our API for this usecase, as it's right up our alley.
I'm not quite sure what your needs are, but as a consultant, I've used Wave (http://www.waveapps.com/) for invoicing and basic bookkeeping, and it's worked out pretty well.
There's a much larger opportunity in serving other companies who are building specific usecases and need payment functionality, versus trying to be the best at everything yourself.
PayPal uses P2P as a way to get users to link their bank accounts. Then later, when those users are checking out at a merchant, PayPal tries to trick/strongly encourage those users to pay with that linked bank account, instead of a credit card.
The economics are dramatically different - PayPal makes about 3% of the transaction on a bank account funded payment, they make much less than 0.5% on a credit card funded payment.
The fundamental difference with WePay is that we take the risk of loss, so marketplaces don't lose money to fraud. Balanced holds the marketplace liable for chargebacks.
Since they aren't taking the risk, Balanced does offer a greater flexibility around the user experience. We have produce improvements in the works to accomplish our vision of complete flexibility & no risk of loss. We also don't charge for payouts, which can make a significant pricing difference for marketplaces.
Can't wait to see the "complete flexibility" thing show up. Once I don't have to ask my customers to make an extra click to accept payments I'll take a look at your solution again. Until then, we'll stick with Balanced.
Thanks. It's tricky to both take the risk and not have a relationship with the seller, hence why we insist on it right now. If we pushed the risk to the marketplace, it would be trivial - but this isn't something we believe is valuable in the long term.
>Once I don't have to ask my customers to make an extra click to accept payments I'll take a look at your solution again.
You actually can setup users via an API call today (so they can start accepting payments immediately) using our register call. They then have 14 days to confirm their email and set a password. On many sites this improves conversion double digit percentages over alternatives like PayPal.
Used WePay for years. They never fixed several problems with their interface, so now I have followed their link to EventSpot (Constant Contact), but Constant Contact does't even support WePay as a provider. Always feels bleeding edge using WePay.
Bill from WePay here. Sorry you had that experience. EventSpot hasn't gone live with their integration yet, but they will before we shut down our Event tool. We'll do everything we can to make the transition smooth - please let us (or me) know if we can help. support@wepay.com bill@wepay.com
I worked with support on issues, but was told that nothing would be changing. Basically seems that WePay was never committed to explaining things well, or a user interface. This change was certainly explained poorly. EventSpot didn't even know what was happening, though they eventually had someone in the know get back to me.
We actually have two apps with WePay support thus far, and we're in the process of adding it to EventSpot. I assure you, it will be there before WePay's events offering goes offline.
I have to be a bit vague about this, but I think you'll find post-WePay EventSpot to be very comparable to what you're getting from WePay right now.
Thanks. I'm sure that's true, but Constant Contact didn't provide this info to their support folks, and WePay didn't explain this well. Good plans with poor communication don't attract a lot of users or goodwill.
That's a bummer. I thought WePay was trying to be something like a more modern version of PayPal's "add to cart" and "donate" buttons, with additional API features for more advanced setups.
So what's a good way to get an "add to cart" button that you can paste into some html and have customers check out without registering for accounts or seeing too much confusing 3rd party branding?
I already replied to the team with similar sentiments, but I think this is a great move.
Many of their D2C products competed with the businesses that were using their APIs, so it makes sense to pick a channel and focus on just one side of the equation.
I really like everything about WePay other than the fact that it's limited to the US.
It did. I considered it for freelance billing at one time. In fact, I signed up, but for life getting in the way never finished setting it up. Guess I can cross that one off my to-dos!
WePay simply has the best business / API combination out there right now. No monthly fee, sure that is important, but getting your money deposited to your account ASAP is the main value and no amount of tech, no matter how simple does what WePay can accomplish.
Writing some OAuth code is pretty much standard fare amongst the API providers....getting your cash? Now that's a different story.
There's no other API out there that is as transparent or seamless to a business, without the new business disruption of having to wait 1 week (or more) for the cash.
At least among my friends Venmo totally dominates the so-called "direct-to-consumer" payment market. Maybe they just didn't anticipate hitting critical mass in competition.
Venmo is a great product (I use it too! And so does Lucas.)
We originally launched WePay thinking we could build a great P2P experience and charge fees for it. We found that end-users preferred free options like Venmo & PayPal versus paid versions, so we gradually drifted up market in response.
We ended up serving platforms because they aggregate lots of individuals in a context where they expect to pay for payment processing. It leverages our core capability of processing payments for individuals, but it does so in a context where our business model makes sense.
Sad about this. Quite a lot of non-profits and activist organizations use WePay for their campaigns and organizing. It was one of the backbones of local Occupy fundraising in many cities.
The Occupy Movement were some of our earliest customers. Our hope is to continue to serve them through our donation partners (like GoFundMe, Fundly, GiveForward, etc) now.
WePay will still be the same backend, but you'll benefit from our partners' software, which is far better for donations than ours is.
