Hello,
There is an issue with I try to save a credit card to a client's account from either the Admin Interface or the Client's Interface having Authorize.net CIM as the Payment Gateway when an Invoice is not Pending.
We use Authorize.net CIM as our Payment Gateway. There's one BIG issue or flaw with how this Gateway works, it requires a Pending Invoice on the client's account in order to create a Profile and generate a Token on Authorize.net CIM.
This is a big problem because not always a client has a pending invoice before the account is established and a credit card is entered on their account for future transactions. For example, sometimes we create the client and all products and services for this client but an invoice is not due immediately therefore an Invoice is not created or due until sometime in the future but the card needs to exist on the account for that future transaction.
After extensive testing, I noticed this should not be a problem to fix or adjust. Currently, WHMCS does create the profile and generated the token on Authorize.net CIM when an Invoice is pending on the client's account. I noticed that WHMCS simply sends a test transaction of $0.00 to Authorize.net CIM as "Authorize Only" transaction (not even Authorize and Capture) which is how WHMCS confirms the card is active and working and in return the client profile is created on Authorize.net CIM and a token generated and transmitted to WHMCS. At this point, WHMCS DOES NOT charge the client for the pending invoice. The pending invoice is actually charged either by manually doing a capture or by waiting for the Cron Job to run that performs the automated credit card transactions.
With this in mind, the notion that a Pending Invoice is required for WHMCS to be able to create a Profile on Authorize.net CIM is basically cancelled. This is because the only thing WHMCS is doing to create the profile and generate a token at Authorize.net CIM is simply sending a test "Authorize Only" $0.00 transaction.
The request is that WHMCS is programmed to perform the SAME "Authorize Only" $0.00 Test Transaction when a card is entered either via the Admin UI or the Client UI even if there's no Pending Invoice and the result should be the same, Profile Created and Token Generated on Authorize.net CIM.
Please find attached an Authorize.net generated email that I receive every time a credit card is entered when an Invoice is Pending on the client's account. Notice how it simply generates a test transaction (not an actual charge), therefore an actual charge is not required (therefore a pending Invoice should not be required either) to create a Profile on Authorize.net CIM and a token generated.
At this point, the only way to add a credit card without a pending invoice is to create a fictitious invoice, add the card then remove the fictitious invoice and this can be done ONLY from the Admin UI. If the client wants to add a card to their account from the client interface without an Invoice being pending, they are not able to.
Finally, one thing also noticed after extensive testing is that if a card is added to the client's account when there's no Pending Invoice, by default WHMCS stores the credit card information on the WHMCS local database, a big security concern. In addition, this information is basically useless because when WHMCS eventually in the future creates an Invoice and attempts to charge this invoice with the credit card information saved (locally), it gives an error "profile not found". Therefore, although the credit card information is saved locally, it does not work anyways because WHMCS looks on Authorize.net CIM for the credit card info and not locally, so this is a lose/lose situation... Security Concern from saving the credit card locally on WHMCS and anyways this info cannot be used by WHMCS because it looks at Authorize.net CIM when attempting to charge and if not there it produces the error "Profile Not found".
I hope this info helps WHMCS Developers come up with a quick solution to fix this bug on WHMCS. My request is to fix this on Authorize.net CIM which is what we use but I assume this same solution could be applied to other Tokenisation gateways if they have the same issue.
Thank you.