"user error: Invalid TxnId" error when hitting 16-char transaction ID limit - consider incrementing ID instead?

Can you tell us why you think there's a connection between the order ID and the failed transaction ID?

Patch attached. Please try this code, and bump your order_id incrementor back up to 10,000 or so to see if the bug gets set off again? As uniqid adds 13chars, you probably only need an order_id >999 to trigger this issue.

I should ask @rjmackay about the use of uniqid in this code, and whether the transaction ID needs to be *unique* or just *unguessable*. I suspect the transaction ID needs to be unique per transaction attempt, and that we need to allow for the chance of multiple transaction attempts per order. Using uniqid here makes it hard to guess the transactionid, but it will be easier to guess once you hit tens of billions of transactions*.

To my mind an incrementing counter would be more useful, because then in the DPS interface we'd see that 4324-1 means this is transaction attempt #1 for order 4324. If we don't actually need it to be unguessable, there's not much advantage in stuffing the transactionID variable with lots of random letters.

* Module users approaching the upper reaches of many billions of transactions are welcome to contact me directly discuss such issues, over some very fine whiskey. My shout.

> To my mind an incrementing counter would be more useful, because then in the DPS interface we'd see that 4324-1 means this is transaction attempt #1 for order > 4324. If we don't actually need it to be unguessable, there's not much advantage in stuffing the transactionID variable with lots of random letters.

I think you're right on that one.
Txn id just needs to be unique, but incrementing it for transaction attempts should be sufficient: http://www.paymentexpress.com/technical_resources/ecommerce_hosted/pxpay...

No idea why I used uniqid() any more. I think merchant reference shows up in the DPS interface which is what I used if I needed to search - but if txnid is available it would be useful to make that readable too.
Sorry - I'm not using DPS or this code anymore so I can't test for you.

Looks like the uniqid came from something like this in pxaccess.inc -

		// $txnId=rand(1,100000);
                $txnId = uniqid("MI");  // You need to generate you own unqiue reference. JZ:2004-08-12

Will commit the substr() workaround for now, and revisit the incrementing ID in this issue "soon".

soon = if someone needs it and re-opens this issue

i like the incrementing id

How soon is now?

I'm having this issue on a site, and despite updating to the March 2012 release of the module, the issue won't go away.

I get to Review Order without problems. I click to go through to payment and it comes back with the "We're sorry...." error. Drupal log reports "Transaction request failed. Order ID: 64. XML:" There's nothing after XML in the log.

I'm technical but not a developer, so am not quite technical enough to troubleshoot this further on my own .... but am willing to be guided....

This module has been working in the past. It's not a busy store that I maintain part-time and I don't know when the issue first arose.

Thanks

David

@millionleaves, could you please confirm a few things?

1. paste a copy of the error message you see
2. installed module version (from modules page)
3. you are using PxPay component, not PxPost or PxAccess
4. check admin - reports - recent log messages (dblog module) for any other clues

#1649722: uniqid generates overlong txnids on some platforms contains a patch for this, as should the current 6.x-1.x and next 7.x-1.x tarballs

@millionleaves, it's been a couple of months since you re-opened this and no reply from you to questions above, so I'm closing this as presumed fixed.