The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.After the 6.x-1.2 update, all payment attempts from my website are met with the following error on the checkout.fi website:
"Error in field/Virhekentässä: STAMP"
Commit aeb4e49 causes this problem: it introduces a new formula for generating the stamp and the new values are too long (21 characters on my side, with a 4-digit order id. 20 chars is the max length checkout.fi accepts).
Comments
Comment #1
demoshane commentedCan confirm this. We cannot accept any more payments via Checkout.fi. Raising priority to critical. This is on Drupal 7 version.
Comment #2
operinko commentedShould be fixed in 6.x-1.5
Comment #3
Neo Mithrandil commentedI'm not convinced by the solution in patch a95aeb3.
I have test suites that generate test payments, reset the website database, and generate test payments again. With the previous version this worked fine. With the new version this will fail with a 1/10 rate, generating a stamp that the server has already seen recently.
I'd prefer to keep something based on order time, and possibly truncate the order id in the formula to make sure there won't be overflows.
Comment #4
operinko commentedNeo: Would you care to share the test suites? Something of that magnitude is rather painful to test without one :)
Comment #5
Neo Mithrandil commentedSorry, what I have in place wouldn't really be usable outside of my website, it relies on various hooks I implemented to modify the interface of both Ubercart and the checkout.fi module.
But it sure isn't rocket science to set up such a test suite. I used Selenium, which allows me to test from a user's point of view and interact with the webpages of Checkout and the bank even though I don't have their source code. The downside is that it runs quite slowly.
Comment #6
operinko commentedOk, can you take a look at a5b5785 (7.x-1.x) or 423cdb5 (6.x-1.x) commits?
I figured that iteration of the stamp generation logic shouldn't trip the 20 character limit on STAMP (atleast, not anytime soon. Should work until 1000000000 orders atleast).
Comment #7
Neo Mithrandil commentedThat should work fine.
I know it won't be needed in practice but I'd consider it good practice to explicitly truncate the order id to 10 chars (keeping the least significant digits), or the whole stamp to 20...
Comment #8
Neo Mithrandil commentedI just updated to version 6.x-1.8, the stamp computation code is still broken.
The problem is now with commit 04f0d03:
Only one argument is passed in the second call to "substr", which is invalid. Also note that the comment is out of sync with the code.
Comment #9
wroxbox commentedThis was the latest stamp generation code that worked:
stamp = variable_get('uc_checkoutfi_merchant_id', 375917) . 'A' . (int) trim($order->order_id);
it was removed in:
http://drupalcode.org/project/uc_checkoutfi.git/commitdiff/aeb4e49dea18c...
took it back and now our checkout process works.
Comment #10
operinko commented@Neo Mithrandil:
Good catch with the substr, don't know how I didn't notice that.
Fixed in -dev now, I believe the last 5 digits of the order ID should be sufficient when combined with the order modified time.
All of that, ofcourse, trimmed to 20 last characters to avoid any issues with too long stamps.
@wroxbox:
The Stamp generation you said to be working has a major flaw in it.
It'll quickly exceed the 20 character limit imposed by Checkout.fi, and the orders will stop working completely.
Comment #11
Neo Mithrandil commentedThanks Olli, version uc_checkoutfi-6.x-1.9 works fine on my side. From my perspective this bug can now be closed.
Still the comment on line 239 doesn't match the stamp generation code (see #8 in this bug). This is of course not critical, but it would be good to fix it in a later commit.
Comment #12
operinko commented