VendorTxCode not guaranteed to be unique or unpredictable about sagepay HOT 3 CLOSED

Thanks Mark.

It looks like that function has lost some code anyway - it should have the time mS appended to the end. Not how or when that disappeared.

$VendorTxCode = uniqid(date('Ymd-His-'), false);

If openssl_random_pseudo_bytes() is optional in a PHP installation (and it isn't PECL, so far as I can see, so should more-than-not likely be available) then it should have a fallback. If it is something that will always be available in PHP >5.3, then let's just go for it :-)

The makeVendorTxCode() in this package is just an example, and I would hope it would always be overridden. Context may be important to some merchant sites, and not to others. It's often easier when testing, but not so important in production.

I'll give the PR a go over the weekend, but it looks good to me (better than the blatant error that I put in there first, without any random element).

from sagepay.

I must have been having a brainstorm at the time. Of course a random element was added to the transaction ID - that is what uniqid() does.

Anyway, the change looks good to me, and hopefully will be more secure. This takes to the ID up to its max length, which has always been defined as 40 in the metadata, so this should not break any sites that have been assuming that max length could be used. I'll release this on a point release just in case.

https://github.com/academe/SagePay/blob/master/src/Academe/SagePay/Metadata/Transaction.php#L127

from sagepay.

Thank you for the fix.

from sagepay.