Free Stripe Payment Gateway with Stripe.js support

[searley]

Me too, it's an excellent module apart from the need to reinstall every time WHMCS is upgraded.

 

Only a couple of parts do.. As the whmcs updates overright the files

 

Create a document with the list of the files that get overwritten, and delete them from the whmcs update before uploading

Simples, will work without hassle

 

This is wise to create an 'update' watch list for thing you need to do before/after an update.. Like and language changes.. Additional whois settings etc

[jclarke]

Can it be added? , even for a cost?..

 

Yes, the Stripe API does allow for sending the credit card number which each transaction so it could be added, you would just need to make sure your server is PCI compliant. If you would like a quote for this, please send an email to support@serverping.net.

[ollybowman]

I seem to be having an issue with this module causing WHMCS to send out Invoice Payment Reminders and Credit Card Payment Failed emails every night when the Cron job is run. Is anyone else having this issue?

[dahamsta]

For the record, I would prefer for development on this plugin to focus on Stripe.JS. There are other plugins available that handle card storage.

[searley]

I seem to be having an issue with this module causing WHMCS to send out Invoice Payment Reminders and Credit Card Payment Failed emails every night when the Cron job is run. Is anyone else having this issue?

 

you would need to check your gateway log to see why the transaction failed.. it could be that the card is declined in which case yes you will get these errors

[linux4me]

I'm currently running WHMCS 5.3.7 and noticed there is a new release, 5.3.8 that came out a couple of days ago.

 

I checked the files for the upgrade patch, and it looks like the only one for the Stripe gateway that it replaces is /templates/orderforms/modern/viewcart.tpl. Is it safe to upgrade WHMCS and use the viewcart.tpl file that came with v. 2.0.0 of the Stripe Payment Gateway or is that going to break something?

[mustardman]

Hi,

 

v5.3.8 has another new /templates/orderforms/cart/viewcart.tpl file

 

Can we keep using the current Stripe Gateway one or will it need to be updated?

[jclarke]

You should continue using the viewcart.tpl we provide, the change WHMCS made to the file just fixes a minor issue with remembering the Security Question selected if the form is submitting incorrectly. We will update our viewcart.tpl with the next release of our module to include this change.

[storm1204]

I had a customer who normally paid with Paypal, we switched to stripe yesterday. When paypal cancelled her subscription, it automatically suspended her even though she'd paid through strip. Is here something I need to erase or change n my clients setup? Maybe deleting the paypal subscription ID-s out so the strip payments can update properly?

[MHDHost]

I liked the fact that this plugin uses stripe.js so I figured I'd give it a try and I installed it.

 

But I just received my second email from a customer who said he was unable to complete his order.

 

It seems the fields Start Date and Issue Number are causing confusion, since their credit cards do not have these details. This is causing customers to abandon their order.

I can only wonder how many others left without taking the time to notify me of the issue.

 

Does anyone know if I can simply remove these two fields from the template and still have the form submit correctly?

[searley]

I liked the fact that this plugin uses stripe.js so I figured I'd give it a try and I installed it.

 

But I just received my second email from a customer who said he was unable to complete his order.

 

It seems the fields Start Date and Issue Number are causing confusion, since their credit cards do not have these details. This is causing customers to abandon their order.

I can only wonder how many others left without taking the time to notify me of the issue.

 

Does anyone know if I can simply remove these two fields from the template and still have the form submit correctly?

 

im guessing you have not replaced the order forms as detailed in the instructions, if you don't then the transactions will fail, I'm sure the stripe gateway does not ask for start date and issue number when installed correctly... go back and re-read and follow the instructions.. then test it for yourself

[visiba]

I liked the fact that this plugin uses stripe.js so I figured I'd give it a try and I installed it.

 

But I just received my second email from a customer who said he was unable to complete his order.

 

It seems the fields Start Date and Issue Number are causing confusion, since their credit cards do not have these details. This is causing customers to abandon their order.

I can only wonder how many others left without taking the time to notify me of the issue.

 

Does anyone know if I can simply remove these two fields from the template and still have the form submit correctly?

General Settings > Invoices > Issue Number/Start Date (Tick to show these fields for credit card payments).

[mustardman]

I am getting the following in my WHMCS logs

 

Smarty Error: unable to read resource: "orderforms/ccforms/"

 

I triple checked permissions of /ccforms directory and files and they are ok. Same as all the other folders and files in orderforms. Everything seems to be working so not sure if this is anything I should be concerned about or not.

[bluehivehost]

I have been using your stripe module addon for WHMCS for sometime now. Today I had a client try to place an order and the error being recorded in the Stripe Log is (NOTE I XXXXXXXXXXX OUT THE SENSITIVE INFO):

 

Parsed Request Query Parameters

 

card:
number: "undefined"
cvc: "undefined"
exp_month: "undefined"
exp_year: "undefined"
name: "XXXXXXXXXXX"
address_line1: "XXXXXXXXXXX"
address_line2: ""
address_city: "XXXXXXXXXXX"
address_state: "XXXXXXXXXXX"
address_zip: "XXXXXXXXXXX"
address_country: "XXXXXXXXXXX"
key: "XXXXXXXXXXX"
callback: "XXXXXXXXXXX"
_method: "POST"

 

Response Body

error:

message: "The 'exp_month' parameter should be an integer (instead, is undefined)."
type: "card_error"
param: "exp_month"
code: "invalid_number"

 

 

We are using a copy of the default WHMCS with just some CSS edits to it. Nothing has been touched in terms on the checkout or order forms. We gladly will pay for support, just not sure where to do so. We need to get this up and running again. We are running 5.3.8 of WHMCS The modules/gateways/stripe.php file doesn't have a version number in it, but says Copyright © 2013, Hosting Playground Inc

 

bluehivehost.com is the domain the WHMCS install is located.

[bluehivehost]

I solved my previous issue by reinstalling the module.

[hosteroven]

I'm interested in giving this a try, but I can't find a concise list of features or supported options (e.g. support for charges, full refunds, partial refunds, etc.). Can anyone point me to a complete feature list? Thanks

[SoftsysHosting]

I have been using your stripe module addon for WHMCS for sometime now. Today I had a client try to place an order and the error being recorded in the Stripe Log is (NOTE I XXXXXXXXXXX OUT THE SENSITIVE INFO):

 

Parsed Request Query Parameters

 

card:
number: "undefined"
cvc: "undefined"
exp_month: "undefined"
exp_year: "undefined"
name: "XXXXXXXXXXX"
address_line1: "XXXXXXXXXXX"
address_line2: ""
address_city: "XXXXXXXXXXX"
address_state: "XXXXXXXXXXX"
address_zip: "XXXXXXXXXXX"
address_country: "XXXXXXXXXXX"
key: "XXXXXXXXXXX"
callback: "XXXXXXXXXXX"
_method: "POST"

 

Response Body

error:

message: "The 'exp_month' parameter should be an integer (instead, is undefined)."
type: "card_error"
param: "exp_month"
code: "invalid_number"

 

 

We are using a copy of the default WHMCS with just some CSS edits to it. Nothing has been touched in terms on the checkout or order forms. We gladly will pay for support, just not sure where to do so. We need to get this up and running again. We are running 5.3.8 of WHMCS The modules/gateways/stripe.php file doesn't have a version number in it, but says Copyright © 2013, Hosting Playground Inc

 

bluehivehost.com is the domain the WHMCS install is located.

 

This is apparently an issue with your ccform. I did find couple of issues whereby the name and id tag were missing for the input boxes which caused similar errors as above.

[MACscr]

Can this be updated to allow users to update their CC info? My apologies if this has already been asked.

[SoftsysHosting]

Can this be updated to allow users to update their CC info? My apologies if this has already been asked.

 

Yes, it does allow customers to update their CC from within WHMCS Manage card option.

[kokyew]

Full featured gateway and just like having your own merchant account.

Edited September 11, 2014 by kokyew
No problem.

[JulesR]

Great module, thanks. Just wanted to provide some public feedback on this. It seems to work very well, and we only ran into a single issue which was down to WHMCS's template cache.

 

If you're receiving an error such as the following:

 

message: "The 'exp_month' parameter should be an integer (instead, is undefined)."

 

Make sure you have, of course, installed the template files correctly. If you're 100% sure they're correctly installed, make sure you empty the template cache within WHMCS. We found some caches were overriding this and causing problems and couldn't find this precaution mentioned anywhere. Emptying the cache fixed this for us.

 

Regarding the module itself, it works perfectly fine. I only have a single gripe and that is that clients do not have the choice to prevent automated/recurring billing. By default this module will store their card details via a Stripe token, and bill them using this card automatically against future invoices. This may not sound like a big deal, but the problem here lies in the fact that *any* card payments made against an invoice will cause their details to be saved for recurring billing automatically. In effect, there is no way for clients to make a *single* card payment using this module without being billed automatically from that point on.

 

There are workarounds to this, such as asking your clients to 'delete' their card after using it (hardly a "fix"). They can also open a ticket and request that you disable the automatic CC processing option in their client profile (again, hardly a "fix").

 

In contrast, by default WHMCS has a tick box where clients can specify that they don't want their card details saved. This option has now been removed by the Stripe module templates. Whilst I understand there may be some limitations with Stripe and because of the way it works card details may have to be saved, I believe there should be an option for clients to request that automatic billing is disabled.

 

When I asked if there were plans for the module developers to add an option for clients to prevent recurring billing, I was told that "It is standard procedure in the hosting industry to automatically charge clients for recurring services.". I respectfully disagree. We've been in business quite a few years, and I've worked for other hosts where this is not "standard procedure" unless the client specifically requests this. Others may operate this way and make it their standard procedure; but we are of the opinion that a client should be able to specify exactly how and when they wish to be billed.

 

Some clients prefer to make manual payments for many different reasons, and forcing recurring billing on them is intrusive. "Stripe" is the only module that forces this, and every other gateway I've seen allows clients to specify that their details are not saved for future use. Again, whilst I understand this may not be possible due to the way Stripe works, there are very useable workarounds, such as adding an option and hooking into the WHMCS API's "disableautocc" option:

 

http://docs.whmcs.com/API:Update_Client

 

This isn't a slight against the developers, I just hope they understand the need for an option such as this. Not everyone operates their business in the same way and surely allowing the client full control over their billing is a good thing?

[JamesOakley]

I think it is a necessity because of the way Stripe works (perhaps Joe could comment on that in more detail). In essence, the card details have to be sent straight to Stripe by a POST direct to the Stripe servers. Back comes a token. You could not store the token in WHMCS, and just use it for a one-off charge, but then the card would still be stored at Stripe, and without a token there'd be no way to delete it. (Unless there was some way that you could (a) obtain the token, then (b) use the token to charge the card for this invoice, then either ©(i) store the token in the database, or ©(ii) use the token one final time to delete the card remotely.

 

Jules, could you elaborate how you could automate card deletion with the hooks? If you've got it working, a slightly more detailed recipe would be helpful.

[JulesR]

I think it is a necessity because of the way Stripe works (perhaps Joe could comment on that in more detail). In essence, the card details have to be sent straight to Stripe by a POST direct to the Stripe servers. Back comes a token. You could not store the token in WHMCS, and just use it for a one-off charge, but then the card would still be stored at Stripe, and without a token there'd be no way to delete it. (Unless there was some way that you could (a) obtain the token, then (b) use the token to charge the card for this invoice, then either ©(i) store the token in the database, or ©(ii) use the token one final time to delete the card remotely.

 

Jules, could you elaborate how you could automate card deletion with the hooks? If you've got it working, a slightly more detailed recipe would be helpful.

Eurgh. Either I didn't explain myself very well or you didn't understand what I wrote

 

I understand it's necessary to store the token, and this is probably forced by the Stripe implementation. That's not my concern or worry with this at all. My concern is, because it operates this way you have to then add/include options that provide the same effective result as the default "Do not store my card details" check-box, even if it doesn't work the same way. By not doing this, you are not giving anyone (particularly end-users/clients) a way of avoiding being billed automatically. Previously they could pay invoices manually using the card, and as long as they checked that option ("Do not save my card details"), they didn't have to worry about being automatically billed. That option is no longer there, so the developers need to look at utilising the other options available to achieve the same result. This is possible by using the Update_Client API to disable CC billing. Sure, the card details are still saved, but they won't be billed - exactly as if they chose not to save their details in the first place.

 

Does that make better sense?

 

I brought this up with the developers and they wanted to charge me - Removed by Request -/hour to build a custom version that includes this. No thanks, this is something that should (imo) be standard. The purpose of me posting in this thread was to get feedback from others on the subject.

 

In regards to automating card deletion, this should be easy via the Update_Client API too. Look for the parameter "clearcreditcard" @ http://docs.whmcs.com/API:Update_Client

Edited September 16, 2014 by Infopro
Modified post by request

[jclarke]

This should really be a feature in WHMCS and not something that comes with our payment module, I would recommend putting in a feature request to WHMCS to add this. The core functionally to disable automatic credit card processing exists on a per client basis within WHMCS but it is not something the client can enable/disable at this time without modification to the client area. If this is something that you or someone else needs, I would be happy to create a module to do this if someone is willing to sponsor the development.

[JulesR]

I give up. I'm disappointed you're pushing the blame elsewhere, and even more disappointed you're requesting "sponsorship" to add a minor option to workaround an issue that your own module introduces.

 

The only positive is that your code is unencrypted. I guess we'll just add this ourselves then.