Closed (fixed)
Project:
iDEAL Pro | Ubercart Payment
Version:
6.x-2.4
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Reporter:
Created:
7 Dec 2011 at 15:22 UTC
Updated:
24 Feb 2013 at 21:50 UTC
Jump to comment: Most recent file
Comments
Comment #1
janton commentedor maybe this is a problem with the simulator?
Does somebody else have the same problem?
Comment #2
janton commentedIf i check the order i see:
Order comments:
Date User Notified Status Comment
12/07/2011
4:10:50 PM - Payment received Payment of €7.95 submitted through iDEAL.
Admin comments:
Date User Comment
12/07/2011
4:10:50 PM - iDEAL reported payment of €7.95 from 108429563 (PHP Solutions, Meppel).
12/07/2011
4:10:50 PM - Order created through website.
It says Payment received, but the order status stays iDEAL Pending.
Could this be because the action changes in the ubercart 6x - 2.7
Or is this again something strainge that only my machine has...
Comment #3
janton commentedi think problem is new action changes from ubercart?
Update order status on full payment
>If the order state is in checkout.
>If the order state is post checkout.
Or could this this not cause the problems?
Comment #4
praseodym commentedYes, this is probably the result of changes in Ubercart. I haven't yet have time to investigate further, so you are welcome to send in a patch.
Comment #5
praseodym commentedNot sure what causes this error. The code 'flow' of this module is the same as the uc_paypal module, so unless it has the same problem it must be a problem in Ubercart code or configuration. In my installation, there is a CA 'workflow' that sets status to 'payment received' when the outstanding balance is zero. If this rule fires as expected, payment status should be updated.
Comment #6
janton commentedThey changed the rules because of Paypal (WPS) payment that send IPN after transaction is complete. (that resulted in 2 times sending email checkout complete)
In my CA i see: (the new Ubercart Rules there is this new line called "Conditions group")
Update order status on full payment
Operator:
X AND. If all of these conditions are TRUE.
--Condition: Check the order balance
Title: If the balance is less than or equal to $0.00.
Balance is less than or equal to €0,00.
--Conditions group
Operator:
X OR. If any of these conditions are TRUE.
-Condition: Check the order state
Title: If the order state is in checkout.
Arguments: Order
Order state: In checkout
-Condition: Check the order state
Title: If the order state is post checkout.
Arguments: Order
(*So there is this new group: Conditions group that also need to retun true for one of the conditions.)
I'm not a well developer, but i guess the iDEAL payment doesn't have this order state?
OR there is something wrong with my CA because of the update or other causes...
Comment #7
praseodym commentedThe module has its own order state, ideal_pending, just like the PayPal module. I don't see why the rule shouldn't fire in this case.
Another option would be setting the status to payment_received in the module code instead, but as I said earlier the PayPal module never does this either.
Comment #8
janton commentedpraseodym, i will try to install everything on a fresh drupal install tomorrow. to check if this happends for everyone.
Or do you also have this problem with the new ubercart version?
Comment #9
eduarddrenth commentedWe as well upgraded to ubercart 6.2.7 and also see "ideal pending" never being changed into "Voltooid" (which is dutch for completed)....
Good luck fixing this!
Comment #10
praseodym commentedI'm having the same problem with an installation that was upgraded from earlier versions of Ubercart and using the ING production gateway. It'd be really helpful if you could check if the same problem appears in a clean installation. If it does then I'll go for the 'hardcoded' option and just set it to 'Payment received'.
@eduarddrenth: it shouldn't actually go to 'Voltooid' unless the order consists only of non-shippable items. Otherwise, the right order is iDEAL Pending->Payment received->(Have someone ship the order and manually set to) Completed
Comment #11
eduarddrenth commentedThanks for clarification,
My orders consist of only non-shippable items. Until the upgrade "Voltooid" would be the final status.
In our case this issue doesn't break functionality though
Comment #12
praseodym commentedWell, then it is clearly an issue with Ubercart's Conditional Actions (CA) system. Looks like there is no easy way to debug it, though (no logs or anything).
Comment #13
eduarddrenth commentedIn cases like this I always fall back on xdebug from within netbeans, works like a charm
Comment #14
eduarddrenth commentedIn my case maybe I can adapt this: admin/store/ca/uc_checkout_complete_paid/edit/conditions
Change bestelstatus (order status) from "betaling ontvangen" (payment received) into "ideal pending"
Or perhaps better change here admin/store/settings/orders/edit/workflow from "ideal pending" to "betaling ontvangen"
Comment #15
promesWe also have the same problem after upgrading from ubercart 6x-2.4 to 6x-2.7.
Comment #16
praseodym commentedAh: since 'iDEAL Pending' is actually of type 'Payment received' the rule probably does not fire. I copied this behaviour from the PayPal module, so I'll check again why it does work there. If I'm certain I'll update the module to fix this.
Comment #17
janton commented@praseodym:
did you already find a fix?
Comment #18
dkarso commentedI just notice this bug too and consequently the error report "iDEAL payment status request error: AP2600: 'Transaction does not exist - Field generating error: Transaction does not exist"
Does this module check for payment received on the iDeal server via a cron task?
Comment #19
janton commented"iDEAL payment status request error: AP2600: 'Transaction does not exist - Field generating error: Transaction does not exist"
I don't have that error..
Comment #20
neorg commentedJust subscribing
Comment #21
praseodym commentedThe Google Checkout module also uses the same code flow as this module, and depends on the Ubercart 'core' trigger to set status to 'Payment received'. I can't test if it works there, but since I couldn't find any bugs I think it does. So, no clue why it won't work for us.
Anyway, I've implemented the workaround on a live site and will have to see if it works there.
Comment #22
janton commentedWhat work around are you revering to?
I hope you can fix it, because it would be nice to see all payments go to complete.. because some other modules in my small webshop depend on it.
Comment #23
praseodym commentedGive the attached patch a try and let me know if it works.
Comment #24
janton commentedok i try this patch on a live site.. i will tell how it goes!
Comment #25
janton commentedMy iDEAL payment now say:
PayPal pending
that doesn't seem right?
Comment #26
janton commentedi know there is a panel somewhere that you can say the order from payments.. like pending or completed etc. I'm already looking for a few minutes but i really can't find this.
> Found it:
/admin/store/settings/orders/edit/workflow
But well.. it doesn't make any difference because all look correct there, i will include a picture!
Comment #27
janton commentedCheck here my settings, perhaps something is wrong or different then yours?
http://imageshack.us/photo/my-images/837/1432012221255.png/
*i now changed Payment received Default order status to Payment received
... will check how that goes ;-)
Comment #28
praseodym commentedIt should indeed be 'Payment received', not sure why it was set to 'PayPal pending'. Changing it should solve the issue.
Comment #29
janton commentedYes i can say the "workaround" works well!
Comment #30
janton commentedOk after 3 weeks, this patch is still working perfect!
Comment #31
praseodym commentedGood to hear, I'll apply the patch and release a new version soon.
Comment #32
artbussy commentedHas the new version been released? I still have this problem (should learn how to patch, I guess).
Comment #33
praseodym commentedNo, it is not yet in any release. However, the patch is so simple that you could actually apply it manually by just adding this one line in the correct place.
Comment #34
praseodym commentedFixed in 6.x-2.4.