Current state of vpsBoard 02/04/2017Dear vpsBoard members and guests:
Over the last year or two vpsBoard activity and traffic has dwindled. I have had a change of career and interests, and as such am no longer an active member of the web hosting industry.
Due to time constraints and new interests I no longer wish to continue to maintain vpsBoard. The web site will remain only as an archive to preserve and showcase some of the great material, guides, and industry news that has been generated by members, some of which I remain in contact to this very day and now regard as personal friends.
I want to thank all of our members who helped make vpsBoard the fastest growing industry forum. In it's prime it was an active and ripe source of activity, news, guides and just general off-topic banter and fun.
I wish all members and guests the very best, whether it be with your business or your personal projects.
PayPal is apparently turning into big brother and demanded that Seafile monitor files that customers upload to its hosted Seafile service as a condition for accepting PayPal. SeaFile refused and so PayPal will no longer be an option for Seafile services as of tomorrow June 19.
The big question is will PayPal start demanding that other cloud storage providers like Dropbox and hosted OwnCloud, (or regular webhosts or openstack object storage providers for that matter) monitor their customer's files, or is this an isolated incident where some idiot at PayPal confused SeaCloud, a file storage/sync provider, with file sharing sites like YouTube ?
+1 to Seafile for telling PayPal to go eff themselves.
Caching layer at Steam exposed game subscribers info to other subscribers.
Details here: http://www.dailydot.com/politics/steam-bug-leaks-player-account-information/
When ordering a service and viewing the due invoice, trying to subscribe to recurring payments sends you to a PayPal page to login. Afterwards, you are then sent to a page to input a 2 factor auth code. When clicking, "Send SMS" to retrieve the 6 digit code an error stating, "We're sorry. There's been an intermittent communication problem. Please try again later."
About an hour has passed, and the issue persists. Anyone know whats up?
By Aldryic C'boas
Like many hosts out there, the bulk of our recurring payments come in via PayPal. And like most hosts that sell some of our services at decently low pricing, we've never been a fan of PayPal's fees taking a noticeable chunk out of the incoming payments.
Standard PayPal fees are 2.9% + 0,30$ per transaction. On a 5$ per month service, this amounts to 0,45$ in fees, leaving a 4,55$ income for the service. If you're a respectable sized operation, let's say running 25 nodes with 75 of these 5$ plans each, that means PayPal is taking 843,75$ of your 9375$ income, leaving you with some change over 8500$. Almost 10% of your income gone right off the top, before you even start looking at operating costs.
For those that frequently collect smaller payments via PayPal, they also have a nifty program dubbed Micropayments. It's a different fee rate you can have applied to your account, in which instead of 2,9% + 0,30$, it's 5% + 0,05$ applied to the sale. So for our 5$ per month service, that puts you at 0,30$ in fees rather than 0,45$. And if you're the respectable sized operation we mentioned before, it means your fees on that 9375$ income would only be 562,50$ rather than 843,75$ - an extra ~300$ in your pocket each month. Sounds great! But there's a catch:
Do the math on those two fee structures, and you'll find the cutoff point is 12,00$ exactly. Anything under 12$, and you pay less fees with Micropayment rates. Anything over 12$, and you pay less on the standard fees. Since few providers out there sell solely on the 12$ and under side of things, this means larger sales would take a bigger hit in fees if you switched to Micropayment rates. Unless you had two PayPal accounts - one to receive the 12$+ payments at normal rates, and one for your <12$ payments are Micro rates. Best of both worlds, and better yet this does *not* violate PayPal's TOS regarding holding more than one account per entity. In fact, while speaking with our PayPal rep about holding a second account for the Micro rates, they encouraged us to pursue that course of action.
But then, the catch strikes again. WHMCS supports PayPal, but only a single account. While the more crafty among us could indeed find a way to enable the PayPal gateway multiple times for multiple PayPal accounts (WARNING: I *strongly* advise against attempting to do this, as it leads to a rather nasty vulnerability), there's no sure-fire way to ensure clients would be using the correct one when paying their invoice, and you could end up being worse off than just eating the standard fees alone.
About a year ago, after a ridiculous amount of testing and development, I wrote two scripts to add a 'PayPal Micro' gateway to WHMCS. Superficially, it looks and behaves just like the normal PayPal gateway, except that you're entering two sets of information: Main PayPal Email, Micro Email; Main API creds; Micro API creds (API creds optional, only needed for refunds just like the regular PayPal gateway). Simply displaying as 'PayPal' to clients, the entire process is done behind the scenes and requires no additional scripting or file modification. When a client makes payment over 12$, the gateway pushes the information to your normal PayPal account, where normal fees are processed. When the payment is under 12$, the gateway pushes to the micro-paypal account, where you get to take advantage of the lower fees on smaller payments, reducing your overhead and adding more to your bottom line. Refunds work exactly the same as they do normally: when you press the 'Refund' button in WHMCS (or trigger it via API/etc), the gateway will select the correct PayPal account to push API credentials for, regardless of how much you're actually refunding of the payment. To clarify: a 3$ refund from a 25$ transaction will still be processed properly by the 'Main' account, since that's where the transaction originally happened.
Now, unlike my previous work, I'm not giving this away for free. As I mentioned earlier, a modest sized operation will be saving hundreds of dollars a month - and obviously the more transactions you have, the more you benefit. There won't be any licensing or recurring payments or any of that mess - a simple one-off payment and you receive two Ioncube encoded .php files - one goes into /whmcs/modules/gateways/ and the other into /whmcs/modules/gateways/callback/. If for whatever reason PayPal decides to change up their API or any adjustments are needed to the files, I'll do so and hand out the updates to the folks that already paid at no cost. This is also not theoretical work - we're using the exact same code at BuyVM/BuyShared, and have been for about a year, with no complications. That's also a pretty solid guarantee that if any updates did have to be made, I'd have it done pretty quickly.
This is a fairly unique setup, so I'm not going to put a price tag here. But if you're interested in grabbing a copy, drop me a PM here on VPSB, and we'll work out a fair price.
Does anyone know how to go about reporting transactions received from stolen Paypal accounts? I cant seem to find anywhere (and I don't want to phoneticify over the phone).
Having recognized the pattern I have refunded all the received payments. A certain new hosting company (isnt summer holidays in US over yet?) decided to pay for their services using 5 accounts and 15 transactions via stolen Paypals. Unfortunately Paypal caught a few before me so Paypal will make a bit in fees :(
Anyway figured if its possible I would do the right thing and report them for the sake of the rightful owners.