Paymate

Hi

I have been working on getting the Paymate payment module working
At this stage I have been able to send the order to Paymate successfully and also return to the checkout success page after payment

But the order doesn't actually get confirmed in the system

Could someone please point me in the direction of what file/function I should be looking at to fix this?

Thanks
Julie

Could

Great to hear someone is working on this,are you planning on offering it for free / gpl'd? I was planning to write one myself, but if you are going to offer it back to the community at no cost I am more than happy to assist with testing etc.

The best method is to look at how pp_standard.php works, which is located in

<basedir>/catalog/controller/payment/pp_standard.php

It's callback confirms the order (sorry, the quote is breaking/wrapping the pasted code)

if (strcmp($response, 'VERIFIED') == 0) {
$this->model_checkout_order->confirm($order_id,
$this->config->get('pp_standard_order_status_id'));
}

Is this what you are looking for?

Hope it helps.

Still not having any luck Superjuice
The callback just doesn't seem to be working for me
If you want to give it a go I would be happy to send you what I have so far?

jules_nz wrote:Still not having any luck Superjuice
The callback just doesn't seem to be working for me
If you want to give it a go I would be happy to send you what I have so far?

Yeah send it over, are you testing on 1.3.2? I just nuked all the other versions on my dev box

opencart@pixeldrift.net

Will see what I can figure out, haven't played with Paymate much yet so will be a good learning experience for me too.

They have been on the 1.3.0 so far
I dont think there was any changes in these files between the different versions
But I will do a compare and check before I send them

Right, after assisting Jules and getting the post back happening.. I thought after reading all the Paymate docco and seeing how it would assist fellow Aussies I would write a Paymate module myself (before tackling eWay )

It's all basically done. All the code is done, just splitting the language files out and packaging it up.. should have something posted on here/ my site tomorrow.

Supports CC processing for AUD, NZD, USD, EUR and GBP for those interested.

Might send it over to jules for some testing across the ditch too

If you can release it. I'll add it to the core release.

Sounds like a threat!

yes please email me the final version SuperJuice
I finished upgrading to 1.3.2 and have installed the Paymate module as we last had it
But I havent tested it yet
So I will wait till you send over the new files, then I will test it on a live account

I have re-written it completely from scratch (except for some small bits that ship with OpenCart), so will send you the full set of files when I get it finished.

I am pretty close to finished but I am running into a problem that I am not sure how to handle.

Paymate only supports the following currencies:
"AUD","USD","EUR","GBP","NZD"

Now, I attempted to limit the use of the payment method by checking what the currency var was on the payment page, and hiding the Paymate option if the correct currency was not selected, the problem is you can select "AUD" on the payment page, module is shown, then go to final confirmation page and you can change it to an unsupported currency, in my example "XYZ"

Paymate's default behaviour is to fallback to AUD if the currency is not supported. This causes a problem because someone could potentially find a currency that's numerical value is worth less than AUD in the shop, select this currency and then Paymate would process it as AUD.

So then you say "Well, if the currency isn't supported, just convert it into a supported currency". This looks great on paper, and I even wrote code so the module had a "default fallback currency" and you could select from the 5 currencies above for your currency to be converted to if the user's selected currency wasn't supported... here is the problem.

What if the cart administrator doesn't have one of the above 5 currencies registered (yes, I like to take care of all scenarios). Do I fall back to the selected fallback currency (if it exists), if it doesn't exist fallback to AUD and run the risk of someone being paid less than the order value because Paymate defaulted to AUD? Additonally how accurate is the currency conversion in OpenCart if it is static? I think I would rather restrict the user's option than convert as a last resort.

The other alternative is, if the currency is not supported, set the 'action' of the 'Confirm Order' button to go directly to the callback, and then have the callback generate a message along the lines of "Currency not supported". This will work, but it would be nice to tell the user before they submit the order so they can make the change and miss an error screen.

Interested to know people's thoughts on this?

The reality is, the stores that have this module setup will be using the supported currencies but it should be OK. I am just concerned these store may offer other currencies outside the 5 listed and this will cause problems if Paymate is selected.

SuperJuice wrote: The reality is, the stores that have this module setup will be using the supported currencies but it should be OK. I am just concerned these store may offer other currencies outside the 5 listed and this will cause problems if Paymate is selected.

That is your answer. Aim for the "rule" not the "exception".
For my paymate module, I check for NZD, if not, then USD.
I also have a check for those before the payment page loads, so if one of those don't exist, it won't even show paymate as a payment option. I make this clear in the readme. Now I could do a check for all 5 currencies just as easily I suppose... but I've heard no complaints about the module so far, and most people are from NewZealand that use it, making them the rule.

Ahhh.. I prefer to over engineer it.

Here is the solution I decided on.

1. Check if the user is using a supported currency, if they are send it to Paymate
2. Check if OpenCart has been configured with any supported currencies, if it has, convert to a supported currency and send to Paymate
3. If no supported Currency available, forward to Paymate using the order total and fall back to AUD

When you check for currency, how do you stop someone changing the currency in the checkout? which will then potentially send an unsupported currency to Paymate.. and cause it to fall back to AUD anyway? Do you just accept that this can happen?

I removed my checking code at the payment section because it was so easily negated in the order confirmation page I didn't think it was worthwhile.

As for your 'rule' about New Zealand, Paymate is Australian, and I would say the primary user base is Australian too. That is the danger of not accommodating for as many as possible.

Ok,

Just did 5-6 test transactions with real CC in 4 different currencies, and confirmed it is all working.

Was a small problem with urlencode which I cleaned up (Paymate was decoding the postback URL.. which caused pain).

Just boxing it up now ready for wider testing

Ok, all done.

Have tested on a fresh install of 1.3.2.

http://www.pixeldrift.net/opencart/

Grab a copy of it and test if you can. I have now done 10+ real transactions with the module without issue.

If you have any problems or suggestions let me know. I will create a specific thread for it's release once I have confirmed other people can get it working

Hi Sam

Have done some testing

The ref is being passed incorrectly to Paymate
It is coming up as the shop name instead of the order number

The Not Approved correctly went to the page advising the buyer of the failure
But I think it would be best for the Continue button on that page to return the buyer back to the checkout/confirm page to allow the buyer to try and complete the purchase again

When I tried doing an approved purchased It came up with this error message
Error: AUTH LOGIN command failed!

That was after pressing the confirm order button with Paymate

jules, as I mentioned above, I have re-written this module from scratch, the order_id isn't passed in the ref as you were doing it and it is instead encrypted in the postback URL. Ref is only to display information to the user, the Store Name is what is being passed, this is by design.

If you want to display the order number with the Store Name in Paymate checkout you need to set the option 'Display Order Number" to "Yes" in the admin/configuration settings.

The Not Approved "Continue" button re-direct can be changed very easily, for me that is personal preference, but I can direct that back to the cart/payment screen, not an issue.

As for the Approved Purchase

-edit-

Just grep'd the OpenCart source tree and it is an OpenCart error:

system/library/mail.php: exit('Error: AUTH LOGIN command failed!');

This is happening in the mail library, probably attempting to send an email confirmation message. Check your mail configuration and try again, I don't think this is related to the Paymate module as it doesn't interact with mail directly.

Once you have confirmed/fixed your email configuration can you try another approved transaction for me.

Daniel, might want to look at that ^

Some sincere advice for your future in payment module creation to make your life easier. And this is something Daniel could benefit from as well, as paypal suffers from this.

Let the code do the loop, and you can standardize your tpl file.

This is something I noticed with paypal and immediately bugged me.
The controller sets the 'data' variables to be passed to the tpl form
But then the form lists them out one by one.

This means that if you add a new field to the code, you also have to update the tpl file.
Extremely unnecessary.

Instead of doing:

controller:

...........
$this->data['pmt_contact_firstname'] = html_entity_decode($order_info['payment_firstname'], ENT_QUOTES, 'UTF-8');
$this->data['pmt_contact_surname'] = html_entity_decode($order_info['payment_lastname'], ENT_QUOTES, 'UTF-8');
$this->data['pmt_contact_phone'] = $order_info['telephone'];
$this->data['pmt_sender_email'] = $order_info['email'];
...........

view:

<form action="<?php echo $action; ?>" method="get" id="checkout">
<input type="hidden" name="mid" value="<?php echo $mid; ?>" />
<input type="hidden" name="amt" value="<?php echo $amt; ?>" />
<input type="hidden" name="amt_editable" value="N" />
<input type="hidden" name="popup" value="false" />
<input type="hidden" name="currency" value="<?php echo $currency; ?>" />
<input type="hidden" name="ref" value="<?php echo $ref; ?>" />
<input type="hidden" name="pmt_sender_email" value="<?php echo $pmt_sender_email; ?>" />
.......
<input type="hidden" name="return" value="<?php echo $return; ?>" />
</form>

If you simply use an array for all fields and loop them in the tpl. This way any changes are dynamically applied to the tpl and it becomes reusable code for all future modules.

controller: (just add ['fields'] after this->data and before the key

...........
$this->data['fields']['pmt_contact_firstname'] = html_entity_decode($order_info['payment_firstname'], ENT_QUOTES, 'UTF-8');
$this->data['fields']['pmt_contact_surname'] = html_entity_decode($order_info['payment_lastname'], ENT_QUOTES, 'UTF-8');
$this->data['fields']['pmt_contact_phone'] = $order_info['telephone'];
$this->data['fields']['pmt_sender_email'] = $order_info['email'];
...........

view: Now change the view to a simple foreach

<form action="<?php echo $action; ?>" method="post" id="checkout">
<?php foreach ($fields as $key => $value) { ?>
<input type="hidden" name="<?php echo $key; ?>" value="<?php echo $value; ?>" />
<?php } ?>
</form>

(used quote tags instead of code tags so I could use color)

Looks good.

Was following the way PayPal was written to keep it 'standard' across all modules, but agree there is no real reason to have the variables split out as they are in the template.

Although it doesn't change functionality, it will make it nicer to work with in the future, so I will update this in the next version.

Thanks for that.

Hi Sam

Looks like I STMP'd when I should have Mail'd
So that's all fixed and the order went through fine

I changed mine to show the order number and that is much better
Since Paymate emails that information I think its important for it to be included

But everything seems to be working great thanks

jules_nz wrote:I changed mine to show the order number and that is much better
Since Paymate emails that information I think its important for it to be included

The option is there to include it in the admin control panel, that what you are talking about changing? or changing the code?

For others, when this option is set:

Instead of (default)

Your Store

It will show

Your Store (#321)

Good to hear you have it working!