Aldryic C'boas
The Pony
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.
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.
