Pin Payments Payment Gateway [Support Thread]

Attachment 16452

This is the support thread for the Pin Payments module for ZenCart. Once our plug-in section listing is approved we'll add a link to it from this post, but in the meantime you can download the module here.

Pin Payments is Australia’s first all-in-one multi-currency online payment system, designed to bring the banks’ traditional merchant services up to date with today’s technology. What this means for Australian businesses is they can sign-up to Pin Payments and have everything they need to accept card payments online. No merchant account is required, you can charge customers in all major currencies and an account can be activated same business day.

Learn more about Pin Payments -> https://pin.net.au/

This version of our module supports Token Payments on ZenCart, and results in the credit card data not touching the merchant's website. Card data is encrypted and sent over a secure connection from the card holders device (computer/phone/tablet) directly to the Pin Payments servers. This assists with PCI-DSS compliance for the merchant.

Note: Currently only Australian merchants are able to setup an account with Pin Payments.

Our Zen Cart plug-in can be downloaded here.

We have just started using Pin Payments after using NAB Transact for many years.

So far have been impressed by the system which does appear to be more secure (good for our customers) and quite easy to use (good for us).

However, have just run into a problem which I believe is a bug in the payment module - need it sorted ASAP if possible.

We have had two attempted payments in last couple of days over $1000 which have gone through normally via Zencart but has resulted in an incorrect charge via Pin Payments.

The first charge was for $2510 - zencart order went through correctly but Pin Payments only charged $2.
Second charge was for $1595 - zencart order went through correctly but Pin Payments only charged $1.

At first I though it might have been something to do with the transaction limit - we have had it increased to $2000 from your default $1000 but the second incorrect charge indicates a more general problem with transactions over $1000.

We have had to contact each customer for card details to do a manual transaction - obviously this is a real hassle and not confidence-inspiring in the customer. They have had no indication that anything has gone wrong unless they check their credit card statement. We have had no indication anything has gone wrong unless we log in to Pin Payments admin and see that the charge has been "successful" but obviously incorrect.


Hoping to get some advice on how to fix urgently. WHile some of our larger orders go through via PayPal and Bank Deposit, the credit card system is not working correctly for those customers who prefer to use their card direct. Without any proper error trapping, this is not working for us on these larger orders.

Please advise.

Thank you
Leah (www.aussiesapphire.com.au)

Quote:

---

Originally Posted by chrisdahl

Our Zen Cart plug-in can be downloaded here.

---

First look at this payment mod.

A few observations:

1. Beware that the file new_files/ajax.php overwrites the current version of ajax.php !

2. The mod uses an 'old' way of installing. You have to manually apply the sql patch pin_payments.sql to create 3 new tables for 'pin' and uses CHARSET=latin1 !

The latter should be incorporated into the file /includes/modules/payment/pin.php so the new tables are created once upon new installation from the admin.

The developers of this module may want to take a look at this.

Hi Leah,

Just wanted to let you know we're looking into this for you. Apologies for any delay.

- Chris.

To expand on what Leah is reporting, there needs to be a dashboard option for the transaction limit. If there is any limit on the payment module, it must be hard coded.

Quote:

---

Originally Posted by frank18

1. Beware that the file new_files/ajax.php overwrites the current version of ajax.php !

---

This is the code added to ajax.php (their version is based on a v1.5.4 ajax.php)

Code:

---

// Pin Payments code - process delete pin token
if (isset ($_POST['delPinTokenAct']) && trim($_POST['delPinTokenAct'])=="del" && (int)$_SESSION['customer_id'] > 0) {
    if(isset($_POST['token']) && trim($_POST['token'])!="")
    {
        require_once(DIR_WS_MODULES.'/payment/pin.php');
        $tmp = new pin();
        $tmp->deregisterToken((int)$_SESSION['customer_id'], $_POST['token']);
    }
}

---

You can add this to your ajax.php to reconcile the versions.

Quote:

---

Originally Posted by bbsbcastle

This is the code added to ajax.php (their version is based on a v1.5.4 ajax.php)

Code:

---

// Pin Payments code - process delete pin token
if (isset ($_POST['delPinTokenAct']) && trim($_POST['delPinTokenAct'])=="del" && (int)$_SESSION['customer_id'] > 0) {
    if(isset($_POST['token']) && trim($_POST['token'])!="")
    {
        require_once(DIR_WS_MODULES.'/payment/pin.php');
        $tmp = new pin();
        $tmp->deregisterToken((int)$_SESSION['customer_id'], $_POST['token']);
    }
}

---

You can add this to your ajax.php to reconcile the versions.

---

No question about that, however, their ajax.php version should reside in the folder modified_core_files and not in the folder new_files.

@ Leah: quick fix would be to modify your includes/modules/payment/pin.php and find line 451:

Code:

---

'x_amount' => number_format($order->info['total'], 2),

---

replace with

Code:

---

'x_amount' => number_format($order->info['total'], 2, '.', ''),

---

Other observations are noted and will be fixed in the next release. Thank you!

Quote:

---

Originally Posted by balihr

@ Leah: quick fix would be to modify your includes/modules/payment/pin.php and find line 451:
Other observations are noted and will be fixed in the next release. Thank you!

---

Thank you for the response and fix. We're testing that now.

Quote:

---

Originally Posted by frank18

No question about that, however, their ajax.php version should reside in the folder modified_core_files and not in the folder new_files.

---

Agreed as to install file placement. I took it as making more of a general point regarding the ajax.php, and thought the edits needed might help someone else.

Quote:

---

Originally Posted by bbsbcastle

Agreed as to install file placement. I took it as making more of a general point regarding the ajax.php, and thought the edits needed might help someone else.

---

It's all fixed now. Install was moved over to the module file, and ajax.php was moved to modified_files respecting version differences. Chris will be submitting an update shortly.

Quote:

---

Originally Posted by balihr

It's all fixed now. Install was moved over to the module file, and ajax.php was moved to modified_files respecting version differences. Chris will be submitting an update shortly.

---

OK - thank you.

Bill has added this edit for me and we are hopefully back in action. Please note though that this is a fairly basic error that I am having to pay to get fixed - not sure why something simple like an order total not being transferred correctly made it into a final version?? Not everyone using zencart is selling $20 items - some of us actually do business in larger amounts.

Can you confirm that Pin Payments will now correctly charge any order over $1000 as per the zencart recorded total?
Can you confirm that you will be adding a transaction limit in future version of the module so that the limit imposed by Pin Payments will be handled correctly by the module?
Can you confirm that there will be some attention paid to the way errors are handled - we were left in the dark on this one with no error reporting at all.

I will have to test on our end but due to the way Pin Payments handles refunds, I have to charge something over $5k (our new transaction limit) and then wait a couple days (or more) for the refund to land back in our account plus the refund is taken immediately from our incoming credit card payments. Not ideal.

I do appreciate the relatively fast advice for this module bug though - thank you.

Leah
(Aussie Sapphire)

Quote:

---

Originally Posted by aussiesapphire

Bill has added this edit for me and we are hopefully back in action. Please note though that this is a fairly basic error that I am having to pay to get fixed - not sure why something simple like an order total not being transferred correctly made it into a final version?? Not everyone using zencart is selling $20 items - some of us actually do business in larger amounts.

---

Yeah, unfortunately, a very basic error. As the person who built this plugin for Pin, I sincerely apologize for the oversight. We were concentrated on security and simplicity of use and just missed to test transactions over $1k. A stupid oversight, I admit and, again, apologize.
As for having to pay to get fixed - I'm not sure how to comment on that. But, I would love to know how much Bill charged for 54 seconds of his time spent to connect to your server, navigate to a file and replace one line of code I had provided... No need for you to answer that...

Quote:

---

Originally Posted by aussiesapphire

Can you confirm that Pin Payments will now correctly charge any order over $1000 as per the zencart recorded total?

---

I have done quite some testing and all orders went through just fine, with correct totals being charged. You can see a fraction of my tests here:

https://s6.postimg.org/jveawjhkx/2016_11_09_215808.png

Quote:

---

Originally Posted by aussiesapphire

Can you confirm that you will be adding a transaction limit in future version of the module so that the limit imposed by Pin Payments will be handled correctly by the module?

---

We'll look into it.

Quote:

---

Originally Posted by aussiesapphire

Can you confirm that there will be some attention paid to the way errors are handled - we were left in the dark on this one with no error reporting at all.

---

Unfortunately, no. Technically speaking, this was not an error, but a miscommunication between the plugin and the Pin server. Neither Pin nor Zen Cart could tell it was an error so it wasn't flagged on either end. It's like the "6 or 9 point of view"...

Quote:

---

Originally Posted by aussiesapphire

I will have to test on our end but due to the way Pin Payments handles refunds, I have to charge something over $5k (our new transaction limit) and then wait a couple days (or more) for the refund to land back in our account plus the refund is taken immediately from our incoming credit card payments. Not ideal.

---

You know the module CAN be switched to Test mode, right? :smile: No need to place a real transaction, switching Transaction Mode to Test works exactly the same as Live, with the difference being in cards used. You can PM me for more details if you want.

Quote:

---

Originally Posted by balihr

Yeah, unfortunately, a very basic error. As the person who built this plugin for Pin, I sincerely apologize for the oversight. We were concentrated on security and simplicity of use and just missed to test transactions over $1k. A stupid oversight, I admit and, again, apologize.
As for having to pay to get fixed - I'm not sure how to comment on that. But, I would love to know how much Bill charged for 54 seconds of his time spent to connect to your server, navigate to a file and replace one line of code I had provided... No need for you to answer that...


I have done quite some testing and all orders went through just fine, with correct totals being charged. You can see a fraction of my tests here:

We'll look into it.


Unfortunately, no. Technically speaking, this was not an error, but a miscommunication between the plugin and the Pin server. Neither Pin nor Zen Cart could tell it was an error so it wasn't flagged on either end. It's like the "6 or 9 point of view"...


You know the module CAN be switched to Test mode, right? :smile: No need to place a real transaction, switching Transaction Mode to Test works exactly the same as Live, with the difference being in cards used. You can PM me for more details if you want.

---

I strongly considered not responding, but I felt some points needed to be addressed.

Any time billed would not be related to the time to put in your edit, but time spent trying to find and verify the non-existent logging and transaction tracking, testing your edit to see if it broke the site, etc. Since you state you "built this for Pin", I assume they compensated you for your time. If you simply mean you modified the authorize.net module to work with Pin as volunteer work, I understand and applaud your efforts.

The function "javascript_validation" in pin.php would be a good place to insert testing of the transaction limit.

Since the "Log file" and "Log and email" settings are of higher precedence, it would normally appear they provide a higher level of logging. That is, one would expect some level of logging beyond "Alerts only" when the module is set to a higher level.

Test transactions would not have detected the issue, since "this was not an error". You can only tell it's happened by looking at the amount that was charged by Pin. That doesn't happen in test mode, so technically we don't really know if it's fixed until someone makes a charge over their new $5,000 limit. It has made test mode charges without breaking on the user or admin side. It's also made live charges under the limit, but that doesn't really confirm it.

Oh, YOU are Bill - wasn't paying much attention. :smile: Okay, I didn't realize "Bill" was someone who was actually involved in the process - thought it was their developer whom they contacted to implement the given solution. Sorry if I said something wrong, but then again - you charged for time you spent without actually providing a solution? I never could understand people who charge for time spent and their own learning curve, but with no end result. I mean, if I don't know something and spend 3 weeks learning and exploring and deliver NOTHING, am I still supposed to charge the client? Some people do that, some don't - if that happens to me (and it has), I choose to bite the bullet and move on. But, this is not the place to discuss this so let's just bury the hatchet and move on.

Test transactions that were sent to Pin with the old bad line of code were showing up in the dashboard as $1 charge (or $2, depending on first digit of order total). Therefore, that's what Pin would've charged. Currently, correct amounts show up in the dashboard. You're absolutely right we can not be 100% sure without a real live transaction, but there's no reason for dashboard to show $1500 and customer's card is charged with $1. And, even if it does happen, who do you think will have to compensate for the loss (hint: dashboard says you have $1500 in your account).

Re: transaction limit - I won't go into that since I'm not authorized for it at the moment. If you have a solution, you're more than welcome to implement it for your client. And, if you want, share with the rest of the community.

Quote:

---

Originally Posted by balihr

Yeah, unfortunately, a very basic error. As the person who built this plugin for Pin, I sincerely apologize for the oversight. We were concentrated on security and simplicity of use and just missed to test transactions over $1k. A stupid oversight, I admit and, again, apologize.
As for having to pay to get fixed - I'm not sure how to comment on that. But, I would love to know how much Bill charged for 54 seconds of his time spent to connect to your server, navigate to a file and replace one line of code I had provided... No need for you to answer that...

---

We appreciate the advice re correcting this module but quite frankly, I am a bit cheesed at your attitude re the above comment.

As Bill points out, his time involved more than the "45 seconds" required to add your edit which hopefully will resolve all the issues. Time that I have to pay for and am happy to do so as Bill has been very helpful on a number of issues (and very reasonable re cost) - but I do reserve the right to feel a bit cheesed off that a pretty basic error was allowed through in the first place.

When we reported the issue to Pin Payments, they said to send the logs - I then asked my developer to do this and try and track down the problem. This was before I posted here and got your response. I expect it to be more than 45 seconds of work.

Now that we know you are supporting this module, I will refer to you in the first instance next time there is a problem.

Leah

Again, my apologies - as I mentioned earlier, I was not aware Bill was involved in the process of debugging.

As for the basic error that slipped through - I'm not trying to excuse myself, but you do know that the most basic errors slip through most often? And it happens to Microsoft, Facebook, Twitter, Mercedes, Toyota, Samsung, Apple etc. Heck, even Pentagon... No software is perfect, no developer is perfect. We all make mistakes and I'm the first to admit it, but at the same time do my best to rectify and fix it. So, please understand that "how could this happen to you" statement doesn't help, especially not with a "use at your own risk" plugin...

Once again, I sincerely apologize for both letting the bug slip through as well as my comment re: Bill - I do appreciate his efforts to resolve the issue. :cheers:

I will do my best to support this plugin although I'm in no way obligated to do that - it's voluntary and based on my personal decision to support the work I've done. I'm NOT a member of Pin, nor am I affiliated. So, if there are any bugs in the future (and I really hope there won't be any), please post here in the forums - I'm subscribed to the thread and will do everything I can to help.

Anyway. I didn't mean to set off a flame war. That's why I had a hard time deciding to respond.

I should not have made any comment as to time, since my point was to discuss the open issues in the module. However, you do not know me, and Leah is assuming I will be charging because they have asked me to. They know we recently spent many hours working an issue with another payment module and charged for less than a quarter of that time. We don't bill for time that doesn't lead to results. Next time, don't ask me to bury a hatchet after you've been hitting me with it. So yes, it would be time to drop these side issues.

I'm not seeing a dashboard that shows an amount for test transactions. Where would we find that?

I get this is a beta adaptation. That's why we've been proceeding slowly and trying to keep everything tested ahead. We thought we had it set for extreme logging. We should have tested more for that.

As to anything we implemented on charge limits, would that be incorporated since it sounds like Pin controls this module?

Quote:

---

Originally Posted by bbsbcastle

I'm not seeing a dashboard that shows an amount for test transactions. Where would we find that?

---

It's the merchant dashboard, Leah must have access.

Quote:

---

Originally Posted by bbsbcastle

As to anything we implemented on charge limits, would that be incorporated since it sounds like Pin controls this module?

---

This part I don't understand. This is an open source module - you can make any changes you want, these checks would run on client side anyways.
For example, you can add your own logic to disable this payment option for certain products, or disable it for payments from, IDK, first time customers... So, what's stopping you from putting an

Code:

---

if($_SESSION['cart']->show_total() > 5000) $this->enabled = false;

---

on let's say line 78... :wink2:

And, as with all plugins here, you're most welcome to post your (better) solution for the community, and if anyone else decides to implement it, nobody can stop them. That's the whole idea with the community contributed plugins here...

Quote:

---

Originally Posted by balihr

It's the merchant dashboard, Leah must have access.

---

Ok. I found the "Test/Live" toggle button on the top of the payments page. I was looking on the sides for a separate page. Pin did reject an order that was over the limit with an error message to the user.

Quote:

---

Originally Posted by balihr

This part I don't understand. This is an open source module - you can make any changes you want, these checks would run on client side anyways.
For example, you can add your own logic to disable this payment option for certain products, or disable it for payments from, IDK, first time customers... So, what's stopping you from putting an

Code:

---

if($_SESSION['cart']->show_total() > 5000) $this->enabled = false;

---

on let's say line 78... :wink2:

And, as with all plugins here, you're most welcome to post your (better) solution for the community, and if anyone else decides to implement it, nobody can stop them. That's the whole idea with the community contributed plugins here...

---

Since you'd said something about not being authorized to make some change, I took it that you were working for Pin under contract. As such, I also assumed you would prefer to have enhanced control over the module versions. If I implemented something to make an admin setting for the limit, etc (I hate hard coding things like that), I didn't want to bump into your efforts.

Quote:

---

Originally Posted by bbsbcastle

Since you'd said something about not being authorized to make some change, I took it that you were working for Pin under contract. As such, I also assumed you would prefer to have enhanced control over the module versions. If I implemented something to make an admin setting for the limit, etc (I hate hard coding things like that), I didn't want to bump into your efforts.

---

Yeah, well... Although anyone can submit updated versions of the plugin, I'd prefer being authorized by Pin so I won't be submitting any updates without their consent.

If you implement your solution and modify the plugin's code, IMHO, you just risk your changes being overwritten when/if a new version is released. Of course, unless you merge it with the new version. But, if the payment over limit was rejected with a friendly message, is there really any need to add custom logic and modify the original code?

Hi,
Installed pin payments on zen v1.5.4. Worked great for Australian dollar orders which is my default currency. However when someone used the USD multi-currency, the invoice and the order I received was ok in USD. But the amount that pin payment received from zencart was the USD amount/ (the currency rate) I had set in the zen cart. So on a order of USD$197.04, which was correct in the order confirmation and invoice, pin payment charged USD$197.04 / (exchange rate), making the total charged USD$50.65 too much. eg USD$247.69. Like it was dividing it twice. If you could point me in the right direction to correct this calculation error would be appreciated.

I believe this is due to lines 499-505 which force currency conversion, but these lines should trigger only if the order currency is NOT one of the supported ones... Since USD is on the list of supported currencies, this conversion wasn't supposed to happen.

Since I'm intrigued by this, you're welcome to PM me and if you agree, I'd like to try and debug it on your site, and will then report back here.

balihr,
Thanks send me your email details so I can send access so when fixed can you can add solution to thread. [email protected]

We've just submitted an updated version (1.1.3) that addresses this, and should be available soon on the official download page.

Thanks for the feedback.

Hi there, This looks like a very interesting plugin. Thanks, Chris and other contributors, for doing the hard work. Has anyone tried this with the One-Page Checkout plugin? If not, I'll try it myself & report back.
Cheers...Gerri