API Question

[aptohosting]

I am having an issue with the WHMCS API. Currently when I go through the check out process, I am able to get everything filled in correctly, however when I go to submit the order it gives me a "Payment Error" message. The payment is definitely processed through Authorize.net successfully (as I see it in the auth.net control panel), but the transaction doesn't show up as being attempted in WHMCS admin. It is not in shown in the gateway log, nor anywhere else.

 

The invoice # in WHMCS matches the invoice # that is being sent to Authorize.net. However there is still no gateway log, no transactions, no invoice paid. According to your wiki (http://wiki.whmcs.com/API:Capture_Payment) this should be possible and work correctly.

[nuclearglory]

Can you provide the sources you're having trouble with? The peeps will probably want to make sure it's not an input problem of some kind.

 

Given that you're seeing an error page I assume it's not a custom cron system you're running. So... either a custom order process for the end-user or a custom way for you to push invoices through for payment?

[aptohosting]

Will get info from developer

[aptohosting]

Here is the code

 

$api_url = "https://########/accounts/includes/api.php"; # URL to WHMCS API file

$api_username = "########"; # Admin username goes here

$api_password = "*########"; # Admin password goes here

$log_file = 'custom/cart_error_log.txt'; # location of error log for order form

 

#http://wiki.whmcs.com/API:Capture_Payment

function apto_capture_payment($invoiceid,$cvv) {

global $api_url,$api_username,$api_password,$log_file;

 

$postfields["username"] = $api_username;

$postfields["password"] = md5($api_password);

 

$postfields["action"] = "capturepayment";

$postfields["invoiceid"] = $invoiceid;

 

if($cvv!='') {

$postfields["cvv"] = $cvv;

}

 

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, $api_url);

curl_setopt($ch, CURLOPT_POST, 1);

curl_setopt($ch, CURLOPT_TIMEOUT, 100);

curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

curl_setopt($ch, CURLOPT_POSTFIELDS, $postfields);

$data = curl_exec($ch);

curl_close($ch);

 

$data = explode(";",$data);

foreach ($data AS $temp) {

$temp = explode("=",$temp);

$results[$temp[0]] = $temp[1];

}

 

if ($results["result"]=="success") {

# Result was OK!

return 'Payment Accepted';

} else {

# An error occured

return $results;

}

}

 

................

//submit payment

$payment = apto_capture_payment($orderinfo['invoiceid'],$args['cardCVV2']);

if($payment != 'Payment Accepted') {

//if payment fails

file_put_contents($log_file,date('d M Y H:i:s').": ".$payment["message"]."\n", FILE_APPEND|LOCK_EX);

$smartyvalues['error'][] = '<h3>Payment Process</h3><p>The following error occured: '.$payment["message"].'.<br />Please do not resubmit the order. Contact support for further help.</p>';

 

}

....................

and from the custom log:

31 May 2010 13:52:52: Payment Attempt Failed

[nuclearglory]

What's the log file say that the script is adding entries to? Everything looks good, particularly if it's registering in Auth.NET properly. Weird that it's returning a failure (or no?) response though.

 

It is possible that the capture API call only does just that... capture, requiring you to call the other API commands to log the transaction and update the invoice.

 

http://wiki.whmcs.com/API:Add_Transaction

http://wiki.whmcs.com/API:Add_Invoice_Payment

 

I'm not 100% sure on that atm, but that does sound most reasonable if it's not a flaw in the design. Doesn't explain the error (or missing) return code though.

[nuclearglory]

Dumb question but the charge is showing up as "authorized" in Auth.NET right? It's not declining the transaction (meaning your front end is actually working) is it?

[MACscr]

Cant add a transaction without a transaction # since nothing is returned. And by design according to the wiki, nothing is supposed to be returned unless there is an error. Also, its not just authorizing, its doing the actual charge. Even if it was just authorizing, it would be pretty crazy not to have that show up in the gateway log.

[aptohosting]

Correct, it is returning an error message...even though the transaction is 100% valid/successful/captured correctly through authorize.net

[nuclearglory]

Good point!

 

So anything in that log? I would recommend dumping the entire "results" array to the log actually since it's unclear what (if anything) is being returned as-is.

[aptohosting]

Any other ideas???

[MACscr]

Here is the error thats logged when we print out the entire $results array from the api:

 

02 Jun 2010 12:00:38: Array

(

[result] => error

[message] => Payment Attempt Failed

)

 

Obviously worthless. =/

[nuclearglory]

Is the gateway in a testing mode or is it live?

 

If it's testing --- is there a cc-number associated with the client's account? Is the gateway setup to take everything in test mode? And is the number made-up, a valid test number, or a real number?

 

The only thing that seems like it could legitimately freak the system at this point is a problem between the assocation with an invoice and the client account, the data in the invoice, or something with the client account itself (a cc number the script assumes will fail but doesn't in reality).

 

The only other thing that comes to mind is an invalid timeout setting. Something where... the API contacts Auth.NET (which runs the transaction) but the script gets tired of waiting, prematurely ends the connection with Auth.NET, and then returns a useless failure code when in reality the transaction went through.

 

If it's none of those things it would seem very likely it's a problem with the API (or gateway response script) in WHMCS. You guys aren't doing anything fancy like purchasing with a different currency are you?

[MACscr]

The gateway is live, only 1 currency is used (USD), and I have reduced the code all the way to just the api with statically assigned data and we still get the same error. As you can see in this file. I have simplified it as much as possible. Still same results as printed at the bottom:

 

http://pastebin.org/301702

 

I also just double checked that whmcs had the right information to process the invoice, so i manually just did "attempt payment" button within the admin and it worked fine of course.

 

All of this only leads me to believe that its the api at fault.

[MACscr]

I just tried the API on my server as well which runs 4.2.1 versus 4.0.2 on the server above. Anyway, I use a completely different gateway and it failed as well with the same worthless error. According to my gateway logs (at the gateway, not whmcs), it didnt even show an auth attempt.

[nuclearglory]

Definitely sounds like an API problem at this point. I would say to have the staff check the install & implementation so they can examine it (provide them the access details, sample scripts, point them to this thread, etc...). Things will go faster if they have as much info and testing capacity out the gate.

[MACscr]

Why would you think it could be an individual issue when i just pointed out that it happens on two different servers with two different installs and two different versions?

 

Also, we obviously opened up a ticket from the beginning, but they have been less than helpful with this issue. =/

[sparky]

You should notice that the client is sent an email for a failed capture "Credit Card Payment Due".

The reason being is that the CC details needs to be saved in the clients account first before the capture payment will work.

(Add the card details to the clients account and the payment should work)

 

Testing by passing the cc details to the capturepayment api function does not work so as there is not an api call to save the cc details one could be easily written as a workaround.

I believe that this needs fixing in the whmcs core api though.

 

EDIT: The card details can be saved using the "Update Client" api call.

Edited June 3, 2010 by sparky

[nuclearglory]

LOL! Quoting myself from a previous post on this topic...

 

If it's testing --- is there a cc-number associated with the client's account?

 

<faints>

 

Edit: The versions wouldn't have mattered if it had been an API problem that existed across many releases of the software. In which case, the tech team would need as much information as possible to fix the API so they don't have to retest (or rethink) things we've already tested for them.

Edited June 3, 2010 by nuclearglory

[MACscr]

Yes, there is of course already a CC associated with the the client as as i already confirmed numerous times, the credit card is passed just fine to the gateway, whmcs just has ZERO records of it happening and of course the error that is shown. Plus I even double checked the credit card details by manually doing the "attempt payment" method from within whmcs admin and that went through just fine.

 

I have no idea why anyone would think that CC details could be sent to the capturepayment api as it only accepts the cvv and the invoice # as variables, so it would be foolish to think otherwise.

Edited June 3, 2010 by MACscr

[MACscr]

How about this, can anyone confirm that they are using the api function "capturepayment" successfully? If so, what gateway and what version of whmcs? heck, even add your php version.

[MickeP]

Bump! Anyone using this API function successfully? I'm at v4.5.2 and are having the same result as above and I've tried paypal and payson gateways...

 

Since I'm implementing whmcs into my C#/.Net environment, I've built my own customised order form from scratch, communicating solely with the whmcs API. Also, I've built a client area listing the customers' all invoices and I want to to have a "Pay Now" button at each row with a invoice's information in. Can't get it to work at all, hence this thread bump...