Dwolla Payments module

[MPCReRuN]

I have it all setup the way the instructions describe, however, when I test it out (in live mode) I get the following in red letters on Step 3 of 3 page on the line above the Confirm Order button:

"There was a problem completeing this checkout. Dwolla said: Invalid total."

I have my API key and code in place as well as my Merchant ID. The way I understand it is that the dwolla.php code is calling the server for a request and passing the required parameters in its post to the proper url for dwolla. I have read the documentation here ( https://www.dwolla.com/developers/of...heckoutRequest ). It would appear I am receiving the Failure version of the Response example. Does anyone have any clue as to what would cause the response to not be a success? I am on a linux Godaddy server (cURL is enabled - JSON enabled). However, I do not currently have SSL enabled on the server. Does dwolla require ssl to function? The calls TO them are over ssl, but I do not ssl for callback.

[MPCReRuN]

I figured it out and it is working ... kind of.
The issue was the test I was doing... I was testing it against a product with attributes. However, just having attributes doesn't cause the issue. It's when you select a product attribute that adds to the cost of the item. Only then do I get the message I listed above. I recall seeing a post about this somewhere, but I will have to take a look to see if it was addressed. If I figure out a solution I will post back. If someone else has a solution, please post.
Thanks.

[Limitless]

When I was working with the developer, we ran into another issue after he patched the version I had installed.

It had to do with zencart and rounding of totals. I think it was going out to 3 decimal places, not the 2 that dwolla was expecting.

I think he resubmitted the patch as the updated module, not sure if its available for download yet.


EDIT: It IS available for download and includes both 'fixes':


* Fix for "Invalid Total" errors.
* Fix for the "Dwolla said: Discount cannot be greater than $0" error.

[Limitless]

Limitless,
btw, do you know if the new update addresses the Web Hook Notifications? In other words, where dwolla posts data back to zen cart.

Not sure if it does or not. Now that its 'working', I need to put it through its paces.

[MPCReRuN]

Not sure if it does or not. Now that its 'working', I need to put it through its paces.

I will be your wing man on this lol. I too am a developer (although I mainly work in .NET and J2EE) I am familiar with PHP and all things web dev.

I made a slight change to the previous code (have not pulled the latest yet, but will). The change I made to get around the "Invalid Total" issue was to modify the $item['price'] call so that it pulls the $item['final_price'] instead. The problem I was having was specific to a product getting a price adjustment due to an attribute adding to the product. For example, a product that is listed at say $10 may have two attributes the user can select. Let's say the product is a t-shirt and the attributes are COLOR: values of red, blue, white, purple and the second attribute is SIZE: small, med, lrg, XXL (+$2.50).

So if a user selects the XXL choice, the price for the product is now 12.50, not 10. $item['price'] is pulling the 10 - $item['final_price'] pulls the price with all attributes added (if any).

In my test, this one change got past the Invalid Total issue. To be sure, I then tried adding more than one of any given item to the cart to see how this change would affect the qty vs pricing. No issues were found. However, I have not taken it through to Dwolla yet to see what it presents to me on that side as a consumer. I am waiting on my second account to be completely setup. One for the merchant side, one for the consumer side.

At any rate, these small issues seem to be coming together, and I see a new issue on the order management side of things. In other words, making sure that during the callback from dwolla, the orders table in zen cart is updated so there is an order in the store database to be processed by the store owner/staff. I am digging into this today... but not before I get the new update first! Heck, it may already be in there.

[Limitless]

I will be your wing man on this lol. I too am a developer (although I mainly work in .NET and J2EE) I am familiar with PHP and all things web dev.

I made a slight change to the previous code (have not pulled the latest yet, but will). The change I made to get around the "Invalid Total" issue was to modify the $item['price'] call so that it pulls the $item['final_price'] instead. The problem I was having was specific to a product getting a price adjustment due to an attribute adding to the product. For example, a product that is listed at say $10 may have two attributes the user can select. Let's say the product is a t-shirt and the attributes are COLOR: values of red, blue, white, purple and the second attribute is SIZE: small, med, lrg, XXL (+$2.50).

So if a user selects the XXL choice, the price for the product is now 12.50, not 10. $item['price'] is pulling the 10 - $item['final_price'] pulls the price with all attributes added (if any).

In my test, this one change got past the Invalid Total issue. To be sure, I then tried adding more than one of any given item to the cart to see how this change would affect the qty vs pricing. No issues were found. However, I have not taken it through to Dwolla yet to see what it presents to me on that side as a consumer. I am waiting on my second account to be completely setup. One for the merchant side, one for the consumer side.

At any rate, these small issues seem to be coming together, and I see a new issue on the order management side of things. In other words, making sure that during the callback from dwolla, the orders table in zen cart is updated so there is an order in the store database to be processed by the store owner/staff. I am digging into this today... but not before I get the new update first! Heck, it may already be in there.

Nice.

Are you talking about this part?:


foreach($order->products as $item) {
if($item['qty'] > 0) {
$items[] = array(
'Description' => $item['name'] . ' / Model: ' . ($item['model'] ? $item['model'] : 'N/A'),
'Name' => $item['name'],
'Price' => round($item['price'], 2),
'Quantity' => $item['qty']
);




I do not have attributes yet (waiting for Ceon's Product Variants), so I didn't test that.

Next will be figuring out how give a discount to customers that use dwolla to pay, similar to what was discussed earlier in the thread.


I too am waiting on my consumer account to finish setup to test a full transaction end to end.

When I created my dwolla 'application' I did not set any Callback or Redirect URL's or the Web Hook Notifications.

Any thoughts on what these should be?




As an aside, I found that the dwolla developer (Michael) was incredibly responsive, answered my email in ~4 minutes, determined the problem in like 5 minutes and had the patch in place about a minute later.

When I found the order total issue, he jumped on to the server and resolved that as well.

If this was paypal, I think I would still be waiting for an email response...

[MPCReRuN]

If it was paypal, I am not sure you would EVER get one ha ha ha....

To your questions... Yes, that is the code area I am talking about. I believe you will still have issues with attributes with that code because the TOTAL on the dwolla side appears to be calculated by adding up the product prices and is matched against the actual total we are sending in. When there is a difference between the two - which would be the case if an attribute modified the final_price and applied to our local total, dwolla hiccups. However, if you supply the final_price for each of those items, then the total we send will match the total dwolla calculates because they are derived from the same numbers. I didn't get any issues with rounding, so I am not sure if that was ever an issue here, but it never hurts to properly round ;-).

As for the discounts. I think that is going to be a rather simple implementation. It just depends on if we want to go the extra mile and have it in the admin interface for people to set a physical dollar amount or a percentage. But as for the code itself, it should not be a big deal. I was looking at this part for the discount scenario:

// Round off figures
$total = round($order->info['total'], 2);
$subtotal = round($order->info['subtotal'], 2);
$shipping = round($order->info['shipping_cost'], 2);
$tax = round($order->info['tax'], 2);
$adjustments = round(($total - $subtotal - $tax - $shipping), 2);

// This can be discounts, low order fees, etc
// When the value is negative, it means that
// theres a discount(s) applied.
// When the value is positive, there's a
// fee applied.
$discount = '0.00';

if($adjustments > 0) {
$items[] = array(
'Description' => 'Extra Merchant Fees',
'Name' => 'Fee',
'Price' => $adjustments,
'Quantity' => 1
);
} else {
$discount = $adjustments;
}

$dwollaJson = array(
'key' => MODULE_PAYMENT_DWOLLA_API_KEY,
'secret' => MODULE_PAYMENT_DWOLLA_API_CODE,
'redirect' => zen_href_link(FILENAME_CHECKOUT_PROCESS, 'referer=dwolla', 'SSL'),
'orderId' => zen_session_id(),
'test' => (MODULE_PAYMENT_DWOLLA_SERVER == 'Test') ? 'true' : 'false',
'purchaseOrder' => array(
'destinationId' => MODULE_PAYMENT_DWOLLA_DESTINATION_ID,
'discount' => $discount,
'shipping' => $shipping,
'tax' => $tax,
'total' => $total,
'orderItems' => $items,
'notes' => 'Order from ZenCart. Session Name ' . zen_session_name() . ' / ID #' . zen_session_id()
)
);

I am taking tha $adjustments and $discounts into consideration here. Basically what happens as the code stands is this: Nothing. In other words, if there are no coupons supplied or a hard coded discount then all is well. If a coupon is added to the order before the checkout confirmation, then it will become the "adjustment" due to the math being performed to populate that var. Example, "$adjustments = round(($total - $subtotal - $tax - $shipping), 2);" <--- this is basically subtracting EVERYTHING from the total EXCEPT the coupon (or any other discount) value.... which would leave the value of such left over, and therefore that becomes the "adjustment". $adjustments is then checked to see if it is positive or negative to determine if it is a discount or a charge. If it is a positive (a charge) it is added to the $items array - if it is a negative number(discount or coupon) then it is added the $discount var.

The trick here is to supply a (either fixed or dynamic) number to the $discounts var and be sure in doing so that we allow for the possibility of a coupon also being used.

So... what we need to do is something like this - I have commented what I am doing in the code:

// Round off figures
$total = round($order->info['total'], 2);
$subtotal = round($order->info['subtotal'], 2);
$shipping = round($order->info['shipping_cost'], 2);
$tax = round($order->info['tax'], 2);
//I am adding this piece for a hard coded 3% discount - but it could be from somewhere dynamic

$dwollaDiscount = 0;
$dwollaDiscount = ((.03)*(round($order->info['subtotal'], 2)));

$adjustments = round(($total - $subtotal - $tax - $shipping), 2);

// This can be discounts, low order fees, etc
// When the value is negative, it means that
// theres a discount(s) applied.
// When the value is positive, there's a
// fee applied.

$discount = 0;
//We then set the discount to rep the one derived above as a numeric value
$discount += $dwollaDiscount;
//This remains the same here to make sure there are no FEES being adding or, more likely, a coupon being added
if($adjustments > 0) {
$items[] = array(
'Description' => 'Extra Merchant Fees',
'Name' => 'Fee',
'Price' => $adjustments,
'Quantity' => 1
);
} else {
//Now we need to take into account that a coupon may also be used and add the dwolla discount to the adjustments coupon.
$discount += $adjustments;
}

$dwollaJson = array(
'key' => MODULE_PAYMENT_DWOLLA_API_KEY,
'secret' => MODULE_PAYMENT_DWOLLA_API_CODE,
'redirect' => zen_href_link(FILENAME_CHECKOUT_PROCESS, 'referer=dwolla', 'SSL'),
'orderId' => zen_session_id(),
'test' => (MODULE_PAYMENT_DWOLLA_SERVER == 'Test') ? 'true' : 'false',
'purchaseOrder' => array(
'destinationId' => MODULE_PAYMENT_DWOLLA_DESTINATION_ID,
//This may need a - in front of $discount to ensure it is represented as a negative number... more on that after a test run
'discount' => $discount,
'shipping' => $shipping,
'tax' => $tax,
'total' => $total,
'orderItems' => $items,
'notes' => 'Order from ZenCart. Session Name ' . zen_session_name() . ' / ID #' . zen_session_id()
)
);
Let me know if that was where you were going with that.

[Limitless]

That is exactly where I was going with that!

Looks like you've covered the different possible scenarios, additional coupons, order fees, etc.

Not sure if its necessary to add the discount field to the admin screen, but would probably be helpful.

Doesn't seem too difficult to add a field(s) to the configuration table ie enable discount true/false and an input box for %.


You should package up the 'attribute' final_price /dwolla discount changes and resubmit the module.

[MPCReRuN]

Good stuff - I figured you probably were. And I will submit this once I know for sure it is relatively free of "issues". Now I need to complete the big part, which is getting dwolla and zen communicating in the back-end correctly. I am taking a look at the IPN_HANDLER file for the paypal mod to see if I can scrape some ideas (and er hmm) some code from there for that part. It is imperative that the store stock levels, order management, and everything else that is affected by a purchase in terms of an ORDER is handled correctly. I do not currently see anywhere in the code here that deals with it on the level that the paypal IPN mod does... But for the most part, I think it is just a matter of identifying the cart contents with the order and creating an order in the TABLE_ORDERS. We'll see... it always looks easy at first, right? lol

[MPCReRuN]

That is exactly where I was going with that!

Looks like you've covered the different possible scenarios, additional coupons, order fees, etc.

Not sure if its necessary to add the discount field to the admin screen, but would probably be helpful.

Doesn't seem too difficult to add a field(s) to the configuration table ie enable discount true/false and an input box for %.


You should package up the 'attribute' final_price /dwolla discount changes and resubmit the module.

Limitless,
I have done just that. I uploaded the update a few minutes ago (about 3:45AM EDT). I added the discount feature with instructions to use a % or a hard dollar value. I added the ability to handle price changing attributes... which brought me to another issue! When the order goes over to Dwolla, it only carries the name and a short description (200 chars max). Well what if the store has an attribute for the product? They would not have any information about that in the Dwolla receipt and may not be able to fill the order for the customer without it. Sooooo.... I added code to deal with that, but there still is a 200 char limit on what can be sent, so I am only sending the VALUE of each attribute wrapped in parentheses. I have attached a screen shot of the Dwolla cart to show what I mean.


Anyway, please take a look at the mod and let me know what your thoughts are. I am now working on an IPN handler for this so that the issue I just mentioned wont matter anymore... I.e Dwolla will be able to ping the cart after the completion of the process and the zen cart database will be updated appropriately.

Additionlly, during my testing, I was getting the BLANK page thing that everyone was talking about... however, mine comes up when I try to purchase without enough funds in the account (still waiting on my verification deposits from dwolla) - at any rate, the issue is in the uRL of the page that Dwolla redirects the user to on an error. In my case it SITEDOMAIN/index.php?main_page=checkout_payment&payment_error=dwolla&error_message=Insuffic ient+funds+exist+to+complete+the+transaction. What is interesting is that as I removed chars from the end of the url and finally got the url to read this:
SITEDOMAIN/index.php?main_page=checkout_payment&payment_error=dwolla&error_message=Insuffic ient+funds+exist+to+complete+the+tr <-- notice the letters I removed from the last word in the url.... once those were gone, the page loads up again. Is there a length restriction in zen cart for url arguments? I am looking into this, but any insight would prove helpful.

Cheers