| Anonymous | Login | Signup for a new account | 2010-09-08 12:01 CEST | ![]() |
| Main | My View | View Issues | Roadmap | Repositories | Search |
| View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||
| 0000207 | Fusion Ticket | Whole system | public | 2010-07-15 03:11 | 2010-07-29 13:07 | ||||||
| Reporter | chris | ||||||||||
| Priority | urgent | Severity | major | Reproducibility | always | ||||||
| Status | new | Resolution | open | ||||||||
| Product Version | BETA6.2 | ||||||||||
| Target Version | BETA6.3 | Fixed in Version | |||||||||
| Summary | 0000207: [EPH] CBR issues with same payment type multiple times. | ||||||||||
| Description | If you have two handling methods in using google checkout with the same merchat details. i.e. Google + Post Handling_id: 10 Google + Collect Handling_id : 11 When the CBR is generated the cbr=# is the same. Subsequently the decoder grabs the first handling method. And when the ipn from google is recived the Order::LoadOrderFromPayment doenst work as the handling ID will allways be the first cbr method. Thus duplicate cbr handling methods DO NOT WORK! | ||||||||||
| Steps To Reproduce | Create two google handling methods with the same merchant details and try and order with the higher handling id. the order will never be paid for. | ||||||||||
| Additional Information | A fix would be to place the handling id in the ipn url but that is an unprefered way of doing it. Having a fall back method with the LoadOrderPaymentId would be better. Or making Decode Callback notice that there could potentially be more than one handling id under that cbr. | ||||||||||
| Tags | No tags attached. | ||||||||||
| Attached Files | |||||||||||
| MantisBT 1.2.1[^] Copyright © 2000 - 2010 MantisBT Group |