Stripe doesn't like the Published key for WHMCS transactions

[HancoEuropa]

Okay, this one is odd.

We've got the right keys in the right slots with the Stripe Gateway payment method, but Stripe says WHMCS is not sending the right keys. 

Weird.

Did error logging, disabled all custom hooks, looked at all logs ... no clue.   Everything thinks it is working just fine -- except for Stripe, which says

This API call cannot be made with a publishable API key. Please use a secret API key.

Which is kinda nuts, cuz yeah, we checked, we put the right keys in the right boxes (doesn't accept wrong keys anyway in the gateway module). 

Yes, we changed to twenty-one template and tested, made sure we're on 8.4.1 with updated scripts and everything, and no, zero errors in the Console, although a strange [WHMCS] Parse error shows up in the Info messages (probably been there a while).  

Stripe is just dead certain it's being fed the wrong keys, despite the fine art of "copy and paste" being employed by us from their live keys. 

Help!

[bear]

I hope that's not your full secret key showing here in the WHMCs settings, but it doesn't match the start of either of the API key screenshots (standard/restrictive). 

[HancoEuropa]

Hehe no bear, no full secret keys being shown there :))

And I think on the secret there (highlighted in red), they show the "last four" on the screen after an elipsis.   You can see they both start with the "sk_live" moniker.

So yeah, honest, the bits entered in the module ARE indeed identical copy pastes from Stripe.  

We just can't figure out how to "monitor" what is being sent by WHMCS to Stripe to confirm Stripe's assertion that the correct secret key is not being sent.    The PHP files of course are all ioncube in WHMCS that do the work ...

[HancoEuropa]

Nevermind, it's a template issue, we copied over fresh standard_cart and twenty-one from github, transaction went through.

Rebuilding our custom work now figuring out what and why the issue is. 

Thanks!

[HancoEuropa]

Issue -- for anyone who cares -- was competing parsers.    This issue is only likely to affect sites running on multiple language-specific domains (i.e., not the domain specified in General Settings) using WPML in WordPress. 

WHMCS Bridge in WordPress uses its parser.inc.php file, competing with the WHMCS url functions ....  we also use WPML parser on top of WordPress, just to make our lives insanely complicated.    But for multi-language, multi-currency, multi-domain -- gotta have all 4 parsers singing the same tune somehow. 

That "singing the same tune" means ALL parsers need to be "basic" rather than Friendly.   (Yes, despite everyone thinking THEIR parser "should" work fine with Friendly urls).   We did a week of intense testing to figure out what and how would work -- after about 15 dead ends -- finally, the "all-basic" thing worked.

But that means going through and enforcing the "dumbed down" urls everywhere.   For example, the reference to one of Stripe's "/get/payment" type post commands in the js was in the friendly mode ... additionally, the < link reference to the scripts.min.js was also in friendly mode.

Changes to resolve:

1. Add a seemingly superfluous script to includes/head.tpl saying with src="{$root}?ccce=js&ajax=1&js=templates/templatename/js/scripts.min.js"  (in "basic" url parameter=value format).  This allows the non-base WHMCS domains to access that file in a way that Stripe (and clientarea!) can figure out.
2. Change the references in the stripe.js to remove the WHMCS.getRouteURL with plain-text references using basic links.

A strange side effect of all this is that the WHMCS Bridge parser continually tries to substitute the "six" template for the default and set WHMCS template -- but only in the non-English language domains, English with the domain set in General Settings works seamlessly.    For now, we're just copying over the whole default template to six.   So bizarre, but works.   We base all templates on latest Twenty-One template of course.

End of the day, basic urls are the only "lingua franca" that parsers can manage.    One day when we have time, we'll need to write an uber-parser or something I think.

I remember how Brian! chided WHMCS for it's lack of awareness with multi-language sites (we all miss him I'm sure).  

Frankly the version 8 improvements are really fantastic.   For example, Stripe, now working fine in all languages and domains, is a JOY to have on our checkout and invoice payment template pages!

While WHMCS has a lot on it's plate and is doing well on gateways and integrations -- would be nice if they could get a team together to explore real-world, multi-domain, multi-language scenarios.   WordPress isn't going away, and having a native WordPress bridge with a unified cross-origin/cross-domain parser would be brilliant, particularly one that works with WPML or one or two other language plug-ins.

It's just that our issues should be handled by the core functions in WHMCS, rather than tacking together add-ons and plug-ins to cope with the basic business requirement of selling in different languages.  People would pay handsomely for a WHMCS International version with WP front end.   I know we would have. 

Cheers!